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

Christian Huitema <> Mon, 19 September 2022 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BBD0C14CE2D for <>; Mon, 19 Sep 2022 12:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8oq5F2LTEx-4 for <>; Mon, 19 Sep 2022 12:05:09 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 7F729C14CE20 for <>; Mon, 19 Sep 2022 12:05:09 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1oaM4m-00031A-64 for; Mon, 19 Sep 2022 21:05:08 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4MWYyj5DQRz9cF for <>; Mon, 19 Sep 2022 12:05:01 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1oaM4j-0001nn-Hk for; Mon, 19 Sep 2022 12:05:01 -0700
Received: (qmail 14618 invoked from network); 19 Sep 2022 19:05:01 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 19 Sep 2022 19:05:00 -0000
Message-ID: <>
Date: Mon, 19 Sep 2022 12:04:59 -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 <>
Cc: Zaheduzzaman Sarker <>, " Extensions" <>
References: <> <>
From: Christian Huitema <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results:; 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/EwzSHE5FGYwwjsNRPCNpe 226neLr1boW9+SzLnJvmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imcau6YoLc4G0fBJNv57OLjy6BQ6V51u76v35b1wNe/MvdJPWWqi c9eoDWW+hxVOsiYx2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEEIgtEXyXj6S3SDvReMcV 8TXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7hMIABpqqRGKyDs8xujM3cq7Rvkiy9CGpqIMbF0Ys3gbbsBpjgoVxxWkDZ3t+RBeDns Td4VyB7Se9UHI7b1hVQ/EnFzsC48bTEFY06/YbB87aZA2T1TDpm1DkXX6Es5zXntCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAkyWiuIoV9YoAM9dq9BlFcWyuLfHqAnAj7rgKH7+eCmmziO2 KgbjM1z7HKOwVgM7t1ShcA6Xvva2QAVEjpqzANbJ1UfXmet2cbFKoyT/OdZLzCPwVJjNPStIOx/H M0DkPm0AuXq0T17woJo3avKeADIsy647Mn0zwmGzAi3Zn+YdthRNgs7Ig4l/XErpYn3glZTKFuaT l19W3ISq9+1KiLsESGU+y+fjdgjudZxiTPi+MG1QP35nsYfP84c+RFK3KiZuZ5OAUoGBziSYFLZu u6zX3xxsmqT8l9ARlsTalAaf
Archived-At: <>
Subject: Re: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Sep 2022 19:05:13 -0000

I followed it from afar. The proposed charter is fine, but I don't see 
much progress towards an actual WG. It seems that these discussions are 
de-factor happening in TCPM. Indeed, the TCPM charter says: "TCPM also 
provides a venue for standardization of incremental enhancements of 
TCP's standard congestion control. In addition, TCPM may document 
alternative TCP congestion control algorithms that are known to be 
widely deployed, and that are considered safe for large-scale deployment 
in the Internet."

-- Christian Huitema

On 9/19/2022 11:52 AM, Martin Duke wrote:
> Christian,
> Did you track my congestion control working group proposal in tsvarea?
> This was well received but is currently no one is stepping up to nail down
> consensus on the charter.
> On Mon, Sep 19, 2022 at 11:50 AM Christian Huitema <>
> wrote:
>> 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 question.
>> 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
>> draft-ietf-quic-ack-frequency.
>> 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
> _______________________________________________
> tcpm mailing list