>>> Well, a start would be a "connectbyname()" API call that takes care of >>> name-to-address mapping and trying different addresses until one works. > >> Most IPv6-capable apps seem to implement that logic now. And in my >> experience, it sucks. Really hard. The app can take a very long time >> to establish a very poor connection. > > If you're going to establish a poor connection, at least do it fast. :-) And then wait for it to timeout. >> The specific reason tends to be >> that the destination and source both have IPv4 and IPv6 addresses, and >> the IPv4 address works better than the IPv6 address (maybe because of >> 6to4 relay routers or whatnot), even though the v6 address is chosen >> first. > > We can generalize this into: when you have a choice, you're going to > make the wrong choice some of the time. > > Downloading over IPv6 is still almost always slower than over IPv4, > but for day-to-day stuff the performance difference isn't an issue > with native IPv6 connectivity (for me). 6to4 is a crapshoot, it can be > reasonable or it can completely fail, with everything in between. But > it's never going to be better than native IPv4, obviously. No, not obviously - because if the application has a need to do address referral then there are conditions in which the 6to4 address will work better. >> But this is just an instance of the general case that some >> source-destination address pairs work better than others. Address >> selection heuristics don't do a good job solving this problem - to solve >> this problem the network actually needs to tell the host which >> source-destination address pairs will work well. (and that's pretty >> ugly) > > I agree that this is an important issue, but I fail to see how this > relates to applications knowing about addresses, unless applications > are going to do their own performance testing, which I don't recommend. p2p applications are doing this already. Sure it's ugly, but they still do it, because they have to. Applications writers would rather not bother with it. But until the network again does a good job at providing good performance while hiding the complexity of routing from applications, the applications will be forced to bother with it. (The old idea that the network provided "best effort" packet delivery service meant that the applications really didn't have a way to improve on what the network was doing, so they didn't bother. But in the new world of lots of source and destination addresses, and arbitrary filtering (from the application's view) the network is effectively no longer responsible for providing "best effort" service. As a result, the layering breaks down.) >> So what you seem to be doing is asking application writers to accept >> degraded performance and reliability in order to conform to some >> arbitrary notion of purity. I don't see it happening. > > Multiple addresses are a reality, not just because the IPv6 specs say > so, but also because lots of hosts are going to have at least one IPv4 > address and at least one IPv6 address. Has nothing to do with purity. Yep, and there are lots of other reasons why multiple addresses will be there - mobility, multiple active network interfaces, encrypted tunnels, etc. So there's going to continue to be a need for some applications to deal with this explicitly. The notion of purity I was referring to was the one that applications should only deal with names and not with addresses. >> On the other hand, if you make it such that application writers can get >> good performance and reliability without messing with addresses, most >> won't see a need to bother with the complexity. But there will still be >> corner cases that will. > > As I said, a good start would be that API because once applications > use it, people working on better address selection etc have a place to > insert their stuff and improve performance of real applications > without having to rewrite the application. I spent a fair amount of time trying to come up with an API that would let applications push this decision-making to a lower layer while allowing that lower layer to make those decisions effectively based on the needs of that particular application. That API ended up looking fairly complex. There are lots of factors that influence address selection. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf