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

[Bob Briscoe]

Jonathan,

On 20/03/2019 23:51, Jonathan Morton wrote:
>> On 21 Mar, 2019, at 1:29 am, Bob Briscoe <ietf at bobbriscoe.net> wrote:
>>
>>> But more importantly, the L4S usage couples the minimized latency use
>>> case to any possibility of getting a high fidelity explicit congestion
>>> signal, so the "maximize throughput" use case can't ever get it.
>> Eh? There's definitely a misunderstanding or a difference in terminology between us here. The whole point of using a congestion controller like DCTCP is so that flow rate can scale indefinitely with capacity. Van Jacobson actually noted that the original TCP was unscalable in a footnote to the tech report version of the SIGCOMM paper.
>>
>> The high fidelity congestion signal of what we call scalable congestion controllers (like DCTCP) is inversely proportional to the window. So as window scales up, the congestion signal scales down, so that their product remains constant. That means the number of ECN marks per RTT is scale-invariant. So the control signal remains just as tight at any scale.
> If you'll indulge me for a moment, I'd like to lay out a compromise scenario where a lot of L4S' stated goals are still met.
>
> There is no dualQ.  There is an AQM at the bottleneck link, of unspecified type, which implements SCE.  Assume that it produces CE marks like a conventional AQM, and also produces SCE marks like an L4S AQM produces CE.
>
> A sender implements DCTCP-SCE, which is essentially Paced NewReno modified to subtract half of all acked data that was SCE-marked from its cwnd.  (This is equivalent to the DCTCP algorithm with g=1 and an arbitrarily small measurement window, but acting on SCE instead of CE.)  Any SCE mark also kicks it out of slow-start.
>
> The means by which SCE information gets back to the sender is left vague for now; it's an orthogonal problem with several viable solutions.
>
> What is missing from this scenario, from L4S' point of view?  And why have I been able to describe it so succinctly?
My goal is also to tighten the EWMA parameter, g, in DCTCP to 1 (or 2). 
That is why we have recommended a queuing-time-based ramp AQM for the 
Low Latency queue, which so far works equivalently to the step with g 
set to its current default of 1/16. We have been doing experiments on 
this for some time. But it is important to assess each change one at a 
time.

Congestion controls are tricky to get stable in all situations. So it is 
important to separate ideas and research from engineering of more mature 
approaches that are ready for more widespread experimentation on the 
public Internet. Our goal with L4S was to use proven algorithms, and put 
in place mechanism to allow those algorithms to evolve.

As regards the desire to use SCE instead of the L4S approach of using a 
classifier, please answer all the reasons I gave for why that won't 
work, which I sent in response to your draft some days ago. The main one 
is incremental deployment: the source does not identify its packets as 
distinct from others, so the source needs the network to use some other 
identifier if it wants the network to put it in a queue with latency 
that is isolated from packets not using the scheme. The only way I can 
see to so this would be to use per-flow-queuing. I think that is an 
unstated assumption of SCE.

In contrast, L4S works with either per-flow queuing or dualQ, so it is 
more appropriate for a wider spread of scenarios. Again, in that same 
unanswered email, I described a way L4S can use per-flow queuing, and 
Greg has since given pseudocode. There are other problems with doing the 
codepoints the SCE way round - pls see that email.

There has been a general statement that the SCE way round is purer. 
However, that concept is in the eye of the beholder. The SCE way round 
does not allow the ECN field to be used as a classifier, so you don't 
get the benefit above about support for per-flow-queueing and dual 
queue. You also don't get the benefit of being able to relax 
resequencing in the network, because the network has no classifier to 
look at. For these, the SCE codepoint would need to be combined with a 
DSCP, and I assume you don't want to do that.

The L4S way round signifies an alternative meaning of the ECN field, 
which is exactly what it is. The problem of having to guess which type 
of packet a CE used to be has been roundly discussed at the IETF in TCPM 
and TSVWG WGs and it has been decided it is a non-problem if it is 
assumed to have been ECT(1) even if it was not - as written up in 
draft-ietf-ecn-l4s-id. And that discussion assumed TCP with 3DupACK 
reordering tolerance, not the more liberal use of RACK (or a RACK-like 
approach in other transports). With a RACK-like approach, it becomes 
even less of a problem.


Bob

>   - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/