Re: [tsvwg] "Pacing" requirement is lost in L4S

[Vasilenko Eduard <[e-mail]>]

Ops, I did not read RFC 9331, because it is just a justification for why ECN(1) is needed.
Reading RFC 9330 (L4S architecture) and 9332 (Double Queue) – it was evident why L4S needs ECN(1).
I have skipped it as redundant and very duplicated to RFC 9330.
Looks like I was wrong with the first impression.

I am a little worried about the exact number 250us on the bottleneck – it would be difficult to achieve.
IMHO: just the requirement to minimize it would be enough (with some explanations).

Actually, burstiness prevention is not a requirement for Prague only (as stated by URL),
It MUST be a requirement for any CCA.
Eduard
From: Greg White <g.white=[e-mail]>
Sent: Tuesday, April 23, 2024 23:18
To: Vasilenko Eduard <[e-mail]>; Neal Cardwell <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] "Pacing" requirement is lost in L4S

I realize that this discussion was really intended to be more of a rate-based vs. window-based CC discussion, but on the subject of a pacing requirement in L4S (using the short-time-scale meaning), there is also one of the “Prague Requirements” in RFC9331 https://www.rfc-editor.org/rfc/rfc9331.html#l4sid_Prague_req-burstiness:


  1.  A Scalable congestion control is expected to limit the queue caused by bursts of packets. It would not seem necessary to set the limit any lower than 10% of the minimum RTT expected in a typical deployment (e.g., additional queuing of roughly 250 us for the public Internet). This would be converted to a number of packets by multiplying by the current average packet rate. Then, the queue caused by each burst at the bottleneck link would not exceed 250 us (under the worst-case assumption that the flow is filling the capacity). No normative requirement to limit bursts is given here, and until there is more industry experience from the L4S experiment, it is not even known whether one is needed -- it seems to be in an L4S sender's self-interest to limit bursts.


From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:vasilenko.eduard=[e-mail]>>
Date: Tuesday, April 23, 2024 at 2:14 AM
To: Neal Cardwell <ncardwell=[e-mail]<mailto:ncardwell=[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] "Pacing" requirement is lost in L4S

Hi Neal,
Big thanks for your answer.

[snip]
2.
Section 8 in general is “Security”. People typically do not read that section.
Requirements are in section 4 - It has nothing about burstiness.
The quote from section 8.2 has a little sense and may be interpreted very loosely.
Not many people would be capable of giving the interpretation that you did.

I did not read the Prague CCA yet because it has the status “personal opinion with zero deployments”.
It may be that it addresses the burstiness properly.
I am trying to understand and predict what will happen next, Prague does not look yet as the probable future.

Eduard

From: Neal Cardwell <ncardwell=[e-mail]<mailto:ncardwell=[e-mail]>>
Sent: Friday, April 19, 2024 17:24

On Fri, Apr 19, 2024 at 4:39 AM Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
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-control-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