Subject: Re: [v6ops] Happy Eyeballs - Exit strategies?

From: <[email-masked]>
Date: Fri, 1 Apr 2011 09:34:42 +0200

Thx Scott, for this clarification. Unfortunately I havn't found a recommendation for the default P value in the I-D. Would it make sense to also think about a general method how this default P value can be adjusted over time refelecting the increase of unbroken IPv6 connectivity? 
I don't think that the standard user can/will do this adjustement and fine triggering.

Kind regards
Olaf 

> -----Ursprüngliche Nachricht-----
> Von: Scott Brim [mailto:[email-masked]] 
> Gesendet: Freitag, 1. April 2011 08:47
> An: Bonneß, Olaf
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies?
> 
> Happy eyeballs is eminently configurable.  For IPv4/v6, you could
> initialize the P value so that it never tries IPv4 unless there are
> extreme delays in getting an IPv6 connection.  You could also
> parameterize P adjustment behavior.
> 
> Scott
> 
> On Thu, Mar 31, 2011 at 19:47,  <[email-masked]> wrote:
> > Hi Hagen,
> >
> > as I tried to explain: If the HE approach remains in the 
> network without a dedicated exit strategy than all the 
> clients outthere will go on trying to connect via IPv4 (see 
> "flashing the destination P value every 10 min") also in the 
> case when there is already a better IPv6 connectivity is available.
> >
> > According to Gerds proposal this will end when there is no 
> A record for the destination is available anymore or the 
> client is IPv6-only. Gerd is of course right but the problem 
> with this approach is, that it simply relies on the 
> assumption that all the people are accordingly updating there 
> DNS records.
> >
> > Besides that, one of the IETF standardization basics is to 
> also think about exit strategies for mechanisms and protocols 
> they standardize.
> > I hope that I could make my position a bit more clear.
> >
> > Regards
> >        Olaf
> >
> > PS: IMHO, HE is a very useful and needed mechanism (that 
> may perhaps have some room for improvement), and thats why I 
> definitely don't share your classification of this mechanism.
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Hagen Paul Pfeifer [mailto:[email-masked]]
> >> Gesendet: Donnerstag, 31. März 2011 19:26
> >> An: Bonneß, Olaf
> >> Cc: [email-masked]; [email-masked]
> >> Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies?
> >>
> >> * [email-masked] | 2011-03-31 11:32:36 [+0200]:
> >>
> >> >Hmm I've made the experience that DNS records are very often
> >> not at such an
> >> >actualized status as they should be.
> >>
> >> >Besides that this (sit back and wait) seems not be an an
> >> acceptable exit
> >> >strategy from a provider point of view. (The same applies
> >> also to the "wait
> >> >until the last IPv4 user died" approach.)
> >>
> >> What are these drawbacks that makes Happy Eyeball approach
> >> somewhat stinking?
> >> Why is Gert's reply not adequate from a provider point of view?
> >>
> >> Hagen
> >>
> > _______________________________________________
> > v6ops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Apr 2011 10:42:05 +0200

On Apr 1, 2011, at 9:34 AM, <[email-masked]> wrote:

> I havn't found a recommendation for the default P value in the I-D. Would it make sense to also think about a general method how this default P value can be adjusted over time refelecting the increase of unbroken IPv6 connectivity?

My first reaction to this was to propose sending p in a DHCP or RA option, but then I realized that in the end case, p will not matter because the HE implementation will have no IPv4 configuration, and therefore will not be sending any IPv4 packets regardless of p.

---

From: <[email-masked]>
Date: Fri, 1 Apr 2011 11:15:57 +0200

Hi Ted,

hmmm I'm not sure if I got you right.
What do you understand under "end case when the HE implementation will have no IPv4 configuration"? 

IMHO the "interesting" phase is the long time interval when the IPv6 Internet connectivity is comparable to (or better than) the IPv4 one, but an IPv4 addressing of services is still heavilly used and IPv4 is far from beeing switched off.
For this time range a DHCPv6 or RA option for proposing an useful P value to the users could perhaps help.

Regards
	Olaf

> Von: Ted Lemon [mailto:[email-masked]] 
> Gesendet: Freitag, 1. April 2011 10:42
> An: Bonneß, Olaf
> Cc: <[email-masked]>; <[email-masked]>
> > I havn't found a recommendation for the default P value in 
> the I-D. Would it make sense to also think about a general 
> method how this default P value can be adjusted over time 
> refelecting the increase of unbroken IPv6 connectivity?
> 
> My first reaction to this was to propose sending p in a DHCP 
> or RA option, but then I realized that in the end case, p 
> will not matter because the HE implementation will have no 
> IPv4 configuration, and therefore will not be sending any 
> IPv4 packets regardless of p. 
>

---

From: George Michaelson <[email-masked]>
Date: Fri, 1 Apr 2011 15:30:30 +0200

I re-ran my checks over one days worth of reverse-DNS.

You are right, the non-FF:FE encoding now overwhelmingly predominates.

the top ten:

VMWARE       17
DELL         21
SYNOLOGY     25
USC-INFORMAT 40
INTEL        44
ASUSTEK      48
XEROX        49
<unknown>  1523
APPLE      3530
nonOUI    19311

I pulled the IEEE registry today, so the high <unknown> suggests some people are being creative inside 2002: probably privacy mode.

Noting that, the largest single vendor of IPv6 active equipment which is demonstrably NOT a gateway box.. 

-G

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 13 Apr 2011 10:43:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Friday, April 01, 2011 12:35 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops] Happy Eyeballs - Exit strategies?
> 
> Thx Scott, for this clarification. Unfortunately I havn't found a
> recommendation for the default P value in the I-D. Would it make sense
> to also think about a general method how this default P value can be
> adjusted over time refelecting the increase of unbroken IPv6
> connectivity?

We will add a discussion of this to the I-D.

My thought is to add a new variable, "offset", which would default to 200ms.
This would be a user-configurable value (e.g., "about:config" or similar).
Offset is always added to P.  This would give IPv6 a 200ms head-start over
IPv4.  A good value of "offset" would be the round-trip time to communicate
to a server on this network, so a value of NNN milliseconds (20ms?) might be
reasonable for a wired connection with a typical home Internet connection,
whereas a hundred milliseconds might be reasonable for a 3G connection or a
slow Internet connection (dialup, satellite without a TCP spoofing device,
etc.).  Automatically tuning offset, based on connection times, might be
useful as well, or getting the P value from the network (via DHCP or RA, as
Ted suggested).

Today, we have an offset (or "P" value) of effectively 21-75 seconds, based
on Teemu's slide 3 at http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf

This 'offset' value would also reduce the worry of doubling traffic when
initially visiting a server, giving a preference to IPv6.

Obviously if 'offset' is too large, the user notices a delay -- which is
exactly what Happy Eyeballs is trying to avoid so that IPv6 does not get a
black eye.

-d

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Apr 2011 13:54:15 -0400

On 2011-04-13 13:43, Dan Wing wrote:
> IPv4.

+1

In my implementation I ended up using 100ms. 200ms is also fine.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Scott Brim <[email-masked]>
Date: Thu, 14 Apr 2011 09:10:36 -0400

On Wed, Apr 13, 2011 at 13:43, Dan Wing <[email-masked]> wrote:

> on Teemu's slide 3 at
> http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf
>
> Sure but I wonder why it's a separate parameter.  Why not just set an
initial value for P?   The initial offset should be overridden by what is
learned, so the distinction between P and offset vanishes after one or two
learning events.

Scott

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 16:21:06 +0200

Another thing that isn't really clear to me, is how the Application-wide P value and the P value per Destination are combined and used to generate a new delay value that is really used at the end.
Perhaps it would also make sense to have different notations / names for these two values in  the I-D.

Olaf

  _____  

  Von: Scott Brim [mailto:[email-masked]] 
Gesendet: Donnerstag, 14. April 2011 15:11
An: Dan Wing
Cc: Bonneß, Olaf; [email-masked]; Andrew Yourtchenko
Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies?

Sure but I wonder why it's a separate parameter.  Why not just set an initial value for P?   The initial offset should be overridden by what is learned, so the distinction between P and offset vanishes after one or two learning events.

Scott

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Apr 2011 07:40:44 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 14, 2011 7:21 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: AW: [v6ops] Happy Eyeballs - Exit strategies?
> 
> Another thing that isn't really clear to me, is how the Application-
> wide P value and the P value per Destination are combined and used to
> generate a new delay value that is really used at the end.

Agreed.  We will probably be renaming "P", too -- it was a placeholder
because I couldn't think of a better name.  Andrew is on PTO at the moment
and when he gets back we will start crafting an update and run it by the
working group.

-d

> Olaf
> 
> ________________________________
> 
> 	Sure but I wonder why it's a separate parameter.  Why not just
> set an initial value for P?   The initial offset should be overridden
> by what is learned, so the distinction between P and offset vanishes
> after one or two learning events.
> 
> 	Scott