In message <201101241115.p0OBFPmU016916@xxxxxxxxxxxxxxxxxxx>, Martin Rex writes : > Brian E Carpenter wrote: > > > > However, see draft-wing-v6ops-happy-eyeballs-ipv6 > > Yuk. That approach appears to be from a completely different universe > that solutions to the IPv4->IPv6 migration issue. > > Instead of solving the problem where it originates, at the network level, > it dumps the entire problem onto the application in the worst conceivable > fashion. It makes IPv6 and IPv4 worlds appear like two completely > seperate and independent Internets, i.e. this proposal incurs on apps > the exact same effort as migrating a completely different network protocol > or completely different network. The solution space is equally applicable to two IPv4 addresses or two IPv6 addresses. You start one, wait a short while to see if it succeeds then start another, etc. If the network is doing its job you get a error back from it before you start the second and you start it sooner. If it isn't then you don't waste 30 seconds for the connect to timeout. If you have a abnormally long path then you get some embryonic connections. 500ms is more than enough time to wait for a terrestrial path to complete. Sydney, Australia to Europe is high 3 hundreds to low 4 hundreds of milliseconds. % ~/a.out www.ripe.net connect_to_host(www.ripe.net) -> 3 in 376 ms % > If anyone had suggested that for a migration from PSTN to VoiP, then > everyone would have to use two phones these days, dial in parallel > and hang up on whichever call establishes second. I've seen plenty of people pick up one phone dial then put the call on speaker then pick up a second phone and dial a different number and put it on speaker when trying to reach someone with two numbers urgently. They hang up which ever doesn't answer. > The problem that this draft tries to solve at the app-level really > ought to be solved at the network level. Use IPv6 addresses that > embed the alternative IPv4 address and have the network figure out > whether the route is IPv6 clean and the connection can be established > as IPv6 or only IPv4. (IPv4-NATing the IPv4 part of such an > address along the way is probably "fun"...) ... for exactly those > network interfaces that _have_ dual IPv4+IPv6 addresses. Having good error recovery at the application layer hasn't been a issue until now because 99.99% of sites were single homed. This is changing with almost a 100% of sites becoming multi-homed. It's time the applications learned how to work well in such a environment. It might also mean that one might be able to stop having to deploy DNS servers that track reachability just to get some robustness that should have been there if clients wern't using naive connection strategies. B.T.W. the a.out above implements this sort of connection strategy with a 500 ms wait before attempting the second connection. The wait for the 3rd connection is 250 ms, the 4th is 125 ms, the 5th is 62 ms. You get the pattern. There are poll, select and thread based versions. Mark > -Martin > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf