Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation

[Sebastian Moeller <[e-mail]>]

Hi Greg,



> On Apr 4, 2019, at 19:06, Greg White <[e-mail]> wrote:
> 
> On 4/4/19, 11:29 AM, "Sebastian Moeller" <[e-mail]> wrote:
> 
>    Hi Greg,
> 
>    [SM]: I happen to believe that head-end AQM will ameliorate the need for an ingress AQM for a lot of casual users, but all those that are constantly running against capacity limits (think ADSL) typically desire a more fine-grained prioritization than a head-end AQM is going to offer, includsing restricting bandwidth to certain proiorety classes to say keep latency increas for game traffic tightly bound. I believe in that case the guarantees L4S offers are not sufficient, as the gaming case requires "guaranteed bandwidth at a certain latency level" as compared to the low_queueung latency guarantee L4S offers (which basically moves the que back into the sending end-host, which is fine, but all it does not help if I need to send @ X Hz).
> 
> [GW]  In an L4S world,

	But we are not living in an L4S world, so it would behoove L4S to play nicely with the existing world, no?

> there is nothing that prevents a user running an "ingress AQM" of their choice with whatever traffic controls they like (as long as the ECT(1) implementation lines up with the L4S definition, which is totally doable in fq_codel and CAKE).    

	So "my way or the highway", eh?


> The issue we have been discussing is where the user is running an old version of fq_codel/CAKE that hasn't been updated to the L4S version of ECT(1).  In that case, the L4S traffic would see worse queuing latency than classic TCP.

	In the case of ingress Shaping this is simply not true and L4S flows have the potential to aggressively use more than their fair share in a way that fq post-bottleneck can only react to too slowly. This is a use case that exists in the real world right now, and I dislike the idea that this will only continue to be possible under the assumption that I need to upgrade my AQM.

> 
> 
> [...]
>> [GW] Alternatively, if fq_codel/CAKE were to treat ECT(1) as non-ECT (or implement the L4S style ECN) this would again not be an issue, I believe.  
> 
>    [SM] I believe this to be just as viable as having L4S AQMs interpret ECT(1) as pulse-modulated continuous congestion information. [...]
> 
> [GW] How?  That seems impossible to me.  What is the classifier that directs traffic to the LL queue vs Classic?  

Well, my point is, 1 single code-point does not make a robust classifier, as seen in the fact that the ECT(1) flow identity does not survive a CE-marking, Really the L4S RFCs are quite verbose in showing why ECT(1) can not serve as a reliable identifier of L4S-flows, only to then turn around and argue why this does not matter. I would propose to simply use a new protocol and you have a perfect identifier in the IP header that can unambiguously identify your flows, problem solved. And once you done that you do not need to overlay two different meanings on the CE mark anymore, just teach your AQM to set a field in the new protocol's header and you are set (for bonus you could use 8 bits and directly encode a graded load signal which would allow even more fidelity and temporal precision than essentially doing PCM, no). That wat CE can keep its meaning and L4S and the TCP-friendly world stay nicely separated. Now, you might bring tunneling as an example, to which I say let's cross that bridge once we get there.
That seems like a clean implementation for a new protocol, IMHO. Is that easy to roll out, hell no, but it is not unique in that regard.


Best Regards
	Sebastian