Re: [tsvwg] L4S vs SCE

Jonathan Morton <> Wed, 20 November 2019 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA45512081D; Wed, 20 Nov 2019 07:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 sk7cIxP6az15; Wed, 20 Nov 2019 07:01:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E81A51200F8; Wed, 20 Nov 2019 07:01:27 -0800 (PST)
Received: by with SMTP id h13so13965650plr.1; Wed, 20 Nov 2019 07:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VY1djQ08PxAySvyR4gzj0lKhAX+G6rxRNi7jUfuUc4c=; b=Hd83XIxHNRshkumyMX80nOROmnIDzHb7v8UOIeLInwERrp/cDofyht7qfHnR5JEte2 gIwAc355NVT/FNxa+VGqyD04nZp92ZVL87SQ1dG8Rv8LWv9HMq6x45IghtrwQpZqg7yF vJpbqrpburKwfUZ6iLyICNDPwsHaNWoUzqOpQFzUFv6TWFhYpa0vLkDxm1TsxEhpFN90 9/0QKhug0uM42Bcl1kAzkE8Bv4JwtMioJeivCuCh095FUXonx/l42+zJ4oWxy3k+yU/g IvTwEjO93PGZyMBJRQYqrS857QJYNH4NcGaznwsYf6oIOZXMYlf6nDRdPQ2TIyXfingZ Xr+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VY1djQ08PxAySvyR4gzj0lKhAX+G6rxRNi7jUfuUc4c=; b=SqrG0kPKFj8RuVrFvdRsNf3kETqbws3lW6lj84iViAUlHCGaDRvU07uptR2EVJpJAs uYNNgkmD9WuZb5opiyAfE5/ZYhB0BvyjgOXUKbgYdxlLGSK+6oQhylyCzkpO8y+EJE1/ rU3bZpN3KhuY+z9+1faHEe1VlRdootCsOZ8A7y+JEQ0yDBxcy8hh09ZLgMHyzwAOaaNI QXsFdwCS6w5y6XzGyNi5/dvl1WhEjCBNfVlpG2oNZ7XNL3+pf4nDAbKm0MDOo4x3WX20 u8SUhpxm3vDDjvpx6xS1EMKeVydpviUnwbAVBmKloomjpF5FPtADAZxWPbe18Sio/Qzb ek6A==
X-Gm-Message-State: APjAAAXHUF86Woo/RWPYCEdF7v2m5T86NjiXK6NDODwkKd+ANiiWYmr2 z1iB1KRjWyK3vzlSKkjINfI=
X-Google-Smtp-Source: APXvYqzbpTvxfxvoneXyftRIeEdSHupfukKcp73qSnOJC0W7VMirdldUdpkIKbPYQPLAZvsfx+2qHQ==
X-Received: by 2002:a17:902:8508:: with SMTP id bj8mr3354312plb.178.1574262087352; Wed, 20 Nov 2019 07:01:27 -0800 (PST)
Received: from jonathartonsmbp.lan ([]) by with ESMTPSA id 206sm37204228pfu.45.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 07:01:26 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 20 Nov 2019 23:01:23 +0800
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <>, G Fairhurst <>, "" <>, Ingemar Johansson S <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Sebastian Moeller <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] L4S vs SCE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 15:01:29 -0000

> On 20 Nov, 2019, at 10:18 pm, Sebastian Moeller <> wrote:
>> One of these opportunities here is to make L4S_TCP less RTT dependent. There have been many working implementations for less RTT-dependent CCs in the past. One that is widely deployed is Cubic, which is doing this for getting more throughput for longer RTTs. The only reason why it didn’t fly for lower RTTs on the current Internet is that they would hurt themselves (get lower throughput, competing with Reno).
> 	[SM] Looking at the pfifo_fast results in Høiland-Jørgensen T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential setting. Computer Networks 89:90–106. For Cubic/pfifo_fast (linux former default combination), I fail to see a strong indicator that cubic is RTT invariant or getting more thoughput at longer RTTs (except for the 10ms versus 50ms "hump"). What paper/data should I be looking at instead?

CUBIC is more RTT-invariant than Reno is, and achieves more throughput on high-BDP paths than Reno does, which I think was the meaning here.

Examining the formulae for calculating steady-state average cwnd from marking probability, and converting to throughput by dividing cwnd by RTT, it's clear that any CC algo that depends only on marking probability for cwnd evolution will converge to an RTT-invariant cwnd and will thus have the same RTT-fairness of throughput with itself as Reno does.  This is in fact true for TCP Prague and all of SCE's response functions thus far.

But CUBIC includes an RTT term in its steady-state formula which partially compensates for the conversion to throughput, such that CUBIC's self-competitive throughput in its high-BDP regime is proportional to the reciprocal quartic root of RTT, rather than to the plain reciprocal.

So I think that to meet Prague Requirement #5 - reducing RTT dependence - one must first achieve at least as good performance as plain old CUBIC in this respect.  Is there work towards this in progress within L4S?

 - Jonathan Morton