[tsvwg] RTT-independence (was: L4S vs SCE)

[Bob Briscoe <[e-mail]>]

Sebastian,

I wanted to pick up your point about RTT-independence that you recently 
said has never been responded to.

I have changed the subject line, because this is not an L4S vs SCE 
issue. With a shared queue it is just as much an issue for SCE as for 
L4S. With an FQ scheduler, it is just as much a non-issue for L4S as for 
SCE.


On 20/11/2019 14:18, Sebastian Moeller wrote:
> Dear Koen, dear all,
>
>
>> On Nov 20, 2019, at 13:40, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
>>
>>
>> One of these opportunities here is to make L4S_TCP less RTT dependent. There have been many working implementations for less RTT-dependent CCs in the past. One that is widely deployed is Cubic, which is doing this for getting more throughput for longer RTTs. The only reason why it didn’t fly for lower RTTs on the current Internet is that they would hurt themselves (get lower throughput, competing with Reno).
> 	[SM] Looking at the pfifo_fast results in Høiland-Jørgensen T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential setting. Computer Networks 89:90–106. For Cubic/pfifo_fast (linux former default combination), I fail to see a strong indicator that cubic is RTT invariant or getting more thoughput at longer RTTs (except for the 10ms versus 50ms "hump"). What paper/data should I be looking at instead?
>
>>   
>> As we are able to define a new independent behavior and the RTT dependence in L4S is taken serious (some even call it a show stopper) this is even a must do opportunity for L4S. It is all a matter of perspective: show-stopper <-> opportunity.
> 	[SM] I believe that working on more RTT independence is worth-while but no replacement for fixing the isolation system as it it is that equitable isolation from existing traffic that basically gives you the slate clean-"green field" development opportunity, no?

[BB] RTT-dependence is caused by the end-system, and should be solved in 
the end-system (whether or not FQ is also deployed to solve it in some 
places). Importantly, RTT-dependence only needs to be addressed in the 
newly deployed scalable (L4S or SCE) end-systems, not pre-existing 
end-systems like Reno & Cubic, as I'll now explain.

The problem is due to the tiny RTT you can get when you have both a tiny 
base RTT and a tiny queue. For example:

	Base RTT/ms
	Queue/ms
	Total RTT/ms
Close Scalable flow: 	2.5
	0.5
	3
Distant Scalable flow: 	100
	0.5
	100.5
Close Classic flow: 	2.5
	15
	7.5
Distant Classic flow: 	100
	15
	105


If all the above flows were RTT-dependent, the lowest 3ms RTT ('Close 
Scalable') would be the potential hog. For example against 105ms 
('Distant Classic') if they were both 'window fair' like Reno, the 
throughput ratio would be 105:3 = 35:1

Whereas the Close vs Distant Classic case is cushioned by the 15ms 
queue. RTT ratio = 105:7.5 = 14:1, which was the Internet status quo 
pre-L4S (or SCE).

So why is it enough for only scalable flows to reduce their RTT 
dependence? Assuming they do, the lowest 3ms RTT ('Close Scalable') 
doesn't go much faster than 'Distant Scalable'. If it's no longer a hog 
in relation to Distant Scalable, it's no longer a hog in relation to any 
of the other flows. So the worst case reverts to the Close Classic flow, 
which isn't so bad because the total RTT is cushioned by the queue. So 
we will be no worse off than we were before L4S or SCE.


You will see we explained this at the end of Section V.B 'Congestion 
Control Roadmap' in the draft journal paper about L4S that we posted 
earlier this year:
“`Data Centre to the Home’: Deployable Ultra-Low Latency for All 
<http://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf#subsection.5.2>”

But is RTT-independent TCP Prague real? No, not quite yet. At the time 
we designed this, we simulated it, but we're now working on it again, 
including implementing it in Linux, so you should see results soon. The 
approach to RTT-independence that we suggest is explained in section 3.2 
of a paper we presented to the iccrg back in Jul 2017.
“Resolving Tensions Between Congestion Control Scaling Requirements 
<https://riteproject.files.wordpress.com/2015/10/ccdi_tr.pdf#subsection.3.2>“


All the above papers are available via the L4S landing page: 
https://riteproject.eu/dctth/#papers
>> I'm also not against the recent vibrant energy, interest and engagement of people, but I think we can better use this energy in making things work. As you noticed, we can use the help to speed things up on the open source part.
> 	[SM]... while at the same time requesting help for implementation and dealing with the consequences of said "code point and requirements".

If you recall, when I asked you not to keep repeating other people's 
arguments without adding anything, you said the RTT-dependence point was 
your contribution to the debate.

The L4S team identified this problem in early 2015 during testing with 
diverse RTTs. When the Prague requirements were first agreed, we (Koen 
in particular) insisted that this should be included as a basic safety 
requirement, even tho some people said it wasn't important. The WG has 
so far kept it as a MUST requirement, justified by the potentially large 
discrepancy in rates that can result, articulated here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#appendix-A.1.5

If I were as cynical as some on this list, I could point out that 
discovering a requirement by reading one of the L4S documents doesn't 
really count as a contribution. But I'll let that pass.

What I wanted to show by this email is that a significant amount of work 
has been done on this, the problem is well-understood and solutions are 
in progress. RTT-independent congestion controls have been produced 
before - not that I'm belittling how hard it is to resolve the tension 
between requirements identified in the 'Tensions' paper above.

So I ask you to take a more constructive approach. Banging on your 
keyboard in the style of "ner ner ne ner ner, I found a problem with 
L4S" doesn't help anyone, when the problem you've "found" exists with 
any low latency shared queue, including an SCE-based solution. Instead 
you could have read all the papers referenced from the L4S landing page, 
understood how much everyone already understands the problem, how much 
has already been done to solve it, and then you could have tried to work 
out the details of a full solution.


Regards



Bob


>
>
> Best Regards
> 	Sebastian
>
>
>>   
>> Regards,
>> Koen.
>>   
>> From: Ingemar Johansson S <[e-mail]>
>> Sent: Wednesday, November 20, 2019 11:50 AM
>> To: Kyle Rose <[e-mail]>; Ingemar Johansson S <[e-mail]>
>> Cc: Sebastian Moeller <[e-mail]>; G Fairhurst <[e-mail]>; [e-mail]; [e-mail]; De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; [e-mail]; Ingemar Johansson S <[e-mail]>
>> Subject: RE: [tsvwg] L4S vs SCE
>>   
>> Hi
>>   
>> So given the imagined outcome that L4S fails.. two scenarios
>>   
>> If other SDOs or developers don’t pick up L4S then things are quite simple I guess, just declare the L4S drafts as deprecated, or is there more to do ?
>>   
>> But, if e.g. 3GPP somehow thinks that this is a good idea and adopts it.. Will the IETF send a message (LS?) to 3GPP with the message “please stop using L4S”, is this even a reasonable scenario?. After all, the fact that it is picked up by other SDOs, speaks against a failure ?
>>   
>> /Ingemar
>>   
>> From: Kyle Rose <[e-mail]>
>> Sent: den 20 november 2019 11:14
>> To: Ingemar Johansson S <ingemar.s.johansson=[e-mail]>
>> Cc: Sebastian Moeller <[e-mail]>; G Fairhurst <[e-mail]>; [e-mail]; Ingemar Johansson S <[e-mail]>; [e-mail]; De Schepper, Koen (Koen) <[e-mail]>; [e-mail]
>> Subject: Re: [tsvwg] L4S vs SCE
>>   
>> On Wed, Nov 20, 2019 at 6:04 PM Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
>>>        How do you expect an industry/commercial roll-out of L4S
>>> technology to behave, if the L4S experiment should terminated without
>>> adoption as a standard track RFC? Are they supposed to phase-out using
>>> ECT(1) as well, or is it understood that deployed L4S instances continue using
>>> L4S methods?
>> [IJ] The premise would be that L4S is declared a failure. I doubt that anybody has a good enough crystal ball to predict what happens. First it is necessary to come to the conclusion that L4S is a failure and I would argue that we are not yet there and I don't currently see that coming. Before that possible event I don't see it meaningful to speculate.
>>   
>> I'm going to have to go ahead and disagree with you strongly here. Given the potential consequences of cleaning up after a failed experiment without a plan worked out beforehand, this blithe approach is simply not acceptable.
>>   
>> In lots of cases, experiments are easy to terminate in an obvious way: for example, in one typical case, a code point can simply be abandoned, or (even better) a pollutable experimental code point returned to the available pool after some time. If that were the case here, it would not be difficult to enumerate a sequence of steps required to do so. It doesn't appear that's the case, however, so all the more reason to make sure we address this as part of the experiment setup.
>>   
>> A launch escape system of the necessary complexity should be a requirement of any experimental deployment. In this case, that might circumscribe the scope of the experiment itself.
>>   
>> Kyle
>

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