Re: [homenet] Why configuration and routing are separate
On Sat, Jul 23, 2016 at 8:30 AM, Mikael Abrahamsson wrote: > On Sat, 23 Jul 2016, Juliusz Chroboczek wrote: > >> Please let me know if you're still unconvinced. I love arguing. > > Well, in my testing I got the feeling (hard to tell since it was really hard > to get a comprehensive picture of what was going on over time), that > sometimes HNCP lost its connection to other HNCP nodes on the lan, while > babel was still working, and the other way around, babel went down and HNCP > was up. I wonder if HNCP could have a local "port" where a routing protocol could deliver the information that a certain linklocal neighbor address is still reachable. HNCP would still do its own neighbor detection, but it could take advantage of the (regularly happening) checks of the links of the routing. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [manet] Manet address assignment
Hi, on the other side a well designed routing protocol does not need much (or any) node-specific configuration... and any mesh-wide configuration could easily deployed by the gateway inside a DNCP/HNCP TLV. Henning Rogge On Sat, Jul 23, 2016 at 1:17 AM, Juliusz Chroboczek wrote: > This message is being sent to the manet mailing list, with homenet in CC. > > I took to the microphone during this week's manet meeting to remind people > that Homenet has designed HNCP (RFC 7788), a protocol for autonomous > configuration of multilink home networks, and that it would be a terrible > missed opportunity if a protocol for manet autoconfiguration were standardised > that did not interoperate with HNCP. > > We at Babel Towers are currently experimenting with HNCP in a small mesh > network. The results are encouraging: up to some minor bugs in the > current implementation, HNCP is able to configure a (non-mobile) mesh > network with no operator intervention. We are planning to spend some time > working on shncpd, our implementation of HNCP, until it is able to work > well in our mesh network: > > - change the link sensing mechanism to work better on persistently lossy > links; > - add the ability to configure just a single /128 on loopback (shncpd is > already able to configure a /128 on each interface, which is useful > for mesh networks but out-of-spec -- HNCP requires a /64). > > If this works out, the plan is then to implement an HNCP protocol > extension that allows it to scale better in large and mobile mesh > networks; this will necessarily involve some tradeoffs, such as being > restricted to allocating /128. I'll let you know more when I have code to > show. > > Note that HNCP only does address configuration and naming; it does not > negotiate routing protocol parameters nor provide monitoring facilities. > Thus, it is not a complete solution for a MANET management protocol, and > I believe it does not conflict with the management work being done within > MANET. > > Regards, > > -- Juliusz > > ___ > manet mailing list > ma...@ietf.org > https://www.ietf.org/mailman/listinfo/manet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: interaction with routing protocol?
On Wed, Dec 16, 2015 at 6:31 PM, Juliusz Chroboczek wrote: >> hnetd does address configuration on interfaces, the routing protocol picks >> this up because that's how it's configured...? Hnetd doesn't communicate >> directly with the routing protocol at all, right? It just sets up the >> landscape so the routing protocol can come and survey it and communicate >> the contents. > > That's exactly right (and very well put). That's what I tried to express > in my talk at Prague -- it turns out that HNCP is a very clean design. > (Except where it isn't, of course.) > > Hnetd and shncpd do that somewhat differently. Hnetd assume that the > routing protocol redistributes everything. Shncpd has closer binding to > the routing protocol, it marks its routes as "proto 43" and expects the > routing protocol to redistribute just that; shncpd also occasionally > inserts dummy "proto 43" routes into the kernel, just so that they get > redistributed into the routing protocol. The result is that shncpd > produces somewhat cleaner (more aggregated) routing tables, at the cost of > requiring special configuration of the routing protocol. Just redistributing protocol 43 will also make you miss the default route you get by DHCP from an uplink. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
On Thu, Nov 26, 2015 at 5:49 PM, Juliusz Chroboczek wrote: >> Hmm. I've also setup many small PKIs and don't agree. I do think someone >> could easily make all that quite usable within the home. > > Have you ever walked a non-specialist through the process? I wonder why this could not be fully automatic? Setup a "press button for first login" system similar to WPS for Wifi that deploys the certificate. No need for the user to do something complicated. Henning ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
On Wed, Nov 18, 2015 at 4:46 PM, Ted Lemon wrote: > Wednesday, Nov 18, 2015 9:20 AM Steven Barth wrote: >> The basic idea behind the SHOULD is that there may be cases where either >> physical security of links (e.g. cables) can be ensured or link-layer >> security such as WPA for WiFi is present. In these cases (e.g. some sort >> homenet wifi repeater) the DTLS would be redundant. > > WPA2, at least in PSK mode, does not provide confidentiality from attackers > who have the PSK. WPA isn't even as good as WPA2. I think relying on this > level of security makes sense if we have no alternative, but in no other case. I don't think DTLS with PSK is much better than WPA2 with PSK... Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISIS wifi testing
On Fri, Oct 23, 2015 at 6:05 PM, Dave Taht wrote: > Except! that there is a bug in sensing the actual channel in babel on > some radios, when last I looked. (the linux api for detecting it > changed) The nl80211 API changed? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] How many people have installed the homenet code?
On 10/22/2015 11:25 AM, Juliusz Chroboczek wrote: SHNCPD is good for a few first tests, but it only contains a subset of the useful HomeNet features. Huh? What useful features are missing? What is about the interaction of SHNCPD with (M)DNS? Can I add the hybrid-proxy and expect it to work? (Yes, I've got your patches, just too busy right now.) Good to hear. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] How many people have installed the homenet code?
Hi, is there already someone who has installed the HNetD software (plus is dependencies) on a normal Debian/Fedora Linux distribution? SHNCPD is good for a few first tests, but it only contains a subset of the useful HomeNet features. Henning Rogge On Thu, Oct 22, 2015 at 9:52 AM, Gabriel Kerneis wrote: > On Thu, Oct 22, 2015 at 8:43 AM, Tore Anderson wrote: >> >> In any case, this might be of help to whoever wants to be #9: >> >> http://blog.toreanderson.no/2015/10/11/making-a-homenet-router-out-of-openwrt.html > > > Already mentioned on this list, I believe, but another tutorial is available > at http://www.pps.univ-paris-diderot.fr/~jch/software/homenet/ > > Best, > Gabriel > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] How many people have installed the homenet code?
On Wed, Oct 21, 2015 at 5:10 PM, Dave Taht wrote: > is it up from 8? > > Dave Täht I did experiments in the CORE network emulator with shncpd... not sure if this counts. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dynamic metrics in IS-IS
On Wed, Sep 30, 2015 at 1:13 PM, Juliusz Chroboczek wrote: >> a valid test of the metric setting features would be to have two wifi >> networks, one 2.4GHz, one 5Ghz, two different L2s, different IP >> networks, and then walk around with two clients connected together with >> a network cable, and check if the routing would change from the 5GHz >> network to the 2.4GHz network as distance from the AP increases and the >> 5GHz network stops working. > > That would be an interesting test if you can show that Christian's code > works better in this case than plain IS-IS and not much worse than > a recent babeld. Both in an unloaded network and under load (10Mbit/s > constant-rate UDP is what I like to test against, but some people think > that TCP is more realistic). The Wifi stress testing script Dave Taht brought to the Battlemesh V8 might also be interesting for this... 10 Mbit/s UDP traffic will be really tame on a modern wifi. Even multihop 100 Mbit/s could not dent or test mesh on the Battlemesh V8. http://docs.battlemesh.org/v8/3-blowing-up-the-network.html#test Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dynamic metrics in IS-IS [was: Info about IS-IS demo from Bits N Bites Prague]
On Wed, Sep 30, 2015 at 12:20 PM, Mikael Abrahamsson wrote: > On Wed, 30 Sep 2015, Juliusz Chroboczek wrote: > >> Please check the Babel web page, which links to a number of papers and >> draft papers that contain both experimental and simulation data. > > > Are you referring to > http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find 4 papers, > two have broken links, one is for ad hoc networks, and another one is > multi-hop mesh protocols. > > It's not obvious to me that homenet is an ad-hoc mesh network, at least > according to the wikipedia page. I don't expect all nodes that participate > to relay messages. I would say that everything that works on an ad-hoc mesh network will also work as good on a wired network... maybe a bit better because of the "missing frame loss". >> Please check the results of previous Battlemeshes. > > I found http://battlemesh.org/BattleMeshV7/Tests but I can't find any > results, only test cases, and all of the test cases are mesh networking > cases. These are the tests and results from the battlemesh v8: http://docs.battlemesh.org/v8/ Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dynamic metrics in IS-IS [was: Info about IS-IS demo from Bits N Bites Prague]
On Fri, Sep 18, 2015 at 7:18 PM, Juliusz Chroboczek wrote: >> - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo > > This is interesting. Could you please share your experimental data? > > Getting dynamic metrics right in link-state is tricky, and using them in > a reliably flooded link-state routing protocol has never been done before > to my knowledge. I have no doubt that you and David are highly competent > engineers, but since this is something that has never been done before, > I think it is essential that you share your experimental data. > > I refer you to [1] that compares an early version of babeld with an early > version of OLSR-ETX. Henning is a highly competent engineer, at it took > him years of hard work to get ETX right in OLSR. I would also be interested in this... a few years ago I wrote a variant of OLSR (v1) with a semi-reliable transport (some linklocal retransmission scheme) but stopped working on the thing because ETX routing metric I had contained too much change/noise anyways. Reliability is not that useful if the metric has changed in a relevant way between two iterations of the update. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg wrote: > Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host > (foo). > > Given no election, use of e.g. mDNS to determine hosts/services would result > in the host showing under both rid1.home and rid2.home. That isn’t a problem > in naming case (you have IP => name, and name => IP resolving), but for > service discovery it kind of sucks. Okay, I see the problem with the hierarchical namespace when two when we have this "host switched to multiple HNCP routers" situation. It would be great if we would get one common (m)DNS name for the host, even if it got multiple IP addresses. Would it be a solution to use a DNS "second level" name for each ethernet segment with hosts attached but NOT include the routers into the DNS name? If you connect two homenet routers to the same ethernet segment, they should know because they see each others HNCP packets (unless its a LEAF interface... which contradicts the switched situation a little bit). Both sides could agree on a common "Link segment" name and announce the host with "host1.link-segment.home". Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg wrote: > On 31.8.2015, at 13.16, Henning Rogge wrote: >> Typical configuration of a cheap router would be to run dnsmasq for >> local DHCP and as a DNS cache. If each of these DNS caches could >> forward DNS queries for *..homenet to the relevant >> homenet router, it would not be necessary to pool all the information >> in an elected DNS “master". > > For naming this works as is fine in our current implementation too; all you > get is some duplicates (foo.link1.rid1.home and foo.link2.rid2.home may both > exist, even if link1.rid1 is same link as link2.rid2). You mean that a Homenet user use a switch to connect two Homenet routers AND a Host ? Or maybe a Host with two interfaces connected to two Homenet routers? Henning ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On Fri, Aug 28, 2015 at 1:29 PM, Juliusz Chroboczek wrote: >> If you don't like the idea using the NODE NAME TLV to announce DNS >> information of the local hosts, how would you do it without a central >> server configured by a network admin? > > * mDNS plus mDNS proxying; or you mean a bi-directional proxy between mdns on the host-interface and some distributed DNS services in the home network? > * mDNS over ff05::fb; or Would not work without a multicast routing protocol. > * announce a bunch of dynamic DNS servers (inside or outside the Homenet) >over HNCP, use some ad-hoc registration protocol. This relies on hosts >consulting all of the advertised servers when search for an RR. which still doesn't solve the problem how the hostnames configured on a homenet router gets into one (or multiple) of these DNS servers. > Henning, the flooding part of HNCP is just a multicasting protocol with > some rather unusual characteristics -- marvelously efficient when there is > no churn, bad in the presence of churn. Let's use its strengths and avoid > its weaknesses, not the opposite. Just to be sure, do you see that the hostname of a router or a host would change that often? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On Fri, Aug 28, 2015 at 12:54 PM, Juliusz Chroboczek wrote: >> - publish a DNS Delegated Zone TLV that points to a (local or remote) >> DNS server that responds for that zone. > > Markus, > > Let's please not put per-host state into HNCP, it's not dealing very well > with churn (remember Jin Kaiwen's results?). Let's use HNCP for > bootstrapping the routers, let's leave routing to the routing protocol, > and naming to the naming protocols. You know, nails and hammers. > > Let's also try to avoid having any more elections (per-link or global). > If a protocol doesn't cannot deal with multiple servers, it should provide > its own election mechanism. If you don't like the idea using the NODE NAME TLV to announce DNS information of the local hosts, how would you do it without a central server configured by a network admin? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On Fri, Aug 28, 2015 at 9:49 AM, Markus Stenberg wrote: > On 28.8.2015, at 10.02, Henning Rogge wrote: >> So what IS the proposed solution for a decentralized HNCP configured >> homenet to share local "configured" DNS names with the rest of the >> homenet? > > For sharing in general, there are two methods (as far as HNCP goes); > > - publish a DNS Delegated Zone TLV that points to a (local or remote) DNS > server that responds for that zone. central server sounds bad for "distributed network". > - publish Node Name TLVs for individual nodes (won’t scale forever, but > possibly enough). That could work... still, if every DNCP node publishes a DNS name for the node (and maybe another one for a few locally attached non-DNCP hosts) this would increase the size of the DNCP database a little bit. Wasn't there a size limit for the database (or was it per node?)? > If the node that has configured state _is not_ running HNCP, then options > boil down to: > > - DHCPv6, mDNS assuming first-hop router cares and does DHCPv6/mDNS (shncpd, > cough) > - DNS-update aimed at the right place (+ injection of DNS Delegated Zone TLV > per zone somewhere in the HNCP cloud) Yes, this would be more complex. But pushing the local router as a nameservice would be enough to inject the knowledge of the HNCP cloud to the attached hosts. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 3:27 PM, Philip Homburg wrote: >>I am not aware of any application doing anything more than "try to >>open the connection again". >> >>How do you propose the application to react? Most applications leave >>the source-IP selection to the operation system... >> >>does any OS currently change the preference order of IPv6 source >>prefixes when it gets ICMP unreachable messages? > > I never bothered to automate, but I regularly switch prefixes by changing > the preference times in RAs. That works very well. > > Linking general ICMP unreachable messages to a source prefix sounds very hard > to me. RA's are generated by the HNCP router, so the generation could take the routing table into account (put prefixes WITH routes in preferred places). If the routing protocol would export the "distance" to the destination in form of the routing table metric value, the RA generation could even make sure that the "closest" gateway is always the preferred one. So we can manipulate the published RAs in a way that the hosts will take normally one the HNCP router prefers? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 2:31 PM, Juliusz Chroboczek wrote: >>> So if a route is flapping, hosts get or don't get an IP depending on the >>> exact time when they send a DHCPREQUEST or NS? Is that better than always >>> assigning an IP to hosts, and expecting ICMP to signal route flapping in >>> real time? > >> Are you talking about a route that is created and vanishes every few >> seconds or minutes? > > What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal > with prefixes that last less than a few hours. See for example RFC 4862 > Section 5.5.3 paragraph e2. (That's just an example, there are other > reasons why yo-yo RAs are a bad idea.) > > Short-term reachability indications are sent to hosts in a reactive manner, > using ICMP unreachables. If any applications are unable to do the right > thing with ICMP unreachables, we should fix the applications. I am not aware of any application doing anything more than "try to open the connection again". How do you propose the application to react? Most applications leave the source-IP selection to the operation system... does any OS currently change the preference order of IPv6 source prefixes when it gets ICMP unreachable messages? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 12:06 PM, Juliusz Chroboczek wrote: >> Yes. If DHCP server and radvd wait until the route to the prefix is >> available in the routing table, we keep the decision about >> "reachability" to the routing protocol without having a hard dependency >> on it. > > So if a route is flapping, hosts get or don't get an IP depending on the > exact time when they send a DHCPREQUEST or NS? Is that better than always > assigning an IP to hosts, and expecting ICMP to signal route flapping in > real time? Are you talking about a route that is created and vanishes every few seconds or minutes? I would guess some kind of hysteresis would be okay. Activate a prefix if you had a route for X seconds... deactivate it if you loose it for X seconds. Still, assigning a source IP address without a route to it is a bad thing, some client applications might just keep trying instead of moving to a different source address. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 11:50 AM, Mikael Abrahamsson wrote: > On Wed, 26 Aug 2015, Henning Rogge wrote: > >> I wonder if HNCP routers should apply all addresses/prefixes to its local >> interfaces, but should check for an existing route to the HNCP router that >> announce the prefix before providing it via DHCP or RA to hosts. > > > Let me rephrase what I think you're saying and tell me if I'm correct: > > Your worry is that HNCP will determine neighbors and speak HNCP well enough, > but the routing protocol thinks the link is so bad, that it's effectively > has partitioned the network (because this was the only link connecting the > two (now) parts), and since there might be two uplinks, you want HNCP to > detect this partition, and only hand out ISP1 prefixes on the side where > ISP1 works, and only ISP2 prefixes, on the ISP2 side that works. Also, if > the network is partitioned, you want prefixes no longer reachable to be sent > corresponding RAs with zero lifetime etc, to make hosts no longer use them > for new connections? This is a good example. > So one way of doing this would be for hnetd to check if the ISPx prefix (for > instance /56) is in the routing table, and if it isn't, it should not use it > to put addresses on interface etc, and if it goes away (at least for any > duration of time), stop using it. Yes. If DHCP server and radvd wait until the route to the prefix is available in the routing table, we keep the decision about "reachability" to the routing protocol without having a hard dependency on it. > I don't remember seeing this discussed anywhere, but it might very well be > something that should be done. I would imagine HNCP is reacting on ISP1 WAN > link going down and stopping to use the ISP1 prefix, but if there is a break > within the homenet (routing protocol wise), nothing is done as long as HNCP > is up. > > One way of solving this would be to create fate-sharing between HNCP and the > routing protocol. Ie, HNCP wouldn't do anything unless there is a valid > routing protocol adjacency with that neighbor (=fate sharing). Yes. HNCP has its own "control plane" (and it needs this control plane), but if we use the neighbor information within HNCP to decide if a prefix is reachable we might create a different view than the routing protocol, which has its own idea what is reachable and what not. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
My problem is not with the prefixes assigned to the interfaces of HNCP routers itself, my problem is with the prefixes provided to attached hosts. If I understand HNCP right then the "uplink" will announce a prefix which should be used by all routers for the attached hosts. The problem will appear if HNCP learns about this prefix through DNCP but the routing protocol cannot provide a route to the uplink (because hysteresis decided one of the links is too bad). I wonder if HNCP routers should apply all addresses/prefixes to its local interfaces, but should check for an existing route to the HNCP router that announce the prefix before providing it via DHCP or RA to hosts. This would not create a dependency loop between routing protocol and HNCP because the routing protocol does only advertise the addresses/prefixes configured on the HNCP interfaces. But it would prevent HNCP to announce a prefix that is not reachable via the routing protocol. Henning Rogge On Wed, Aug 26, 2015 at 11:33 AM, Juliusz Chroboczek wrote: >> It is not uncommon for wireless links to use some kind of hysteresis >> on a routing protocol. The problem/feature of D/HNCP is that it is >> independent of the routing protocol... so it does not know. > > I'm not sure I'm following you. > > All that shncpd does is to announce attached prefixes over the routing > protocol. It is then the routing protocol's business to pick a path to > one of the routers advertising the prefix (or to drop all such routes, if > the link quality has collapsed too much). > > -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 9:42 AM, Mikael Abrahamsson wrote: > Hm, there must be some preconception here that I do not understand. > > Why would a routing protocol choose to decide not to use a "bad" link if > there are no other alternatives available? Bad links should be avoided if > there are better available, but if this is the only one available it should > be used anyway? It is not uncommon for wireless links to use some kind of hysteresis on a routing protocol. The problem/feature of D/HNCP is that it is independent of the routing protocol... so it does not know. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Reachability of distributed prefixes
Hi, I am experimenting with SHNCPD at the moment and wonder about a detail in the Homenet prefix distribution to attached hosts. Does HNCP somehow make sure that there is a route towards the prefix it distributes? While D/HNCP checks that there is a path of links, the routing protocol might decide that one of the links is too unstable/slow for traffic and does not use it for routing. What is the preferred way to deal with this situation? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Tue, Aug 25, 2015 at 8:06 PM, Alia Atlas wrote: > Ok. Let me poke a bit more. Is it safe to use parallel wireless links > between > two routers A and B? Consider that there's a square topology, as below, > where E<->F and > D<->E are both wireless, and links have the same metric. Can C safely send > traffic > to reach F via both D and E? Can F safely send traffic to reach C via both > D and E? > How is this case different than if C were split into a C1 and a C2 so that > F-E-C1 and F-D-C2? > >[ C ]-[ D ] > | | w > | | > [ E ] ---w--- [ F ] > > Basically, I'm trying to understand the restrictions. Could be, but not necessarily... wireless is always a "shared broadcast" medium... if any of the links between two routers use the same frequency, they would interfere with each other. Its more a matter of position and frequencies than interfaces. Oh, depending on the hardware even a different frequency would not give you a perfect separation... the filters of wifi cards are often for the whole band, so that you get some amount of interference between all 2.4 GHz (or 5 GHz) channels. But that depends on the hardware and on the antenna. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Tue, Aug 25, 2015 at 7:38 PM, Alia Atlas wrote: >> There is also the point that multipath choices tend not to be >> isometric... just because the two paths from your local point of view >> seem to be good they are not necessarily good from the point of view >> of the next hop. > > > In a way that can't be captured by link metrics? I haven't really looked at > the unique characteristics for wireless. I'm happy to do a bit of > self-education. Imagine a network with three wireless routers (A,B,C)... A is the uplink, you are C, but both A and C can only see B. All routers are dualband routers (all have both a 2.4 GHz and a 5 GHz radio). >From your (C) point of view the multipath-solution is "easy", one path use 2.4 GHz (C to B to A), the other one uses 5 GHz (C to B to A). But when your IP packet arrives at B, B doesn't know it is part of a multipath stream... so forcing both streams to stay on their frequency is not trivial if you don't want to do source routing. There is a solution for this easy example (as Juliusz will certainly be able to tell you), but there are more complicated setups which are even more difficult. Multipath on wireless links is easy to mess up, so I would suggest NOT including it into the feature-set required by Homenet. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Tue, Aug 25, 2015 at 7:02 PM, Alia Atlas wrote: > Ted, I asked a question about a feature that is considered critical in every > routing environment that I am familiar with. > I find it frustrating that looking ahead to significantly more complex home > networking topologies and link types, which may be > many years out still, is unexceptional, but asking about a feature that > allows better use is described as premature optimization. > I am asking about a routing requirement. > > I still am not clear on how link interference is handled for different > destinations. The options I know are "ignore it" or "include the interference domain size into the link cost". Still, using multipath in wireless environments can be tricky... it is quite easy to mess up even with two paths and get less throughput than from a single path. There is also the point that multipath choices tend not to be isometric... just because the two paths from your local point of view seem to be good they are not necessarily good from the point of view of the next hop. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
Hi, would be nice to have a NTP daemon on every Homenet router... gateways pull their time from the uplink, every other router pulls time from the gateway routers. Henning Rogge On Tue, Aug 18, 2015 at 2:34 PM, Juliusz Chroboczek < j...@pps.univ-paris-diderot.fr> wrote: > How do Homenet routers configure NTP? Just use the pool? > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch wrote: > DAD is also needed to detect duplicates due to host misconfiguration, > such as when a cloned MAC is added to the same network or when addresses > are duplicated by other means (e.g., DHCPv6 misconfiguration). > > I couldn't confirm, but isn't this also not a local decision? I.e., if > DAD fails you might end up with a duplicate address even when you set > your IP addresses based on the burned-in MAC because others could select > the same address randomly (I didn't see how that was avoided by the > self-assignment algorithm). If you have a duplicate MAC then DAD will not safe you... you cannot communicate anyways because of a layer-2 problem. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Wed, Aug 12, 2015 at 8:23 PM, Joe Touch wrote: > That's true, but specific protocol behaviors do address this issue > already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs. > > DAD is a "negative information" protocol, i.e., a lossy link can give a > false positive. This issue is already addressed Sec 4.4 of RFC 4429: the > effect of L2 losses can be mitigated by recommending a different value > for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this > parameter might need to be defaulted to a different value for particular > link types, and such might need to be the case for 802.11. Luckily DAD is mostly needed for randomized IPv6 addresses... if you use the MAC address for generating the IP you are either fine or you have a MAC level collision, which means you have an unsolvable problem. (it gets even worse on 802.11 IBSS/Adhoc mode) Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Wed, Aug 12, 2015 at 7:17 AM, Mikael Abrahamsson wrote: > I'd say most applications people actually use start behaving very badly > around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really get > affected etc. I'd imagine most people I interact with that design protocols > design protocols have in their mind that the packet loss rate is around this > level, not higher. > > So for me, the "contract" that 802.11 needs to fulfil for the IETF not to > start looking into changing IP for 802.11, is for 802.11 networks to deliver > broadcast and multicast packets with around 0.1% packet loss (or less) as a > design goal for normal operations. The problem is we are dealing with more and more wireless devices, so the medium starts to become congested more easily. 0.1% - 1% packet loss (not frame loss) is possible for unicast, but 0.1% multicast packet loss is unrealistic. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Wed, Aug 12, 2015 at 5:20 AM, Alia Atlas wrote: > Yes - downstream paths, as I already said. That is going to next-hops that > are closer to the destination than the computing router. As long as your > next-hop's distance to the destination is strictly decreasing, it is safe to > use. In theory yes... in practice (especially in the presence of wireless links) you might just spam your airspace by producing lots of additional collisions. > There are two questions. First, is the desirable to load-balance among > different paths useful/necessary/unnecessary in homenet? Second, is that > accomplished with metric assignment that encourages equal-cost, are > downstream paths used, and/or is there a way of doing explicit paths? Making the metric too simplistic means you cannot deal with a heterogeneous network like a mixture of ethernet (of different link speeds) and wifi (with LOTS of different link speeds and frame loss). Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Mon, Aug 10, 2015 at 11:33 AM, Lorenzo Colitti wrote: > Sure, but for small packets, it's pretty unlikely that unicast would be > cheaper. An RA will likely only be 100 or 200 bytes. First 802.11 has aggregation, so it is possible to combine the unicast media access with other outgoing unicasts. There is also multi-user MIMO coming, which means a AP can talk to several other stations simultaneously. Both factors can make multiple short unicast frames more efficient than a single multicast, but only the linklayer has enough information to decide this. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Mon, Aug 10, 2015 at 10:34 AM, Mikael Abrahamsson wrote: > Donald Eastlake posted this a few days ago: > > "- 802.11 does have a feature called GCR -- Groupcast With Retries, > which was part of the 802.11aa amendment, although it is not widely > implemented. It includes such features as a way for the AP to send > several multi-destination frames and then, using unicast, to poll > associated stations for a bit map of which of those frames they > correctly received (BlockAck) and a feature for the AP to > spontaneously transmit a multi-destination frame more than once > without causing confusion for improved reliability." Okay... this is quite new and I am not sure it will solve all the multicast problems for 802.11. Neighbor discovery (both IPv6 and routing protocol) has potentially to deal with a lot of neighbors, some of them not even known to the transmitter. It also feels like a lot of consumed airtime to replace a multicast with a multicast and one unicast for each known neighbor. This could be dozens of media accesses. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Mon, Aug 10, 2015 at 9:32 AM, Mikael Abrahamsson wrote: > IETF standards generally assume that multicast and unicast are delivered > with a similar level of packetloss (which is low). > > Not all 802.11 implementations have the multicast ACK mechanism implemented, > thus it would seem that multicast will be less likely to get delivered to > the recipient over these 802.11 implementations. > > For me, it seems these 802.11 broadcast/multicast ACK functions should be > "mandatory" to implement if the device wants to support IPv4 and IPv6 > networks. Excuse me, multicast ACKs on 802.11? I know that some implementations/stacks split up multicast into several unicasts (which will then be acked and will have retransmissions), but I have yet to hear about multicast ACKs in the IEEE 802.11 standard. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] MIF support [was Moving forward.]
On Tue, Jul 28, 2015 at 2:41 PM, Margaret Cullen wrote: > > On Jul 28, 2015, at 2:58 AM, Brian E Carpenter > wrote: >> The former is obvious but I'm not sure that any case has been made to require >> MPVDs in the basic Homenet model. There are no references to the MIF WG or >> its >> documents in the Homenet architecture RFC. > > Since MPVDs are implemented on hosts, and informed by information distributed > in RAs and/or via DHCP, Homenet should already support MPVDs to some extent. > There are some issues with how Homenet would distribute the MPVD DHCP > options, most of which would apply to other container options, and we have a > group of people looking into that now. Assuming we can resolve those issues > to everyone's satisfaction, Homenet will support MPVDs with no additional > complexity in the Homenet protocols. I think the reason why this "MIF support" thread started was that different gateways might be good or bad (because of the topology/links in between) for one router or the other one. The question is how to push this local information to the attached Hosts. Transporting DHCP options over HNCP has nothing to do with it, because it will be a local decision anyways, not one decided by the gateway. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, Jul 27, 2015 at 5:42 PM, Juliusz Chroboczek wrote: >> I wonder if the "data-propagation/router control" part of HNCP and the >> "attached host control" part of HNCP should be split into two >> entities... this would allow the second one to get hints from the >> routing protocol about the metric without generating a dependency >> cycle. > > There's no "attached host control" part in HNCP -- there's just RA and > DHCPv4 (DHCPv6 optional). HNCP is purely a router-router protocol. you could say that setting your local prefix on the interface is "control the local node" and setting up RA/DHCPv4 is "control the address of the host". still, at the moment I just see a problem and have no good solution, just a few guesses. > It's a pretty clean design. > > In principle, it might be possible to use routing protocol metrics to > influence RFC 4191 preferences, but I'm not sure how that would work. > If you know (and have implementation experience), I'm interested. I just got my olsrv2 implementation source-specific routing capable... I plan to look at your "simple" HNCP implementation to see how routing metrics could help. But this is still a "todo" for me. Henning ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, Jul 27, 2015 at 4:15 PM, Juliusz Chroboczek wrote: >> if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers, >> who makes sure that these are prefixes that are "reasonable good" >> measured by the metric of the routing protocol? > > Nobody. From the point of view of the host, all connected routers are > equivalent. > > If the host is single-homed, any suboptimal routing will be resolved by > the redirect mechanism. If the host is multi-homed, there's a realistic > risk of suboptimal routing -- I don't know any good solution to that (but > I haven't looked carefully at the MIF work). I wonder if the "data-propagation/router control" part of HNCP and the "attached host control" part of HNCP should be split into two entities... this would allow the second one to get hints from the routing protocol about the metric without generating a dependency cycle. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, Jul 27, 2015 at 3:58 PM, Juliusz Chroboczek wrote: > During my quick talk on Wednesday, I mentioned that I had been pleasantly > surprised at the very clean interaction between the protocols: > > - HNCP redistributes assigned prefixes into the routing protocol; > - HNCP redistributes assigned prefixes into the RA and DHCPv4 servers; > - the routing protocol redistributes the default route into RA and DHCPv4. > > That's very elegant -- unless I've missed something, there are no other > cross-protocol interactions in the subset of the Homenet stack that is > implemented in shncpd. There is one thing I worry about with this strategy... if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers, who makes sure that these are prefixes that are "reasonable good" measured by the metric of the routing protocol? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Hi, there is also the point that "wifi repeaters" are quite stupid devices at the moment. I could see "Homenet wifi extenders" which just are Homenet routers with multiple wifi interfaces routing traffic between them. Henning Rogge On Mon, Jul 27, 2015 at 2:12 PM, Jonathan Hansford wrote: > Was in the process of asking the same question about "one wifi link". I > don't think my homenet is "average", but I have the wifi router and two > APs, > each has its own SSID for static devices, and share one home SSID and one > Guest SSID for more mobile devices. > > Jonathan > > > -Original Message- > > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Margaret > > Cullen > > Sent: 27 July 2015 13:08 > > To: Hemant Singh (shemant) > > Cc: Pascal Thubert (pthubert) ; Ted Lemon > > ; Dino Farinacci ; HOMENET > > ; Mikael Abrahamsson ; Gert > > Doering ; Terry Manderson > > Subject: Re: [homenet] Moving forward. > > > > > > On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)" > > wrote: > > > (c) An average home has one wifi link. > > > > > > Any other requirements or changes to the above text? > > > > This depends on what you mean by "one wifi link". I think we expect > homes > > to continue to have guest and home wi-fi SSIDs, or equivalent. I don't > know > > whether this will continue to be provided at layer 2, or whether homenet > > prefix delegation would allow these links to be routed, instead of > bridged. > > Also, I think we expect homes to potentially have other types of wireless > > links (i.e. IEEE 802.16). > > > > Margaret > > > > > > ___ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Mon, Jul 27, 2015 at 11:59 AM, Juliusz Chroboczek < j...@pps.univ-paris-diderot.fr> wrote: > Whatever happens within Homenet, it's good to hear that we've managed to > put dynamically computed, unstable metrics on the radar for at least some > IETF insiders. > > The exchange of ideas is also happening in the other direction -- Matthieu > and I are going to Battlemesh next week, and we'll be trying to sell the > idea of source-specific routing to the community mesh people. (Henning > is telling me that he already has an implementation of source-specific > routing for OLSRv2, he'll hopefully demo it at Battlemesh.) The code itself is working (I tested it with Teco Boot during the IETF), I just have to resolve the detection of routers that cannot do source-specific routing. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing Protocol in HNCP
On Thu, Jul 23, 2015 at 10:41 AM, Juliusz Chroboczek wrote: > What you are suggesting requires some form of tighter binding between HNCP > and the RP. This raises a number of difficult questions, such as what is > the metric space (e.g. RIP uses 4-bit integers, IS-IS uses 8- or 24-bit > integers, plain Babel uses 16-bit integers, the Babel-Z extension uses > variable-length vectors of 8-bit integers), what mechanism should be used > to communicate the metric between HNCP and the RP (is the kernel priority > field suitable and what systems implement it?) and how often HNCP should > inform the RP of metric fluctuations. yes, putting the metric values of links into the HNCP database sounds BAD. Configuring the type of metric of the routing protocol could be a job for HNCP (similar to delivering a shared key to the routing protocol, its a configuration issue). Putting metric values in there does not. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Mesh networks in the homenet
On Wed, Mar 25, 2015 at 5:15 PM, Alexandru Petrescu wrote: > Err, no. It's an A-B-C situation where each (even B) has 1 interface, > and all are in an IBSS. This is the situation described in that draft. > >>> Are there 1-interface routers in homenet? >> >> >> In an 802.11 IBSS, I would assume yes. > > > Well IBSS is not made to have 1-interface routers on them, so this > (1-interface routers) is not really good to do, in my personal oppinion. > > IBSS is made to have 1-interface Hosts on it, not routers. one of the typical use-cases of IBSS mode was to connect larger amount of routers for a mesh network. > Remark this is my IMHO and a number of other people disagree with this. > > I know. > > I just tell that you can build a very good ad-hoc network without an AP > and with 2-interface routers. At that point there is no hidden-terminal > problem. Unfortunately this is wrong. The number of interfaces is totally irrelevant to the hidden station problem. The only question is if you have one wireless radio interface (among many on a router) connecting to two other routers (with maybe many more interfaces) that cannot hear each other on this interface. It can even happen on AP/client networks if you use them to connect multiple routers. There is no guarantee that the clients can see each other. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] rt protocol comparison on criterion 'transitivity' A-B-C draft-baccelli-intarea-adhoc-wireless-com-00.txt
On Tue, Mar 24, 2015 at 11:06 PM, Alexandru Petrescu wrote: > Hello, > > During the slide presentation by Margaret we saw a criterion for protocol > comparison describing 'transitivity', in the sense A sees B sees C but A > does not sees C - aka a 'hidden terminal problem' in WiFi IBSS mode. You can also have this with AP mode or Wifi-Direct... two routers with a Wifi client interface connected to the same router but not seeing each other. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar wrote: > The basis for the metric in RFC 7181 is out of scope. So what did you > use? This: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 I am still using the multicast loss (plus the raw link speed) to judge the links, but I have done some early experiments with integrating the L2 frame statistics too. Not sure it works that well for wifi without a lot of probing, much more than you need for getting an useful link speed). > Also I'm not sure what you meant by the "MPR code". Did you leave in > the LINK_METRIC TLV and leave out the rest of RFC 7181? Multipoint Relays. Its a method to reduce the flooding overhead in a wireless mesh network. Its defined in RFC 7181, but its a modification of NHDP so I put it into my NHDP implementation. > So my point still stands that there is nothing like LQM is anything > over WiFi (more correctly 802.11). With an Atheros card I get both transmitted frames, retransmitted frames and (completely) lost frames on the sender side of a link... its just that these values are not that useful when most of your wireless links are not transporting traffic. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
Sorry, too much working on the implementation side of NHDP/OLSRv2 in the last years... should have thought a bit more about the reply before sending it. Yes, you are correct that RFC6130 does not contain the description of the link metric... it only contains a rough EWMA based "link quality" hysteresis that switches on and of links. I don't even think the algorithm defined in the RFC is really useful (but its easy to plug in a different one because the Link Quality calculation and decision is just local). I was thinking about the Link Metric NHDP extension defined in RFC7181 (which can easily be used without using the OLSRv2 routing), which is based on "Incoming/Outgoing Link Metric" values. (in my implementation I put the whole Link Metric and MPR code into NHDP to make them usable without OLSRv2) Henning Rogge On Tue, Mar 3, 2015 at 12:28 AM, Curtis Villamizar wrote: > Henning, > > You cut the following off the top of your reply. > >> > The Neighborhood Discovery Protocol (RFC 6130) has a similar >> > mechanism... each node collects local link quality information and >> > then shares them from time to time with all neighbors, which means >> > everyone knows about both directions of a link. >> > >> > Henning Rogge >> >> >> RFC 6130 uses probes (hello message success rate). > > Cutting this off makes a big difference. See below. > > In message > > Henning Rogge writes: >> >> On Sun, Mar 1, 2015 at 11:14 PM, Curtis Villamizar >> wrote: >> > RFC 6130 uses probes (hello message success rate). >> >> No, it does not... at least not for calculating the link metric. > > The discussion was the quality measurement. The quality measurement > uses hello message success rate. See section 14 in RFC 6130. > > The discussion was not link metrics. You chopped the prior discussion > when quoting the one sentence above. Below I describe the why RFC > 6130 Link Quality is nothing like LQM. > >> > For example: If an AP sends 100 packets a second to a neightbor and 5 >> > drop it would be better to send one LQM packet and know that loss is >> > 5% rather than have to send 100 hello packets in addition to the 100 >> > data packets to reliably know that loss is 5%. (In MPLS it could be a >> > billion packets between LM packets). >> > >> > LQM does not rely on a count of probe packet success. Please reread >> > what I sent earlier or read about PPP LQM or MPLS-TP LM OAM. >> > >> > Please compare RFC 6130 section 14.2 (Basic Principles of Link >> > Quality) >> >> "Link quality" and "Link metric" are two different kind of things for >> NHDP/OLSRv2. >> >> Link quality is used for a hysteresis mechanism that can make a link >> symmetric/asymmetric. >> >> Link metric (as defined in RFC 7181) is used for path selection. >> >> > with RFC 1989 and RFC 6375. In RFC 6375 look at Section 2.2 >> > (Packet Loss Measurement) and Section 3.1 (Loss Measurement Message >> > Format). RFC 6130 has no comparable mechanism. >> >> RFC6130 (NHDP) and RFC 7181 (OLSRv2) define the incoming link METRIC >> calculation as an external process. It can be anything, as long as it >> gives you a dimensional link cost in the right range. >> >> I admit the splitup between RFC6130 and RFC7181 is a bit confusing... >> >> Henning Rogge > > I know the difference between link quality and link metric. > > You just jumped from ND to OLSRv2 for MANET. RFC 7181 does not > preclude using a LQM-like mechanism, but neither RFC 6130 or RFC 7181 > define such a mechanism. > > The discussion was regarding doing something like LQM and three > messages ago you stated that RFC 6130 already had something like LQM. > Neither RFC 6130 or RFC 7181 define a mechanism anything like LQM. > > Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Sun, Mar 1, 2015 at 11:14 PM, Curtis Villamizar wrote: > RFC 6130 uses probes (hello message success rate). No, it does not... at least not for calculating the link metric. > For example: If an AP sends 100 packets a second to a neightbor and 5 > drop it would be better to send one LQM packet and know that loss is > 5% rather than have to send 100 hello packets in addition to the 100 > data packets to reliably know that loss is 5%. (In MPLS it could be a > billion packets between LM packets). > > LQM does not rely on a count of probe packet success. Please reread > what I sent earlier or read about PPP LQM or MPLS-TP LM OAM. > > Please compare RFC 6130 section 14.2 (Basic Principles of Link > Quality) "Link quality" and "Link metric" are two different kind of things for NHDP/OLSRv2. Link quality is used for a hysteresis mechanism that can make a link symmetric/asymmetric. Link metric (as defined in RFC 7181) is used for path selection. > with RFC 1989 and RFC 6375. In RFC 6375 look at Section 2.2 > (Packet Loss Measurement) and Section 3.1 (Loss Measurement Message > Format). RFC 6130 has no comparable mechanism. RFC6130 (NHDP) and RFC 7181 (OLSRv2) define the incoming link METRIC calculation as an external process. It can be anything, as long as it gives you a dimensional link cost in the right range. I admit the splitup between RFC6130 and RFC7181 is a bit confusing... Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Sun, Mar 1, 2015 at 5:08 PM, Curtis Villamizar wrote: > Henning, > > That sounds like a good strategy. Negotiating a rate among two > parties is not a hard protocol problem, nor is changing it. > > Note that PPP LQM (link quality monitoring) or MPLS-TP LM (loss > monitoring) is not probe data. For example, one cycle of LQM packet > every 10 seconds yields the exact number of packets sent and recieved > and the exact number dropped in both directions over a 10 second > period. One cycle is three packets, with two in one direction. The Neighborhood Discovery Protocol (RFC 6130) has a similar mechanism... each node collects local link quality information and then shares them from time to time with all neighbors, which means everyone knows about both directions of a link. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Sun, Mar 1, 2015 at 12:52 AM, Curtis Villamizar wrote: > If any of the control packets drop, drop a partial result, repeat > later, and compare to the last complete result. > > Is one cycle per neighbor too much? How about one cycle per neighbor > each 5 seconds? If "B" is the AP it sends only one packet per cycle > but both sides get accurate drop rate for both directions. I went even further and restricted the probing to a fixed amount per interface... to prevent the wifi network from overloading in crowded adhoc networks (where everyone can see everyone). Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Fri, Feb 27, 2015 at 10:37 PM, Curtis Villamizar wrote: > Henning, > > How can a router make use of throughput to a mostly idle neighbor? > How do you get packets sent to a neighbor that dropped or packets that > a neighbor sent to you that didn't arrive here? Raw link speed or > packet and byte counts don't by themselves tell you much. The > equivalent of PPP LQM or MPLS-TP LM OAM would be the sort of thing > needed is you didn't want to use BFD with a high probe rate. You need a bit of probing traffic... a few packets per second are enough to give you an idea about the speed of the link. Of course you only need to probe neighbors that you did not send normal unicast anyways since the last probe. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Wed, Feb 25, 2015 at 9:36 PM, Curtis Villamizar wrote: > In message <87a903ef2j.wl-...@pps.univ-paris-diderot.fr> > Juliusz Chroboczek writes: >> As to wireless links -- as far as I'm aware, making efficient use of >> wireless L2 information in a routing protocol is an open research problem. > > Other than signal strength and collision rate, what L2 information is > available? Per MAC information would be nice for the AP side or any > node in mesh or adhoc mode but that isn't collected anywhere AFAIK. Raw linkspeed and (on Linux) even Throughput to each neighbor... and a lot more. Just run "iw wlan0 station dump" on a Linux system with wifi and you will be surprised how much information you will get. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Fri, Feb 20, 2015 at 9:51 AM, Teco Boot wrote: >> At the moment I just get the ethernet port link speed... that is not >> really good for switched ports, but its better than nothing. >> http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master >> >> If you have hardware with a built-in switch that can report the >> link-speed, it would be easy to add code that integrates this (and >> some traffic statistics). > > Your SW depends on ethtool, right? Not a problem, this is implementation > detail. Link speed probes could be added for verification the ethtool > provided info. No, it does directly call into the operation system. Calling a different executable and parsing the output is a good source for subtle bugs. > And yes, I didn't mean we cannot use the 80% solution. What I want to say is > that the Homenet Routing Protocol shall be able to use all the link metrics > it can get. > > I am still worried about loops caused by dynamic link metrics used by a link > state routing protocol. For me, this is the major difference between ISIS and > Babel. Thats because I don't code the protocol. If I was, I would be worried > about the non-IP transport in ISIS. It is a matter of metric stability... so you need a good hysteresis and post-processing to make it work. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Fri, Feb 20, 2015 at 9:19 AM, Teco Boot wrote: >> There is also the "linklayer database" approach I selected for my >> olsrd2 implementation. Instead of hardcoding linklayer specific code >> into the metric, I split the codebase into "link layer gathering" code >> (which is often OS and linklayer specific), generic routing metric >> code... and a generic API in between that stores the values. >> >> This makes it quite easy to adapt the codebase to new linklayer types. >> > > So you have the placeholder for an automatic ethernet link speed detection. > Great! > > We cannot trust ethernet port L2 feedback. Ports can be connected to switches > with multi-rate ports. Could be powerline, wired_over_wireless bridges or > other stuff that hides a slow link. In homes, there is no place for protocols > that cannot detect and handle such cases. At the moment I just get the ethernet port link speed... that is not really good for switched ports, but its better than nothing. http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master If you have hardware with a built-in switch that can report the link-speed, it would be easy to add code that integrates this (and some traffic statistics). Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Fri, Feb 20, 2015 at 8:56 AM, Teco Boot wrote: > Bad luck, I kindly ask you to pay a little more attention to it. Link metrics > for wireless links are crucial, but let's not forget wired links. > > Some years ago, Thales NLD worked on olsr-lc (link costs, ETT). A plugin > probed WiFi link speed with large & small packets, filtered out jitter and > used the outcome as link metric (merged with ETX, I think). For static > networks and very patient people, it may work. For mobile networks, it is > far, far to slow. Convergence is tens of minutes. Speed up some timers > increases load on the wireless links to unacceptable levels. So it died. > > But for wired links at homes, this plug&play mechanism could work out well. > No L2 API needed. There is also the "linklayer database" approach I selected for my olsrd2 implementation. Instead of hardcoding linklayer specific code into the metric, I split the codebase into "link layer gathering" code (which is often OS and linklayer specific), generic routing metric code... and a generic API in between that stores the values. This makes it quite easy to adapt the codebase to new linklayer types. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Thu, Feb 19, 2015 at 8:45 PM, Juliusz Chroboczek wrote: >> A marginal link is simply one that has a measurable amount of packet loss. > > Ok, re-reading this exchange, it looks like I may have wrongly assumed > that people are aware of background. I'll need to put that into the > routing comparison document, this is as good a place as any to draft my > text. > > Carrier and enterprise routing protocols are optimised for wired networks, > where a link is either down (drops all packets) or up (drops one packet in > 10^10). > > Home networks usually include link technologies that have an intermediate > "marginal" state: a link that drops a non-negligible fraction of packets. > With 802.11, in particular, marginal links have fairly unpleasant performance > characteristics. For example, if the BER is 10^-4, > > - multicast packets are dropped at roughly the nominal rate (10% for 120 > byte packets, 90% for 1500 byte packets); > - unicast packets are dropped at a much lower rate, but the efficiency > suffers (0.9 for 120 byte packets, 0.1 for 1500 byte packets). > - unicast packets have a high probability of being duplicated (no > figures given, I'm too lazy to look up the size of an ACK frame). > > This is of course a very naive analysis -- in practice, errors tend to > come in bursts, and furthermore 802.11a/g/n implements some very complex > lower-layer magic. Don't believe any results from computation or > simulation, with radio, only actual testing in real-world networks is > trustworthy. There is also the really bad case of wifi links without packet loss which are stable at 6 Mbit/s... stable but incredible slow. If you have a combination of two 450 Mbit/s links you can use instead, you want to do it... Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, Feb 19, 2015 at 7:18 PM, Ole Troan wrote: > there are very few shared media around anymore. I don't think I've ever been > connected to a 10base5. > why should the IP subnet model emulate a shared medium, when the physical > topology is a star. > > wireless with security is also a star topology, with a unidirectional > broadcast channel. Unfortunately on layer-1 both are still broadcast... you send a unicast, it might interfere with anyone else in range. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On Fri, Dec 19, 2014 at 11:54 PM, Matthieu Boutier wrote: >> You might also need to combine the features of the gateway with the >> metric(s) of the path to the gateway. >> >> Its not really useful to select a faster gateway if the path towards >> the gateway goes over a slow wifi link. > > I do end-to-end measurements in my mosh implementation, so we should > not have the problem. The host selects a source address, in fact a > pair (src, dst), depending on the performances of the whole path > determined by this pair. Does this really scale well? If every application on every attached computer in the Homenet measures the end-to-end performance through every gateway... that could be a LOT of overhead for larger Homenet installations. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On Fri, Dec 19, 2014 at 6:31 PM, Juliusz Chroboczek wrote: >>>> Sounds interesting. In the ideal world, that would be a pluggable >>>> policy algorithm. Lowest RTT may not always be the best choice. > >>> It is, in our particular context. That's the nice thing about working at >>> the application layer -- you are the application, so you have a pretty >>> good idea of what the desirable properties are. > >> Are you sure? > > This particular debate aside, I think we're in agreement about the > underlying issue -- source selection in networks with source-specific > routing is an interesting problem, and one that we haven't explored much > yet. You might also need to combine the features of the gateway with the metric(s) of the path to the gateway. Its not really useful to select a faster gateway if the path towards the gateway goes over a slow wifi link. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for Routing Protocol
On Mon, Nov 17, 2014 at 5:38 PM, Juliusz Chroboczek wrote: > If I understand Dave right, the idea is to switch things around: instead > of having the Nest node speak a stub version of a Homenet protocol, you > have a specialised Homenet node that speaks a degraded version of Nest's > protocol (just like a babel-pinger node speaks both Babel and a degraded > version of DNS). yes. > This solves the issue of unexpected routing pathologies (the Homenet node > is participating in the native Homenet routing protocol, and hence doesn't > introduce any new pathologies), as well as that of flash and RAM usage (the > Nest node isn't running any new software). It does cause sub-optimal > routing, though, unless the specialised node is at the right place in the > network. If Homenet assume any "lightweight nodes" (e.g. a Nest node) speak IP, then using ICMP might be an easy way to do this. If the node does not speak anything beyond its own protocol, I agree it would need a special piece of code in the Homenet node. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for Routing Protocol
On Mon, Nov 17, 2014 at 5:08 PM, Juliusz Chroboczek wrote: >> Something of an aside to this conversation, but there is a similar >> problem in dealing with an external gateway that does not speak the >> routing protocol either. > > Aye. > >> The ¨babel-pinger¨ mechanism >> >> http://lists.alioth.debian.org/pipermail/babel-users/2008-September/000160.html >> >> would have been a cure for this... > > I had forgotten this hack. > >> A Nest-pinger (or responder - ) might be a way to keep a route alive > > You're completely right, Dave. This would solve the issue with minimal fuss. Isn't the "Nest pinger" just a shortcut for reducing the intervals and validity times of the information transfer between the Nest-node and the true-Homenet-node? If you want to discover a link loss quickly, just exchange data more often to make sure the other side is still there. Doesn't matter if its a ping, a HNCP packet, a BABEL packet or a layer2-beacon. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Clarification on Routing Thoughts
> I think Joël's reluctance about hopcount qualifying the gig-e/wifi > choice may change if considering wifi-ac instead. I.e. hopcount may be > good to qualify a choice between Gigabit Ethernet and Gigabit wifi. Measuring any kind of wifi connection just with "hopcount" is not a good idea. Even 802.11ac will downgrade to a few Mbit/s if the connection is bad. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [dnssd] IETF-89 WG meeting minutes
On Fri, Apr 11, 2014 at 1:53 AM, Douglas Otis wrote: > mDNS is not easily deployed at large scale over wireless without filtering. > Wifi has improved by offering mitigation strategies like multicast queuing > per N beacons and multicast specific filters. Even so, these strategies are > unlikely needed at home. I make extensive use of mDNS within a dense > wireless spectrum containing dozens of nearby access points without > difficulty while transferring multiple HD+ streams. I would be interested in > knowing what problems you are experiencing within your home. Its not only mDNS, its also ARP, ICMPv6 and other "linklocal multicast" protocols that work badly over large Wifi linklayer domains. Linklocal normally means "fast, cheap, atomic, in-order"... if you replace it with a large wireless layer-2 domain, it becomes something very different. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Tsinghua work on source/destination routing
On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek wrote: >> > Excellent. Could we please have a look at the source code ? (It was >> > already promised in Berlin, if memory serves.) >> >> If you want, I can send you the current version privately at this moment. > > I'd much prefer a public repository, something I can discuss freely > with people (and eventually cite) without worrying whether I'm disclosing > anything confidential. I agree with Juliusz, a public repository would be much better, even if it only contains "in development" code. If the code will be open sourced in the end anyways I don't see any drawbacks. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Capabilities of small devices
On 08/12/2013 11:40 AM, Mikael Abrahamsson wrote: On Mon, 12 Aug 2013, Teco Boot wrote: Joel Jaeggli mentioned the forwarding performance. Today's homenets are mainly single subnet with link-speed forwarding between (gig) ethernet ports, in hardware. L3 forwarding in software with single uplink or WiFi port at near to gig speed is doable. Forwarding in software on all ports require a new generation of low power and cheap CPU, I think. So probably use hardware forwarding as much as possible? Hardware assisted forwarding might be problematic due to us deciding on new functionality (source based routing for instance). I've read that in some routers the forwarding is done by microcode implemented by the hardware manufacturer, hindering the integrator (who buys the SoC in bulk) from doing what might be needed. So yes, forwarding performance is a concern, at least when we're talking above 100 megabit/s. I also think it would be beneficial if we could figure out as soon as possible what the requirements are on the forwarding plane, writing this down, so that hardware designers can avoid putting functionality into hardware that won't do what we need going forward. I agree, software forwarding should be the standard way. That makes it also more easy to adapt different routing protocols to HOMENET. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Capabilities of small devices
On 08/12/2013 09:49 AM, Mikael Abrahamsson wrote: On Mon, 12 Aug 2013, Henning Rogge wrote: Many current home-routers have 32 MB RAM (some have more), some more "expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB. How much of this cost increase is due to the flash and RAM, and how much is due to more expensive other components plus the software development effort to perhaps drive additional features these more expensive devices bring? How much of it is just "hey, this is the improved version"? We don't know. For 80$ you already get routers with 8 MB flash and 128 MB ram. Personally I like the way CODEC WG approached this, by making a reference implementation available in source code in the standard. This is probably not practical for a complete homenet router, Why? A "homenet" package (most likely multiple packages) for OpenWRT as a reference implementation would be a great thing. but at least my hope is that there will be freely available code that implementers can use so that just like they don't have to spend time to develop the linux kernel they're running on their devices, they don't have to develop (or buy) the routing control plane code (or forwarding for that matter), because it's already available. And it might give consumers the chance to get a router with a reasonable modern linux. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Capabilities of small devices
On 08/12/2013 01:54 AM, Juliusz Chroboczek wrote: A more important factor is the size of the memory on the devices, a box with 8MB memory will have problem with running many services, but many boxes sold today have 32-128MB memory (both NVRAM and RAM) An additional point is that all home routers sold in the last 10 years or so have enough RAM to perform stateful NAT for hundreds of connections. Anything that can do stateful NAT can do IPv6 and link-state routing without effort. The community mesh networking community (ahem) has a lot of experience with cheap boxes. Henning will correct me if I'm wrong, but as far as I am aware, - no box sold in the last few years has RAM issues (kernel+v4+v6+well implemented routing daemon fit in 32 Megs with plenty to spare); - some older boxes lack flash, this is not an issue on recent boxes; - some popular cheap boxes used to have power supply issues (overheating and crashing under load). As flash and RAM keep getting cheaper, I expect the power supply to increasingly become the main problematic component. Older (and cheap) home-routers had typically 4 MB flash and 16 MB RAM. You can run a dualstack router with routing protocol on this, but you have to be a bit careful not to overdo bloated additional software. Many current home-routers have 32 MB RAM (some have more), some more "expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Capabilities of small devices
On 08/09/2013 04:11 AM, Ted Lemon wrote: On Aug 8, 2013, at 9:49 PM, Hartog, F.T.H. (Frank) den wrote: At the same time, new and much smaller devices are introduced in the home. E.g. light bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we should define a baseline definition of what we mean with "small device" anno 2013 to frame the homenet arch discussions and documents. Regards, Frank. Do bear in mind that Olafur is talking about home routers here, not lightbulbs. From a RAM/CPU perspective no current home routers should have a problem with IPv6. Its just that some manufacturers don't integrate the necessary components into their basic firmware. I think IPv6 support should be mandatory for Homenet routers. Maybe they won't have an uplink to the Internet with IPv6, maybe they have some attached devices without IPv6, but the software on the core Homenet routers should have access to IPv6. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
