Subject: Re: The IPv6 Transitional Preference Problem

From: Geert Jan de Groot <[email-masked]>
Date: Sun, 20 Jun 2010 21:52:12 +0200

> 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
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

Geert Jan

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Jun 2010 10:21:35 +1000

>    again, and nobody seems to care - there's no effort to make connectivity

And many of the tunnels are not a issue even if it would be better if they
were turned into native connections.

>    with this result cached, would be helpful in high-latency

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Sun, 20 Jun 2010 22:56:36 -0400

>   again, and nobody seems to care - there's no effort to make connectivity

I think this is an over-statement (at least, if you consider that global IPv4 connectivity *does* exist, which I might choose to argue about over an open pack of Stroopwafels).

>   with this result cached, would be helpful in high-latency

I haven't run the numbers, but my instinct is that this is a problem worth solving. If a thousand out of every thousand and one queries is answered from the cache, then optimising a thousand and two (AAAA and A) back to a thousand and one isn't going to make a perceptible difference to anybody, at the cost of interop and fallback in a world where AAAAA is not universally available.

It would be good if someone with access to a nice variety of query dumps from resolvers in various situations was able to estimate the practical impact on the end user of optimising (A, AAAA) into (AAAAA -- nice name) since this idea is a good enough one that (plain to see) it keeps coming up. If it has value, let's see the numbers and do something about it. If not, let's put it to bed.

Joe