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

Brian Candler <brian@nsrc.org> Wed, 17 April 2024 10:53 UTC

Return-Path: <brian@nsrc.org>
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 011A6C14F68C for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2024 03:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nsrc.org header.b="PUsuVMfQ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="LIAfL1eJ"
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 KLRzGE7fktOH for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2024 03:53:44 -0700 (PDT)
Received: from wfout8-smtp.messagingengine.com (wfout8-smtp.messagingengine.com [64.147.123.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50565C14F68F for <v6ops@ietf.org>; Wed, 17 Apr 2024 03:53:44 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.west.internal (Postfix) with ESMTP id B2A4E1C00155; Wed, 17 Apr 2024 06:53:39 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 17 Apr 2024 06:53:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nsrc.org; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1713351219; x=1713437619; bh=QSeyGttoxx u7nFm9RPmVYOi6bb2EOQd2jHxs4mCsb5g=; b=PUsuVMfQ5QOVS+2Snle82g0fYq Udvj+GSWVfeJEiM8LjYPJ9Dygk6ABU0YShLt7rkBSamqDRpOTZNdT97VrxPthwRt kVz2UY2QLsnYtcZXv2mw8394frnVIklXAYMNKyDS4coL6zvBehPzbuNm4AT8trxv CVVC5yny/yZe+7jMMj6uAtBla4YPC9NLJEcEmBI7Q+JI76Yq2rGeLJ7SENPlnYfO QUrerXi687qZZsNmiNr3JETNL0ZS/t1xA060H/2ct/A4bSm7X2/NLrOAcmprX1Or A/H/u7+eBn8B94BjyR+F67zcQ335jhxpZM1bcEZuQxaqhuGwZxho7Xv3v5qg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1713351219; x=1713437619; bh=QSeyGttoxxu7nFm9RPmVYOi6bb2E OQd2jHxs4mCsb5g=; b=LIAfL1eJWHcXXnpsrIOYhA27FjKHRS9ltojvgAZiwwtn Yvo51ub6FLLAKvcbbmsMVKCpKxeOJBesNZoP3Md1vEw/JWOt0g949GpAsn1CYIae XS/0ItNu8OFaBVrtgBAKVASfeT1knfCkWIqPB3chXUHSVaKvUQI7gePleJD6Efs0 Hy94aAYcVHfibCf6OLFX/U6AriHmxUNujRVaPvUR0J0/Ri4dO5NgGnWhWLj7znsA Phcc5IfHxMvDuCnpwiOXZVNDil3UUuGymWDjtVKmaxRt66IY5fOE26i485PrLvOI /mo8sZ6OJEg3+YJsajtfsRR8neRjHSzUt+F5IHEUKA==
X-ME-Sender: <xms:MqofZirs_niaeyBLiYQvjas2SQLJ-25txQCOvKRh1dxbNNG9CqlQIQ> <xme:MqofZgpmZvdxA3wmpRjSi7HqQCONxW3Lgw8ebLW7vZ6nijIuEC3k1PRQP0bIwN-2r y1wqPsQvtCZw7OpCpI>
X-ME-Received: <xmr:MqofZnPG3gpqFoRToikSIuMpkB18tKTw5_FVaNzSJQvGHHVfNnzCxRGgQVSAJjg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudejkedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuvfevfhfhjgesrgdtreertddvjeenucfhrhhomhepuehrihgr nhcuvegrnhgulhgvrhcuoegsrhhirghnsehnshhrtgdrohhrgheqnecuggftrfgrthhtvg hrnhepfedtkefhveffiefhgefhleeileeitdfggfffveevjefhteeuudeifeetueeufeef necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrih grnhesnhhsrhgtrdhorhhg
X-ME-Proxy: <xmx:MqofZh49DbihPIn443-gX6IHNJ7n_qLp-V2PX9J4ga7p_b_p4Mhu-Q> <xmx:MqofZh6-d9r5qyNUPc67_PUalKu6r54EaGGhDBmwYDNFdGN-7qJ08g> <xmx:MqofZhiDWWLdg7Bv0VNiUYLgVl00FkSkaIsA09l2QLijNKrQAf296A> <xmx:MqofZr7yoWgZa5YTFFx-vZGMpF7_6PsTW1jE-raWrPApMslgjfAmdA> <xmx:M6ofZvSDWOQFfAdPMckFYXclt3Di_zC3IX6bvt6ejAoRvvv-W_Dommkf>
Feedback-ID: i8f09498f:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 Apr 2024 06:53:37 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------nfIB90UtaU8zFLHsq9VwkZ98"
Message-ID: <41e6d96d-dd6d-4982-9160-92bffb5eafad@nsrc.org>
Date: Wed, 17 Apr 2024 11:53:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>, Mark Andrews <marka@isc.org>, Toerless Eckert <tte@cs.fau.de>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
References: <ZfplwNJGdpl05bZO@faui48e.informatik.uni-erlangen.de> <EF78559D-7879-4C0D-A47B-08AB279FD40B@isc.org> <5a4d382100604730bd31c45ba196d62a@huawei.com>
From: Brian Candler <brian@nsrc.org>
In-Reply-To: <5a4d382100604730bd31c45ba196d62a@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qD1NWX3PL57XjShsDhqHxPE-nCw>
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 10:53:49 -0000

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.