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

Bob Briscoe <ietf@bobbriscoe.net> Thu, 22 July 2021 15:42 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A8E373A4AC0; Thu, 22 Jul 2021 08:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TsHV8yQIwyr6; Thu, 22 Jul 2021 08:42:25 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B13B3A4ABC; Thu, 22 Jul 2021 08:42:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z6wFSqRNkrJI1VA2dcsLzmG1AAWUim97yZdLjM+tEvY=; b=gqiO5TR1kzOyugPhUmuoOcJ0N3 skBjVSZylFV4OWcUUHFreQUjI1RQtPh/Z381fY+kVmbRp2xzPtBmam1gCCJjPWCwKUWq5yJk5B2Fj ovQX4rASqcHdcjgpXpSkp1seDTH5TvtMR6O3gV5QDABuTVRsn8GxNZS3ZhTbtwKb3WfAAjPr+cz9X wWVGukt76taYIsR4rX7p2cekhGc8oNy4+Rn9cVW3wgZZV1cnyI/pbCkBO3GoeVHtr15SPNrB3VDlX r18q4SvHVA3OY8Nsb7au3I7kNVSrjMe8nmwRaujj1n8G2V1JPoi14jSiTmWD6kTd7BO5culqnexel MttHBplg==;
Received: from ([]:48760 helo=[]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1m6aqB-0002K6-A4; Thu, 22 Jul 2021 16:42:20 +0100
To: Praveen Balasubramanian <pravb@microsoft.com>
References: <162610476442.30543.4667406094304409800@ietfa.amsl.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tcpm@ietf.org, draft-ietf-tcpm-hystartplusplus@ietf.org
Message-ID: <98289918-67d1-2be1-723d-2df66be46fac@bobbriscoe.net>
Date: Thu, 22 Jul 2021 16:42:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <162610476442.30543.4667406094304409800@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------674DDBBD62C5B2BDB82A2B6D"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/8f9qJ8M02-Fo_YG3FIb58nqKlbA>
Subject: [tcpm] Full review of: draft-ietf-tcpm-hystartplusplus-02 (technical)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2021 15:42:32 -0000

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 



    ===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).




On 12/07/2021 16:46, internet-drafts@ietf.org 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

Bob Briscoe                               http://bobbriscoe.net/