Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Toerless Eckert wrote: On Fri, Feb 20, 2015 at 02:57:21PM +0100, Mikael Abrahamsson wrote: L3 - route injection (got a routing protocol there already, use it) This sounds like it needs at least a coordination protocol between the APs? NO, just between the first-hop (homenet) routers. Should work with unchanged of the shelf crap-APs as long as they're attached to a homenet router. Could someone please explain to me how this is supposed to work? How do the first-hop routers figure out where the client is? Do we do /128 route injection into the homenet for active IPv6 addresses in that /64, and announce the same /64 everywhere, and then we use proxy-nd for all off-L2 active IPs? I guess we need to handle IPv4 as well, so we use proxy-arp for that? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] OpenWRT hardware [was: A poll]
On Fri, 20 Feb 2015, Dave Taht wrote: 802.11ac rates on the wifi, it does not have enough cpu to push it that hard. It was only getting wndr3800 style forwarding rates when I last tried on on ethernet also. Which for me was around 100-120 megabit/s with a single session, which is definitely not enough for me with my 250/50 megabit/s Internet connection. Currently I use the Apple Airport Time Capsule 802.11ac thingie and a HE tunnel. We're going to evaluate a product based on http://www.marvell.com/embedded-processors/armada-38x/ which looks very promising from a performance point of view. I'll report back if we successfully get OpenWRT running on it and if I can find hardware based on it that can be bought retail if it seems to work well. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 02:57:21PM +0100, Mikael Abrahamsson wrote: > >L3 - route injection (got a routing protocol there already, use it) > > This sounds like it needs at least a coordination protocol between the APs? NO, just between the first-hop (homenet) routers. Should work with unchanged of the shelf crap-APs as long as they're attached to a homenet router. Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Client roaming [was: Routing protocol comparison document]
I was going to say host-routes as well but Markus beat me to the punch. I definitely think we should target a solution without host changes though as the tactical solution. I thought LISP had implemented this type of stuff, eg: host address mobility for hosts on access-LANs. Can't quite remember how, but it must be something involving the tracking of a device when it moves from it's original location, and the first-hop router(s) would then create a host-route for that host and make sure that the host keeps its address (acting as DHCP server or the like ?) Can't be that hard though. Definitely less work than trying to build an L2 overlay to give stupid L2 APs the ability to do L2 roaming. IN any case, it should at most be all control-plane, no new forwarding plane. Of course, host-routes themselves don't solve the possible problem of link-local multicast after mobility, but i'd very much hope that we can get rid of apps relying on that anyhow. Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] OpenWRT hardware [was: A poll]
On Fri, Feb 20, 2015 at 2:22 PM, Dave Taht wrote: > On Fri, Feb 20, 2015 at 12:33 PM, Juliusz Chroboczek > wrote: >>> I'd be a bit curious to know what people are using for test hardware. >> >> The WNDR3800/WNDR3700v2 is still my favourite. I've still got a couple >> Asus 500GP v1, and they're just fine if you don't need 802.11n and can >> fit in the slightly more limited flash. > > Despite evaluating well over 60 products and chipsets in the past 3 > years, I have yet to find something as nice as the wndr3800 as either > a R&D or day to day ultra-reliable home router. > > More generically the ag71xx/ath9k chipsets it used are the most > aimiable to hacking on and there are hundreds upon hundreds of current > products based on that, like the WZR the homewrt folk used. > > However single cpus like that with 32k dcache proved not up to the job > of 802.11ac and there is a lot of chaos and crap gear going around on > that standard. > > Elsewhere the whole wifi industry is seemingly in a race to the > bottom. As one example, I use the nanostation M5s heavily, and they > (silently) changed the underlying chipset last year from one with two > ethernet interfaces, to 1 connected to a 100Mbit switch. Result - no > link status anymore, the impossibility of measuring traffic well > across the two interfaces, and an increase of latency under load to > the buffering in the switch. > > The new nanostation IS a bit faster (mips 74k based rather than 24k), > and has twice the ram, for the same cost as the old, and it still has > 8MB flash, so I should not complain too much, I guess. (My typical > topology is 2 nanostations connected to a picostation M2HP AP) > > I have been seeking an integrated outdoor tri radio replacement for > that particular setup for a long time. > > As for everything else I have evaluated, I am thinking of publishing > it all, after I tone down the invective logged in my notes. > Most recently I took a look at two 802.11ac products from d-link. > > https://lists.bufferbloat.net/pipermail/bloat/2015-February/002310.html > > ubnt is *clued* in comparison to nearly everyone else. The tp-link archer C7 v2, after a year of teething pains on the ath10k interface, is a not horrible platform for openwrt development (and the ath9k also on board, is great). Just dont expect the claimed 802.11ac rates on the wifi, it does not have enough cpu to push it that hard. It was only getting wndr3800 style forwarding rates when I last tried on on ethernet also. I was fairly impressed with the capabilities of the netgear x4, but was able to crash it regularly in testing when I last pulled it out and I dont think the gpl drop landed yet so there is no open source for it. There are a couple other 802.11ac routers out there like asus´s and so on, I do hope the market starts sorting out one or more that is useful to hack on. Felix recommended trying the d-link DIR-860L *model B*, but as yet I havent sorted out how to actually order that. He is also hot on the mt72 chipset in it as a candidate for multi-station queueing. I note that I have not, for most of the last year, been heads down into any of this stuff, I burned out pretty badly as we stablized cerowrt by last april and needed a major break. I happen to like gfiber´s new ethernet/wifi/video gw quite a bit, but that is only just now beginning be deployed in austin, and there is still a need for a followup release of the software, and I cant talk about it much, since I worked on it. I dont see much hope of seeing general support for the chipset it used (mindspeed) in mainline linux, either. .. I think that is all of my invective-free notes on various existing products. >> Both models: >> >> - are well supported by OpenWRT; >> - are very difficult to brick (just set up a tftp server and interrupt >> the boot sequence to reflash); >> - have a manageable built-in switch that's configurable from OpenWRT. >> >> The WNDR3800 has 16/128 flash/RAM, the 3700v2 16/64, the Asus 8/32. >> >> The WNDR3800/3700v2 has some other nice features, like a second gigabit >> NIC that doesn't go through the internal switch (to get VLANs without >> messing with the switch), support for 5GHz, and two radios usable >> simultaneously (which Babel is able to use for avoiding intra-route >> interference). > > With the current chaos calmer code (using linux 3.18) I get a > downstream rate of 560mbits and an upstream of 146 on the ethernet. > > The ratio used to be closer to 340/180. > > So much else in my lab (notably the tcps) has changed since the last > time I did benchmarking that I have no idea what to point at, and > openwrt enables the wndr3800 vlan by default, which is not my fav > thing, either, and I haven´t poked into any of it much, being > presently focused on evaluating the latest patchset for minstrel-blues > ( http://www.linuxplumbersconf.org/2014/ocw/sessions/2439 ) right now. > > >> -- Juliusz >> >> ___ >> homene
Re: [homenet] A poll
On 21/02/2015 05:50, Dave Taht wrote: > So a quick poll: Goodie, I love polls (not) ;-) > 0) Have you managed to get ipv6 working at all? If so, how? What sort > of problems did you encounter? Yes. (a) Using SixXs/ayiya. Geek problems (the SixXs geeky registration interface, and the fact that installation is definitely not for the general public). But it works very reliably for a single host. (b) With my current ISP, native dual stack service via a FritzBox. Worked out the box. Until it didn't, when the ISP admitted to switching IPv6 off without warning due to unspecified issues with some customers. Then they switched it on again without explanation, and it works fine again. [Probably, the issue was MTU size problems with a well-known CDN's nearest POP, which was across the Tasman Sea at the time; compounded by Google's recent bad hair week.] I've gone into detail there because for more than a year, my wife was using IPv6 without knowing it (on Windows 8). But when the above mentioned problems occurred, she noticed PDQ and did not have SixXs to fall back on. So we had to disable IPv6 on her machine. Happy Eyeballs did *not* conceal the problem. > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? No, sorry, only one link here. > 2) Have you attempted to get hnetd's prefix distribution system > working? (it supports linux mainline and openwrt presently) No > 3) Do you use ethernet? How many clients in your home are ethernet connected? Normally zero. I would plug in if I hit wireless issues. > 4) Do you use wifi? How many clients are wifi connected? Two to four (house guests get free Wi-Fi ;-). My ancient printer refuses to break, so that is hard wired to a computer. > Do you use range extenders? No > 5) How many devices do you think you will have connected to the > network in your home in 5 years? Let's guess 10. But the interesting questions are how many routers, and will it be dual-homed. > How many now? > > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? No. > 7) Do you use mdns service discovery? No > 8) Why are you here? (especially, if your answers to 0-2, are "no") http://tools.ietf.org/html/rfc3935 Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] OpenWRT hardware [was: A poll]
On Feb 20, 2015, at 5:22 PM, Dave Taht wrote: > Despite evaluating well over 60 products and chipsets in the past 3 > years, I have yet to find something as nice as the wndr3800 as either > a R&D or day to day ultra-reliable home router. What about something like the Cubietruck, which isn't strictly a WiFi base station, but could function as one? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
0) Have you managed to get ipv6 working at all? If so, how? What sort of problems did you encounter? I originally had IPv6 service through a tunnel to SixXS, which was OK once I got the details sorted. I'm using a Linksy E4200 with development software from a project at Cisco that includes IPv6 support. Without any announcement to me, Comcast turned on IPv6 service to my house and AIBFM I had a second prefix, advertised from the Linksys home gateway. Interestingly, it did not disrupt my home service at all and I literally discovered the service was on as I was working on a project using IPv6 on the home network. Devices on the network were unexpectedly showing a second prefix, which I checked to confirm was coming through PD to the Linksys home gateway. I turned off the SixXS tunnel, and am now using just IPv6 service from Comcast. 1) Have you attempted to deploy a routing protocol in your home? Which one, and why? No. 2) Have you attempted to get hnetd's prefix distribution system working? (it supports linux mainline and openwrt presently) No. 3) Do you use ethernet? How many clients in your home are ethernet connected? Yes. ~7 devices; some through a homeplug extension 4) Do you use wifi? How many clients are wifi connected? Do you use range extenders? Yes. ~10 devices. I have 3 access points on ethernet back to the home gateway. 5) How many devices do you think you will have connected to the network in your home in 5 years? How many now? 30 devices in 5 years; maybe more if sensors and actuators are available. 15-20 now, depending on how many little devices are connected for projects. 6) Do you use any other network connected technologies (homeplug, 802.14, LTE, etc). If so, which ones, and why? homeplug, 802.15.4 (for projects; not production) 7) Do you use mdns service discovery? Extensively. 8) Why are you here? (especially, if your answers to 0-2, are "no") I'm trying to figure out how we get to a network that provides the services I want, avoids performance issues and runs completely autonomously. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] OpenWRT hardware [was: A poll]
On Fri, Feb 20, 2015 at 12:33 PM, Juliusz Chroboczek wrote: >> I'd be a bit curious to know what people are using for test hardware. > > The WNDR3800/WNDR3700v2 is still my favourite. I've still got a couple > Asus 500GP v1, and they're just fine if you don't need 802.11n and can > fit in the slightly more limited flash. Despite evaluating well over 60 products and chipsets in the past 3 years, I have yet to find something as nice as the wndr3800 as either a R&D or day to day ultra-reliable home router. More generically the ag71xx/ath9k chipsets it used are the most aimiable to hacking on and there are hundreds upon hundreds of current products based on that, like the WZR the homewrt folk used. However single cpus like that with 32k dcache proved not up to the job of 802.11ac and there is a lot of chaos and crap gear going around on that standard. Elsewhere the whole wifi industry is seemingly in a race to the bottom. As one example, I use the nanostation M5s heavily, and they (silently) changed the underlying chipset last year from one with two ethernet interfaces, to 1 connected to a 100Mbit switch. Result - no link status anymore, the impossibility of measuring traffic well across the two interfaces, and an increase of latency under load to the buffering in the switch. The new nanostation IS a bit faster (mips 74k based rather than 24k), and has twice the ram, for the same cost as the old, and it still has 8MB flash, so I should not complain too much, I guess. (My typical topology is 2 nanostations connected to a picostation M2HP AP) I have been seeking an integrated outdoor tri radio replacement for that particular setup for a long time. As for everything else I have evaluated, I am thinking of publishing it all, after I tone down the invective logged in my notes. Most recently I took a look at two 802.11ac products from d-link. https://lists.bufferbloat.net/pipermail/bloat/2015-February/002310.html ubnt is *clued* in comparison to nearly everyone else. > Both models: > > - are well supported by OpenWRT; > - are very difficult to brick (just set up a tftp server and interrupt > the boot sequence to reflash); > - have a manageable built-in switch that's configurable from OpenWRT. > > The WNDR3800 has 16/128 flash/RAM, the 3700v2 16/64, the Asus 8/32. > > The WNDR3800/3700v2 has some other nice features, like a second gigabit > NIC that doesn't go through the internal switch (to get VLANs without > messing with the switch), support for 5GHz, and two radios usable > simultaneously (which Babel is able to use for avoiding intra-route > interference). With the current chaos calmer code (using linux 3.18) I get a downstream rate of 560mbits and an upstream of 146 on the ethernet. The ratio used to be closer to 340/180. So much else in my lab (notably the tcps) has changed since the last time I did benchmarking that I have no idea what to point at, and openwrt enables the wndr3800 vlan by default, which is not my fav thing, either, and I haven´t poked into any of it much, being presently focused on evaluating the latest patchset for minstrel-blues ( http://www.linuxplumbersconf.org/2014/ocw/sessions/2439 ) right now. > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On 20.2.2015, at 22.01, Dave Taht wrote: > On Fri, Feb 20, 2015 at 11:34 AM, Steven Barth wrote: >> >> Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon : >>> Hm, I will have to try it out. Is it in a distribution? >> >> ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. >> >> Manual configuration without hncp is a bit awkward since you need to name >> each link manually and on every router configure the resolver (e.g. >> dnsmasq). I guess we might want to provide a little example for 2 links at >> some point. > I would like to deploy hncp in my upcoming make-wifi-fast testbed. > However the biggest headache is ensuring that all the routers > inbetween have hncp burned into them, and are only acting as relays as > I generally only obtain a few (/60) real IPv6 prefixes per GW and they > only need to be on the APs. > > GW1 - routerA - routerB - routerC - routerD - AP1 > | > GW2 - routerE - routerF - routerG - routerH - AP2 > | > AP3 > > GW3 ... > > (the actual topology of the testbed is way more complex than this > (covering ethernet, wifi, and moca) and I am not going into it here) > > 1) is there a way to configure hncpd as purely a relay, and NOT do any > address assignment at all on routers B,C,D,F,G,H? In theory (=spec), but not in current implementation (I _think_). You do not really need non-linklocal addresses for HNCP, or routing protocol, so as long as there are no hosts on the link.. (traceroute is a bitch though given just linklocals) As workaround in current implementation, if you set it to assign e.g. /80 per link used for your intermediate links, you would have almost all of address space left; however, in your case, I am not sure you can even afford to split one /64 for that purpose. > 2) have you tested that it is indeed possible to get the separate ipv6 > prefixes from GW1,GW2,GW3 to AP1,AP2, AP3? Yes. > 3) Can ULA and "Real" address assignment be distinguished along the > way? I have no problem assigning ULAs to the routers, but dont want to > use up real addresses on them. In theory (=spec), not in current implementation (ULA is actively discouraged in current impl, I cannot remember if there was option to override). > 4) What happens when someone pulls the plug on GW1, it reboots, and > gets a new Ipv6 subnet (I have seen comcast do this to me > every time that happens with the code I have in place now - no > retraction, and I go through hell manually eliminating every former > prefix from the network. Yes. I have upses. And cerowrt, at least, > stays up for 90+ days without a problem. But it happens and sucks when > it does) Renumbering should just work as usual. I.e. rest of nodes should learn of the new prefix, and old one should disappear. -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
> On Feb 20, 2015, at 11:50 AM, Dave Taht wrote: > > The homenet working group has been laboring for several years now to > find ways to make ipv6 more deployable to home (and presumably small > business) users. > > In addition to multiple specification documents some code has been > produced to try and make things easier. At least in the USA, comcast > has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on > their router, and/or is willing to install a custom firmware on their > router to get that, and of course tunneling ipv6 is possible if the > ISP does not support it. > > So a quick poll: > > 0) Have you managed to get ipv6 working at all? If so, how? What sort > of problems did you encounter? > Works fine at both my Cambridge home and my Mountain View Condo. In both cases I’m using Airport Extremes as the home router. In one case it’s a DOCSIS 3.0 modem from Comcast, with the Airports doing PD. In the other case it’s behind a pair of Ubiquity radios homed on a Linux router in turn connected to Comcast business service with PD. > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? > I run OSPF at home in Cambridge, mostly to route in a controlled way among some VLANs I use for isolation purposes. There are trunk VLANs running from the main switch to an access switch in my home office. > 2) Have you attempted to get hnetd's prefix distribution system > working? (it supports linux mainline and openwrt presently) > No. The Airport Extreme IPv6 with PD has been adequate for my needs. > 3) Do you use ethernet? How many clients in your home are ethernet connected? > Yes. Total count excluding 802.11 clients is probably 10-12. 4 macs, a NAS, AppleTV, two Tivos, Sonos bridge, 2 printers. > 4) Do you use wifi? Yes, extensively - In Cambrige to get coverage I have a WiFi AP in each of the 3 floors (Airport Extreme + 2 Airport express. > How many clients are wifi connected? additional 5-7 > Do you use > range extenders? > No, each of the AP’s is wired with Cat5 to a big Cisco Cat3600 switch/router. > 5) How many devices do you think you will have connected to the > network in your home in 5 years? How many now? > In five years, probably at least 50, maybe more if I decide to use WiFi light bulbs and window/door sensors and other random stuff. > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? Not at present. All 802.11AC and N. > > 7) Do you use mdns service discovery? > Yes, extensively. > 8) Why are you here? (especially, if your answers to 0-2, are "no”) Because bridging sucks, and IPv6 allows us to have aminimal-touch routing solution that “just works”. > > > -- > Dave Täht > > http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > > ___ > 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] OpenWRT hardware [was: A poll]
> I'd be a bit curious to know what people are using for test hardware. The WNDR3800/WNDR3700v2 is still my favourite. I've still got a couple Asus 500GP v1, and they're just fine if you don't need 802.11n and can fit in the slightly more limited flash. Both models: - are well supported by OpenWRT; - are very difficult to brick (just set up a tftp server and interrupt the boot sequence to reflash); - have a manageable built-in switch that's configurable from OpenWRT. The WNDR3800 has 16/128 flash/RAM, the 3700v2 16/64, the Asus 8/32. The WNDR3800/3700v2 has some other nice features, like a second gigabit NIC that doesn't go through the internal switch (to get VLANs without messing with the switch), support for 5GHz, and two radios usable simultaneously (which Babel is able to use for avoiding intra-route interference). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
In message , Dave Taht writes: > The homenet working group has been laboring for several years now to > find ways to make ipv6 more deployable to home (and presumably small > business) users. > > In addition to multiple specification documents some code has been > produced to try and make things easier. At least in the USA, comcast > has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on > their router, and/or is willing to install a custom firmware on their > router to get that, and of course tunneling ipv6 is possible if the > ISP does not support it. > > So a quick poll: > > 0) Have you managed to get ipv6 working at all? If so, how? What sort > of problems did you encounter? HE tunnel to a FreeBSD base router. dhclient-exit-hooks are used to automatically reconfigure the tunnel on IPv4 renumber events. HE tunnel to a MacBookPro running 10.8.5. The kernel panic when suspending the MacBook with the tunnel enabled. > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? no. > 2) Have you attempted to get hnetd's prefix distribution system > working? (it supports linux mainline and openwrt presently) no. > 3) Do you use ethernet? How many clients in your home are ethernet > connected? yes. 5 > 4) Do you use wifi? How many clients are wifi connected? Do you use > range extenders? yes. 9 to over 30. This is bridged to the ethernet segment. no range extenders.` > 5) How many devices do you think you will have connected to the > network in your home in 5 years? How many now? 20+ > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? no > 7) Do you use mdns service discovery? Some of the machine use it automaticall. > 8) Why are you here? (especially, if your answers to 0-2, are "no") > -- > Dave Tht > > http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
Am 20. Februar 2015 21:01:50 MEZ, schrieb Ted Lemon : >I'd be a bit curious to know what people are using for test hardware. >That's a big issue for me. I have a WNDR3800 as an internal router, >and a Mac Mini as my edge router, and haven't had time to really try to >make HNCP and Babel work with them. Making IPv6 prefix delegation >work on a stock Ubuntu device is not seamless. :/ Buffalo wzr600dhp with some bleeding edge openwrt w/ hnetd (hncp + dhcpv6pd) etc. as primary router + small number of wndr3800 and / or tplinks for testing openwrt and hncp. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
I'd be a bit curious to know what people are using for test hardware. That's a big issue for me. I have a WNDR3800 as an internal router, and a Mac Mini as my edge router, and haven't had time to really try to make HNCP and Babel work with them. Making IPv6 prefix delegation work on a stock Ubuntu device is not seamless. :/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 11:34 AM, Steven Barth wrote: > > > Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon : >>Hm, I will have to try it out. Is it in a distribution? > > ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. > > Manual configuration without hncp is a bit awkward since you need to name > each link manually and on every router configure the resolver (e.g. dnsmasq). > I guess we might want to provide a little example for 2 links at some point. I would like to deploy hncp in my upcoming make-wifi-fast testbed. However the biggest headache is ensuring that all the routers inbetween have hncp burned into them, and are only acting as relays as I generally only obtain a few (/60) real IPv6 prefixes per GW and they only need to be on the APs. GW1 - routerA - routerB - routerC - routerD - AP1 | GW2 - routerE - routerF - routerG - routerH - AP2 | AP3 GW3 ... (the actual topology of the testbed is way more complex than this (covering ethernet, wifi, and moca) and I am not going into it here) 1) is there a way to configure hncpd as purely a relay, and NOT do any address assignment at all on routers B,C,D,F,G,H? 2) have you tested that it is indeed possible to get the separate ipv6 prefixes from GW1,GW2,GW3 to AP1,AP2, AP3? 3) Can ULA and "Real" address assignment be distinguished along the way? I have no problem assigning ULAs to the routers, but dont want to use up real addresses on them. 4) What happens when someone pulls the plug on GW1, it reboots, and gets a new Ipv6 subnet (I have seen comcast do this to me every time that happens with the code I have in place now - no retraction, and I go through hell manually eliminating every former prefix from the network. Yes. I have upses. And cerowrt, at least, stays up for 90+ days without a problem. But it happens and sucks when it does) > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
>So a quick poll: > >0) Have you managed to get ipv6 working at all? If so, how? What sort >of problems did you Yes. Most foss router software sucked with v6. Tried to fix some things. Still not 100% convinced. > >1) Have you attempted to deploy a routing protocol in your home? Which >one, and why? Well babels & autoisis but only for testing purposes. My production network is still single link. > >2) Have you attempted to get hnetd's prefix distribution system >working? (it supports linux mainline and openwrt presently) Yes > >3) Do you use ethernet? How many clients in your home are ethernet >connected? 3 to 4 > >4) Do you use wifi? How many clients are wifi connected? Do you use >range extenders? Yes. 5 to 8. No. > >5) How many devices do you think you will have connected to the >network in your home in 5 years? How many now? I guess 50-100% increase. > >6) Do you use any other network connected technologies (homeplug, >802.14, LTE, etc). If so, which ones, and why? Does bluetooth count? Otherwise 3.5g as connectivity backup. > >7) Do you use mdns service discovery? Seldom. When setting up my printer. Seldomly the .local resolving.___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Agree. I would not architect around multi-hop multicast, subnet OK, targeted probably. Not sure everyone has had the pleasure of running large IP multicast infrastructures running video, it is a wonderful challenge. It also has the side benefit of encouraging poorly designed applications. Interoperability on even core routers for IP multicast barely exists. In a home environment, although smaller, will be even less wonderful. Just the race conditions between PIM and the IGP are always challenging. On 2/20/15, 1:50 PM, "Joel M. Halpern" wrote: >It seems pretty clear that over time, the bulk of video will be unicast, >in order to meet on-demand needs. There will always be a few items that >folks really want to watch live, and thus where multicast may add value. > But making multicast the design driver for home networking >archtiecture seems backwards to me. > >Yours, >Joel > >On 2/20/15 1:22 PM, Dave Taht wrote: >> On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson >>wrote: >>> On Fri, 20 Feb 2015, Toerless Eckert wrote: >>> So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. >>> >>> >>> I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD >>>when >>> they receive two simultaneous IPTV streams when doing channel >>>switching. >>> >>> So it's not only about bandwidth, but about how much traffic these >>>kinds of >>> devices are designed to receive. >>> >>> Also, remember that we're going to 4k IPTV streams that might be in >>>the 20 >>> megabit/s range, and we might be doing multiples of them. All devices >>>on the >>> subnet will receive this if there is no MLD/PIM snooping precent. >> >> Is there a formal definition of IPTV? as used here, it seems to imply >>multicast. >> >> Frankly, until now, I was expecting the world to go to a HAS model for >>content, >> especially big content. >> >>> >>> -- >>> Mikael Abrahamssonemail: swm...@swm.pp.se >>> >>> ___ >>> 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] Routing protocol comparison document
Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon : >Hm, I will have to try it out. Is it in a distribution? ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. Manual configuration without hncp is a bit awkward since you need to name each link manually and on every router configure the resolver (e.g. dnsmasq). I guess we might want to provide a little example for 2 links at some point. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
Hi, On Fri, Feb 20, 2015 at 08:50:10AM -0800, Dave Taht wrote: > So a quick poll: > > 0) Have you managed to get ipv6 working at all? If so, how? What sort > of problems did you encounter? Yes, PPPoE/L2TP session to myself as ISP on the other end (so I cheated). > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? Did some testing with HCNP/Babels, to see if it works. But the "production network" is plain flat L2 today. > 2) Have you attempted to get hnetd's prefix distribution system > working? (it supports linux mainline and openwrt presently) Yes, on OpenWRT. Worked. > 3) Do you use ethernet? How many clients in your home are ethernet connected? Yes, ~10-ish. > 4) Do you use wifi? How many clients are wifi connected? Do you use > range extenders? Yes, ~3-5, no. > 5) How many devices do you think you will have connected to the > network in your home in 5 years? How many now? "More" - I see some sensors coming up, and maybe some of these thingies people call "smart phones" even if they are neither smart nor very good phones. > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? No. > 7) Do you use mdns service discovery? Half of the devices are Apple built, so, yes. > 8) Why are you here? (especially, if your answers to 0-2, are "no") To complain about lack of useful source address selection (aka "prefix labeling so users can make an informed choice"), and frown about IETF committee behaviour. Or so. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
It seems pretty clear that over time, the bulk of video will be unicast, in order to meet on-demand needs. There will always be a few items that folks really want to watch live, and thus where multicast may add value. But making multicast the design driver for home networking archtiecture seems backwards to me. Yours, Joel On 2/20/15 1:22 PM, Dave Taht wrote: On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson wrote: On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] A poll
On 02/20/2015 08:50 AM, Dave Taht wrote: The homenet working group has been laboring for several years now to find ways to make ipv6 more deployable to home (and presumably small business) users. In addition to multiple specification documents some code has been produced to try and make things easier. At least in the USA, comcast has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on their router, and/or is willing to install a custom firmware on their router to get that, and of course tunneling ipv6 is possible if the ISP does not support it. So a quick poll: 0) Have you managed to get ipv6 working at all? If so, how? What sort of problems did you encounter? Yes, he. Mostly trying to figure out how to get tunnel endpoints up. 1) Have you attempted to deploy a routing protocol in your home? Which one, and why? no. 2) Have you attempted to get hnetd's prefix distribution system working? (it supports linux mainline and openwrt presently) no. 3) Do you use ethernet? How many clients in your home are ethernet connected? ~ half dozen. 4) Do you use wifi? How many clients are wifi connected? Do you use range extenders? it's hard to keep track of, but 5-10. and I'm not sure what you'd consider the ethernet cable between my house and my friend's house with two AP's on each end to be. 5) How many devices do you think you will have connected to the network in your home in 5 years? How many now? i expect it will be way more than most of us fear/imagine. now: about 10. 6) Do you use any other network connected technologies (homeplug, 802.14, LTE, etc). If so, which ones, and why? Nope. LTE obviously for phones, but I don't think that's what you're asking. 7) Do you use mdns service discovery? Nope. 8) Why are you here? (especially, if your answers to 0-2, are "no") Mostly interested in the naming problem, and the occasional insight as to how service discovery saved $MEGACORP from the dustbin of history. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Client roaming [was: Routing protocol comparison document]
>> - have clients talk stub RP + stub HNCP, be done with it > if we want to require changes to clients, I have all kinds of ideas how > to solve this in other ways than you propose. Please share. We might not implement them, but we'll certainly listen. (Note that we're not *requiring* changes to hosts, we're just proposing optional host changes that are likely to enhance the user experience. I'm pretty sure that's consistent with Homenet's charter.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
On 20.2.2015, at 18.50, Dave Taht wrote: > The homenet working group has been laboring for several years now to > find ways to make ipv6 more deployable to home (and presumably small > business) users. > > In addition to multiple specification documents some code has been > produced to try and make things easier. At least in the USA, comcast > has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on > their router, and/or is willing to install a custom firmware on their > router to get that, and of course tunneling ipv6 is possible if the > ISP does not support it. > > So a quick poll: > > 0) Have you managed to get ipv6 working at all? If so, how? What sort > of problems did you encounter? Yes. Used to be he.net tunnel and now 6rd Sonera right up to my home (VDSL2). > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? OSPFv3 at some point and nowadays Babel. Obvious reasons, homenet ;) > 2) Have you attempted to get hnetd's prefix distribution system > working? (it supports linux mainline and openwrt presently) Yes. > 3) Do you use ethernet? How many clients in your home are ethernet connected? Dozen-ish. > 4) Do you use wifi? How many clients are wifi connected? Do you use > range extenders? Half dozen. No range extenders. > 5) How many devices do you think you will have connected to the > network in your home in 5 years? How many now? <20 now. Probably 30+ in 5y. > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? LTE. Fallback connectivity. > 7) Do you use mdns service discovery? I used to. OS X 10.10 broke it on wlan pretty much. (ping foo.local => ‘foo who?’. ping foo.lan => ok.. sigh.) > 8) Why are you here? (especially, if your answers to 0-2, are “no") I wonder about it at times. Bad habit? Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
On Fri, 20 Feb 2015, Dave Taht wrote: 1) Have you attempted to deploy a routing protocol in your home? Which one, and why? Home, HE tunnel. 2) Have you attempted to get hnetd's prefix distribution system working? (it supports linux mainline and openwrt presently) Yes, I had this working, but since the routers I had available (WNDR3800) didn't perform forwarding quickly enough for my everyday needs, I didn't put them into "production". 3) Do you use ethernet? How many clients in your home are ethernet connected? Well, since 802.11 is ethernet as well I will interpret this as "how many devices in your home use cable", and say 9. 4) Do you use wifi? How many clients are wifi connected? Do you use range extenders? I have approximately 8-10 devices connecting using wifi, 6 of them more frequently than the others. I do not use wifi range extenders. 5) How many devices do you think you will have connected to the network in your home in 5 years? How many now? Good question, I'd say increase of 10 at least, I presume by then I will have some kind of "smart home" stuff such as sensors or alike. 6) Do you use any other network connected technologies (homeplug, 802.14, LTE, etc). If so, which ones, and why? Well, our mobile phones speak LTE, but apart from that it's the bluetooth usage that apples does without me having to know much about it. 7) Do you use mdns service discovery? No, I use single subnet. 8) Why are you here? (especially, if your answers to 0-2, are "no") I want multi-subnet home to work for everyday users such as my mom. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson wrote: > On Fri, 20 Feb 2015, Toerless Eckert wrote: > >> So foremost, it would be good to understand if there really is home L2 >> equipment that MUST see MLD to operate correctly. Otherwise i'd happily >> ignore the problem and say there is enough bandwidth to just NOT DO snooping >> but have multicast be flooded in the L2 segments. > > > I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when > they receive two simultaneous IPTV streams when doing channel switching. > > So it's not only about bandwidth, but about how much traffic these kinds of > devices are designed to receive. > > Also, remember that we're going to 4k IPTV streams that might be in the 20 > megabit/s range, and we might be doing multiples of them. All devices on the > subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Markus Stenberg wrote: - have clients talk stub RP + stub HNCP, be done with it Oooh, if we want to require changes to clients, I have all kinds of ideas how to solve this in other ways than you propose. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on > service discovery. "Cooperate" is such a strong word. :) They are aware of the issue, they will be kept informed as to how the issue is progressing and what homenet and dnsext are doing to tackle the issue, and they know what their options are. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks, Barbara. Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on service discovery. On Fri, Feb 20, 2015 at 02:37:38PM +, STARK, BARBARA H wrote: > > There are good proposal how to do servicce discovery in homenets or the > > like with DNS-SD (/mDNS), but i think we should still worry about > > compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are > > IMHO better solved with router-level "proxy" > > solutions than with ASM IP multicast. > > FYI. I did a presentation to DLNA (which has a lot of key UPnP people) that > warned them to start thinking about service discovery in the multi-router > world, and the world where more and more Wi-Fi APs are limiting the multicast > that makes it to Wi-Fi devices. I mentioned the DNS-SD proxy work, homenet, > and told them: > " - People have started to study the current quantity of multicast traffic > and its impact on power consumption by battery-operated Wi-Fi devices. > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 > http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-00 > - Concern is growing and proposals are starting to appear for ways to > decrease the quantity of multicast messages. > http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 " > > My recommendations were that they had 2 basic options of either also > supporting DNS-SD / mDNS for service discovery, or defining a SSDP proxy > similar to what I expect will be done for DNS-SD. Anyway, I told them I'd > keep them updated on the state of affairs regarding this issue. > Barbara -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
On Fri, Feb 20, 2015 at 11:50 AM, Dave Taht wrote: > The homenet working group has been laboring for several years now to > find ways to make ipv6 more deployable to home (and presumably small > business) users. > > In addition to multiple specification documents some code has been > produced to try and make things easier. At least in the USA, comcast > has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on > their router, and/or is willing to install a custom firmware on their > router to get that, and of course tunneling ipv6 is possible if the > ISP does not support it. > > So a quick poll: > > 0) Have you managed to get ipv6 working at all? If so, how? What sort > of problems did you encounter? > Yes. Both hurricane electric tunnel and Comcast native IPv6. Getting the HE tunnel configured properly is somewhat a pain, as the terminology on OpenWrt is slightly different than that used by HE. The native IPv6 from Comcast has been fine. > > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? > Babel. Out of the box in CeroWrt. > > 2) Have you attempted to get hnetd's prefix distribution system > working? (it supports linux mainline and openwrt presently) > > 3) Do you use ethernet? How many clients in your home are ethernet > connected? > Dunno exactly. Probably around 8-10 devices. > > 4) Do you use wifi? Yes. > How many clients are wifi connected? maybe 8-10 devices. > Do you use > range extenders? > No > > 5) How many devices do you think you will have connected to the > network in your home in 5 years? 25. > How many now? > Maybe 16. > > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? > No. > > 7) Do you use mdns service discovery? > Yes. > > 8) Why are you here? (especially, if your answers to 0-2, are "no") > > > -- > Dave Täht > > http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > > ___ > 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] More about marginal links [was: Routing protocol comparison document]
> > Does it need to be a routing protocol? Just to throw another possible > > protocol into the mix being tossed around (like we don't have enough), > > I don't think current protocols used by ISPs or enterprises fits our plug&play > requirements. Also, there is a lot more wireless in homes. That doesn't mean > we cannot build on current protocols. ??? Huh? IEEE 1905.1 is being pushed by the likes of Broadcom, Qualcomm, MStar Semiconductor. They've suggested they want to have it in their Wi-Fi, MoCA, HomePlug, and Ethernet products, that are targeted at the CE industry. The certification is being offered by HomePlug Alliance. While Orange and AT&T have expressed an interest (because helping customers with their home networking issues is a huge customer care cost), I wouldn't call a "protocol used by ISPs". And enterprises?! I don't think so. Enterprises are definitely *not* the target audience. > > I'd like to suggest that a non-routing protocol be considered for topology > discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help > with > this. It can provide L1 and L2 topology info with link metrics, and identify > intervening bridges that support LLDP for IEEE 802.1 bridge discovery. I > wouldn't want individual devices all doing their own 1905 topology discovery - > - that's too chatty. But if the all the homenet routers did, and then > advertised > a "service" (DNS-SD) that provided a link to a router-provider HTML page > with the topology and metric info the router can discover provided in a > standardized XML or JSON syntax, then everything who can discover that > service (on each router) would have access to this info. Applications could > also make use of this info to do intelligent source address selection in a > multi- > WAN-interface network, because routers could report on the speed of their > WAN connections, as well. > > My thoughts are as follows: sub-IP mechanisms provide usable metrics. > Somewhere, near to L3 routing, this information is translated to a > dimensionless cost metric for each link, where a link is a sub-IP path between > two routers. Cost is not symmetric, cost A->B can differ from B->A. It is the > routing protocol to distribute this information in the routing domain. I don't understand your point here, and whether you're trying to calculate the cost of running a L7 (application) protocol, or the relative cost of using different routes? Note that all protocols used to supply info to routing configuration applications are operating at the application layer (L7). HNCP is a L7 protocol. IEEE 1905.1 is a L7 protocol. As are IS-IS, and HTTP. The question is "what information does a router's routing configuration application need to properly configure routing behavior?" Once you figure out the info you need, then you can figure out the various options for getting that info to the router. It's not always necessary to multicast or broadcast all the information all over the place. Sometimes it's enough (and more efficient) to broadcast the existence (and where to get) the information, and then just let routers (or other devices) who want the info to go and ask for the info (unicast). If info changes, you can broadcast a message saying something changed, an d then let interested devices query to find out what the change was. You could even stick a "for more info" TLV in HNCP that supplies the URL of a router's info-providing web page. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi Barbara, > OTT video does not use multicast. IPTV deployments do use multicast. Those > that I'm aware of require use of the provider-supplied CE router, which has > an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN > multicast management. Where Wi-Fi distribution of these multicast streams is > supported, it is only done on a dedicated (and highly managed and somewhat > proprietary) Wi-Fi network, that is distinct from the general-purpose (and > not "professionally" managed) Wi-Fi network. The LAN interfaces of the > provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from > flooding the general-purpose network interfaces with large multicast streams. > There may also be a coax networking interface. If there is, this also tends > to be dedicated and highly managed. Where Ethernet is used for distribution > of multicast, it is done so that the provider STBs are all attached to the > provider CE router via the same Ethernet port (and no other devices use that > port) and the re are no intervening routers. I mentioned at the last IETF that I expect some "home networks" to have managed and unmanaged segments. I don't consider the dedicated, managed segments to be part of the homenet domain. I would hope that the provider-supplied CE router would support homenet on its general purpose network interfaces. > > I'd be curious to learn about multicast IPTV deployments that allow users to > supply their own CE routers and send multicast streams on network segments > that are also used for general-purpose home networking (especially > general-purpose Wi-Fi networks). The above is correct. Provider-supplied CPEs are currently necessary and intermediate routers are not supported. The TV streams can be on a separate VLAN. But this is what is currently done because of the difficulty of doing it over the regular home network. It doesn't mean we should design Homenet in the same way. I'd rather see that providers supply Homenet routers to their customers and that the multicast TV streams just work. Cheers, Sander ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> I am not mandating that each and every device is in its own broadcast > domain, I am however advocating that we leave the model that has been > prevalent for 10-15 years at least, ie that a home gateway has a "WAN" > port and 4 "LAN" ports, and these 4 ports are bridged. You certainly have a point -- that's something we never discussed, and it appears that there's no consensus. > I'm saying the typical device should have 4-5 "L3" ports. You're then > free to connect one of these to your L2 switch if you so please. I'll just point out that on all the hardware I know this is configurable -- it's quite possible to set up an OpenWRT router to put each Ethernet port on a different VLAN. So perhaps a Homenet router could ship with the LAN ports bridged, and have a configuratifon option somewhere in the "Beware the tiger" tab of the "Advanced" menu that allows unbridging selected ports? (I'm sure somebody will point out that the right configuration could be chosen automatically, but I'm not sure I'm comfortable with the set of interfaces changing at runtime on a home router.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] A poll
The homenet working group has been laboring for several years now to find ways to make ipv6 more deployable to home (and presumably small business) users. In addition to multiple specification documents some code has been produced to try and make things easier. At least in the USA, comcast has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on their router, and/or is willing to install a custom firmware on their router to get that, and of course tunneling ipv6 is possible if the ISP does not support it. So a quick poll: 0) Have you managed to get ipv6 working at all? If so, how? What sort of problems did you encounter? 1) Have you attempted to deploy a routing protocol in your home? Which one, and why? 2) Have you attempted to get hnetd's prefix distribution system working? (it supports linux mainline and openwrt presently) 3) Do you use ethernet? How many clients in your home are ethernet connected? 4) Do you use wifi? How many clients are wifi connected? Do you use range extenders? 5) How many devices do you think you will have connected to the network in your home in 5 years? How many now? 6) Do you use any other network connected technologies (homeplug, 802.14, LTE, etc). If so, which ones, and why? 7) Do you use mdns service discovery? 8) Why are you here? (especially, if your answers to 0-2, are "no") -- Dave Täht http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 20, 2015, at 11:33 AM, Juliusz Chroboczek wrote: >> Has the group considered a Bier model for multicast in the home? > > As in a place where you put dead people? Bier is a new working group in the routing area. https://datatracker.ietf.org/wg/bier/charter/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> L3 - route injection (got a routing protocol there already, use it) Yes, just put a stub router on the host and advertise /128. As far as I'm aware, current HNCP doesn't provide a way for a host to request a subnet-independent /128. What's the thinking on that? Just grab a /128 from whichever subnet you happen to be connected to at boot, and advertise that? > L3.5 - SHIM6. not deployable > L4/L5 - MP-TCP > L5/L7 - MOSH I don't think that's specific to Homenet -- being able to deal with multiple addresses that change over time is something that our stacks don't deal with very well. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Has the group considered a Bier model for multicast in the home? As in a place where you put dead people? Please explain. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
> If you have hardware with a built-in switch that can report the link-speed, The WNDR3700v2 under OpenWRT appears to do so: # swconfig dev switch0 show | grep 'link:' link: port:0 link:down link: port:1 link:down link: port:2 link:up speed:100baseT full-duplex link: port:3 link:down link: port:4 link:down link: port:5 link:up speed:1000baseT full-duplex txflow rxflow auto but to use this information, you need to know: 1. that vlan1 on eth0 is connected to ports 0 through 3 of switch0; 2. that neighbour fe80::dead:beef is connected over port 2. You could do (1) with a small amount of model-specific code (yuck), but I have no idea how to do (2). Consult the ND cache to find out the neighbour's MAC, then find a way to snoop on the switch's forwarding table? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Has the group considered a Bier model for multicast in the home? On 2/20/15, 9:41 AM, "Toerless Eckert" wrote: >I have seen more L2 switches that have broken IGMP/MLD snooping than >working ones. I am not aware of real proliferation of PIM snooping. >Snooping in transit LANs with PIM is a bad idea anyhow, and i have >tried to steer any customer who asked me away from it. > >Bidir-PIM makes snooping particularily difficult. For once >you have to track DF-winner election messages (difficult) and >secondly you have to then flood all multicast to all DF winners >because you don't know which group-range is served by which RP. > >IMHO, there is never enough multicast to justify this snooping complexity. >The only thing to worry about is what packets to send out from a router >to ensure the snooping doesn't screw up the traffic flow. > >I would be surprised to find equipemnt that does PIM snooping by default. > >So, i'd recommend to a homenet router: > >-> even if you don't do PIM, send out PIM Hellos. This should > effectively make all stupid "enterprise class" IGMP/MLD snooping > switches (that often have broken IGMP/MLD snooping) send > you all multicast traffic (inhibits snooping). > >-> Still send MLD/IGMP memberships to get traffic through the > L2 home equipment that has likely never heard about PIM. > I'd guess that eg: powerline equipment falls into this > category. > >Cheers >Toerless > >On Fri, Feb 20, 2015 at 11:04:41AM +1100, Andrew Mcgregor wrote: >> Why? PIM and MLD snooping are pretty standard on very low-end >>enterprise >> switches, which will be next year's midrange consumer models. If the >> dumb-as-rocks stuff goes away, that would generally make people happier. >> >> On 20 February 2015 at 05:22, Mikael Abrahamsson >>wrote: >> >> > On Thu, 19 Feb 2015, Ted Lemon wrote: >> > >> > On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson >>wrote: >> >> >> >>> I would like my router-to-router links to not have a lot of hosts in >> >>> them if I can avoid it. >> >>> >> >> >> >> Why is that? >> >> >> > >> > If we're going to be routing multicast within the home, we're most >>likely >> > going to have to use some kind of variant of PIM. Asking the L2 >>switches >> > people connect to the router to support both PIM and MLD snooping >>seem like >> > it might be asking too much. >> > >> > I might be wrong though. >> > >> > -- >> > Mikael Abrahamssonemail: swm...@swm.pp.se >> > >> > ___ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >> > >> >> >> >> -- >> Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221 > >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > >-- >--- >Toerless Eckert, eck...@cisco.com > >___ >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] Routing protocol comparison document
> > I don't know. Homenet multicast is an open issue. But I don't think this > use case represents a serious problem, because as far as I can tell streaming > video is not done using multicast in practice anyway. > > Sorry, bad assumption. I just finished working on a TV streaming project for > an ISP and there is lots of multicast there. All live TV channel streams to > STBs > are multicast and this is a common setup amongst ISPs. OTT video does not use multicast. IPTV deployments do use multicast. Those that I'm aware of require use of the provider-supplied CE router, which has an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN multicast management. Where Wi-Fi distribution of these multicast streams is supported, it is only done on a dedicated (and highly managed and somewhat proprietary) Wi-Fi network, that is distinct from the general-purpose (and not "professionally" managed) Wi-Fi network. The LAN interfaces of the provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from flooding the general-purpose network interfaces with large multicast streams. There may also be a coax networking interface. If there is, this also tends to be dedicated and highly managed. Where Ethernet is used for distribution of multicast, it is done so that the provider STBs are all attached to the provider CE router via the same Ethernet port (and no other devices use that port) and there are no intervening routers. I mentioned at the last IETF that I expect some "home networks" to have managed and unmanaged segments. I don't consider the dedicated, managed segments to be part of the homenet domain. I would hope that the provider-supplied CE router would support homenet on its general purpose network interfaces. I'd be curious to learn about multicast IPTV deployments that allow users to supply their own CE routers and send multicast streams on network segments that are also used for general-purpose home networking (especially general-purpose Wi-Fi networks). BTW, the dedicated, highly-managed and somewhat proprietary Wi-Fi delivery of IPTV multicast streams has been very successful. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
> Op 20 feb. 2015, om 15:55 heeft STARK, BARBARA H het > volgende geschreven: > >> So what I want to see is a proposal for a routing protocol that specify link >> metrics for a set of commonly used link types in homes. This spec could be >> BCP. > > Does it need to be a routing protocol? Just to throw another possible > protocol into the mix being tossed around (like we don't have enough), I don't think current protocols used by ISPs or enterprises fits our plug&play requirements. Also, there is a lot more wireless in homes. That doesn't mean we cannot build on current protocols. > I'd like to suggest that a non-routing protocol be considered for topology > discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help > with this. It can provide L1 and L2 topology info with link metrics, and > identify intervening bridges that support LLDP for IEEE 802.1 bridge > discovery. I wouldn't want individual devices all doing their own 1905 > topology discovery -- that's too chatty. But if the all the homenet routers > did, and then advertised a "service" (DNS-SD) that provided a link to a > router-provider HTML page with the topology and metric info the router can > discover provided in a standardized XML or JSON syntax, then everything who > can discover that service (on each router) would have access to this info. > Applications could also make use of this info to do intelligent source > address selection in a multi-WAN-interface network, because routers could > report on the speed of their WAN connections, as well. My thoughts are as follows: sub-IP mechanisms provide usable metrics. Somewhere, near to L3 routing, this information is translated to a dimensionless cost metric for each link, where a link is a sub-IP path between two routers. Cost is not symmetric, cost A->B can differ from B->A. It is the routing protocol to distribute this information in the routing domain. Teco > > Just a thought. I've been working on trying to get myself to write a > contribution describing the idea of the router-provided info service for a > while now. > Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On 20.2.2015, at 15.22, Mikael Abrahamsson wrote: >> Back to the subject: What are the requirements of a high performance WiFi >> home network to the homenet routing protocol? I guess we don't know. > Within the current framework to solve this problem with what exists today > when it comes to clients, I would say we need either: > > 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the > APs using the same SSID, so the SSID can have the same L2 domain. This would > probably mean we want to increase MTU on the physical links to avoid > fragmentation. Messy. Possibly we could advertise lower MTU on the wifi > network to minimize fragmentation if we don't raise MTU. > > 2. We set up some kind of L2 switching domain between the APs. This would > require VLAN support in the HGWs, and something to set this up with loop > avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as > control plane, that way we could possibly run the same IGP for both L2 and > L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds > like an understatement. > > Frankly, I don't know how to solve this without a lot of complication. > > We need clients to be able to change IPv6 addresses without losing existing > connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two > connections at once and inform the application that one address is going away > soon so it can do its thing to try to handle this? What if clients do not need to change addresses? In 2 words: Route /128s. Two ways to do it: - have clients talk stub RP + stub HNCP, be done with it - have first-hop router do proxying for them by advertising the /128s only when they are connected to it (may have issues with e.g. clients assuming /64, but nothing a redirect could not fix, hopefully) This L3(ish) solution actually works for all apps, unlike L4+ solutions some people advocated. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 02/18/2015 11:54 PM, Mikael Abrahamsson wrote: On Wed, 18 Feb 2015, Michael Thomas wrote: But we're not talking about an interpreted language in the forwarding plane, right? Is the load from routing protocols we're talking about likely to have any noticeable effect on the the forwarding rate? even when you're running hot on the routing daemon side, you're not too likely to be running hot on the forwarding side because something is hosed, right? The complaints about the Erlang implementation has so far been on memory and flash footprint, not CPU resources and affecting performance. The above is true for most interpreted languages, such as python etc. When you install the environment, they're going to use noticable memory and disk space. Next application that needs the environment won't add much to the footprint though, it's the environment itself that takes space. My Python executable on my debian box is 2.7 megabyte. I don't know about the rest. So if one wants to run Python on the home gateway, that would also use significant space. But forwarding will be done the same way regardless of what routing protocol we use, that'll be done by the kernel. The routing protocol just programs the RIB/FIB. One nice side-effect of putting in, say, a headless android into a router is that it would forevermore insure that there's plentiful memory, just like it did for cell phones. It's not like we physically can't get enough ram/flash into those boxen after all... it's the will to bear the cost that's really at issue. A better development environment for home routers would *really* help development efforts along. From what I've seen they suck out loud. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Were you before me? http://www.ietf.org/mail-archive/web/homenet/current/msg00971.html (November 2011) More than three years later, same discussion. That makes me sad. Teco > Op 20 feb. 2015, om 15:14 heeft Ted Lemon het volgende > geschreven: > > On Feb 20, 2015, at 8:22 AM, Mikael Abrahamsson wrote: >> 2. We set up some kind of L2 switching domain between the APs. This would >> require VLAN support in the HGWs, and something to set this up with loop >> avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as >> control plane, that way we could possibly run the same IGP for both L2 and >> L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds >> like an understatement. > > Long ago I proposed using Trill to make this work, but nobody listened... > > :) > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
At the end if the day, L3 will need to get services from L2 to set and managed constrained path based on Link attributes. 802.1Q is specifying multi-path short path bridging for this purpose and will allow to maximize the BW provide by the whole topology of the home network in a loop free manner. L3 and L2 for this manner could share the same IS-IS topology DB. All the elements are there but require to make a joint IEEE 702.1 and IETF effort /Philippe Philippe Klein, PhD Broadcom BTG Sent from my iPhone On Feb 20, 2015, at 16:56, STARK, BARBARA H wrote: >> So what I want to see is a proposal for a routing protocol that specify link >> metrics for a set of commonly used link types in homes. This spec could be >> BCP. > > Does it need to be a routing protocol? Just to throw another possible > protocol into the mix being tossed around (like we don't have enough), I'd > like to suggest that a non-routing protocol be considered for topology > discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help > with this. It can provide L1 and L2 topology info with link metrics, and > identify intervening bridges that support LLDP for IEEE 802.1 bridge > discovery. I wouldn't want individual devices all doing their own 1905 > topology discovery -- that's too chatty. But if the all the homenet routers > did, and then advertised a "service" (DNS-SD) that provided a link to a > router-provider HTML page with the topology and metric info the router can > discover provided in a standardized XML or JSON syntax, then everything who > can discover that service (on each router) would have access to this info. > Applications could also make use of this info to do intelligent source > address selection in a multi-WAN-interface ne tw > ork, because routers could report on the speed of their WAN connections, as > well. > > Just a thought. I've been working on trying to get myself to write a > contribution describing the idea of the router-provided info service for a > while now. > Barbara > > ___ > 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] More about marginal links [was: Routing protocol comparison document]
> So what I want to see is a proposal for a routing protocol that specify link > metrics for a set of commonly used link types in homes. This spec could be > BCP. Does it need to be a routing protocol? Just to throw another possible protocol into the mix being tossed around (like we don't have enough), I'd like to suggest that a non-routing protocol be considered for topology discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help with this. It can provide L1 and L2 topology info with link metrics, and identify intervening bridges that support LLDP for IEEE 802.1 bridge discovery. I wouldn't want individual devices all doing their own 1905 topology discovery -- that's too chatty. But if the all the homenet routers did, and then advertised a "service" (DNS-SD) that provided a link to a router-provider HTML page with the topology and metric info the router can discover provided in a standardized XML or JSON syntax, then everything who can discover that service (on each router) would have access to this info. Applications could also make use of this info to do intelligent source address selection in a multi-WAN-interface netw ork, because routers could report on the speed of their WAN connections, as well. Just a thought. I've been working on trying to get myself to write a contribution describing the idea of the router-provided info service for a while now. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I have seen more L2 switches that have broken IGMP/MLD snooping than working ones. I am not aware of real proliferation of PIM snooping. Snooping in transit LANs with PIM is a bad idea anyhow, and i have tried to steer any customer who asked me away from it. Bidir-PIM makes snooping particularily difficult. For once you have to track DF-winner election messages (difficult) and secondly you have to then flood all multicast to all DF winners because you don't know which group-range is served by which RP. IMHO, there is never enough multicast to justify this snooping complexity. The only thing to worry about is what packets to send out from a router to ensure the snooping doesn't screw up the traffic flow. I would be surprised to find equipemnt that does PIM snooping by default. So, i'd recommend to a homenet router: -> even if you don't do PIM, send out PIM Hellos. This should effectively make all stupid "enterprise class" IGMP/MLD snooping switches (that often have broken IGMP/MLD snooping) send you all multicast traffic (inhibits snooping). -> Still send MLD/IGMP memberships to get traffic through the L2 home equipment that has likely never heard about PIM. I'd guess that eg: powerline equipment falls into this category. Cheers Toerless On Fri, Feb 20, 2015 at 11:04:41AM +1100, Andrew Mcgregor wrote: > Why? PIM and MLD snooping are pretty standard on very low-end enterprise > switches, which will be next year's midrange consumer models. If the > dumb-as-rocks stuff goes away, that would generally make people happier. > > On 20 February 2015 at 05:22, Mikael Abrahamsson wrote: > > > On Thu, 19 Feb 2015, Ted Lemon wrote: > > > > On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson wrote: > >> > >>> I would like my router-to-router links to not have a lot of hosts in > >>> them if I can avoid it. > >>> > >> > >> Why is that? > >> > > > > If we're going to be routing multicast within the home, we're most likely > > going to have to use some kind of variant of PIM. Asking the L2 switches > > people connect to the router to support both PIM and MLD snooping seem like > > it might be asking too much. > > > > I might be wrong though. > > > > -- > > Mikael Abrahamssonemail: swm...@swm.pp.se > > > > ___ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > > > -- > Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221 > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> There are good proposal how to do servicce discovery in homenets or the > like with DNS-SD (/mDNS), but i think we should still worry about > compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are > IMHO better solved with router-level "proxy" > solutions than with ASM IP multicast. FYI. I did a presentation to DLNA (which has a lot of key UPnP people) that warned them to start thinking about service discovery in the multi-router world, and the world where more and more Wi-Fi APs are limiting the multicast that makes it to Wi-Fi devices. I mentioned the DNS-SD proxy work, homenet, and told them: " - People have started to study the current quantity of multicast traffic and its impact on power consumption by battery-operated Wi-Fi devices. http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-00 - Concern is growing and proposals are starting to appear for ways to decrease the quantity of multicast messages. http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 " My recommendations were that they had 2 basic options of either also supporting DNS-SD / mDNS for service discovery, or defining a SSDP proxy similar to what I expect will be done for DNS-SD. Anyway, I told them I'd keep them updated on the state of affairs regarding this issue. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 10:57:24AM +0100, Mikael Abrahamsson wrote: > I have thought of this as mostly L3 network. I thought the service > discovery problem between subnets was being solved or had been solved. > >From the discussion here the past few days it's clear to me now that the > mind image of what a future homenet is differs a lot between participants > in this working group. There are good proposal how to do servicce discovery in homenets or the like with DNS-SD (/mDNS), but i think we should still worry about compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are IMHO better solved with router-level "proxy" solutions than with ASM IP multicast. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Snooping switches would certainly be a good reason to prefer MLD proxying over PIM in homenet. There could be other reasons like reducing codeside (thats Pierre pet reason ;-). But trying to be compatible with snooping switches also implies that improvements in MLD that we might wnat then for homenet would break interoperability with that L2 equipment, because you must assume this L2 equipment will only correctly react to MLD message and message sequences as they have been defined 8 years ago. So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I only remember vaguely one old data point that seemed to indicate that some powerline equipment was doing snooping and you couldn't switch it off. can't find the pointers to this data point though. Would love to know if any powerline standards exist and what they say about MLD... Worst case, whatever the preferred solution for IP multicast is in homenet, if we identify that there is L2 equipment that MUST get MLD, we need to ALSO have homenet routers send out MLDv1/v2 backward compatible MLD messages to keep that L2 equipment happy. That is also pretty much what we do in commercial environments too, for example in satellite links where we really want to connect router-to-router signaling with PIM, but those routers are set up to ALSO send IGMP/MLD to keep the satellite modems happy. Toerless On Thu, Feb 19, 2015 at 07:22:34PM +0100, Mikael Abrahamsson wrote: > On Thu, 19 Feb 2015, Ted Lemon wrote: > > >On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson wrote: > >>I would like my router-to-router links to not have a lot of hosts in them > >>if I can avoid it. > > > >Why is that? > > If we're going to be routing multicast within the home, we're most likely > going to have to use some kind of variant of PIM. Asking the L2 switches > people connect to the router to support both PIM and MLD snooping seem > like it might be asking too much. > > I might be wrong though. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 20, 2015, at 8:22 AM, Mikael Abrahamsson wrote: > 2. We set up some kind of L2 switching domain between the APs. This would > require VLAN support in the HGWs, and something to set this up with loop > avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as > control plane, that way we could possibly run the same IGP for both L2 and > L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds > like an understatement. Long ago I proposed using Trill to make this work, but nobody listened... :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Ole Troan wrote: Frankly, I don't know how to solve this without a lot of complication. why do you think this has to be solved at L2? I don't that's why I wrote the next paragraph outlining L3 solutions. We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? at least you can do: L3 - route injection (got a routing protocol there already, use it) This sounds like it needs at least a coordination protocol between the APs? L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH I would prefer the last two. I use MOSH all the time, it's great. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Op 20 feb. 2015, om 14:22 heeft Ted Lemon het volgende > geschreven: > > So Teco, to satisfy your use case, which I share, you would actually need the > homenet to identify all Wifi access points that are being used to serve > hosts, and treat those as a single subnet, correct? Because I am not optimistic on deployment of mobility protocols in the home, my answer is yes. WiFi APs in same home has same SSID(s). Each SSID provides an IP subnet. Providing multiple SSIDs should be in scope, with and as default SSIDs. Both and differ from my neighbors SSIDs. Al least two directions for a solution: 1) the WLAN controller with tunnels between the APs and the WLC. 2) distribute the AP configuration for APs, either manually or guided by a homenet protocol. I hope we can circumvent VLANs in homenet. An alternative would be /128 prefix routing. Whatever we choose, we have to keep in mind that dual stack operation will not fade away soon. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Mikael, >> Back to the subject: What are the requirements of a high performance WiFi >> home network to the homenet routing protocol? I guess we don't know. > > Within the current framework to solve this problem with what exists today > when it comes to clients, I would say we need either: > > 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the > APs using the same SSID, so the SSID can have the same L2 domain. This would > probably mean we want to increase MTU on the physical links to avoid > fragmentation. Messy. Possibly we could advertise lower MTU on the wifi > network to minimize fragmentation if we don't raise MTU. > > 2. We set up some kind of L2 switching domain between the APs. This would > require VLAN support in the HGWs, and something to set this up with loop > avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as > control plane, that way we could possibly run the same IGP for both L2 and > L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds > like an understatement. > > Frankly, I don't know how to solve this without a lot of complication. why do you think this has to be solved at L2? > We need clients to be able to change IPv6 addresses without losing existing > connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two > connections at once and inform the application that one address is going away > soon so it can do its thing to try to handle this? at least you can do: L3 - route injection (got a routing protocol there already, use it) L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
So Teco, to satisfy your use case, which I share, you would actually need the homenet to identify all Wifi access points that are being used to serve hosts, and treat those as a single subnet, correct? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Teco Boot wrote: Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Within the current framework to solve this problem with what exists today when it comes to clients, I would say we need either: 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the APs using the same SSID, so the SSID can have the same L2 domain. This would probably mean we want to increase MTU on the physical links to avoid fragmentation. Messy. Possibly we could advertise lower MTU on the wifi network to minimize fragmentation if we don't raise MTU. 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Frankly, I don't know how to solve this without a lot of complication. We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks sharing this. What I can add: Our house is a little bit bigger. It was formerly a farmhouse. It has a stone firewall between living room and formerly hay storage place. This firewall is quit good in blocking RF. My "production" network has 2 dual band APs. I have good indoor coverage. In summertime, I use WiFi in my garden to watch live TV (iPhone, iPad, MacBook, Android gear). It is partly testing, partly following Tour de France, news etc. My partner is less a geek and carries the TV, coax and power cables. Still possible with some analogue channels. Soon we have to carry a lot more stuff to decode DTV, this is bad. Or watch over WiFi. I don't want to CAT6 my garden, sorry. Walking from living room to desk to garden means AP switch-over. I used to have 2.4 and 5GHz SSIDs, this doesn't work well. With exact same SSID and keys, handover works. Not well, but it works. With different SSIDs and different IP subnets: no, total failure. There are WiFi AP kits around that operate in same channel and spoof AP BSSID. Roaming is transparent for clients. Nice idea, not accepted by standards bodies nor by industry. Back to my point: I want L3 on each and every homenet box. At the same time, I want high performance wireless links. It must be cheap, I don't want to pay € 1000 for a WLC and €400 for each AP. As long as homenet enlarges my WiFi problem, it is useless for me. And I thought I was candidate for early adoption, as I have multiple APs, a wired backbone, thinking of dual ISP links etc. And as geek, I want to pay a bit more for high performance and I am able to troubleshoot a bit. Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Teco > Op 20 feb. 2015, om 13:17 heeft Mikael Abrahamsson het > volgende geschreven: > > On Fri, 20 Feb 2015, Teco Boot wrote: > >> Do you have CAT6 to WiFi APs in every room? Can you share experience with >> moving WiFi devices? > > No, my apartment is covered by a single 5GHz AP in the center of the > apartment. > > I mainly use cabled connections for media players and similar devices since > they work much better over full duplex gige than over wifi. If I just could > go back to my 1ms RTT Internet access link, things would be a lot better > because my current DOCSIS3 cable connection is a lot worse (for instance when > it comes to RTT and PDV) than my previous connection I had at the previous > apartment which was a lot more consistent. > > I tend to use a CAT6 ethernet adapter in my laptop when I'm at my desk, even > though both my AP and laptop has 802.11ac. Wifi is mostly used to handle > mobile devices such as tablets and mobile phones. > > My experience is that even with state of the art equipment, wifi still is not > even close in quality of experience compared to cable, apart from very light > use where it's still sufficient. > > My experience with multiple APs (from other places) is that clients don't > switch APs easily enough so they're seldom connected to the optimal AP. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Teco Boot wrote: Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? No, my apartment is covered by a single 5GHz AP in the center of the apartment. I mainly use cabled connections for media players and similar devices since they work much better over full duplex gige than over wifi. If I just could go back to my 1ms RTT Internet access link, things would be a lot better because my current DOCSIS3 cable connection is a lot worse (for instance when it comes to RTT and PDV) than my previous connection I had at the previous apartment which was a lot more consistent. I tend to use a CAT6 ethernet adapter in my laptop when I'm at my desk, even though both my AP and laptop has 802.11ac. Wifi is mostly used to handle mobile devices such as tablets and mobile phones. My experience is that even with state of the art equipment, wifi still is not even close in quality of experience compared to cable, apart from very light use where it's still sufficient. My experience with multiple APs (from other places) is that clients don't switch APs easily enough so they're seldom connected to the optimal AP. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Op 20 feb. 2015, om 10:57 heeft Mikael Abrahamsson het > volgende geschreven: > > On Fri, 20 Feb 2015, Andrew Mcgregor wrote: > >> Why? PIM and MLD snooping are pretty standard on very low-end enterprise >> switches, which will be next year's midrange consumer models. If the >> dumb-as-rocks stuff goes away, that would generally make people happier. > > There are enterprise switches out there currently (pretty expensive ones) > that still do not have MLD snooping, and the ones having PIM snooping is most > likely a lot less. I've been in the networking industry for close to 20 > years, the first "bridge" I laid hands on was a pretty advanced thing back in > the time with 3 AUI ports, and could barely do 10 megabit/s. I've then seen > the evolution into 100meg hubs, then 10/100 dual speed hubs (basically two > hubs with a switch in between), to 10/100 switches with all ports switched, > to gig equivalent etc. During this entire time, switches that could do IGMP > snooping has always been substantially more expensive, mostly (I guess) they > couldn't be implemented in pure switch silicon, but always required > administration interface, operating system etc. Still today, these typically > cost 100 USD or more, when you can buy a stupid one for 30USD. So yes, over > time this might change, but I still think there will be cost involved. It > might be that the h omenet "routers" are going to look quite different than the typical router we see today when it comes to phsyical ports. Or perhaps they're only going to have 2-3 ports and the rest is going to be wifi. What do I know. > > What I do know is that so far, cable has always been a lot better than radio. > Lots of support calls to ISPs end up being related to wifi problems. I have > CAT6 to every room in my apartment, but then again, I am not a typical user. > However, I often speak to people who have performance problems who then end > up pulling a physical cable and after that their problems are solved. > > With 60GHz wifi, you're going to need line-of-sight to every AP from the > clients, which will probably be located in the ceiling in every room where > you want good performance. These APs are going to need physical cables for > uplinks to get any meaningful bump in performance. > > I have thought of this as mostly L3 network. What I can add: the multicast snooping feature could be somewhat behind development and deployment of the standards and / or buggy. So some administrators switch off the snooping / rate limiting feature. I do. L3 all the way to switch ports make the network more robust. But this requires L3 forwarding in hardware, multicast routing and adjustments in discovery protocols. Can all multicast forwarding be performed in hardware? Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? Teco > I thought the service discovery problem between subnets was being solved or > had been solved. >> From the discussion here the past few days it's clear to me now that the > mind image of what a future homenet is differs a lot between participants in > this working group. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > 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] Routing protocol comparison document
On Fri, 20 Feb 2015, Andrew Mcgregor wrote: Why? PIM and MLD snooping are pretty standard on very low-end enterprise switches, which will be next year's midrange consumer models. If the dumb-as-rocks stuff goes away, that would generally make people happier. There are enterprise switches out there currently (pretty expensive ones) that still do not have MLD snooping, and the ones having PIM snooping is most likely a lot less. I've been in the networking industry for close to 20 years, the first "bridge" I laid hands on was a pretty advanced thing back in the time with 3 AUI ports, and could barely do 10 megabit/s. I've then seen the evolution into 100meg hubs, then 10/100 dual speed hubs (basically two hubs with a switch in between), to 10/100 switches with all ports switched, to gig equivalent etc. During this entire time, switches that could do IGMP snooping has always been substantially more expensive, mostly (I guess) they couldn't be implemented in pure switch silicon, but always required administration interface, operating system etc. Still today, these typically cost 100 USD or more, when you can buy a stupid one for 30USD. So yes, over time this might change, but I still think there will be cost involved. It might be that the homenet "routers" are going to look quite different than the typical router we see today when it comes to phsyical ports. Or perhaps they're only going to have 2-3 ports and the rest is going to be wifi. What do I know. What I do know is that so far, cable has always been a lot better than radio. Lots of support calls to ISPs end up being related to wifi problems. I have CAT6 to every room in my apartment, but then again, I am not a typical user. However, I often speak to people who have performance problems who then end up pulling a physical cable and after that their problems are solved. With 60GHz wifi, you're going to need line-of-sight to every AP from the clients, which will probably be located in the ceiling in every room where you want good performance. These APs are going to need physical cables for uplinks to get any meaningful bump in performance. I have thought of this as mostly L3 network. I thought the service discovery problem between subnets was being solved or had been solved. From the discussion here the past few days it's clear to me now that the mind image of what a future homenet is differs a lot between participants in this working group. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
> Op 20 feb. 2015, om 09:54 heeft Henning Rogge het volgende > geschreven: > > 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. Great. > >> 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. I wonder. If the change hits the hysteresis threshold, two actions will happen. SPF calculation is triggered and routes may change. This would take place in sub-ms. The other action is sending link state to neighbors or flood over the whole network. That takes time, especially when there is no triggered update, there are some packets queued, there is a shared medium with timer based media access etc. Meanwhile, the topology is not guaranteed to be loop-free. Little you can do on the node itself. OK, we have the enterprise/ISP loop avoidance mechanisms, but to reuse this in homenet? Deploy this year? I highly appreciate your work on olsrd/olsrd2, of course !! Teco ___ 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]
> Op 20 feb. 2015, om 09:22 heeft Henning Rogge het volgende > geschreven: > > 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). 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. 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. Teco ___ 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]
> Op 20 feb. 2015, om 09:04 heeft Henning Rogge het volgende > geschreven: > > 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. > 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. Teco ___ 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
