[tcpPrague] Is there another way to do this?

[Bob Briscoe <[e-mail]>]

Costin & all on the tcpprague list,

You asked "Is there another way to do this?" in the bar BoF in Prague. I 
am taking "this" to mean the features of the proposed new service 
(L4S),. Then the questions becomes, "Are all the elements needed at once?":
* Low Loss,
* Low Latency
* Scalable throughput.

[For those on the list who were not in Prague, a way to achieve L4S is 
described in this pre-print: "Data Centre to the Home 
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf>"]

There are a number of elements to "this", so I'll take them in vaguely 
decreasing order of obviousness. Then everyone can identify any 
unnecessary assumptions.
A. ECN-capable (sndr, rcvr, aqm)?
B. Shift ECN smoothing from AQM to source (aqm, sndr)?
C. Second queue (aqm)?
D. Scalable congestion control (sndr)?
E. Accurate ECN feedback (sndr, rcvr)?
F. Finally, a more intangible question: significantly better service vs 
incrementally better?

The further features we discussed in the Bar BoF are secondary to all 
these questions.

Taking each in turn...

*A. Is ECN essential? *
(sndr, rcvr, aqm)
I think we're all agreed that ECN is essential. Without ECN:
#1. as load increases (i.e. as each TCP flow's rate has to decrease), an 
AQM has to introduce excessive drop to keep queuing delay low.
   (If you weren't in the AQM wg, see "questioning a fixed delay target 
<https://www.ietf.org/proceedings/93/slides/slides-93-aqm-4.pdf>" or the 
tech report <http://www.bobbriscoe.net/projects/latency/credi_tr.pdf> 
that backs it up).
#2. Throughput scaling requires roughly 1 congestion signal per RTT at 
high flow rates, at least within an order of magnitude. As load 
increases, segments per RTT (the window) has to reduce, so the drop 
ratio has to increase. With low RTT (assuming we have achieved v low 
queuing delay) the window is also smaller.

See also {Note 1}

*B. Is shifting smoothing of ECN signals from the AQM to the source 
essential?*
(aqm, sndr)
There's no reason to smooth ECN in the AQM, and little harm from not 
smoothing it.

A newly implemented source can smooth incoming ECN feedback itself.
If a classic TCP-ECN source does not smooth ECN feedback, it's not a 
killer, because it will ignore >1 feedback per RTT anyway.
If a source smooths ECN that has already been smoothed in the AQM, its 
response could be sluggish, but we can make this unlikely as follows:

Smoothing (burst allowance) should be turned off by default for ECN in 
all AQMs (RED, PIE, CoDel, etc) now.

*C. Is a second queue essential?*
(aqm)
With one queue, 'new' traffic shares the latency of the queue with 
'classic' Internet traffic.
So to achieve low latency with one queue, the AQM threshold for all 
traffic has to be shallow. To achieve really low latency, this means 
classic traffic would severely underutilise capacity. Colleagues in the 
RITE project tried shifting the AQM threshold down only if there was no 
ECN traffic, but they couldn't get it to work.

Is full utilisation important? Well, probably not as important as it 
used to be. But network operators (ISPs or DC operators) are not going 
to deploy an AQM that prevents existing traffic using a large proportion 
of the link capacity.

*D. **Is scalable **congestion control essential?**
*(sndr)
As under question A, throughput scaling requires roughly 1 congestion 
signal per RTT at high flow rates, at least within an order of magnitude.
I.e. if the congestion control algo gives packet rate proportional to 
1/p^b, where p is drop probability, then scalable means b=1

For now, we can probably make do with b<1 as long as b~=1, e.g. b=0.8 or 
something similar.
However, we will need b=1 in the future. So it all depends whether we 
can map out a route to increase to b=1 later, bearing in mind this 
traffic will still have to co-exist with b=0.5 (Reno) as well as b=0.75 
(Cubic).

*E. Is Accurate ECN feedback essential?*
(sndr, rcvr)
Without AccECN, each downward rate response to one ECN feedback has to 
be greater, because it has to be enough for a whole round trip. This 
makes the sawteeth bigger, which creates the dilemma between higher 
delay and lower utilisation. This is primarily important when numerous 
flows are arriving and departing but the total number is not huge (i.e. 
typical conditions on an access link, or in a data centre).

*F. Is sIgnificantly better service essential (vs incrementally better)?**
*Altho this is the most controversial question, I think it is the most 
important:
* Without the wow factor of the potential for new products and 
applications, deployment has to be pushed by a few individual visionary 
engineers, rather than pulled by product and marketing /teams/.
* Starting with a new queue with near-zero queuing delay creates 'social 
pressure' to keep it that way (similar to the TCP friendliness meme). 
This may be sufficient to avoid the need for behaviour policing. 
Whereas, incrementally better delay gets polluted by incrementally worse 
behaviour, so it either never gets anywhere, or it requires complex 
behaviour policing.

HTH


Bob

{Note 1} Both the dilemmas A#1 & A#2 are inherent to any congestion 
control of the form r = K/(R^c * p^b), where
   r : packet rate
   K: constant
   R: RTT
   p: drop probability
   c & b are constants of the congestion control algo.
Even if c=0 (i.e. the congestion control is RTT-independent), dilemma #1 
becomes the same as dilemma #2.

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