IETF Logo Mail Archive

Re: Consensus call for Late-Stage documents, pre-IETF 108 edition

Lars Eggert <lars@eggert.org> Thu, 23 July 2020 07:22 UTC

Return-Path: <lars@eggert.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18693A09C5 for <quic@ietfa.amsl.com>; Thu, 23 Jul 2020 00:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmQruQbDH1O9 for <quic@ietfa.amsl.com>; Thu, 23 Jul 2020 00:22:40 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DFD3A09C4 for <quic@ietf.org>; Thu, 23 Jul 2020 00:22:39 -0700 (PDT)
Received: from [IPv6:2a00:ac00:0:35:c64:9a85:72f7:4fc2] (unknown [IPv6:2a00:ac00:0:35:c64:9a85:72f7:4fc2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 27DDD604660; Thu, 23 Jul 2020 10:22:32 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1595488952; bh=Z9ZhR8Khyy8QDWaPrQnCcud+BqVikh6kUKW+h4PHRdc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=luKx5IZxeNLUj9vy8YqOAuKCKBj2nX6kClVlLU14BDbHuzaA4mCx2FRgWX+KFJZT0 jPODROD4mD90Ts7PEzKgB+q7xLuP+MCqAqcXTdwIt6b7Wb4Sgsp/OANplYgEBspe+c nmU5s9IXP4iDUDPMoHaI4vF0rNA6HtZvwKKP2MlM=
From: Lars Eggert <lars@eggert.org>
Message-Id: <FA3E4F14-570C-4A28-A2C8-EA2B3937E614@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_69E98048-1D7E-4183-B1C1-24F9B2B066FB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: Re: Consensus call for Late-Stage documents, pre-IETF 108 edition
Date: Thu, 23 Jul 2020 10:22:31 +0300
In-Reply-To: <32c098c3-24e4-1d7c-fdf5-33761adacfa8@erg.abdn.ac.uk>
Cc: Martin Thomson <mt@lowentropy.net>, quic@ietf.org
To: Gorry Fairhust <gorry@erg.abdn.ac.uk>
References: <CALGR9obkGENj_Brk5D29Z6HB-yq9TbPLjUXSNbotAZJ0LRHgSg@mail.gmail.com> <CABcZeBMQNX_qbXT_qCmyWuXdLeL2=ar0u9yKB=c8M7=WNB4oVQ@mail.gmail.com> <1909E24B-73CC-4129-9B64-F0A3BE2D74D7@eggert.org> <CA+9kkMCRfhNayN5jM5g3Ckwst4GGxR++be5p7ea1jYkE3MbzqA@mail.gmail.com> <CABcZeBOcZd9=Th4T=rm0i+EGnG1i8bjembf20ungVYaDSpjusQ@mail.gmail.com> <7b5c104c-36b6-3fe1-4e5b-0e42cc9e2b36@huitema.net> <74ef5430-8e3f-4b6b-b81f-b25443e975b4@www.fastmail.com> <32c098c3-24e4-1d7c-fdf5-33761adacfa8@erg.abdn.ac.uk>
X-MailScanner-ID: 27DDD604660.A82EE
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eHaJhYRjj03RJmLVGpZNvIc2fPw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2020 07:22:42 -0000

Hi,

On 2020-7-23, at 10:09, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> I thought the point that NAPT was common point had been discussed in QUIC before, and was noted that there are devices on path that change the forwrading path and hence congestion conditions based on the flow's port value. ECMP is a not that uncommon example, other load ballancing can also change the path.

but with ECMP, SFQ and similar schemes, the intent it spread the load equally over a set of candidate paths. So, assuming some level of utilization, all those candidate paths should have more-or-less similar path characteristics?

I agree that in general, a path change should cause a CC state reset, but in this specific case, I think we can make some assumptions (like the above) that may make it OK to not do that.

Lars

v2.23.0 | Report a Bug | By Email