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

[Eric Rescorla <[e-mail]>]

In case I wasn't clear before (totally possible) I have no problem with
this text.

-Ekr


On Mon, Oct 23, 2017 at 12:27 PM, David Schinazi <[e-mail]>
wrote:

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