Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Jonathan,

On 17/10/2021 03:16, Jonathan Morton wrote:
>> 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.

[BB] Can you please stop preceding every discussion with completely 
unnecessary and nasty accusations.

You can still read my words above. They are about "the unscalable aspect 
of loss-based congestion control", which started with TCP congestion 
control back in 1988, and how it has continued through to BBRv2 today. 
The 1988 footnote is the relevant reference for the noise sensitivity 
scaling problem. When you jumped to the conclusion that my omission of 
CUBIC from the succession was part of some disingenuous conspiracy, 
before jumping to an insult, you could have first tried to think of 
other innocent explanations - like that I was giving an email summary of 
a longer argument.

The fuller account in the L4S architecture draft quantifies how CUBIC is 
now reaching its scaling limit (search for the words: 'less unscalable').

Ironically, for the next rev, I have had to change the numbers because 
CUBIC's unscalability is ~14% worse than I thought - due to a mistake 
about the numbers in the Linux implementation of CUBIC pointed to by 
Neal on the tcpm list. (Also, if you're following tcpm, you will have 
noticed that I have written up corrections to the paper (not mine) that 
the CUBIC RFC relied on for CUBIC's Reno-friendliness formula. This is 
in support of the CUBIC RFC moving to standards track.)

Tom Kelly's Scalable TCP (capital S) turned out to be unstable due to 
synchronization effects. A number of the people on this list and in 
iccrg (including me) were involved as BIC, CUBIC, Scalable TCP, etc  
were being worked through (around the annual PFLDnet workshops). In DCs, 
CUBIC (and Compound) have been and are being superseded by DCTCP. DCTCP 
and L4S are a continuation of that work to evolve towards scalable 
congestion controls.

> 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.

[BB] Yes, you have repeatedly made this argument. And it has been 
repeatedly pointed out in response that such throughput increasing 
attacks are already possible in any of the non-FQ AQMs or FIFOs in the 
Internet. This is not L4S-specific.

There is no work in the IETF to address this more general problem, 
because it's not been a significantly /exploited/ problem for the last 
33 years. It is an advantage of FQ that it solves this /potential/ 
problem, but it is also important to understand why it has not been a 
significant /actual/ problem anyway. Most likely because inter-customer 
scheduling limits the attack to intra-customer (going right back to 
[RFC970]). This means that any attempt by a server to improve its own 
performance will be at the expense of other usage in the same household. 
And therefore likely to become unpopular and die away.


Bob

> 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

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/