[Ecn-sane] where the l4s ect1 takeover is documented

[Ecn-sane] where the l4s ect1 takeover is documented

[Dave Taht]

It's in: Appendix B.1 of:

https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-02#appendix-B.1

Which is sort of like the vogons demolishing the internet for a cable
industry bypass..

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Dave, “yes I did. It was on display in the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign on the
door saying ‘Beware of the Leopard.”


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Ecn-sane] where the l4s ect1 takeover is documented

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]


A question from a bystander/ Why is the L4S proposal such a major fork that it needs wo be thought of as if it were an alternative to current IPv4 and IPv6 packets?
 
Shouldn't all traffic be in this new class called scalable low loss low latency traffic?
 
In a sense, the proposal seems to be like running two Internets (A and B) on the same cables.
 
That seems control-theoretically unstable since neither one knows about the other, yet they share resources and influence the dynamics of each other.
 
One would need to prove that they are compatible and cause performance to converge when used at the same time.
 
If that's been answered, great.
 
Remember, the IP datagram and routing layer is the single neck of the hourglass that regulates everything.
 
 
-----Original Message-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Wednesday, April 3, 2019 11:30am
To: "ECN-Sane" <ecn-sane@lists.bufferbloat.net>
Subject: [Ecn-sane] where the l4s ect1 takeover is documented



It's in: Appendix B.1 of:

https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-02#appendix-B.1

Which is sort of like the vogons demolishing the internet for a cable
industry bypass..

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Dave, “yes I did. It was on display in the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign on the
door saying ‘Beware of the Leopard.”


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
_______________________________________________
Ecn-sane mailing list
Ecn-sane@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane

[-- Attachment #2: Type: text/html, Size: 3863 bytes --]

Re: [Ecn-sane] where the l4s ect1 takeover is documented

[Jonathan Morton]

> On 3 Apr, 2019, at 11:18 pm, David P. Reed <dpreed@deepplum.com> wrote:
> 
> One would need to prove that they are compatible and cause performance to converge when used at the same time.

And that's the problem; the precise opposite has been proved, unless either:

- the traffic runs through an FQ system at the bottleneck (where the FQ system enforces fair convergence), or

- the DualQ system is at the bottleneck (where the AQMs handling each class are coupled in a compatible manner), or

- a dumb tail-drop FIFO is at the bottleneck (which we're trying to get the heck away from, but L4S' response to drops is TCP friendly).

If there's a simple single-queue ECN-enabled AQM at the bottleneck, L4S ends up squashing any Classic ECN or Not-ECT traffic out of existence, simply because it responds less to each CE mark and requires a continuous stream of them (two per RTT) to hold the cwnd stable.  That same CE marking (or packet dropping) rate will cause normal TCPs to collapse to minimum cwnd within a handful of RTTs, whether they implement the 50% reduction of Reno, the 70% of CUBIC, or the 85% permitted by the ABE spec - so L4S cannot safely coexist with normal traffic.

Much of the present debate revolves around how prevalent these AQMs actually are now, or might become in the foreseeable future.  It's obvious to me that DualQ is designed as a way to make L4S work in places where a single-queue AQM would normally be deployed, as much as been made of the relative simplicity of implementing it in high-speed hardware, and the initial rollout appears to be in the same class of devices for which PIE was developed.

By adopting ECT(1) as SCE and retaining the existing meaning of CE, the two forms of AQM marking are much better integrated and have a much better chance of coexisting in a heterogeneous environment.  I and some others are now actively engaged in proving that by example.

 - Jonathan Morton

Re: [Ecn-sane] where the l4s ect1 takeover is documented

[Mikael Abrahamsson]

On Wed, 3 Apr 2019, Dave Taht wrote:

> It's in: Appendix B.1 of:
>
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-02#appendix-B.1

https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08#section-2.3

https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-02#section-2.2

So while there perhaps could have been more up-front discussions, it's not 
THAT buried as you are implying.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se