Re: [homenet] Roaming hosts [was: Routing protocol comparison document]
In message Mark Townsley writes: > When a host connects to a different link covered by a different subnet, > indeed it will require a new IP address. That's pretty fundamental to what > a subnet is. Hosts are getting better and better at handling multiple > addresses, of both versions, coming and going. MPTCP should continue to > help in this regard. I'm a big fan of seeing more and more MPTCP, and I've > been impressed at the ability of modern devices to upgrade their host > stacks in the past 4-5 years (vs. the decade or so before). I'll remain > cautiously hopeful here for the long term. > > In the mean time, I fully expect that to support seamless wifi roaming from > one AP to another there will have to be some sort of bridging or tunneling > (capwap, et. al) taking place to keep the single ethernet wifi subnet alive > for IPv4 and less modern IPv6 hosts. That doesn't mean there will be no > room for routing in the home, as one of the primary motivations for IP > routing is to support diverse media types. i.e, it's much easier I think if > wi-fi only has to worry about roaming within wi-fi, and not MOCA, EoPL, > 802.15.4, Bluetooth LE, etc. as well. > > One day if/when hosts and apps finally become fully resilient to IP address > changes, then it could become much easier on APs as they will have the > chance to simply hand out a new IPv6 address and route, avoiding bridging > and/or tunneling tricks. That could be a nice win for wifi scalability, but > to be honest is shrouded in so many operational practicalities and moving > parts that it's best not to try pretend that this will come to pass even if > we are successful in providing the world with zero-touch IP routing > technology in the home. It could be a very nice bonus, and I hope it > happens, but I wouldn't want to set the bar that high in the near term as > something homenet can make happen on its own. > > - Mark The way this was solved circa early-mid 1990s (with configuration required and a bit of code hack) involved putting a fixed address on the loopback interface. For incoming TCP connections, only an ifconfig lo0 was required. For outbound TCP connections, no MPTCP was needed, just an ability to favor binding to the loopback address on critical applications where an outbound connection is made. This was the code change needed back then (and was tupically done to klogin, and the other kerberos enabled r-commands). Today, with address selection policy (ie: ip6addrctl on BSD), no code changes are needed for outbound TCP connections as well. This type of allocation would work if moving from one AP to another within an administrative domain (within a homenet or from an office to a conferance room at work) but not when roaming from home to the coffee shop wifi AP. Here is one way it might get done. It might be worth considering a multiple means to hand out addresses for lookbacks. For example extensions to DHCP, SLAAC, DHCPv6, would require only minimal host changes. Hosts could also run OSPF and be stub routers (can be dual or multi homed, but no transit). A router can use OSPF link local addresses as it does today and make an implicit request for a loopback address. The implicit request is made by its existance in the topology with no routable address. Allocation can be by the CPE at a provider border for the router itself, mapping OSPF or ISIS router-id to the requested prefix. Explicit requests can be made using a TLV with a MAC associated with a DHCP lease. Together these two TLVs imply a /32 or /128 stub. If a host is dual homed and gets information from DHCP, then when making a request on a second interface, its already allocated /32 and/or /128 or its other MAC can be included in the DHCP request to avoid a second allocation. The router could then advertise an alternate way to reach that loopback. The host would now be a stub reachable via two routers. For the benefit of older OSPF or ISIS implementations if there were such a thing in the home, any /32 or /128 stub can be explicitly advertised into the LSDB. I don't expect a homenet to get overrun with /128 addresses in the OSPF or ISIS LSDB. Hosts with a /128 on its own loopback would use the default route to get to other stubs within the same /64 as its loopback. This would only be updated hosts, so it would be safe to assume they won't make the /128 into a /64. Note that hosts then don't require routeable interface addresses, only an address on the loopback. This works within an administative domain and doesn't require that the other side of a TCP connection to be upgraded (as is the case with MPTCP). There are no TCP stack changes required, but also implementing MPTCP won't hurt when wandering to the coffee shop. Old hosts works as they did before. They get two interface addresses. As long as they send traffic to an interface that is up and gave it a default route things should work. Switch over based on lease expire would be bad with long lease
Re: [homenet] Routing protocol comparison document
> On Feb 25, 2015, at 9:50 PM, Michael Richardson wrote: > > > Ray Hunter wrote: >> I agree that WiFi roaming is a problem that needs addressing in >> Homenet. > > Yes, but can we rule it out of scope for now? Yes, we can. I think the WG needs to focus on securing success before taking on wild success at this moment in time. - Mark > > Can we agree that it's not strictly a routing problem, and that the set of > solutions that we are considering could be used, and that we could also > explain how to do something like automatically setup capwap using HNCP for > discovery, but that we don't have the head-of-queue block on this item for > now? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > 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
Ray Hunter wrote: > I agree that WiFi roaming is a problem that needs addressing in > Homenet. Yes, but can we rule it out of scope for now? Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Wed, Feb 25, 2015 at 9:36 PM, Curtis Villamizar wrote: > In message <87a903ef2j.wl-...@pps.univ-paris-diderot.fr> > Juliusz Chroboczek writes: >> As to wireless links -- as far as I'm aware, making efficient use of >> wireless L2 information in a routing protocol is an open research problem. > > Other than signal strength and collision rate, what L2 information is > available? Per MAC information would be nice for the AP side or any > node in mesh or adhoc mode but that isn't collected anywhere AFAIK. Raw linkspeed and (on Linux) even Throughput to each neighbor... and a lot more. Just run "iw wlan0 station dump" on a Linux system with wifi and you will be surprised how much information you will get. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message <87a903ef2j.wl-...@pps.univ-paris-diderot.fr> Juliusz Chroboczek writes: > > > Thought: In general, my feeling is that L2 link status is widely relied > > upon in commercial product/dpeloyments. If homenet feels it can not rely > > on it due to the non-commercial nature of its development platforms, > > thats an interesting aspect, especially because it could impact an IETF > > standard that we'd like to see commercially implemented and then the > > constraints could be different... > > Are you referring to the routing protocol comparison, or to something else? > > I have the impression that Babel and IS-IS behave essentially the same > wrt. L2 status -- they both converge fast enough after link status has > been established, and they essentially provide the same facilities for > application-layer link sensing (IMHO Babel's Hello/IHU subprotocol is > slightly more flexible, but that's probably not a big deal). > > As to wireless links -- as far as I'm aware, making efficient use of > wireless L2 information in a routing protocol is an open research problem. Other than signal strength and collision rate, what L2 information is available? Per MAC information would be nice for the AP side or any node in mesh or adhoc mode but that isn't collected anywhere AFAIK. > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ISPs mostly use Ethernet as point-to-point (PTP) links. Including using 100GbE as PTP. No switches. L2 Link down is one fast indicator of link down. But for Ethernet over transport gear (ie: OTN) BFD is almost always used. For short distances L2 over extended reach optics can be used, including colored optics and WDM. This is also PTP and in this case BFD should not be needed. To the extent that routers use SONET or OTN interfaces, these have fast L2 link down indication and are integrated with L3 link down detection. In all of these detection is on the order of 10 msec (geographic distance dependent), failover using FRR is under 50 msec, and IGP convergence is well under a second (typical 100-200 msec today AFAIK). L3 hellos are way too slow. BFD is not heavy weight. L3 hellos (OSPF, ISIS) can be set down to 1s with detection in 3s (too slow). BFD, Hellos, or any form of probe traffic over wireless has the speed of detection vs overhead issue. At nominal 10 Mb/s (low end today for wireless) a small probe would take about 0.1 msec (for example, 125 bytes including all overhead is about 1000 bits). Not bad if running 100 probes/sec (30 msec detection) unless there are a very large number of stations using the AP and doing the same thing. In that case 10 probes per second might be better. A very high collision rate (typically not due to probes, but to real traffic) might result in a link down indication. If that is the case, then moving to another AP would be a good thing. Flapping needs to be avoided if an alternate is available (ie: with 20% loss, in .2*.2*.2 = .008 = 0.8% of intervale a down indication would occur). If any packet received would bring it back up, then at 100 probes / sec, a change in IGP link state could occur about once a second on average. Remembering a link down and holding a down state for a (longish) while would be a good thing. If there is no alternate route, not probing at all and/or holding an up state would be good. OTOH- 20% loss borders on completely unusable. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 26/02/2015 05:14, Mikael Abrahamsson wrote: > On Wed, 25 Feb 2015, Ray Hunter wrote: > >> That way the devices can roam at L3, without all of the nasty side effects >> of re-establishing TPC sessions, or updating >> dynamic naming services, or having to run an L2 overlay network everywhere, >> or having to support protocols that require a >> specialised partner in crime on the server side (mTCP, shim6 et al). > > It's my firm belief that we need to rid clients of IP address dependence for > its sessions. Asking clients to participate in HNCP > only addresses the problem where HNCP is used. > > Fixing this for real would reap benefits for devices moving between any kind > of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
On 25/02/2015 21:15, Markus Stenberg wrote: > On 25.2.2015, at 0.56, Juliusz Chroboczek > wrote: should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size. >>> I guess this is another MUST to be added to HNCP text (DNCP itself is >>> not IPv6-specific as such). >> You mean that every HNCP node MUST ba able to accept packets of up to 64kB? >> What’s the status of typical embedded stacks? > > Configuration dependant more than implementation at least in the few I have > played with, but usually they’re really short of RAM so usually configuration > is rather conservative. Sticking (say) DTLS in one is probably no-go due to > lack of computing power to start with so I am not sure this is that relevant. > > That said, from my point of view, if this is really thought to be an issue by > the WG, correct solution is to use TLS (+TCP) instead of DTLS (+UDP) in any > case. I've thought about this in the Anima/GDNP context and reached the same conclusion. Why make life complicated when TLS makes it simple? Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On 25 Feb 2015, at 16:58, Ted Lemon wrote: > >> On Feb 25, 2015, at 10:47 AM, Ray Hunter wrote: >> One suggestion from my side for handling WiFi roaming is for these clients >> to incorporate a software loopback interface that does not renumber, and is >> always up, and these roaming clients also actively take part in HNCP, and >> the Homenet routing protocol as "stub routers." > > Something like this is currently done with Babel, but it's not a complete > solution because it requires Babel-specific modifications on the client. > The proposal to have a single bridged WiFi broadcast domain would eliminate > this problem, at the cost of some substantial pain in terms of how to set > that up automatically and in terms of performance, which clearly would suffer > from the expanded broadcast domain. And there's also the problem of > differentiating backbone wifi links from wifi leaf networks. Agreed. For the purposes of this discussion, I think a soft requirement on a stub-only implementation of the chosen Homenet routing protocol on a host OS could be an interesting differentiator. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. -- 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 Feb 25, 2015, at 10:47 AM, Ray Hunter wrote: > One suggestion from my side for handling WiFi roaming is for these clients to > incorporate a software loopback interface that does not renumber, and is > always up, and these roaming clients also actively take part in HNCP, and the > Homenet routing protocol as "stub routers." Something like this is currently done with Babel, but it's not a complete solution because it requires Babel-specific modifications on the client. The proposal to have a single bridged WiFi broadcast domain would eliminate this problem, at the cost of some substantial pain in terms of how to set that up automatically and in terms of performance, which clearly would suffer from the expanded broadcast domain. And there's also the problem of differentiating backbone wifi links from wifi leaf networks. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Mikael Abrahamsson wrote: 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? I agree that WiFi roaming is a problem that needs addressing in Homenet. One suggestion from my side for handling WiFi roaming is for these clients to incorporate a software loopback interface that does not renumber, and is always up, and these roaming clients also actively take part in HNCP, and the Homenet routing protocol as "stub routers." That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). YMMV. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
> Op 20 feb. 2015, om 17:50 heeft Dave Taht het volgende > geschreven: > > 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 tunnel. Set up a few times, vanished same number of times. Waiting for IPv6 roll-out in NLD. I'm hopeful for 2015. > > 1) Have you attempted to deploy a routing protocol in your home? Which > one, and why? Having a small olsrd.org testbed for couple of years. IPv4-only. In mean time, SmartGateway with multi-homing support is running fine. This provides connection pinning for mobile nodes, at setup of connection, GW is fixed so no NAT / firewall problems. Tried MPTCP, not integrated with olsrd / sgw yet. I have plans to move to homenet's protocols. > > 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. About 6 nodes, stationary (iMac, TV, MacMini as backup server, Cameras, sometimes MacBook). 1x MacBook never connects to ethernet. > > 4) Do you use wifi? How many clients are wifi connected? Do you use > range extenders? Yes. About 6 nodes. More for testing. Two own APs in production. ISP AP with guest access for all ISP customers (millions). Couple of APs in olsrd testbed. Phones are APs. > > 5) How many devices do you think you will have connected to the > network in your home in 5 years? How many now? Little more. > > 6) Do you use any other network connected technologies (homeplug, > 802.14, LTE, etc). If so, which ones, and why? LTE (2x phone). Maybe add ADSL to cable, for redundancy. Waiting for better multi-homing support. Now, it only adds complexity and uptime would go down Sometimes, tethering to phones (from MacBook) is still active at home. Should switch to high speed flat fee WiFi automatically. > > 7) Do you use mdns service discovery? > Yes. > 8) Why are you here? (especially, if your answers to 0-2, are "no") Current situation is bad. No multi-homing, lousy roaming between APs, need for keep-alive to refresh NAT state etc. I think the homenet protocols have much more potential than just home networks. E.g. satcom terminals act like CPE devices. Mobile devices roam between homes, cars, trains, @work, hotels. Also, more plug&play reduces O&M costs. Teco > > -- > 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] DNCP questions
On 25.2.2015, at 1.10, Juliusz Chroboczek wrote: >>> Another question -- is it possible to participate in Trickle-driven >>> flooding without building the full topology graph? > >> The current answer based on strict reading of the spec is no. > [...] >> Is this desirable to be changed? Probably so. > There's not only the stub case that you consider, but also the pure > client/forwarder node -- a node that doesn't wish to publish any data, but > uses static HNCP data, and serves as a link between two parts of the > network. Ideally, such a node should not contribute any replicated state. > > (Note that a Babel/AHCP router that doesn't announce any routes > contributes no state whatsoever to non-neighbouring nodes. So you can add > arbitrary many intermediary hops with no cost incurred by distant nodes.) That sounds like distance vector <> link state tradeoff (and yes, we know HNCP isn’t a routing protocol but it both exists due to politics, and isn’t one due to politics; good luck shoving IS-IS on top of *TLS, or sticking in dozen+ random TLVs there). Suggestions on how to address that are welcome of course. (Forward case is tricky; client isn’t problematic, see below.) > The reason I'm asking is somewhat out of scope for Homenet -- I'm looking > into deprecating AHCP in mesh networks in favour of a subset implementation > of HNCP. AHCP is a very simple protocol, and one can implement an AHCP > client/forwarder in constant space. Not so with HNCP -- in HNCP, every > node has a copy of the topology, and contributes a vertex to the replicated > neighbour graph. > > HNCP is naive link state, with no network nodes (pseudonodes) and no > DR/DIS/MPR election. So its scaling is quadratic in the worst case. > Consider a network containing a switched Ethernet backbone consisting > a mere 30 routers. Unless I'm missing something, this backbone will > contribute no less than 30 vertices and 435 edges in the neighbour graph, > and this state will be duplicated in every single node in the network. Yep, intentionally so for now; of course, we could turn it even more in the scalable (routing) protocol direction if there is desire. In another draft for a different WG I have specified auto-area extension for it already :p > There's an obvious solution -- it is to have pure client nodes that > participate in Trickle but don't contribute a vertex to the neighbour > graph. But HNCP doesn’t support that. That shouldn’t be hard to address if it seems desirable, but doing (robust) (stateless) forwarding that way is problematic. Willingness to drop one lets you get the other, but not both I think For the ‘pure client’ (and especially ‘limited client’) case, I would argue that they are not interested in most of the state in HNCP in any case and would want just some sort of request-reply of current state, and possibly notifications about state changes from their first-hop non-client node. As an alternative, some flag to say that ‘I do not want to be your neighbor’ would allow read-only client usage of HNCP state using normal RNS+RNDxN messages, but I think nodes would be more interested in per-TLV state that is applicable, and not retrieving whole network state just to get e.g. assigned addresses. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
On 25.2.2015, at 0.56, Juliusz Chroboczek wrote: >>> should not send packets larger than 1500 octets unless it has assurance >>> that the destination is capable of reassembling packets of that larger >>> size. >> I guess this is another MUST to be added to HNCP text (DNCP itself is >> not IPv6-specific as such). > You mean that every HNCP node MUST ba able to accept packets of up to 64kB? > What’s the status of typical embedded stacks? Configuration dependant more than implementation at least in the few I have played with, but usually they’re really short of RAM so usually configuration is rather conservative. Sticking (say) DTLS in one is probably no-go due to lack of computing power to start with so I am not sure this is that relevant. That said, from my point of view, if this is really thought to be an issue by the WG, correct solution is to use TLS (+TCP) instead of DTLS (+UDP) in any case. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
