Re: [tsvwg] start of WGLC on L4S drafts

[Jonathan Morton <[e-mail]>]

> On 17 Oct, 2021, at 2:38 am, Bob Briscoe <[e-mail]> wrote:
> 
>> If TCP had been designed with a scalable congestion control from the 
>> start, we would have had L4S with no need for a scheduler at all. The 
>> scheduler is primarily a transition mechanism, to isolate from Classic 
>> traffic. But no traffic /needs/ to be Classic, it's just how "stuff 
>> happened".
>> 
>> I do not think this is true in this specific case. 
>> There is an advantage in terms of goodput for applications to use 
>> loss-based congestion control and create bigger queues (in
>> absence of isolation).
> 
> [BB] This may be true in the short term for non-latency sensitive bulk traffic, especially over variable capacity (e.g. radio) links where buffered packets can fill newly available capacity while the e2e congestion control catches up.
> 
> Nonetheless, there is also the unscalable aspect of loss-based congestion control where, as flow rate scales, it takes longer and longer (minutes) to recover after each loss [RFC3649]. As was pointed out in footnote 6 of [Jac88], the noise sensitivity gets worse as flow rate scales. Meaning, even if there's a very low level of transmission losses or new flows arriving, a flow keeps getting knocked down by each noise event, while it's slowly trying to regain its previous position.
> 
> It's possible that some new approach will get out of that unscalable rut, but it's been quite resistant to solutions so far. BBRv2 has already had to reinstate a capped dependence on loss probability, in order to remain backward compatible with the legacy of loss-based congestion controls. The setting of that cap will have to keep being reduced in order to scale flow rate, so it is trapped in the same noise sensitivity problem. 

I think it's very disingenuous for you to quote only a paper from 1988, at the very dawn of TCP congestion control research, in support of this argument.  At that time, only the Reno algorithm was in use, and Reno does have widely-acknowledged scalability problems, especially with respect to random loss on high-BDP paths.  It's actually rather strange, given that fact, that TCP Prague uses only the Reno growth function while claiming to be a "scalable transport".

However the deployed state of the art today is CUBIC (as you very well know), and CUBIC is considerably more scalable than Reno (in the upward direction, at least), especially in the face of low levels of random loss.  On the research side there is also Scalable TCP, an MIMD algorithm that is even less sensitive to random loss than CUBIC.

This sensitivity to random loss is easily shown to be a function of the cycle time of the congestion-control loss-response sawtooth; iff loss events occur more frequently than this cycle time, the average cwnd will trend downwards.  In Reno (and Prague), this cycle time is proportional to RTT and to the square of throughput.  In CUBIC, the cycle time is roughly proportional to throughput and mostly independent of RTT.  In Scalable TCP, the cycle time is proportional to RTT and independent of throughput.  (These generalisations assume constant segment size, etc.)

> I don't know whether bulk flows will prefer to continue to use the classical approach with more buffering, or the scalable approach with frequent control signals. I'm just saying it's not as clear-cut as you make out.

They will likely choose the option that is universally available and yields the maximum goodput.  In the present state of L4S, that is clearly "Classic".

> As a fairly close analogy, can you imagine any individual or company gaming a PIE AQM to induce more latency on their own flow, in order to impose more latency on others in the same household?

The goal would not be to increase latency.  The goal would either be to selfishly increase throughput for their own traffic (which could be done using Relentless TCP at the sender side, exploiting exactly the same effect with a drop-only AQM as L4S would impose in a shared ECN AQM), or to increase packet loss and thus degrade service for the other traffic (which could be done using a simple flood, driving the AQM into a high dropping probability).  These scenarios are so common, and so easy to imagine, that they should be part of a standard security analysis - and neither of them would result in substantially higher latency on the path, since in both cases it is assumed that the AQM effectively controls the queue delay to its target.

DualQ offers attackers a very easy way to gain higher throughput for themselves.  With some traffic, it also offers an easy to to increase packet loss as high as 100% for a particular type of target traffic.  These are problems over and above those of PIE, which are relatively minor by comparison.

 - Jonathan Morton