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:42 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 A5BEA3A0866 for <quic@ietfa.amsl.com>; Thu, 23 Jul 2020 00:42:38 -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 uHXqdjPGUf8y for <quic@ietfa.amsl.com>; Thu, 23 Jul 2020 00:42:37 -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 AA97B3A076C for <quic@ietf.org>; Thu, 23 Jul 2020 00:42:36 -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 4A1D86046B5; Thu, 23 Jul 2020 10:42:28 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1595490148; bh=gjz+q4hX7ItIXfLQUtcmAoPlRA7tXA/zhFg+n9D0CFM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=W4bGNKSHqZCEJ7lBxXRdl/Wj8qfIrvuDeNT24KFXmCW7+EdDi2aun9pjTJriKUJrl O9jVbAyyNAp3KEDWtBcn12ooUa/96l70jK2k/MsOysjB4qK4WE2Lc8iK/kxOdn+aC0 fKbd8baUbmLIRmSmKZWYG6Nc/K1UKTpSwdi3lsQM=
From: Lars Eggert <lars@eggert.org>
Message-Id: <3644F334-F148-4FF5-AE86-015C073871AC@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_AB404ECA-69AD-4D0A-9F73-8A9D9CECBA71"; 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:42:26 +0300
In-Reply-To: <0ee0a444-3910-3e71-54aa-581431495648@erg.abdn.ac.uk>
Cc: QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
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> <FA3E4F14-570C-4A28-A2C8-EA2B3937E614@eggert.org> <0ee0a444-3910-3e71-54aa-581431495648@erg.abdn.ac.uk>
X-MailScanner-ID: 4A1D86046B5.A36B4
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sbDp808mOFPDP4ELUlLGLjL-b7E>
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:42:39 -0000

Hi,

On 2020-7-23, at 10:34, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> These methods often hash based on port, IP, and maybe other fields to select a queue - There are a finite set of queues, a rehash results in the traffic moving queue ... to chooses a different path or queue within the device. This mapping is statistical, this matters more if the multiplexing is low and a port change results in unbalance across quques/paths.

I agree this is mostly a concern for low-mux'ing cases when a single rehash can create significant imbalance. How common are such deployments, and how much of a problem is such a temporary imbalance (the CC will adjust quickly). Esp. compared to forcing slow-start after every NAT rebind.

Lars

v2.23.0 | Report a Bug | By Email