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

Martin Duke <> Mon, 19 September 2022 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07516C1522A4 for <>; Mon, 19 Sep 2022 11:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jpHvPfp-Yg2X for <>; Mon, 19 Sep 2022 11:52:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 74A88C14CE38 for <>; Mon, 19 Sep 2022 11:52:40 -0700 (PDT)
Received: by with SMTP id d1so461807qvs.0 for <>; Mon, 19 Sep 2022 11:52:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=oBWSd0paFe9pouBkUNS5JnkzZPZnjwD9UzTANjjORTw=; b=LXAYHssRl8i+RYTRfjVFs61eHdyCFjQGX1REgna1QZ8vIA/S07Wpo49yb0MmqeVpJv j61PdXVRxtjRkYAk9k84g3XyN5rqQDiH8F4CJvT77Loccz5KLhOgQV3psL9YdoAhIEW0 9uJHb7N1ntH1/9Vu1AJCXxTRTfzwTw8oCQtXKjhFDWQBEawqw+4btWii/sc0kKW8QMBV 7zLjLqwOKKtdtgDwb83mBrgi3cCflhgVJkrerIiZuBmqr1qnOxjFtH6uEYysgMjuoMTc LpKf5+iwrtI+uVRbx8XvNbGe+CyIZGR4HKeyV0/Ow5ZGD1O1DbxmlXG+/KjU8VN5+YEI ip8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=oBWSd0paFe9pouBkUNS5JnkzZPZnjwD9UzTANjjORTw=; b=Vv/XkZ9Ik2NImZBJP1AnUjZlpv6b+b4tpNhGBlgeQC2bYyZGBwVOfh5D24wbppJus2 iNohTvKEoTTdSe2Pa7lKG6rH9ShnZpJ72S0IFDl/gKN2UMb13PZo3VRYF8jLkg0PAZUj 4cIrRta+1kc3aVcz2r2uqfCtXZkTAMvokvvaHNUxSNZ4D7VN+VilUhLelzqZRzEbeq5u kjfEtJkmVAQaF6eGowgXyZEbcOJefJ93verZaw0PQGBUoyQvki2qz7PwyWRIiEkrTLmE MII2a9AcnCXnWDn1Tb/MnK+Hxrm8mZVDu2fjz9R7wFXVWd4ZOKj6PjT8c5nrG4gvCkzj 5xyA==
X-Gm-Message-State: ACrzQf1506pDaPSH8ZlxXzQ0yc6BgXOFSlYzPut6XAFdLaNz9aBMw4GS rFb4c9AAQJnKC21JzqO2A8KBiXVRMBFQNsLNprE=
X-Google-Smtp-Source: AMsMyM6/29OSdV/v496R2oinmBeY3feCAIigrAGPoq0jPb/JGwfj0tsQBjvPyGC55yAwpylYHfHdKeOcE+7Zl5UcORU=
X-Received: by 2002:a05:6214:5195:b0:4ad:1d6a:7775 with SMTP id kl21-20020a056214519500b004ad1d6a7775mr11497075qvb.120.1663613558723; Mon, 19 Sep 2022 11:52:38 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Martin Duke <>
Date: Mon, 19 Sep 2022 11:52:26 -0700
Message-ID: <>
To: Christian Huitema <>
Cc: Zaheduzzaman Sarker <>, " Extensions" <>
Content-Type: multipart/alternative; boundary="0000000000003619e605e90c37de"
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 18:52:41 -0000


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

> 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