Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
Dave, my take is that applications, and the entire gai.conf/getaddrinfo() library is broken. Applications can neither be updated nor be trusted to know enough about the system to be able to make a proper decision. Somewhere, someone was working on a new connect(2) call that took FQDNs rather than sockaddr's, such that the kernel could take ownership of this problem. (Of course, actually solving the problem in a kernel is probably the wrong answer). What is necessary is some new infrastructure inside the box which becomes standardized (like sockets API was), with some daemon that thinks about the best source addresses is, and possibly gets involved with routing protocols. (I'm told that OSX has a sophisticated state machine that combines DHCP and 1x, and wifi... it sounds like it could be the start of such a thing) I think that shim6 and mptcp are answers in this equation. shim6 has, I'm told, deployment issues which make me very very sad. 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. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpBNJLk4kzWV.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On 19/12/2014 04:07, Michael Richardson wrote: Dave, my take is that applications, and the entire gai.conf/getaddrinfo() library is broken. Applications can neither be updated nor be trusted to know enough about the system to be able to make a proper decision. Somewhere, someone was working on a new connect(2) call that took FQDNs rather than sockaddr's, such that the kernel could take ownership of this problem. I suppose you are thinking of Name Based Sockets: http://tools.ietf.org/html/draft-ubillos-name-based-sockets It's dead, as far as I know. (Of course, actually solving the problem in a kernel is probably the wrong answer). What is necessary is some new infrastructure inside the box which becomes standardized (like sockets API was), with some daemon that thinks about the best source addresses is, and possibly gets involved with routing protocols. (I'm told that OSX has a sophisticated state machine that combines DHCP and 1x, and wifi... it sounds like it could be the start of such a thing) I think that shim6 and mptcp are answers in this equation. shim6 has, I'm told, deployment issues which make me very very sad. Like, it cannot get through most firewalls. 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, but certainly that needs to be generic because we cannot expect all apps developers to reinvent it. That's one reason we wrote http://tools.ietf.org/html/draft-naderi-ipv6-probing recently. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
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. 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 https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] sorting out the right ipv6 addr to choose and name in a source specific world
The ideal scenario is where the host app picks the best address for each connection type, and I am a little vague on what actually happens. What my backbrain (but not RFC 3484 - is there a later rfc for what gai.conf should do?) With ordinary next-hop routing, routing policy is entirely in the routers -- the end hosts have no control whatsoever on the path taken. The opposite of source routing, where the hosts have the ultimate control on routing policy, and the routers merely provide a mechanism [1]. Now source-specific routing is an interesting compromise between the two: it splits policy decisions between the routers (who distribute a set of source-specific routes) and the hosts (who pick among one of the available routes by specifying a given source address). But even though the amount of policy control given to hosts is fairly modest, it still requires that some routing intelligence be implemented within the hosts -- and, as you justly note, the available mechanisms are insufficient. I think we're pretty much done with the routing part -- I'm fairly confident now that we've got a reasonable understanding of source-specific routing in edge networks [2,3]. On the other hand, we haven't done any serious work on the host side of things -- if anyone understands how to distribute source address selection policies in a way that is both fully automated and flexible enough, they're not saying. (And I'm pretty sure that DNS is the wrong place to do that.) [1] J. Saltzer, D. Reed, D. Clark. Source-routing for Campus-wide Internet Transport. 1980. http://groups.csail.mit.edu/ana/Publications/PubPDFs/SourceRouting.html [2] M. Boutier, J. Chroboczek. Source-specific routing. 2014. https://hal.archives-ouvertes.fr/hal-00947234v3 (Yes, it's a new version.) [3] As opposed to core networks, where there's the ugly issue of routing table explosion -- please give Matthieu a core network to break) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On 18/12/2014 03:16, Dave Taht wrote: ... The ideal scenario is where the host app picks the best address for each connection type, and I am a little vague on what actually happens. What my backbrain (but not RFC 3484 - is there a later rfc for what gai.conf should do?) Not sure if anyone else has responded to that: Yes, it was obsoleted by RFC6724. It probably won't change anything material for this thread, but it's very important for other reasons. btw I strongly recommend the pages like this one: http://www.rfc-editor.org/info/rfc3484 if you want to get Obsoleted by/Updated by/Errata information for any RFC. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On 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. 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 https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter 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? 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 https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On 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 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 signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On 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
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On 19/12/2014 14:49, Juliusz Chroboczek wrote: 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. It is, in our particular context. That's the nice thing about working at the application layer -- you are the application, so you have a pretty good idea of what the desirable properties are. Mosh is an interactive shell, and in this particular context it's latency you want to optimise for. Are you sure? Suppose I open a file transfer window (which as a matter of fact I do almost every time I use SSH these days). For large file transfers I might want to specify cheapest not fastest. Once we gain some real-world experience from mosh, we can think about making something more generic. But I, at least, don't feel comfortable about doing that. Understood. But all I'm thinking is that you might make that bit a self-contained module. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On Thu, Dec 18, 2014 at 7:38 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 19/12/2014 14:49, Juliusz Chroboczek wrote: 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. It is, in our particular context. That's the nice thing about working at the application layer -- you are the application, so you have a pretty good idea of what the desirable properties are. Mosh is an interactive shell, and in this particular context it's latency you want to optimise for. Are you sure? For mosh, which is a very low bandwidth, highly interactive application, lowest RTT is the right choice. Suppose I open a file transfer window (which as a matter of fact I do almost every time I use SSH these days). For large file transfers I might want to specify cheapest not fastest. I would argue that a transfer over LTE (which is the most expensive option), would generally exhibit higher RTT over any other method. lowest financial cost does not have a whole lot of meaning otherwise along the edge. Highest bandwidth or least congested might be other selectors... But: in kicking off this thread, what I was mostly thinking about was making a choice between 9 or more ipv6 addresses to choose from, what to start with, and when to give up. (and which ones should end up in DNS) It seemed to me that I should longest prefix match, except when other characteristics of the route interfered. As one example it made sense to choose a native connection over a tunneled one. As another example, when there was a vpn in play (with it's own address range) to try to use the vpn rather than any public addresses that existed. And then there is a choice to try and prefer stabler addresses (infinite lifetime) over addresses with shorter lifetimes. And then, in order to have a better choice of multi-path connectivity, for an app like mosh or something using mptcp, to chose addresses that are wildly different. I would argue for an app that wants multiple forms of connectivity to pick 3-5 addresses total (and for mosh, to ensure it did ipv4 and ipv6). I tossed hip in there just to make things difficult, as arguably hip addresses should only be used when trying to contact another device in the hip address range ( 2001:10::/28 ) Once we gain some real-world experience from mosh, we can think about making something more generic. But I, at least, don't feel comfortable about doing that. Understood. But all I'm thinking is that you might make that bit a self-contained module. Well, I think I was seeking a new API here. But writing a select or poll loop for 9 addresses is not much harder than 2. Brian -- 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
