Re: [v6ops] Eric Rescorla's No Objection on draft-ietf-v6ops-rfc6555bis-05: (with COMMENT)

[David Schinazi <[e-mail]>]

Hi all,

I also don't think the review of RFC6555bis is the right place to be having the discussion of whether to prefer IPv6 or not.
The IETF reached consensus on preferring IPv6 with RFC3484 (now RFC6724).
The benefits of IPv6 are documented more thoroughly in RFC8200.

The text in draft-ietf-v6ops-rfc6555bis-06 is as follows:

   Note that this document assumes that the host destination address
   preference policy favors IPv6 over IPv4.  IPv6 has many desirable
   properties designed to be improvements over IPv4 [RFC8200].  If the
   host is configured to have a different preference, the
   recommendations in this document can be easily adapted.

As such, RFC6555bis does not recommend IPv6 or IPv4, which is left to other documents.

Thanks,
David Schinazi


> On Oct 23, 2017, at 12:08, Brian E Carpenter <[e-mail]> wrote:
> 
> On 24/10/2017 07:44, Eric Rescorla wrote:
>> Thanks for the reference.
>> 
>> The question is *not* whether IPv6 is faster than IPv4 for the same
>> physical route but rather whether it is faster for the same endpoint. To
>> know that, you need to do A/B testing. It's clear Facebook did not do that.
>> 
>> Skimming the APNIC results, it appears that they show that for the A/B
>> test, v4 and v6 are similar:
>> 
>> "These measurements show that in a large set of individual comparisons
>> where the IPv4 and IPv6 paths between the same two dual stack endpoints are
>> examined, the two protocols, as measured by the TCP SYN round trip time,
>> are roughly equivalent on average, but with some significant outliers."
>> 
>> You might also take note of:
>> 
>> "While the TCP connection performance is roughly equivalent once the
>> connection is established, the probability of establishing the connection
>> is not the same. The current connection failure rate for IPv4 connections
>> was seen to be some 0.2% of all connection attempts, while the equivalent
>> connection failure rate for unicast IPv6 is eight times higher, at 1.6% of
>> all connection attempts.
>> "
> 
> None of which addresses the question of how many user transactions succeed
> or fail with IPv4 or IPv6 respectively, assuming acceptable performance
> in both cases. It's really very hard to define and measure metrics that
> really answer Eric's challenge.
> 
>> -Ekr
>> 
>> 
>> On Mon, Oct 23, 2017 at 11:31 AM, Mark Smith <[e-mail]> wrote:
>> 
>>> 
>>> 
>>> On 21 Oct. 2017 8:56 am, "Brian E Carpenter" <[e-mail]>
>>> wrote:
>>> 
>>> On 21/10/2017 10:33, Tommy Pauly wrote:
>>>> 
>>>> 
>>>>> On Oct 20, 2017, at 2:30 PM, Eric Rescorla <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Oct 20, 2017 at 2:11 PM, Brian E Carpenter <
>>> [e-mail] <mailto:[e-mail]>> wrote:
>>>>> Eric,
>>>>> 
>>>>> On 21/10/2017 09:45, Eric Rescorla wrote:
>>>>>> Eric Rescorla has entered the following ballot position for
>>>>>> draft-ietf-v6ops-rfc6555bis-05: No Objection
>>>>>> 
>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>>> introductory paragraph, however.)
>>>>>> 
>>>>>> 
>>>>>> Please refer to https://www.ietf.org/iesg/stat
>>> ement/discuss-criteria.html <https://www.ietf.org/iesg/sta
>>> tement/discuss-criteria.html>
>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>> 
>>>>>> 
>>>>>> The document, along with other ballot positions, can be found here:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ <
>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------------------------------------
>>>>>> COMMENT:
>>>>>> ----------------------------------------------------------------------
>>>>>> 
>>>>>> This document should provide a rationale for why you are favoring v6
>>> over v4
>>>>>> addresses when v4 addresses resolve first. Is there some technical
>>> reason
>>>>>> (e.g., it works better) or is there just a political reason (we want
>>> to push
>>>>>> people to v6).
>>>>> 
>>>>> I don't think that's a political desire. IPv6 in general works better,
>>>>> because it isn't encumbered by NAT.
>>>>> 
>>>>> Can you please provide a reference to a measurement showing that this
>>> is true?
>>>>> -Ekr
>>>> 
>>>> For the draft, I'm going to update it to point to the IPv6 RFC (RFC
>>> 8200) to point to the various design benefits that an implementation may
>>> favor.
>>>> 
>>>> While I agree that in our experience, we've seen performance benefits
>>> gained by avoiding NATs, etc, I don't believe that we have the correct
>>> material to reference from this draft to assert that point.
>>> 
>>> Yes, we sadly lack serious scientific measurement about this, and about
>>> NAT-induced
>>> transaction failures too. There are data on the prevalence of CGN but not
>>> on its effects on user performance and reliability, as far as I know.
>>> 
>>> So, Eric, I can't answer your challenge.
>>> 
>>> 
>>> 
>>> APNIC have measured that IPv6 is quite commonly faster than IPv4.
>>> 
>>> https://blog.apnic.net/2016/08/22/ipv6-performance-revisited/
>>> 
>>> 
>>> Facebook have found that too.
>>> 
>>> https://code.facebook.com/posts/1192894270727351/ipv6-it-s-
>>> time-to-get-on-board/
>>> 
>>> Regards,
>>> Mark.
>>> 
>>> 
>>> 
>>>   Brian
>>> 
>>>> 
>>>> Thanks,
>>>> Tommy
>>>>> 
>>>>> So we want to push people to v6
>>>>> for technical reasons.
>>>>> 
>>>>> 
>>>>> 
>>>>>   Brian
>>>>> 
>>>>>> I could live with either, but the document should be clear IMO.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> v6ops mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/v6ops <
>>> https://www.ietf.org/mailman/listinfo/v6ops>
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops