Re: [tsvwg] plan for L4S issue #29

[Bob Briscoe <[e-mail]>]

Jonathan, Wes, list,

Sorry, I've been dead to the L4S conversations on this list for weeks 
now. But I've resolved to get back involved now. I stopped interacting 
on L4S over the summer because I became burned out by the L4S 
conversation being dominated by the same two or three people who do not 
want the agreed deliverables at all. I have never had to work on a 
technology before where I am faced with a continual stream of blocking 
messages, rather than constructive criticism or solutions being offered.

It has always been recognized that there are not enough bits in the IP 
header for a perfect encoding scheme, so that we will have to choose the 
least worst compromise. We had a consensus call in April, in which the 
questions of Classic ECN fallback (#16) and false positives in the 
current algo (#29) were well understood by all concerned. The result was 
a decision not to go with the alternative solution (SCE) that inherently 
addresses issues #16 & #29, but instead to continue with the solution 
(L4S) that partially addresses these issues and fully addresses other 
concerns. The L4S design team were asked to prepare a new ops guidelines 
draft as part of that decision.

I became disheartened about working further on the Classic ECN AQM 
fallback algo when all the work we'd done was just dismissed as futile. 
It became apparent that no amount of work on it would ever satisfy the 
few people who have been vocally opposing L4S as a whole. Now that's a 
shame, because I/we had worked out an additional heuristic to address 
the large bulk of the false positives that appeared at low link capacity 
(note that is different from low flow rate). I admit that this solution 
would not have addressed the few cases that arise in apparently random 
circumstances. And I admit that, without having tried it, it might not 
work at all.

I now prefer to work on Classic ECN AQM detection more than fallback. My 
logic for this is that L4S can be /unfair/ against Classic flow(s) in a 
Classic ECN AQM, but it is not /unsafe/. Unsafe means starvation, but 
Classic flows always still progress against L4S. So, it should be 
sufficient for L4S senders to /monitor/ for Classic AQMs, at least in 
the initial stages of the L4S experiment.

This can then become part of the monitoring infrastructure that the L4S 
ops guidance proposes for the L4S experiment. It can highlight where 
classic ECN AQMs might have been deployed. Then, if it produces false 
positives, further digging should discover that there is not actually 
any classic ECN AQM where it says there is. Then at least false 
positives don't harm performance.

If it turns out that there are a lot of classic ECN AQMs out there, it 
then becomes important to improve the detection algo so it can be used 
in-band for fall-back. On the other hand, if we find there is very 
little, it becomes preferable to use the network configuration 
techniques described in the ops guidance to alter the classic ECN AQMs 
to isolate classic ECN and L4S ECN traffic.

Regards



Bob

PS. There are also the cases where L4S flows don't perform well 
(particularly around start-up behaviour) in a Classic ECN AQM within an 
FQ scheduler (e.g. the experiments Pete did with L4S over FQ_CoDel and 
with Cake). Over the summer Joakim and I have been working on faster 
response to marking in the Prague algo, and we need to combine that with 
delay measurements for these cases.

I would also like to see a commitment to improving the CoDel and Cobalt 
control laws to increase ECN marking more rapidly in response to 
consistently increasing delay. Because this has always been a problem 
with unresponsive flows, irrespective of whether L4S had ever appeared 
on the scene. I'd be willing and interested to help with that sort of 
work,... assuming my day job left sufficient time for this.


On 31/07/2020 19:03, Jonathan Morton wrote:
>> On 31 Jul, 2020, at 6:41 pm, Wesley Eddy <[e-mail]> wrote:
>>
>> Hello, ticket #29 for the L4S documents is about classic bottleneck detection misidentifying L4S queues as classic ECN queues.
>>
>> https://trac.ietf.org/trac/tsvwg/ticket/29
>>
>> In contrast to other issues, it doesn't seem like this should block a WGLC on the L4S drafts.
>>
>> 	• It is specific to classic bottleneck detection algorithm, which is planned to be worked on in the Prague ICCRG draft.
>> 	• The result is sometimes failing to achieve the best possible L4S behavior, but doesn't seem to be an Internet safety issue.  This resulting in people turning off classic bottleneck detection would be a different issue, and something maybe the operator guidelines would address.
>> 	• It seems like it can be worked on further in the course of L4S experimentation, without negative effects to others.
>> So, I believe we should track this work in the ICCRG, and close the ticket here.  Please let me know in the next week if I've misunderstood any aspect of this and it should remain open.
> Presently, the Prague congestion control algorithm is unsafe on the Internet without a properly functioning classic-bottleneck detection heuristic.  Additionally, the classic-bottleneck detection heuristic that has been published and demonstrated does not function properly.  This combination of facts absolutely *is* a blocker for WGLC.
>
> Therefore, this issue should not be closed until it has been concretely addressed.
>
>   - Jonathan Morton
>

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