Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt

Neal Cardwell <> Tue, 09 July 2019 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD3AF1201DC for <>; Tue, 9 Jul 2019 08:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.205
X-Spam-Status: No, score=-16.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yz8MmI7oLEQL for <>; Tue, 9 Jul 2019 08:07:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F21E9120248 for <>; Tue, 9 Jul 2019 08:07:18 -0700 (PDT)
Received: by with SMTP id p17so19953858ljg.1 for <>; Tue, 09 Jul 2019 08:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZV+ejO1m3BJmQ2Lynropf5L8pIQT1m1CcMJjfudg9JE=; b=VETvZYj4cqdCGB3LfirAtWJDWU05VKXF+7eN/qx5X/QgA8FpvQbdiB1WSSKHZTKdsX ZihNy1KlcGEBUotyaUQrlbk4lD445jFDV2+mEKe2v4X1gwB147UjCc4iXSUAL78pzByR vBvs9ElXbW51r67eFgoBYLaFU40TKbP/u3HxYbdV9yxS5IFBSzbEjj15gnyRyufVF/bp 6LRUT/Vp2GWITcG7ISgKGfB6ZkmH+XIWjf+NuOGPjEKCIVbJYreBh6l4WgLx9NKI439f xbjQvc7XqVIDWvYUaezSN6iBxuDgjno2/LHWcMr/DOlavBiuqh6+Zqs8UWCvBqDFML2V qA8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZV+ejO1m3BJmQ2Lynropf5L8pIQT1m1CcMJjfudg9JE=; b=s+7VYm48sNf718OTcZUDFZmm6H9r7NZZSbMTI31B5pdpm3RV26a/QEioq5oEECNAPr rfhXWQAADlVmwSndzvepNMfemrIatWXFIg3cHDVoIzA4c1hSUvRAAaEAvbwnEf339gjW mpt1j2DJcQpDJPABh6cwclW84pYvDN+UC1rhTn8Mu+kAQLGen1UCGd8jCso6wzntD6K1 HnfvJsIeJH7HYQTA85TCZdk+VjKaX+QaIG88RWzMJPjKMnRq6w93QxlkgwkM6H4zRIQ6 Y7XH+34nTo9mSxZoeIzlhu8z3/krlzS4y07wkZR+ibA0eWWsFUwFlIC218aWLBiWGGld XOFw==
X-Gm-Message-State: APjAAAULOt6+aJ5Uopdx5aVvgnUaY+S21g7QC0SGSaO/nXhqqw7GgsfK pmL18xh5x/5aykwqfak1LbKT7F6nxbOxn2zctPnkTg==
X-Google-Smtp-Source: APXvYqz9uGaJZ58LacXj9euxyi6ABW97cJ9qJRPd04c5mDyLI6T7ZAOLRj5FesMopjzJ6GmK99eBUEI7qRUk+amge6Y=
X-Received: by 2002:a2e:894a:: with SMTP id b10mr12198979ljk.99.1562684836934; Tue, 09 Jul 2019 08:07:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Neal Cardwell <>
Date: Tue, 09 Jul 2019 11:06:58 -0400
Message-ID: <>
To: Praveen Balasubramanian <>
Cc: "" <>, Matt Olson <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [tcpm] FW: New Version Notification for draft-balasubramanian-tcpm-hystartplusplus-00.txt
X-Mailman-Version: 2.1.29
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: Tue, 09 Jul 2019 15:07:28 -0000

On Mon, Jul 8, 2019 at 7:11 PM Praveen Balasubramanian
<> wrote:
> We submitted a draft for modified slow start using HyStart and Limited Slow Start. Feedback is welcome.

Thanks for posting this draft! (

This is a very nice, clear document, IMHO.

I was curious about a couple of items:

(1) In the draft the condition for exiting slow start is:

            Eta = clamp(MIN_ETA, currentRoundMinRTT / 8, MAX_ETA)
            if (currentRoundMinRTT >= (lastRoundMinRTT + Eta))

The use of currentRoundMinRTT/8 to compute Eta is counterintuitive to
me, and is different from both the Hystart paper and the Linux CUBIC
Hystart implementation from the CUBIC authors.

The Hystart paper used (modified pseudocode):

  if (currentRoundMinRTT> lastRoundMinRTT + clamp(lastRoundMinRTT / 16))

The Linux implementation from the Hystart author Sangtae Ha in 2008
used the approach (pseudocode):

  if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 16))

Eric Dumazet changed the Linux approach in 2014 to use a different
constant scaling factor (also pseudocode):

  if (currentRoundMinRTT> lifetimeMinRTT + clamp(lifetimeMinRTT / 8))

I am curious about the rationale for:

(a) Using an RTT threshold for exiting slow-start that is based on
currentRoundMinRTT/8, rather than being purely a function of the RTT
values from previous rounds (as in the Hystart paper) or the lifetime
of the connection (as in Linux)?

(b) Using a function of lastRoundMinRTT and currentRoundMinRTT for the
exit threshold, rather than a function of the min RTT over the
lifetime of the connection ("lifetimeMinRTT" in my pseudocode, above)?
Is the rationale here partly to deal with fluctuations in RTT due to
cellular/wifi/DOCSIS paths with noisy RTTs?

Any background on the motivation would be interesting to hear, or
perhaps to include in future drafts.

(2) The Limited Slow-Start approach described in the draft seems to
boil down to increasing cwnd by roughly ssthresh/4 each round trip.
It does seem like that would be considerably faster than Reno or CUBIC
would normally grow in congestion avoidance, for the first few seconds
after exiting slow start. But it does seem to be essentially just a
large additive increase. And so it would seem that if CUBIC were
instead in its native CUBIC congestion avoidance instead of limited
slow-start, then CUBIC would eventually (e.g. after a few seconds)
tend to reach the rapid-growth convex portion of the cubic curve, and
eventually grow much faster (eventually reaching exponential growth of
1.5x per round trip). I wonder if it would be advantageous for CUBIC
connections exiting HyStart++ to use a  strategy of growing the cwnd
using the maximum of the schedule calculated using limited slow-start
and the schedule calculated using the normal CUBIC congestion
avoidance logic. That seems like it might have the potential to
mitigate performance issues for CUBIC connections that spuriously exit
slow-start too soon?

best regards,