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

[Sebastian Moeller]

Hi ECN-sane,

I reduced the CC list as I do not expect this to further the discussion much, but since I feel I invested too much time reading the L4S RFCs and papers I still want to air this here to get some feedback.


> On Mar 20, 2019, at 21:55, Greg White <g.white at CableLabs.com> wrote:
> 
> In normal conditions, L4S offers "Maximize Throughput" +  "Minimize Loss" + "Minimize Latency" all at once.  It doesn't require an application to have to make that false choice (hence the name "Low Latency Low Loss Scalable throughput").  
> 
> If an application would prefer to "Minimize Cost", then I suppose it could adjust its congestion control to be less aggressive (assuming it is congestion controlled). Also, as you point out the LEPHB could be an option as well.
> 
> What section 4.1 in the dualq draft is referring to is a case where the system needs to protect against unresponsive, overloading flows in the low latency queue.   In that case something has to give (you can't ensure low latency & low loss to e.g. a 100 Mbps unresponsive flow arriving at a 50 Mbps bottleneck).

	Which somewhat puts the claim "ultra-low queueing latency" (see https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03) into perspective. IMHO, ultra low queueing latency is only going to happen in steady state if effectively pacing senders spread their sending rates such that packets arrive nicely spread out already. I note that with that kind of traffic pattern other AQ would also offer ultra-low queueing latency... I note that "‘Data Centre to the Home’: Ultra-Low Latency for All" states that they see 20ms queue delay with a 7ms base link delay @ 40 Mbps, back of the envelope calculations tell us that at that rate ((40 * 1000^2) / (1538 * 8)) * 0.02 = 65 packets will be paced out of the dualpi2 AQM add 65 more on the L4S side and queuing delay will be at 40ms. Switching to a pacing and less aggressive TCP version helps to smooth out the steady-stae bursts, but will do zilch for transients due to an increase in the number of active flows. 

I wonder how this is going to behave once we have new flows come in at a high rate (at  3.251 KHz capacity adding loads at 100 Hz does not seem like that a heavy load to me especially given)  (actually I don't wonder, the dual-AQM draft indicates that the queue will grow to 250ms and tail dropping will start). If I would be responsible at IETFI really would want to see some analysis of resistance against adversarial traffic patterns before going that route, especially in the light of the fuzzy classification vie ECT(1).

Best Regards
	Sebastian


> 
> -Greg
> 
> 
> 
> 
> On 3/20/19, 2:05 PM, "Bloat on behalf of Jonathan Morton" <bloat-bounces at lists.bufferbloat.net on behalf of chromatix99 at gmail.com> wrote:
> 
>> On 20 Mar, 2019, at 9:39 pm, Gorry Fairhurst <gorry at erg.abdn.ac.uk> wrote:
>> 
>> Concerning "Maximize Throughput", if you don't need scalability to very high rates, then is your requirement met by TCP-like semantics, as in TCP with SACK/loss or even better TCP with ABE/ECT(0)?
> 
>    My intention with "Maximise Throughput" is to support the bulk-transfer applications that TCP is commonly used for today.  In Diffserv terminology, you may consider it equivalent to "Best Effort".
> 
>    As far as I can see, L4S offers "Maximise Throughput" and "Minimise Latency" services, but not the other two.
> 
>     - Jonathan Morton
> 
>    _______________________________________________
>    Bloat mailing list
>    Bloat at lists.bufferbloat.net
>    https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat