Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency

[Sebastian Moeller <[e-mail]>]

Hi Lars,

I appreciate your considerate and balanced position.

I would like to ask a question, you say:

"If "Prague" (I guess you mean a TCP variant taking advantage of L4S?) is a "work in progress", why are we then pushing towards finalizing the L4S part of the overall scheme?"

And I agree that is worth discussing. The problem is, that the network bits of L4S, basically the AQM are sold on a set of promises that require a compliant protocol to realize themselves.

Honestly, I wonder how one would go and test, characterize the network bits without having a fully working protocol to test them against/with.

All of this indicates that L4S simply is not fully baked, or baked enough to consider turning its components into RFCs. And the rationale for not doing that is simply, that L4S is not with-out side effects, and spending scarce resources like an IPv4/6 codepoint should be well weighted against the risk that the code-point might be wasted. If L4S wants to use that codepoint exclusively, I think it is not too much to ask, that L4S first demonstrates that it actually can deliver on its promises in real and realistic internet conditions and that at the least it does not make things (considerably) worse than they are right now.
	IMHO L4S has still a way ahead of itself to demonstrate safety and promised functionality before it should be even considered to be turned into an RFC.

Best Regards
	Sebastian



> On Nov 17, 2020, at 13:32, Lars Eggert <[e-mail]> wrote:
> 
> Hi,
> 
> On 2020-11-17, at 13:46, Ingemar Johansson S <[e-mail]> wrote:
>> I imagine that, as Prague is work in progress, then the original authors of
>> this mail thread could have considered to try out the different options that
>> address the RTT bias. Or at least consider to re-run the experiment instead
>> of digging down in long discussions on what is default and not. Prague is
>> work in progress after all, I don't think that this is unreasonable to ask
>> and it could have saved us a few roundtrips in in this mailthread ?
> 
> I've long ago given up trying to follow the blow-by-blow of this overall discussion. And maybe that means I've disqualified myself from having an opinion. But I don't quite know what to make of your statement.
> 
> If "Prague" (I guess you mean a TCP variant taking advantage of L4S?) is a "work in progress", why are we then pushing towards finalizing the L4S part of the overall scheme?
> 
> Maybe I'm naive here, but I always thought the queuing scheme and a TCP variant for it would necessarily go together. That TCP variant might be an initial design that maybe doesn't take full advantage of all the benefits the queueing scheme might offer, but surely it should demonstrate some significant benefit without significant downsides?
> 
> And we can of course have a discussion on whether RTT unfairness (or any other property or lack of one) is a significant downside or not, but I don't think we've had that discussion?
> 
> Basically, I'm trying to re-engage here for a bit to see if there is *any* hope for this entire area of work, if I should just ignore it again or even start arguing we should abandon it all, given how wedged the discussion between the camps has been for a long time.
> 
> Thanks,
> Lars