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

["Bajpai, Vaibhav" <[e-mail]>]

On Jul 5, 2013, at 4:30 PM, Andrew Yourtchenko <[e-mail]> 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