On 19/12/2014 13:47, joel jaeggli wrote: > On 12/18/14 4:39 PM, Jim Gettys wrote: >> >> >> On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter >> <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote: >> >> On 19/12/2014 11:22, Juliusz Chroboczek wrote: >> > Shouldn't we reduce the amount of cross-posting at some point? >> > >> >>> mptcp, I'm told, is likely to show up in Apple and Google >> products and >> >>> infrastructure, and my idea (and many others) is that you >> don't always have >> >>> to pick the perfect address for the SYN, just one that works, >> but rather one >> >>> can add better addresses as one discovers them. >> > >> >> But bad luck if you need UDP. >> > >> >> Some form of intelligent probing does seem to be the answer, >> > >> > I'd like to attract your attention to the work that Matthieu >> Boutier has >> > been doing on mosh, Keith Winstein's UDP-based ssh replacement: >> > >> > http://comments.gmane.org/gmane.network.mosh.devel/749 >> > >> > Boutier's version of mosh builds connections across all >> source/destination >> > pairs, and picks the one with lowest RTT. >> >> Sounds interesting. In the ideal world, that would be a pluggable >> policy algorithm. Lowest RTT may not always be the best choice. >> NAROS* suggested distributing policy from a single source, for >> example. >> >> The point about shim6, of course, is that allows you to change >> horses in midstream without bothering the transport layer. >> It's a real shame we don't know how to deploy it, especially >> for homenets where nobody manages the routing policy. >> >> >> >> What were the problems with getting shim6 deployed? >> > need a time machine > > https://www.nanog.org/meetings/nanog35/presentations/schiller.pdf
Well, let's not start that argument again. Shim6 was never intended to address operator's concerns, so it didn't. The real world problems are these: 1. Most firewalls drop packets containing the shim6 extension header. 2. When shim6 switches addresses, the packets get a big bigger and that might reveal a PMTUD problem. 3. Absent SADR in the exit router, shim6 has a high chance of falling victim to BCP38 filtering. More details: H. Naderi & B.E. Carpenter, Putting SHIM6 into Practice, Australasian Telecommunication Networks and Applications Conference (ATNAC 2014), Melbourne (November 2014). https://www.cs.auckland.ac.nz/~brian/Shim6-ATNAC14-subm.pdf Brian > >> There appear to have been >> a Linux implementation, and if the idea now has merit, that is enough >> of the market (which is very responsive) >> to get significant deployment, and to do so quickly. (codel/fq_codel >> went from concept to shipping code is under 3 months, with wide test >> deployment in a year, and now becoming default). We aren't talking >> about 5 year product cycles any more. >> >> As to policy, the home routers themselves give us a place to enable >> people to state the policy they want (e.g. only use the LTE upstream >> if the cheap broadband service is unavailable...). >> - Jim >> >> >> Brian >> >> * C. Launois, O. Bonaventure, and M. Lobelle. The NAROS approach >> for IPv6 >> multihoming with traffic engineering. volume 2811 of Lecture Notes in >> Computer >> Science, pages 112–121. Springer Berlin Heidelberg, 2003. >> >> > It's a work in progress -- >> > there are multiple versions, and Matthieu has yet to decide which >> > implementation he's going to submit for inclusion in mainline mosh. >> > >> > We hope to write that stuff down when Matthieu has decided which >> is the >> > "right" version, but I'm not promising any hard deadlines -- we >> have a lot >> > of stuff that we want to write down. >> > >> >> but certainly that needs to be generic because we cannot expect >> >> all apps developers to reinvent it. >> > >> > Uh-huh. But there's only one thing that's worse than >> generalising from >> > one example -- it's generalising from zero eexamples. >> > >> >> http://tools.ietf.org/html/draft-naderi-ipv6-probing recently. >> > >> > I'll have a look, thanks for the pointer. >> > >> > -- Juliusz >> > >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org <mailto: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
