From ncardwell@google.com Fri Apr 19 07:24:36 2024 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0D5C151064 for ; Fri, 19 Apr 2024 07:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.596 X-Spam-Level: X-Spam-Status: No, score=-17.596 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpLjPPv2S6Qw for ; Fri, 19 Apr 2024 07:24:31 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799C2C14F60E for ; Fri, 19 Apr 2024 07:24:31 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-dcd7c526cc0so2338362276.1 for ; Fri, 19 Apr 2024 07:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713536670; x=1714141470; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bbFLGWSKDWHRJy6KbY5ctwI+HCftoti14v9rqPTsFiA=; b=WKOzyByw4t05rBL+OZ6W6PG3juE65Z4rWqddmONeShGlaaTzWREo3MKIopN+rIOYHr 2UwfyXiXhlwUozEsY3iUVwEgwIaNb+xxwS1IrtnPAV7pLf223JlxY2ajG6a35owm/NQf EuXvK9oFLusuhQpjB/5Rf/ytshgcl40mwgOhHrOXbwJmdKwOhlcN6IR99wBq9QaYGfIC Eje0FQ+rkqrfucpho62YXgGsZOBT5ifPLMjovbG1mDefabzXYNA0o/1ALCpn1hbh18B7 He5xBbFZjGj1Jw2rdmjehZbZh7/3gKcgD/fEzEMockMhnQv2Gh8PrhVfBkSnWSjLNwlp PQXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713536670; x=1714141470; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bbFLGWSKDWHRJy6KbY5ctwI+HCftoti14v9rqPTsFiA=; b=mEQMoQ1RBJCWOlsvv+tFwPgI0uqE6DyfTSrcNrx1eMUsY5AQYrcgGgN5uRwFd/RbwN 7ZAS5GLLWgNwHz9esuofAyW0WExV1ZNozdcz9+eo8e6EVhv6hu4XNu7hycRxjT9hwj8Z pyV4qkdE4h6g9xXoT0lMIkPK1Ti3iwV0DCGp1xtxJ7Nm74qQrfLcSG7ZvAQaSQrIWKAV znkBAA17H8ohGUo0V7ohe/H0RBwB70QTAnL5LQg2/PbJba7fnv1kBMacN01PmL7eiXri soshrkMPbOwJUIBHZaWzDOI0+3u8DHQNQQEvT7f5huHWDSwmgAa6xxOwLVuuFMwlTpJV 5kLg== X-Gm-Message-State: AOJu0YzgdEP+9e865X8QFEoylar6HHHlJwgZU42orP6unpr9bkxiDGg0 o86wNOnYq0plUP+i2JPx4oJ9lQrSSFSxPqk44NqyBE0aLfhFxtp0xz24TAX3Wu9wl6Hg+bfQGjg tIyJ2y5rTg1N2Bo5OWuW5l3Cna7ONVugs1VM0s2EQ+dtxCmVHmguIOmw= X-Google-Smtp-Source: AGHT+IEI7wXAHoa3v8113S9KTv6MJq6zRx6t/OFLB/3FYAbazk5Qp9if9qzLmFBpCr23lQCMsDkAX1k5D9MBOGAvNyM= X-Received: by 2002:a25:870c:0:b0:de4:6e3c:d173 with SMTP id a12-20020a25870c000000b00de46e3cd173mr2060350ybl.16.1713536669870; Fri, 19 Apr 2024 07:24:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Fri, 19 Apr 2024 10:24:08 -0400 Message-ID: To: Vasilenko Eduard Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000852ec3061673d88b" Archived-At: Subject: Re: [tsvwg] "Pacing" requirement is lost in L4S X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2024 14:24:36 -0000 --000000000000852ec3061673d88b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 19, 2024 at 4:39=E2=80=AFAM Vasilenko Eduard wrote: > Hi Experts, > I see L4S as the "Congestion Control Next Generation from IETF" (that is > actually in competition with "Congestion Control Next Generation from > Google"). > IMHO BBR is not in competition with L4S. BBR is, at its core, about maintaining an explicit model of the network path using whatever signals are available, and using that model to try to achieve low/bounded delay, low loss, and high throughput. L4S, IMHO, is largely about creating a low-latency, low-loss, scalable throughput service model (metaphorically a "lane") in Internet bottlenecks, and using ECN to provide a signal to achieve that. There is nothing fundamentally at odds about those two models. And once the details of the Prague congestion control algorithm are finalized, one goal (as our team has mentioned for a number of years) is to have a version of BBR that can use L4S signals and coexist with Prague congestion control in the L4S lane of Internet bottlenecks. > Then I see the important requirement that is missing in L4S. > > The primary requirement for CC is that it "should not grow the buffer on > the bottleneck link". > It is very disputable: is "the Scalable" requirement about it or not? > Let's pretend that it is about it. > > Then the next critical requirement is "pacing" which is missed in L4S > completely. > IMHO it is not at all fair or accurate to say that L4S misses the pacing requirement. :-) The pacing requirement is implicit in RFC 9330, at the very least in Section 8.2, 'Latency Friendliness': https://www.rfc-editor.org/rfc/rfc9330.html#section-8.2 That section says: "Like the Classic service, the L4S service relies on self-restraint to limit the rate in response to congestion. In addition, the L4S service requires self-restraint in terms of limiting latency (burstiness)." The only approach I'm aware of to limit the "rate" and "burstiness" of a flow, and the "latency" that it imposes, is to use pacing= . And this is explicit in Section 2.5.1, "Packet Pacing", of the Prague congestion control draft, which is part of the L4S suite of documents: https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-contr= ol-03.html#section-2.5.1 That section says: "A Prague CCA MUST pace the packets it sends to avoid the queuing delay and under-utilization that would otherwise be caused by bursts of packets..." best regards, neal > Kudos to Google because I understood its importance after one local (but > big) company tested and investigated BBRv1 (then implemented it). > After tests, they concluded that pacing is even more important than low > latency. (I doubt, probably latency is more important) > Imagine that the server would increase the window sharply. The Server may > have a 100GE interface. It could generate 10us of traffic as a burst (or > even more). > Intermediate links could be 100GE or even bigger (highly probable), and > the burst would travel as it is (without any spreading). > Then this burst could arrive at 10Mbps subscriber (good performance for > shared public WiFi). 0.01ms burst would become 100ms burst. > It would create many negative consequences for the bottleneck link: > - tail drop if buffers are not enough > - guaranteed huge latency > Hence, we should completely forget about W (window) while discussing CC, > we have to use T (time between packets). > CC next generation "should avoid bursts regulating inter-packet time, not > the information permitted in transit". > > Best Regards > Eduard Vasilenko > Senior Architect > Network Algorithm Laboratory > Tel: +7(985) 910-1105 <+7%20985%20910-11-05> > > --000000000000852ec3061673d88b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 19, 2024 at 4:39=E2=80=AFAM V= asilenko Eduard <vasilenko.eduard=3D40huawei.com@dmarc.ietf.org> wrote:
Hi Exper= ts,
I see L4S as the "Congestion Control Next Generation from IETF" (= that is actually in competition with "Congestion Control Next Generati= on from Google").

IMHO BBR is not = in competition with L4S.

BBR is, at its core, abou= t maintaining an explicit model of the network path using whatever signals = are available, and using that model to try to achieve low/bounded delay, lo= w loss, and high throughput.

L4S, IMHO, is largely= about creating a low-latency, low-loss, scalable throughput service model = (metaphorically a "lane") in Internet bottlenecks, and using ECN = to provide a signal to achieve that.

There is noth= ing fundamentally at odds about those two models. And once the details of t= he Prague congestion control algorithm are finalized, one goal (as our team= has mentioned for a number of years) is to have a version of BBR that can = use L4S signals and coexist with Prague congestion control in the L4S lane = of Internet bottlenecks.
=C2=A0
Then I see the important requirement that is missing in L4S.

The primary requirement for CC is that it "should not grow the buffer = on the bottleneck link".
It is very disputable: is "the Scalable" requirement about it or = not? Let's pretend that it is about it.

Then the next critical requirement is "pacing" which is missed in= L4S completely.

IMHO it is not at all = fair or accurate to say that L4S misses the pacing requirement. :-)

=
The pacing requirement is implicit in RFC 9330, at the very leas= t in=C2=A0Section 8.2,=C2=A0 'Latency Friendliness':
Th= at section says: "Like the Classic service, the L4S service relies on = self-restraint to limit the rate in response to congestion. In addition, th= e L4S service requires self-restraint in terms of limiting latency (burstin= ess)." The only approach I'm aware of to limit the "rate"= ; and "burstiness" of a flow, and the "latency" that it= imposes, is to use pacing.

And this is explicit in Section 2.= 5.1, "Packet Pacing", of the Prague congestion control draft, whi= ch is part of the L4S suite of documents:That section says: &= quot;A Prague CCA MUST pace the packets it sends to avoid the queuing delay= and under-utilization that would otherwise be caused by bursts of packets.= .."

best regards,
n= eal

=C2=A0
Kudos to Google because I understood its importance after one local (but bi= g) company tested and investigated BBRv1 (then implemented it).
After tests, they concluded that pacing is even more important than low lat= ency. (I doubt, probably latency is more important)
Imagine that the server would increase the window sharply. The Server may h= ave a 100GE interface. It could generate 10us of traffic as a burst (or eve= n more).
Intermediate links could be 100GE or even bigger (highly probable), and the= burst would travel as it is (without any spreading).
Then this burst could arrive at 10Mbps subscriber (good performance for sha= red public WiFi). 0.01ms burst would become 100ms burst.
It would create many negative consequences for the bottleneck link:
- tail drop if buffers are not enough
- guaranteed huge latency
Hence, we should completely forget about W (window) while discussing CC, we= have to use T (time between packets).
CC next generation "should avoid bursts regulating inter-packet time, = not the information permitted in transit".

Best Regards
Eduard Vasilenko
Senior Architect
Network Algorithm Laboratory
Tel: +7(985) 910-1105

--000000000000852ec3061673d88b--