In message
<20100620195212(_dot_)4BD395413(_at_)berserkly(_dot_)xs4all(_dot_)nl>, Geert
Jan de Groot writes:
I would argue the opposite; people won't turn it on otherwise,
due to lack of knowledge or negligence. What I would also argue is
that the API that opens a session should try all available
address pairs in relatively short order - on the order of
tens of milliseconds between new attempts
Internet protocols historically have had good scaling properties
on widely varying bandwiths and RTT times.
Short probe intervals will cause difficulty if RTT isn't also
in the order of tens of milliseconds.
There's places (I was in one only 2 weeks ago) where RTT to USA
was 400 ms, unless we were on backup vsat, in which case it was
2-4 seconds, with congestion and packet loss.
And they pay a lot more for bytes transferred than we're used to.
Not all the world has low latency and high bandwith.
Adding a dependency on this in IPv6 will not help acceptance.
IMHO, there's 2 issues:
1. Global IPv6 connectivity doesn't exist - at best, it's a tunnel mess
with bits and pieces continuously falling off, then getting reconnected
again, and nobody seems to care - there's no effort to make connectivity
more stable
And many of the tunnels are not a issue even if it would be better if they
were turned into native connections.
2. A new client query type - AAAAA - (that's 5 A's, meaning "give me IPv6
unless it doesn't exist, in which case return me IPv4),
with this result cached, would be helpful in high-latency
situations
It would do *nothing* to help. The client or the libraries it calls
can already do this if they want. Making two lookups is not a real
issue. You would need to upgrade both clients and libraries to
make this change without breaking existing application. Just add
a new flag to getaddrinfo() and upgrade the clients to set it.
While you are upgrading getaddrinfo() change the sorting order of
of the addresses you return and you have addressed most of the tunnel
issues as well.
Mark
Geert Jan
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf