Re: [tsvwg] L4S issue #16/17 questions from reading the session slides

[Sebastian Moeller <[e-mail]>]

Hi Jake,

Thanks for your feed-back.

> On Nov 22, 2019, at 04:24, Holland, Jake <[e-mail]> wrote:
> 
> On 2019-11-21, 19:20, "Sebastian Moeller" <[e-mail]> wrote:
>> D) "Issue #17: Conclusion
>> The main result of concern was due to a bug in initializing the value of TCP Prague alpha, which has been fixed and demonstrated to resolve the latency impact that was spanning multiple seconds"
> 
>> COMMENT: In the light of https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s6-2/batch-l4s-s6-2-prague-vs-cubic-50Mbit-80ms_fixed.png showing that L4S still mishandles CE markings in that condition (albeit with the fall-out restricted to itself) it seems that the alpha fix alone might not be sufficient (which basically makes TCP Pragues response to the first CE independent of the CE interpretation scheme)
> 
> I brought this up,

	Great, the video's are still not up, so it will take a while before I cought up with the status quo.

> but Greg and Pete each explained to me that this
> impacts only the L4S flow in the observed behavior during testing,
> and doesn't make a giant persistent queue in the upstream dumb fifo.

	Ah, yes, I should have made this clearer, in principle I have no objections against L4S if it did a) equitably share bandwidth with normal traffic and b) would default to only hurting itself (in case when the approximations fail). But unfortunately when L4S fails to meet its own requirements it mostly is at the expense of other traffic (not in this specific instance though), honi soit qui mal y pense...

> 
> While this is maybe still worth considering as a performance question
> for L4S, I don't think it's the safety issue that was originally
> opened (nor that it's especially severe and worth blocking on).

	Yes, I agree and should have made that clearer, thanks for pointing that out.

> 
> I think I agree this means the issue is closeable, AFAIK.

	Yes.

> 
> Just to clarify: my expectation is that finding a future test case
> with another similar problem for competing flows could still happen,
> and would justify re-opening the issue.

	I believe hope the chairs are open to that. I am going to try test this hypothesis soon, by trying to get dualq's isolation failure corner-cases onto the issue tracker asd the L4S team seems to ignore to properly address anything less than a tracked issue. I will try to frame the issue as an issue of "congestion collapse" for the normal queue (which I believe it to be) so I can cite RFC verses and rhymes to move this out of the realm of "oh, it is just Sebastian being a PITA, again".


> 
> I'll also suggest I'd be more comfortable if we had a suite of test
> situations that covered, in a more principled or structured way, a
> "range of environments" (a la 5033) that happened to include this
> case, among many others.

	Yes, it seems like a worthwhile goal for all CC/AQM work to have an enumerated list of known tricky issues a CC/AQM should/must solve.

> 
> I won't try to argue the lack of such a suite is a blocker, just that
> its lack remains a source of much of my skepticism.
> 
> Best,
> Jake
> 
>