IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Thu, 23 July 2020 18:47 UTC

Return-Path: <huitema@huitema.net>
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 34D863A0C9F for <quic@ietfa.amsl.com>; Thu, 23 Jul 2020 11:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SUfjL0Gk0jmX for <quic@ietfa.amsl.com>; Thu, 23 Jul 2020 11:47:12 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEEF3A0C4A for <quic@ietf.org>; Thu, 23 Jul 2020 11:47:09 -0700 (PDT)
Received: from xse100.mail2web.com ([66.113.196.100] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jygF9-000tqj-QO for quic@ietf.org; Thu, 23 Jul 2020 20:47:05 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BCLsZ2J3Hz2rrX for <quic@ietf.org>; Thu, 23 Jul 2020 11:46:58 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jygF8-0007en-6Q for quic@ietf.org; Thu, 23 Jul 2020 11:46:58 -0700
Received: (qmail 3115 invoked from network); 23 Jul 2020 18:46:57 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.134]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mt@lowentropy.net>; 23 Jul 2020 18:46:57 -0000
To: Lars Eggert <lars@eggert.org>, Gorry Fairhust <gorry@erg.abdn.ac.uk>
Cc: QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
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> <3644F334-F148-4FF5-AE86-015C073871AC@eggert.org>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Subject: Re: Consensus call for Late-Stage documents, pre-IETF 108 edition
Message-ID: <c28e05f6-637d-9183-11db-f8daa8b9e7c4@huitema.net>
Date: Thu, 23 Jul 2020 11:46:57 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <3644F334-F148-4FF5-AE86-015C073871AC@eggert.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="iKGI0yqBdPgpfECRN7bhlUaAIPNKBZ317"
X-Originating-IP: 66.113.196.100
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.100/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.100/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.06)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0bN4ZX/cCaR95pQ7tQtUF1ypSDasLI4SayDByyq9LIhVwvqCnoCzIMxx cK3dmWAY/UTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fsI50dXFKDqEMh2AAzAdoU5U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/WSlmRJUKMrJ+ahcq82ahPryme9ldZJ7uNXfg/GfS8fXOC4kn OJkMS8NGDKsP9r3Khy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8aUJfluQqfeAjECBQJTOQmpO7d6CDlWuQmnn8BRF01Cm0lp7yPqtzbP+0yi5RYbydIn dLDoft3gQzSYknam2p7RRtZL+RcVylNt/Xabq9oLs6zNjLvclnGzlTC8ZgkR3laIWqvAxiBHuIuS y5fCAlEkJ4c2pukl0P19e8QH3YrtPlACVO3tx78u0bG7If2TCVToC9jhOddqBfwcZ+DpisSDVzOz K7x3y6AqURyjPjZ6KznzSXChKWk/itcbicJsIPfz7d1Fe52vb2pe5EJ6a2Umfqb5R4VemuUI6bcE ARsm0De6PaZO6/JToEyx4tmc5OljkPSpPXAVjl2oMr8a1xm0wfXUFMjTH2DyD8i5kO5bZlYFvf25 LVONYbYifH5OzZCwIgD/xDehea09OpnwSuobZrrGExMR7eTbBjMGDKI3ijhhJn7Muv/NHXl0o++8 3wM=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/j7XyfDstN63ZwBIsSkeHI_MPGR0>
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 18:47:13 -0000

On 7/23/2020 12:42 AM, Lars Eggert wrote:

> 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.


Gorry, Lars, where can we find data on the NAT behavior and the relation
between NAT rebinding and routing paths? In home routers, NAT rebinding
typically only change if the session is quiet for some time. Do we
observe a different behavior with CGNAT?

-- Christian Huitema

v2.23.0 | Report a Bug | By Email