Subject: Re: [v6ops] Some comments on http://www.ietf.org/id/draft-bajpai-happy-00.txt

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Wed, 10 Jul 2013 13:16:16 +0000

On Jul 5, 2013, at 4:30 PM, Andrew Yourtchenko <[email-masked]> wrote:

> a couple of comments re. the draft...

Thank you so much for the review!

> First, the overall goal. The RFC6555 was not designed to get the best possible
> user experience. It was designed to (somewhat) minimize the degradation of the
> user experience in case of nonworking IPv6. I think I did not catch it during
> the live presentation in Dublin, but reading the draft I think this is a
> misunderstanding that I need to correct - please take a second look at the
> abstract of RFC6555 as well.

We understand it's a policy discussion to facilitate IPv6 adoption. We will
add a section in the draft to clarify the motivation of RFC6555.

> Now a couple of nits to the text:
> 
> " It appears that an application never uses IPv6 using Teredo except
>   when IPv4 connectivity is broken.
> 
> This is expected, it was deprecated because Teredo IPv6 connectivity is bad.

Yep! a reprise to confirm that happy eyeballs is doing the right thing here.

> " We noticed, that a 300ms advantage
>   leaves a dual-stacked host only 1% chance to prefer a IPv4 route even
>   though it may be significantly faster than IPv6."
> 
> This 1% is in aggregate is a *good* thing, and why the 300ms delay is in
> place.

We are not arguing that happy eyeballs is _not_ doing its job. It's 
definitely improving the user experience by orders of magnitude when the 
user has broken IPv6 connectivity. 

We argue that since applications on top of TCP will not be happy eyeballed
only in scenarios where IPv6 connectivity is broken, but also in scenarios
where the dual-stack host enjoys perfect IPv6 connectivity, we want to 
measure how much imposition does such a user experience in reality by 
measuring the effect of the 300ms timer value. 

> We, as a community, want IPv6 to be deployed. If the HE was easily swayed back
> to the IPv4, this would result in a huge stress to have IPv6 systems function
> *faster* than IPv4. This is pretty hard if not impossible in many
> circumstances.
> 
> Why is this important ? Because an operator who *has* to deploy a CGN to still
> deliver IPv4 will be able to use the IPv6 to offload the traffic to dualstack
> sites.
> 
> If the HE is too sensitive, or selects the best path, chances are high that
> the IPv4 path will be selected, therefore nullifying the investment into IPv6.
> 
> On aggregate, thus, being *too* attentive to the user experience will paint a
> bleak picture in the future by inhibiting IPv6 progress.
> Please add this variable into your research model when you are doing the next
> iteration!

We understand. We will add a section describing this policy decision.

Thanks!

Best, Vaibhav

-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 10 Jul 2013 23:29:32 +0900

> add a section in the draft to clarify the motivation of RFC6555.

Actually, I think that's not enough, because I suspect the disagreement is
deeper than you think. "Effectiveness" implies performance compared to a
goal, but what Andrew is saying here is that latency minimization was
(within reason) not a goal at all. The goal was to avoid impact so we could
get on with enabling IPv6.

If you do want to measure this, I think you might have to call it something
other than "effectiveness". And to be pedantic, even with your definition
of "effectiveness", it's not the "effectiveness" of happy eyeballs that
you're measuring, you're comparing the "effectiveness" of IPv6 and IPv4.

> measuring the effect of the 300ms timer value.

Actually, that's not a good definition either. If the dual-stack host
enjoys perfect IPv6 connectivity, then by definition IPv4 can never be
better (since IPv6 is perfect), the 300ms timer will never fire. So by
"perfect" I think what you really mean is "perfectly reliable".

> We understand. We will add a section describing this policy decision.

Please also change the wording as well.

Cheers,
Lorenzo