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

[Bob Briscoe <[e-mail]>]

Praveen and co-authors.

Thank you for hystart++.
I've sent a separate posting with technical review comments.

Cheers


Bob


    ==Editorial comments==


      Abstract

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 Briscoe                               http://bobbriscoe.net/