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

[Marten Seemann <[e-mail]>]

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:

   1.

   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?
   2.

   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?
   3.

   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.
   4.

   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.
   5.

   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.
   6.

   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]> <[e-mail]>, Koen De
> Schepper <[e-mail]> <[e-mail]>,
> Olivier Tilmans <[e-mail]>
> <[e-mail]>, Vidhi Goel <[e-mail]>
> <[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
>