Re: [tcpm] WGLC for draft-ietf-tcpm-hystartplusplus-04

Reese Enghardt <> Wed, 27 April 2022 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0EABC157B47 for <>; Wed, 27 Apr 2022 11:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.955
X-Spam-Status: No, score=-3.955 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, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 s6niEsIIFqWc for <>; Wed, 27 Apr 2022 11:18:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C00C5C14F74D for <>; Wed, 27 Apr 2022 11:18:51 -0700 (PDT)
Received: from user.client.invalid (localhost []) by (Postfix) with ESMTPSA id 9A7D4AA; Wed, 27 Apr 2022 20:18:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20170414; t=1651083529; bh=uJKkQGly+9j40FVO9k6YOK6jmSqmpUhu1aPyd829h9M=; h=Date:Subject:To:References:From:In-Reply-To:From; b=P1ujcRG6U0UoFJa4BX5SubjUnKy4w+A/7rSrhr/SIBUNjMBLQLJfhngmx3L+jCCoR 7lrel3ksFsUWqkUfgdzN25eT9NDA9JhLU5NH08K+/OA+AL1ME/M5a/YItDKyeVn4zY 0wrl+E+p9LNnJ23vzWOYSXV+DwLJUfQY68TY/tMXQzX0tKzqznMpVFS+CzG8+BFRpv ZoneFtFdOtKkv3aibNR67wRA0/Y52VYiLD869vT5NaUnNlJPq3A65FFqKZRI+GNgrt aj9TT4IZOiI9Q+9lj0ZtWBSLtFvHGZt0GkhPM1h204Pj9fogp90TrX1/ThlhLnOczw VeVxAV66MLMxA==
Message-ID: <>
Date: Wed, 27 Apr 2022 11:18:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: Michael Tuexen <>, tcpm IETF list <>
References: <>
From: Reese Enghardt <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-hystartplusplus-04
X-Mailman-Version: 2.1.34
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: Wed, 27 Apr 2022 18:18:57 -0000

Dear Michael, all,

I have done some testing of the FreeBSD implementation with NewReno, and 
I have also read through draft-ietf-tcpm-hystartplusplus-04.

The document specifies Hystart++ precisely enough for me to understand 
how it works, and I appreciate the brevity and clarity. I am in favor of 
this document advancing.

I do have a couple of questions/comments, which I would appreciate to 
see considered before publishing the document:

First of all, I realize this is TCPM, but is it still worth adding a 
statement about the generality of the mechanism, as Hystart++ can also 
be implemented for other transport protocols? Is Hystart++ expected to 
be "compatible" with all congestion control algorithms? Please consider 
adding a brief statement to the Abstract or Introduction.

In Section 1, it says "HyStart++ reduces packet loss and 
retransmissions, and improves goodput in lab measurements and real world 
I think Hystart++ could potentially also help reduce queue delay for 
some congestion controllers and a non-AQM bottleneck, is this correct? 
If so, I think this point would be worth adding.
Are there any published testing results and/or more details on the 
tested setup(s), network path conditions under which Hystart++ has been 
tested, etc, that the authors are aware of, beyond the existing Section 
5? If so, please add links to them here or in Section 5. Please also 
consider adding a forward reference to Section 5 here.

In Section 4.2, the document defines "windowEnd as a sequence number 
initialized to SND.UNA". Why SND.UNA and not SND_MAX, i.e., the highest 
sequence number that was sent? (I think the FreeBSD implementation 
initializes it to tp->snd_max, which makes sense to me, therefore, I'm 
wondering if the spec should say the same.)
I think initializing it to SND.UNA would still work, as SND.UNA would 
probably be acked soon and then windowEnd would become SND.NXT. But in 
my mind, it seems like this adds one very short round at the beginning, 
perhaps unnecessarily. Please let me know if I'm missing anything here.

For Section 5: Are there any particular network path characteristics for 
which Hystart++ (with the recommended constants or others) is expected 
to perform particularly well, or not so well? Are there any results for 
higher capacity links such as 1 Gbps, any results specifically for 
mobile links, etc? Please consider adding citations here.
If you are aware of any findings along these lines, or any guidance on 
how to tune the constants in these cases, please consider adding a few 
sentences here or in Section 4.3.

Thank you.


On 4/13/22 13:18, Michael Tuexen wrote:
> Dear all,
> this e-mail starts the working group last call for draft-ietf-tcpm-hystartplusplus-04.
> The WGLC runs until Friday, May 6th 2022.
> Please send any comments, including indications to support this document,
> to the TCMP mailing list by then.
> The ID is available at
> Best regards
> Michael
> _______________________________________________
> tcpm mailing list