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

["Holland, Jake" <[e-mail]>]

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, 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.

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).

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

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'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.

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