Re: [v6ops] Geoff/queue-closed: 56%

Xipengxiao <xipengxiao@huawei.com> Wed, 17 April 2024 15:56 UTC

Return-Path: <xipengxiao@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA03C14F680 for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2024 08:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6X9BaTVrmbJ for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2024 08:56:47 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8594AC14F5FF for <v6ops@ietf.org>; Wed, 17 Apr 2024 08:56:47 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VKQTH3XCXz6K5s9; Wed, 17 Apr 2024 23:54:43 +0800 (CST)
Received: from frapeml500004.china.huawei.com (unknown [7.182.85.22]) by mail.maildlp.com (Postfix) with ESMTPS id EC30F1408FE; Wed, 17 Apr 2024 23:56:43 +0800 (CST)
Received: from frapeml500004.china.huawei.com (7.182.85.22) by frapeml500004.china.huawei.com (7.182.85.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 17 Apr 2024 17:56:43 +0200
Received: from frapeml500004.china.huawei.com ([7.182.85.22]) by frapeml500004.china.huawei.com ([7.182.85.22]) with mapi id 15.01.2507.035; Wed, 17 Apr 2024 17:56:43 +0200
From: Xipengxiao <xipengxiao@huawei.com>
To: Brian Candler <brian@nsrc.org>, Mark Andrews <marka@isc.org>, Toerless Eckert <tte@cs.fau.de>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Geoff/queue-closed: 56%
Thread-Index: AQHaen8TvndkX0U9oUylmMlF4nbIQLFACzqAgCxb0oD//+1sgIAAa3ew
Date: Wed, 17 Apr 2024 15:56:43 +0000
Message-ID: <6cabd7ddb37e4451bfca7834fcdf8cdb@huawei.com>
References: <ZfplwNJGdpl05bZO@faui48e.informatik.uni-erlangen.de> <EF78559D-7879-4C0D-A47B-08AB279FD40B@isc.org> <5a4d382100604730bd31c45ba196d62a@huawei.com> <41e6d96d-dd6d-4982-9160-92bffb5eafad@nsrc.org>
In-Reply-To: <41e6d96d-dd6d-4982-9160-92bffb5eafad@nsrc.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.76.36]
Content-Type: multipart/alternative; boundary="_000_6cabd7ddb37e4451bfca7834fcdf8cdbhuaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uIlhtuZQKKW4FXGiY96ijFiY9Tw>
Subject: Re: [v6ops] Geoff/queue-closed: 56%
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2024 15:56:51 -0000

Hi Brian,

There are many different opinions on IPv6 and it’s difficult to discuss every point, so I will just respond to 2 of your points:

  *   Brian: As far as I can tell there is no fundamental reason why IPv6 should be any more performant than IPv4 for latency, and I would expect typical TCP throughput to be ~1.4% worse on IPv6, due to the larger headers.
     *   I know many people have opinion similar to yours. This is why I keep bringing up the IPv6 performance topic – to draw people’s attention to the new fact: APNIC has stats showing that average IPv6 RTT smaller than IPv4 RTT:  https://stats.labs.apnic.net/v6perf/XA.  I hope more people know this.
     *   The more important question is “why would IPv6 has shorter average RTT than IPv4?”.  This article from Erik/Akamai has clear explanation (in Section 9): https://www.akamai.com/blog/trends/10-years-since-world-ipv6-launch
     *   There are more talks from Meta, Apple, Dell on better IPv6 performance:
        *   https://developer.apple.com/videos/play/wwdc2020/10111/
        *   https://engineering.fb.com/2015/09/14/networking-traffic/ipv6-it-s-time-to-get-on-board/
  *   Brian: Also, everyone should be clear that there is currently no such thing as "migrate to IPv6". You either add IPv6 to your IPv4 stack, or you stay with IPv4. You can't remove the IPv4 part without cutting yourself off from most of the Internet.
     *   In a later message you said yourself “add v6 this month, remove v4 next month, job done”.  That’s one way to “migrate to IPv6”.  There are other ways.  "migrate to IPv6" doesn’t mean cut off IPv4 completely or immediately.
Thanks for the discussion.

XiPeng

From: Brian Candler <brian@nsrc.org>
Sent: Wednesday, April 17, 2024 12:54 PM
To: Xipengxiao <xipengxiao@huawei.com>; Mark Andrews <marka@isc.org>; Toerless Eckert <tte@cs.fau.de>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Geoff/queue-closed: 56%

On 17/04/2024 11:13, Xipengxiao wrote:

We should document IPv6 packet loss issues, identify causes, and publish

 drafts to address the issues.  Now that average IPv6 RTT is lower than

IPv4 RTT (according to APNIC stats), if we can bring IPv6 PLR (packet

loss rate) comparable to IPv4 PLR, then we can declare IPv6 provides

better performance than IPv4.

I think first we need to dig into *why* those measurements are seen.

As far as I can tell there is no fundamental reason why IPv6 should be any more performant than IPv4 for latency, and I would expect typical TCP throughput to be ~1.4% worse on IPv6, due to the larger headers.

Personally, I observe paths taken over the IPv6 Internet often to be quite different to those taken for IPv4, and that may indeed mean shorter and/or less congested paths for IPv6, but this seems to be down to political issues rather than technical ones (e.g. a certain well-known tier 2 backbone provider offering free peering on IPv6, to pick up more routes in an attempt to persuade tier 1's to peer with them)

I don't think this is sustainable in the long term though.
Furthermore, the fact that IPv6 topology is not the same as IPv4 has its own problems. If you can argue in any form that the IPv4 Internet is "fully connected", then the IPv6 Internet is not; for example Google doesn't announce IPv6 routes to transit providers (or didn't last time that I checked), meaning that some people can't reach Google over IPv6 at all. Most of the time, Happy Eyeballs papers over the cracks - i.e. IPv4 connectivity is the only one that matters today.

> That can become a universal reason to persuade people to migrate to IPv6.

I don't believe that it stands up as such.

Also, everyone should be clear that there is currently no such thing as "migrate to IPv6". You either add IPv6 to your IPv4 stack, or you stay with IPv4. You can't remove the IPv4 part without cutting yourself off from most of the Internet.