Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Jonathan Morton <[e-mail]>]

It was suggested that I should copy this point here for more robust discussion.

> On 19 Mar, 2019, at 7:52 am, Greg White <[e-mail]> wrote:
> 
> L4S utilizes TCP Prague, which falls back to traditional congestion control if the bottleneck link doesn't provide isolation.  

You see, this is the part I find difficult to believe that it will operate reliably.  For a start, I have seen no detailed public description of TCP Prague, even though it has supposedly been in "open" development for so long.  My most recent information is that it's essentially a slightly modified DCTCP.

I did find this, which reads like a requirements spec rather than a working algorithm:

" It would take time for endpoints to distinguish classic and L4S ECN
  marking.  An increase in queuing delay or in delay variation would be
  a tell-tale sign, but it is not yet clear where a line would be drawn
  between the two behaviours.  "

Internet history is littered with failed attempts at implementing delay-sensitive TCPs.  I can immediately think of several reasons why delay can and will vary for reasons other than the bottleneck not implementing an isolated queue  (just ask the BBR devs).  The mere presence of a wifi link on the path, even if it is never the bottleneck, would be a trivial and common example.

So please explain (or point to good documentation) how TCP Prague robustly avoids misbehaving in a standard ECN environment, as is presently deployed.


SCE explicitly does not rely on specific changes in behaviour by endpoints.  It just provides a conduit of information from the network to the receiver, in addition to standard ECN behaviour.  The receiver is free to ignore that information, without harming the network, and will naturally behave normally and safely when that information is absent.  We have a proof-of-concept implementation (a trivial mod of sch_codel and sch_fq_codel) which successfully passes this information across the Internet and works with (is transparently ignored by) existing endpoints and middleboxes.

In short, SCE is incrementally deployable by design.

The broader system of feedback and modified congestion control, which I call ELR (Explicit Load Regulation) as an umbrella term, offers benefits which, yes, have not yet been proved - but which are straightforward in concept and should be amenable to analysis.  It seems likely that some work from L4S can be used in this context.

- Jonathan Morton