Subject: Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 7 Aug 2019 10:41:33 +0200 (CEST)

On Fri, 26 Jul 2019, Jonathan Morton wrote:

> Based on our post-session discussions, I feel that it may not actually 
> be entirely clear to the L4S people just how serious the situation with 
> L4S and Codel is.

My take on all of this is that whatever we come up with needs to be 
incrementally deployable on an Internet that has everything from stupid 
huge FIFOs to FQ_CODEL to whatever else might be out there, and there 
should be no huge pathological downsides of deployment that causes 
widespread degradation/collapse of anything currently being in wider use 
on the Internet.

In 5-10 years we're still going to have all kinds of AQMs and stupid huge 
FIFOs still in wide use.

So I'd like to see robust testing done for all proposals to see that they 
work properly on everything from GSM EDGE to ADSL to FQ_CODEL and 
dual-queue whatever we come up with together with commonly used traffic 
types on the Internet today, elastic and non-elastic.

I realise this is problematic and gets in the way of progress but the 
Internet is a messy place and we need to do mitigation of pathological 
cases where new and old don't always play nice together.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 7 Aug 2019 12:06:08 +0200 (CEST)

> cases where new and old don't always play nice together.

I forgot to also mention that I still would like to see more testing of 
the benefits of removing the ordering requirement on some traffic. Having 
been exposed to different medias over the past 25 years I've seen numerous 
Head-of-Line blocking problems my fair share of time and removing this 
ordering requirement would free up some medias to deliver some packets 
even though other packets are being re-transmitted and delivered later.

I also encourage if we can reach overall consensus that transports should 
take into account that packets can be re-ordered and what timescales would 
be acceptable for this to happen (1ms? 10ms? 100ms? Even more? Less? Not 
at all?)

---

From: John Leslie <[email-masked]>
Date: Fri, 9 Aug 2019 19:26:02 -0400

> even though other packets are being re-transmitted and delivered later.

   +1

--
John Leslie <[email-masked]>