Re: [tsvwg] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Greg White <[e-mail]>]

On 3/19/19, 3:07 AM, "tsvwg on behalf of Jonathan Morton" <[e-mail] on behalf of [e-mail]> wrote:    
    > 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.  "

[GW] Yes, you've found the public description of the requirements for an L4S TCP (Appendix A of https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id).  I think Bob is giving an update on the implementation status at NetDev this week.  But, in any case, this is only a concern on single-queue bottleneck links that implement an AQM with classic ECN marking.   I am aware of fq_codel/cake deployments that support classic ECN (which would not cause a starvation issue), but I'm not aware of others.
    
    
    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.

[GW] The main problem with SCE is that it only provides a benefit when the bottleneck link supports fq.  That is a show-stopper for millions of bottleneck links around the world.   L4S on the other hand, can be very easily implemented in fq, but also it can be implemented in a dual-queue device.  So, from my viewpoint L4S is far more incrementally deployable than SCE.

    
    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