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

[Sebastian Moeller <moeller0@gmx.de>]

> On Mar 19, 2019, at 08:10, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 19 Mar, 2019, at 7:52 am, Greg White <g.white@CableLabs.com> 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.
> 
> "  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.  "

	IMHO this is caused by the fact that ECT(1) is simply not suitable as a classifier, as it will only reliably classify unmarked packets, anything marked CE will looses the destinction whether the flow considers itself L4S ready or not. Could anyone point me to the section in the L4S RFCs that discusses this, please?

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ has the following:
" Given shortage of codepoints, both L4S and classic ECN sides of
         an AQM would have to use the same CE codepoint to indicate that
         a packet had experienced congestion.  If a packet that had
         already been marked CE in an upstream buffer arrived at a
         subsequent AQM, this AQM would then have to guess whether to
         classify CE packets as L4S or classic ECN.  Choosing the L4S
         treatment would be a safer choice, because then a few classic
         packets might arrive early, rather than a few L4S packets
         arriving late;"

But how is the L4S queue actually maintaining its low latency if it just admitted an non-L4S flow? This _might_ work if CE marked packets are rare, but IMHO this confirms my assessment that ECT(1) is a terrible choice for a classifier bit.

Best Regards
	Sebastian




> 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
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat