Re: [tcpm] Full review of: draft-ietf-tcpm-hystartplusplus-02 (editorial)

[Bob Briscoe <[e-mail]>]

Praveen & co-authors,

Sry, omitted one more comment about the abstract. Added inline.

Bob

On 22/07/2021 16:43, Bob Briscoe wrote:
> Praveen and co-authors.
>
> Thank you for hystart++.
> I've sent a separate posting with technical review comments.
>
> Cheers
>
>
> Bob
>
>
>     ==Editorial comments==
>
>
>       Abstract
>

s/prevent/mitigate/
Otherwise over-claiming.

> s/doument/document/
> s/overshotting/overshooting
>
>
>       1. Intro
>
> s/pefrormance/performance/
>
> "...lead to overshooting the ideal sending rate and cause significant 
> packet loss"
> Also queuing delay? Is reducing queuing delay (for other flows) also a 
> goal of Hystart++?
>
> Last para of intro seems to be about Hystart, and it doesn't make it 
> clear how Hystart relates to Hystart++:
> * "HyStart++ adds delay increase..."
>    Adds to what?
> * "After the HyStart delay algorithm finds an exit point, a 
> Conservative Slow Start (CSS) phase is used"
>   But what about Hystart++? does it do CSS too?
>
> Final sentence is not related to the rest of the para about Hystart, 
> so should be a separate para.
>
>
>       3. Definitions
>
> It seems odd to define some well-known variables (like cwnd), but not 
> others like SND.UNA, SND.NXT, etc.
>
> cwnd: Would be useful to define the units assumed in the pseudocode 
> later (bytes), because some implementations use segments.
> It's confusing for cwnd to use bytes but LOW_CWND to use segments.
>
>
>       4.2 Algorithm Details
>
>
>     "The choice of value of L is up to the implementation."
> I suggest:
>     "The choice of value of L is discussed in RFC 3465."
> Reason: RFC3465 doesn't say it's completely up to the implementation - 
> it gives recommendations and advice.
>
> "normal slow start"
> I appreciate you were asked to use this word, but... I suggest it's 
> best to define this phrase because, for instance, the normal slow 
> start for Cubic (Hystart) is different from the normal slow start for 
> Reno. It's also a problem finding a good word that means the 
> pre-existing thing. 'Reno slow start' would be more precise than 
> 'normal slow start' (if you mean the one in Reno). Because Cubic is 
> more normal than Reno these days. And saying 'standard' will soon be 
> ambiguous, because Cubic is on its way onto the standards track.
>
>
>     "If congestion is observed anytime during slow start or CSS, enter 
> congestion avoidance."
> The word 'congestion' is ambiguous, because it could include delay 
> increase. How about:
>     "If loss or ECN-marking is observed anytime during slow start or 
> CSS, enter congestion avoidance."
>
>
>       5.  Deployments and Performance Evaluations
>
>     As of the time of writing, HyStart++ has been default enabled for all
>     TCP connections in Windows for two years.  The original Hystart has
>     been default-enabled for all TCP connections in Linux TCP for a
>     decade.
>
> I suggest you give the actual deployment times, so these two sentences 
> don't keep having to be updated as the draft ages.
> Also, in Linux, Hystart is only implemented for Cubic (the default CC 
> module), so Hystart is not default if a non-default CC module is in 
> use. How about:
>
>     In Linux, the original Hystart has been default enabled for
>     TCP connections using the default congestion control module (Cubic)
>     for a decade.
>
>
> Regards
>
>
> Bob
>
>
> On 12/07/2021 16:46, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>>
>>          Title           : HyStart++: Modified Slow Start for TCP
>>          Authors         : Praveen Balasubramanian
>>                            Yi Huang
>>                            Matt Olson
>> 	Filename        : draft-ietf-tcpm-hystartplusplus-02.txt
>> 	Pages           : 8
>> 	Date            : 2021-07-12
>>
>> Abstract:
>>     This doument describes HyStart++, a simple modification to the slow
>>     start phase of TCP congestion control algorithms.  Traditional slow
>>     start can cause overshotting of the ideal send rate and cause large
>>     packet loss within a round-trip time which results in poor
>>     performance.  HyStart++ is composed of the delay increase variant of
>>     HyStart to prevent overshooting of the ideal sending rate, while also
>>     mitigating poor performance which can result from false positives.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-hystartplusplus-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/