Subject: [tcpm] New draft: draft-briscoe-iccrg-prague-congestion-control-00.txt

From: Bob Briscoe <[email-masked]>
Date: Tue, 9 Mar 2021 13:42:57 +0000

iccrg, tsvwg, tcpm, tcpPrague lists,

We've just posted the first draft that documents the Prague Congestion 
Control.
Abstract and links below.

It's been promised (and actually the core section was 90% written) for a 
while now. Finally finished the whole thing.

Hope it helps.

Bob

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-briscoe-iccrg-prague-congestion-control-00.txt
Date: 	Tue, 09 Mar 2021 05:35:45 -0800
From: 	[email-masked]
To: 	Bob Briscoe <[email-masked]>, Koen De Schepper 
<[email-masked]>, Olivier Tilmans 
<[email-masked]>

A new version of I-D, draft-briscoe-iccrg-prague-congestion-control-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name: draft-briscoe-iccrg-prague-congestion-control
Revision: 00
Title: Prague Congestion Control
Document date: 2021-03-09
Group: Individual Submission
Pages: 30
URL: 
https://www.ietf.org/archive/id/draft-briscoe-iccrg-prague-congestion-control-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-briscoe-iccrg-prague-congestion-control/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control
Htmlized: 
https://tools.ietf.org/html/draft-briscoe-iccrg-prague-congestion-control-00

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 the current default
options of the reference Linux implementation of TCP Prague, but it
includes experience from other implementations where available. It
separately describes non-default and optional parts, as well as
future plans.

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.
In two cases, research code is replaced by placeholders until full
evaluation is complete.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 12 Mar 2021 18:33:40 +0100

Hi,

After some discussion, I got convinced to formally submit a draft,
explicitly describing a simple lost retransmission detection mechanism
to prevent RTO when a retransmission is lost.

While full featured stacks can address this issue within the RFC series
already by using TCP RACK, on a more constrained platform where only
SACK support is viable but not RACK, this mechanism may be an
interesting alternative.

Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is
included, as it may be the case that current implementations which
recover from lost retransmissions may not actually use this as a
subsequent congestion control signal, and retain the ssthresh / cwnd
from the initial loss recovery - and it is certainly debatable, if
a single, or two engagements of a CC reaction is in order.

The mechansim described is very conservative (another CC reaction, and
requires more data to be sent, to have high confidence when
retransmitting a prior retransmission).

https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00

(The graph in the appendix needs some overhaul, as PRR is becoming
standard).

Best regards,
    Richard

---

From: [email-masked]
Date: Fri, 12 Mar 2021 18:51:03 +0100

> On 12. Mar 2021, at 18:33, Scheffenegger, Richard <[email-masked]> wrote:
> 
> Hi,
> 
Hi Richard,

thanks a lot for the ID. Maybe the Light-Weight Implementation Guidance WG
is also interested: https://datatracker.ietf.org/wg/lwig

Best regards
Michael
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 12 Mar 2021 13:26:39 -0500

> (The graph in the appendix needs some overhaul, as PRR is becoming

Thanks for the ID!

Indeed this could be a useful algorithm to document for nodes too
constrained to run RACK.

You mention in the ID that there is a TCP stack that "started using LRD
more than two decades ago." Just curious: is that FreeBSD?

This approach sounds similar to (a) the improvement in the paper that your
informative references cite as [SACKPerf], and similar to (b) the algorithm
added in Linux 2.6.24 in 2008 in  tcp_mark_lost_retrans()  (later removed
in the era of RACK). And it seems perhaps (a) and (b) are roughly the same
thing, since the [SACKPerf] paper mentions their idea was incorporated into
Linux 2.6.24? But I wasn't sure what the relationship is.

I did not see [SACKPerf] mentioned in the body of the ID. Would it be
possible to add some text in the ID that mentions [SACKPerf] and clarifies
the relationship of the ID to the [SACKPerf] paper and Linux code?

best regards,
neal

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 12 Mar 2021 21:39:23 +0100

Hi Neal,

I was specifically thinking about Linux, but my recollection as to when
it first showed up there must have been skewed.

The SACKPerf reference appears to be dead (only a copy on archive.org is
available - I don't know if that is valid to quote instead of the link
that I found all these years ago.

https://web.archive.org/web/20150103014718/http://projects.itri.aist.go.jp/gnet/sack-bug.html

In any case, the improvement described therein sounds as if some more
limited form of lost retransmission detection was already present in
Linux before that. (For single Hole/SACK Ranges).

As I am not that intricately familiar with Linux, is my assesment
correct that (at the time of ~2.6.24), CC would not be triggered anew
when a lost retransmission is detected?

If you have a suggestion for an appropriate text honoring all the prior
work on Linux, I would be very grateful. I would also like to invite you
to coauthor this document, if you want to help refine the text further.

Also, I have a more aggressive mechanism, using a heuristic to
differentiate between a SACK for an original segment vs. a SACK for a
retransmitted segment, and using the latter to also engage LRD. As this
variant does not rely on new data to be sent, it can also work at the
end-of-stream, albeit with some potential misdetections of lost
retransmissions (again superceded by TLP /  RACK).

However, I felt that the conservative mechanism is the proper starting
point for now.

Best regards,
    Richard

Am 12.03.2021 um 19:26 schrieb Neal Cardwell:
>
>
> On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 <https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00>
>
> This approach sounds similar to (a) the improvement in the paper that
> your informative references cite as [SACKPerf], and similar to (b) the
> algorithm added in Linux 2.6.24 in 2008 in  tcp_mark_lost_retrans()
>   (later removed in the era of RACK). And it seems perhaps (a) and (b)
> are roughly the same thing, since the [SACKPerf] paper mentions their
> idea was incorporated into Linux 2.6.24? But I wasn't sure what the
> relationship is.
>
> possible to add some text in the ID that mentions [SACKPerf] and
> clarifies the relationship of the ID to the [SACKPerf] paper and Linux code?
>
> best regards,
> neal
>

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 12 Mar 2021 15:49:36 -0500

> https://web.archive.org/web/20150103014718/http://projects.itri.aist.go.jp/gnet/sack-bug.html

FWIW looks like there is a copy of the [SACKPerf] paper here:
  http://www.hep.man.ac.uk/g/GDARN-IT/pfldnet2008/paper/kodama_y%20Final.pdf

> Linux before that. (For single Hole/SACK Ranges).

Oh, interesting. Maybe so. I have not had time to read the paper or
the preceding code.

> when a lost retransmission is detected?

Yes, that sounds correct. In Linux Reno/CUBIC/etc there would only be
one cwnd reduction until SND.UNA reaches the value SND.NXT had at the
time of the previous reduction. That is, there is one cwnd reduction
per "window", where "window" is interpreted in sequence space rather
than time.

> to coauthor this document, if you want to help refine the text further.

I have not had the time to read the [SACKPerf] paper that seems key to
this archeology, so would defer to your wording. Thanks for your
generous offer, but my plate is a bit full at the moment.

> However, I felt that the conservative mechanism is the proper starting

Sounds interesting. I would agree that documenting something close to
the existing LRD algorithm that has a lot of air miles from 2008 until
RACK seems like a good place to start.

best regards,
neal