Re: [iccrg] Updates to draft-briscoe-iccrg-prague-congestion-control-03

[Sebastian Moeller <[e-mail]>]

Hi Bob

On 31 October 2023 17:57:11 CET, Bob Briscoe <ietf=[e-mail]> wrote:
>Sebastian,
>
>On 31/10/2023 12:04, Sebastian Moeller wrote:
>> Hi Marten,
>> 
>> just a quick note, so far there is no implementation that I know of that actually implements Bob's idea of marked bytes ratio... So nobody has bothered thinking about whether it is feasible in reality or not. My take on this is, it is actually misguided introducing additional complexity without noticeable better performance over a much simpler "fraction of packets approach".
>
>[BB] Marten's point was about additive increase (specifically, which non-CE packets a delayed ACK covers for Prague's equivalent of TCP's appropriate byte counting).

[SM] Partially, it was also about how to convert an imprecise accumulative marked packet count into marked bytes. To which my response was 'you do not'... as the complexity is not worth it.... feel free to disagree.

>
>> But then i also believe that L4S in total is too little too late... we already know from the data center that rate coding queue filling status is too slow to begin with and that a non-ambiguous per-packet queue filling signal is strictly superior...
>
>"We already know" implies you have some form of proof?

[SM] Astute readers of the literature will notice a number of papers showing alternative methods of congestion signalling that use richer information than single bit rate codes and that generally outperform DCTCP. I have read a number of those and to me the matter is settled even though none of these papers offered a mathematical proof. Again, feel free to disagree.

>
>The unary ECN signal is all we have in the public Internet for the foreseeable future.

[SM] This why I consider it a problem that we wasted that codepoint on L4S instead of e.g. SCE with its three cobgestion levels...

 As Matt Mathis pointed out many years ago (when multi-bit congestion signalling was first being proposed for DCs), there are W unary bits of information per round in all the ECN fields of a round of W packets, which scales with the window.

[SM] Two problems with this:
A) decoding a rate code obviously takes time which interferes with a timely response
B) the information is likely spread over multiple flows making it even harder to get a timely approximation of the true congestion state.

Assuming the best congestion response is based on as good an estimate of the true congestion magnitude it seems pretty clear that maintaining 1 ECN bit is the end all of congestion signaling is not all that forward thinking.
As before feel free to disagree.

Regards
         Sebastian


>
>
>Bob
>
>
>> 
>>> On Oct 31, 2023, at 11:50, Marten Seemann <[e-mail]> wrote:
>>> 
>>> I read the draft and I'm trying to figure out how I'd implement Prague in my QUIC stack. There are a couple of things I've noticed:
>>> 	• Section 2.3.2: It’s unclear to me when exactly alpha is updated. I assume that once I receive the first ACK, I save the timestamp. When I receive a new ACK, there are two code paths: if it’s received within one rtt_virt, just accumulate the counters used to calculate frac. If it’s received after rtt_virt, update alpha according to the equation given in this section, reset the counters for frac and save the timestamp as the beginning of the next rtt_virt epoch. However, this would mean that the alpha value used for multiplicative decrease (section 2.4.2) would always be slightly outdated, which seems suboptimal for an immediate response to a growing queue. Is there a better way?
>>> 	• Section 2.3.3: QUIC uses both packet- and time-threshold loss detection (see sections 6.1.1 and 6.1.2 of RFC 9002). I’m not sure what exactly the recommendation of this draft is. It would certainly be possible to turn off packet-threshold loss detection, and rely on time-threshold altogether. Is that what QUIC implementations should do?
>>> 	• Section 2.4.2: Is the suppression of further decreases after one ECN-triggered decrease for one srtt, or is it one rtt_virt? Reading section 2.4.4 it sounds like it’s rtt_virt, but this could probably be clarified in this section.
>>> 	• Section 2.4.3: The QUIC ACK frame acknowledges (multiple) ranges of packets at the same time, together with cumulative ECN counts. It’s therefore not possible to tell which packet was ECN-marked. This means that a QUIC stack will be able to determine acked_sacked, but not ece_delta. Is it valid to approximate it by assuming that all packets had the same average size? Either way, this is pretty awkward to fit into the pseudo-code given in appendix B.5 of RFC 9002.
>> 	[SM] But back to your problem, simply ignore the size in bytes and operate on traction of packets (after all that is what the actually tested version of TCP Prague did as well). In reality most capacity seeking flows will employ as large packets as possible anyway so the byte fraction is going to be identical to the per packet fraction.
>> 
>> 
>>> 	• Section 2.4.3: Similarly, what's the correct order to process an ACK that reports an ECN marking: For example, an ACK might acknowledge 20 new packets, and report one ECN marking. I think the correct order would be applying the additive increase for 19 packets first, and then applying the multiplicative decrease afterwards. This is because receiving a CE-marked packet would elicit an immediate ACK frame from a QUIC receiver (RFC 9000, section 13.2.1). The draft should probably be explicit about this.
>>> 	• Section 2.4.4: I'm struggling to follow how exactly cwnd is supposed to change for small RTTs. Most important from an implementation perspective: section 2.4.3 says that ai_per_rtt will have a different value for small RTTs. It would be helpful if section 2.4.4 would contain an equation for ai_per_rtt.
>>> 
>>> 
>>> On Sat, 14 Oct 2023 at 19:45, Bob Briscoe <ietf=[e-mail]> wrote:
>>> iccrg,
>>> 
>>> We've just posted an update to prague-congestion-control.
>>> Links to diffs are quoted below.
>>> The main technical changes:
>>> 	• the Apple implementation falls back to CUBIC behaviour on loss (both the reduction and the subsequent increase). Currently the Linux implementation still falls back to Reno on loss, but that is being changed.
>>> 	• how the Apple implementation over QUIC behaves when the path or the remote peer fails to support ECN properly
>>> 	• the items already discussed on this list in response to Neal's review, some of which were editorial, but others were technical, e.g.
>>> 		• pseudocode for removing integer rounding bias
>>> 		• clarifying the RTT-independence approach
>>> Cheers
>>> 
>>> 
>>> Bob & co-authors
>>> 
>>> 
>>> 
>>> -------- Forwarded Message --------
>>> Subject:	New Version Notification for draft-briscoe-iccrg-prague-congestion-control-03.txt
>>> Date:	Sat, 14 Oct 2023 05:07:58 -0700
>>> From:	[e-mail]
>>> To:	Bob Briscoe <[e-mail]>, Koen De Schepper <[e-mail]>, Olivier Tilmans <[e-mail]>, Vidhi Goel <[e-mail]>
>>> 
>>> 
>>> A new version of Internet-Draft
>>> draft-briscoe-iccrg-prague-congestion-control-03.txt has been successfully
>>> submitted by Bob Briscoe and posted to the
>>> IETF repository.
>>> 
>>> Name: draft-briscoe-iccrg-prague-congestion-control
>>> Revision: 03
>>> Title: Prague Congestion Control
>>> Date: 2023-10-14
>>> Group: Individual Submission
>>> Pages: 34
>>> URL: https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-control-03.txt
>>> Status: https://datatracker.ietf.org/doc/draft-briscoe-iccrg-prague-congestion-control/
>>> HTML: https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-control-03.html
>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control
>>> Diff: https://author-tools.ietf.org/iddiff?url2=draft-briscoe-iccrg-prague-congestion-control-03
>>> 
>>> Abstract:
>>> 
>>> This specification defines the Prague congestion control scheme,
>>> which is derived from DCTCP and adapted for Internet traffic by
>>> implementing the Prague L4S requirements. Over paths with L4S
>>> support at the bottleneck, it adapts the DCTCP mechanisms to achieve
>>> consistently low latency and full throughput. It is defined
>>> independently of any particular transport protocol or operating
>>> system, but notes are added that highlight issues specific to certain
>>> transports and OSs. It is mainly based on experience with the
>>> reference Linux implementation of TCP Prague and the Apple
>>> implementation over QUIC, but it includes experience from other
>>> implementations where available.
>>> 
>>> The implementation does not satisfy all the Prague requirements (yet)
>>> and the IETF might decide that certain requirements need to be
>>> relaxed as an outcome of the process of trying to satisfy them all.
>>> Future plans that have typically only been implemented as proof-of-
>>> concept code are outlined in a separate section.
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> _______________________________________________
>>> iccrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/iccrg
>>> _______________________________________________
>>> iccrg mailing list
>>> [e-mail]
>>> https://mailman.irtf.org/mailman/listinfo/iccrg
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.