[tcpm] draft-ietf-tcpm-hystartplusplus and QUIC

Christian Huitema <huitema@huitema.net> Mon, 19 September 2022 18:50 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DF6ACC14F74C for <tcpm@ietfa.amsl.com>; Mon, 19 Sep 2022 11:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aDES6u5mF9gl for <tcpm@ietfa.amsl.com>; Mon, 19 Sep 2022 11:50:09 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com []) (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 40CDCC14CF15 for <tcpm@ietf.org>; Mon, 19 Sep 2022 11:50:08 -0700 (PDT)
Received: from xse35.mail2web.com ([] helo=xse.mail2web.com) by mx256.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1oaLqE-000Hll-0m for tcpm@ietf.org; Mon, 19 Sep 2022 20:50:05 +0200
Received: from xsmtp21.mail2web.com (unknown []) by xse.mail2web.com (Postfix) with ESMTPS id 4MWYdM50Pnz5bL for <tcpm@ietf.org>; Mon, 19 Sep 2022 11:49:59 -0700 (PDT)
Received: from [] (helo=xmail09.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1oaLqB-0001es-ID for tcpm@ietf.org; Mon, 19 Sep 2022 11:49:59 -0700
Received: (qmail 24477 invoked from network); 19 Sep 2022 18:49:56 -0000
Received: from unknown (HELO []) (Authenticated-user:_huitema@huitema.net@[]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martin.h.duke@gmail.com>; 19 Sep 2022 18:49:54 -0000
Content-Type: multipart/alternative; boundary="------------30VQHtOn96Gv38FqK32LpF70"
Message-ID: <e0f16f9e-e16c-2194-bb1c-2afebde2aacc@huitema.net>
Date: Mon, 19 Sep 2022 11:49:51 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Martin Duke <martin.h.duke@gmail.com>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
From: Christian Huitema <huitema@huitema.net>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
X-Spampanel-Domain: xsmtpout.mail2web.com
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjTC8Fov82/EJuxz8FihBPKj/EwzSHE5FGYwwjsNRPCGFY rRfMsdrQbpqDVcg2w73mD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaElcg2GBBjrbkJhbd9/2bNhQ6V51u76v35b1wNe/MvdIASZp0 7mnQqdezZCtq+A712+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEEIgtEXyXj6S3SDvReMcV 8TXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7hMIABpqqRGKyDs8xujM3cqKtEyjRS48tkuSWBkVvcslCR1RDFY04iEycsW7Yw4y6S1 +eNIFJM4+q/GFrwbjkOSEnFzsC48bTEFY06/YbB87aZA2T1TDpm1DkXX6Es5zXntCB3G1CwpaI3Z 4ESkMWDVEmlGVTLa11kLY1eVj2D9MJQNgEftlVCmKB29oEvem6zZcpPgEJKLbDyaC/LdLvvYsbnE a4ggDYkkn3Hu73LQOvpVB9v9zY0h8asEYmbGGsLRRrpb2yB+9SGl7QVSZMRQ6JOfehwPPH2yBPhd 2IUBmh0sl4OFxBT1d23OUWLVuGpBtL9ewJnoHKUNLZpf7DfZK/JdWvgd2/FibEdMM0Jnxu/VcARR JJg0CPVGXFYA7xCx7SWZBpdAUArn/St00aGa08t44IPL25P8DLNzMDIRDLdvK/cKOEqlCIPGIfYQ DNLcNVwigJ23suxKKQl6t4RW
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/h7mhL_bPBBIwEQfqgZsT6UBLHl0>
Subject: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2022 18:50:10 -0000

I have followed the progress of the Hystart++ draft in TCPM, and I have 
a process question.

Algorithms like Hystart++ are not just used by TCP, but also by other 
protocols like QUIC. They are developed in the "TCP maintenance" WG, 
which is indeed about TCP, and thus the spec is quite TCP centric. For 
example, in the definition section of draft-ietf-tcpm-hystartplusplus, 
we read that "if the MSS option is not used, [the receiver maximum 
segment size] is 536 bytes" -- but "QUIC assumes a minimum IP packet 
size of at least 1280 bytes" per RFC9000. Which leads to the process 

Should congestion control algorithm be specified in a transport protocol 
specific way, as for example "HyStart++ for QUIC", or should the 
specification be kept as generic as possible?

I can absolutely see valid reasons for doing either way. Having generic 
specification means doing the work just once, also help achieving 
somewhat compatible behavior by multiple transport protocols. Having 
transport specific specifications leads to more precise specification -- 
HyStart++ for QUIC can reference the correct minimum packet size, the 
negotiation of "max_udp_payload_size", or the interaction with 

The QUIC WG recently had an adoption call of a draft specifying "Careful 
resumption of congestion control from retained state with QUIC". The 
adoption was refused. To quote, "The chairs' sense of the feedback is 
that while this is useful work that people support at the IETF, it is 
work in a problem space is more broadly to do with congestion control 
and not entirely QUIC specific." The authors were instructed to work 
with tsvwg, or with a to-be-formed congestion control WG. So we see two 
discussions with opposite conclusions: HyStart++ adopted in TCPM, 
careful resumption redirected to a generic WG.

I wish there was a consistent approach...

-- Christian Huitema