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

[Bob Briscoe <[e-mail]>]

Praveen and co-authors.

Thank you for hystart++.
This one's my technical review. I've sent my editorial review in a 
separate posting.

I actually reviewed an earlier draft (balasubrmanian-02), but never got 
round to writing it up for you. I've just reviewed the latest (ietf-02) 
draft, and incorporated my comments about the older revision where still 
relevant.

Cheers


Bob


    ===Technical Comments==


4.2.  Algorithm Details

------------------------------------------------------------------------

  Round can be approximated using sequence numbers as follows:
    ...
    At the start of each round during normal slow start and CSS:

It might be worth stating that using sequence numbers is the /best/ way 
to measure rounds, not just one way. You want every round to contain at 
least one of the ping-ponged segments that were grandfathered by the 
very first segment of the IW (because that will be the segment most 
likely to have the min RTT). For instance, if you measure rounds in 
time, you might underestimate the duration of a round. Then, in some 
rounds, you would risk not seeing one of this ping-pong series at all.

------------------------------------------------------------------------

"where currRTT is the RTT sampled from the incoming ACK"
Need to make it clear this RTT is based on the latest ACK'd packet, not 
the earliest (in contrast to the RTT used for RTO).

------------------------------------------------------------------------

The somewhat opaque clamping of RTTThresh below needs to be justified:

       For rounds where cwnd is at or higher than LOW_CWND and
       N_RTT_SAMPLE RTT samples have been obtained, check if delay
       increase triggers slow start exit
       ...
             RttThresh = clamp(MIN_RTT_THRESH, lastRoundMinRTT / 8, MAX_RTT_THRESH)
             if (currentRoundMinRTT >= (lastRoundMinRTT + RttThresh))
                cssBaselineMinRtt = currentRoundMinRTT
                exit slow start and enter CSS


To aid comprehension for the benefit of the list, I'll separate the 
clamp line into two steps and substitute the default constants:
             RttThresh = clamp(32ms, lastRoundMinRTT, 128ms)
             RttThresh /= 8

To me, it makes good sense without the clamping. In english, that would 
be just:
     "if queuing due to slow start increases the min RTT by more than 
12.5% from one round to the next, exit slow start"

However, taking the default values of the constants, the clamping 
expression adds the following conditions:

    #1) If the base RTT is lower than 32ms, the queue has to be greater
    than 4ms to exit slow start.
    #2) If the base RTT is higher than 128ms, the queue only has to
    exceed 16ms to exit slow start.

I.e. at both extremes, the threshold becomes absolute, rather than a 
fraction of the base RTT.

Possible rationales for the lower condition when the base RTT is small (#1):

    a) an absolute Qdelay threshold is needed because small delay
    measurements are too noisy.
    b) a relative amount of Qdelay would become smaller than humans can
    perceive, so an absolute floor is sufficient.

If (a), this needs to be stated, because different min delay measurement 
techniques can achieve different noise immunity.
I don't agree with (b), because unnecessary delay over a sequence of 
rounds can accumulate to become perceivable.

I can't think of a good rationale for the higher condition (#2). I'm 
sure it was the result of experiments, but it seems to be likely that as 
base RTT increases beyond 128ms, Hystart++ would become increasingly 
sensitive and exit slow start earlier and earlier - unnecessarily (?).

Whatever, the rationale for clamping RttThresh needs to be stated, so 
admins know how to set the parameters for other scenarios (for instance, 
in DCs excessive loss would occur with the given defaults).


------------------------------------------------------------------------

5.  Deployments and Performance Evaluations

It would be useful to see testbed results separated by whether the 
bottleneck before the flow arrives is empty, full, or part-full of traffic.

Although Hystart is default enabled in Linux, it is invariably disabled. 
So, it's misleading to just say Hystart is default enabled, which 
implies it's widely used, when people clearly find it has problems 
(which motivates Hystart++). I found this out through an informal survey 
I did at the Mar'18 IETF in London by asking round the implementers of 
the most prevalent stacks (I would name names if I could find the note I 
later sent to someone or to some list, but I can't find it - sry).


------------------------------------------------------------------------

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/