Re: [tsvwg] RTT unfairness (was RE: new tests of L4S RTT fairness and intra-flow latency)

[Sebastian Moeller <[e-mail]>]

Hi David,



On 17 November 2020 19:50:42 CET, "Black, David" <[e-mail]> wrote:
>Lars,
>[writing as an individual]
>
>> > The RTT unfairness.. I believe that it has been discussed to death
>by
>> > now. To be honest I don't believe that additional discussion will
>do
>> > anything more than consume energy. Feel free to disagree.
>> 
>> Maybe it's been too long, but I can't recall the WG having anything
>like
>> agreement on the question whether less RTT fairness compared to
>"standard"
>> TCP is OK or not. And I don't have a strong opinion here. What we do
>need
>> though is agreement in the WG what kind of regressions/changes in
>behavior
>> from current TCP we're OK with for this new variant of TCP, and which
>ones we're
>> not. Have we had that discussion?
>
>Not really, for at least a couple of reasons that I can see:
>
>- TSVWG is not the "home" WG for TCP-related work or transport protocol
>work in general.
>- RTT fairness and other transport protocol aspects have entered
>discussion here as goals of ECN-related work, L4S in particular.
>
>On RTT fairness, here's what was set out as a goal for L4S congestion
>control (draft-ietf-tsvwg-ecn-l4s-id, Section 4.3):
>
>   o  A scalable congestion control MUST eliminate RTT bias as much as
>      possible in the range between the minimum likely RTT and typical
>RTTs expected in the intended deployment scenario (see Appendix A.1.5
>for rationale).

Please keep in mind that "typical RTT" is also the L4S specific term for the acceptable standing queue of the deep "classic" queue. 
@Bob And @Koen, what exactly is typical RTT referring to in this requirement? 

Best Regards
        Sebastian



>
>It's not at all clear how to determine whether a congestion control
>meets that requirement.
>
>That's one of six bullets setting out requirements that a congestion
>control has to meet in order to use the L4S ECT(1) codepoint.
>
>Thanks, --David
>
>> -----Original Message-----
>> From: tsvwg <[e-mail]> On Behalf Of Lars Eggert
>> Sent: Tuesday, November 17, 2020 8:38 AM
>> To: Ingemar Johansson S
>> Cc: tsvwg IETF list
>> Subject: Re: [tsvwg] new tests of L4S RTT fairness and intra-flow
>latency
>> 
>> Hi,
>> 
>> On 2020-11-17, at 15:25, Ingemar Johansson S
>> <[e-mail]> wrote:
>> > I see Prague as work on a congestion control algorithm that can
>exploit L4S.
>> > Other work is done on e.g. BBRv2 that can use L4S as well, and then
>we
>> > have SCReAM that is likely to be updated to make better use of L4S.
>> > Like with other congestion control I don't foresee a one size fits
>all
>> > here, for instance realtime media has different dynamics than bulk
>> > transfers
>> 
>> thanks for explaining! I agree.
>> 
>> > I see all these algorithms as work in progress and I don't see it
>> > explicit in the charter that there must be a fully functional L4S
>> > capable congestion control available.
>> 
>> Here, I disagree. IMO an existence proof of a CC scheme that derives
>some
>> benefits from L4S in at least some realistic/common scenarios without
>suffering
>> from issues is *key* - why else would we do even do L4S (or any other
>queueing
>> scheme)? How would we even know that we got the queuing part right?
>> 
>> > I see that the Prague work addresses many of the issues, among then
>> > the RTT unfairness issue. It is still not perfect I guess but all
>this
>> > is a matter of brain cycles in --> results out. Prague is an
>initial
>> > design and I imagine that it will be improved over time. Also I see
>it
>> > likely that L4S capable CCs can draw attention among academics in
>the
>> > future but for that to happen we need to move forward to give the
>> > signal that we move forward, to make it worthwhile to engage in the
>work.
>> 
>> The future may bring advanced CC schemes that optimize their use of
>L4S,
>> delivering large benefits without suffering from any issues. But, it
>also may not.
>> An existence proof of a CC scheme that managed to deliver some
>benefits for
>> some key scenarios *now* without regressions in others would go a
>long way to
>> convince me that such advanced schemes are on the horizon.
>> 
>> > The RTT unfainess.. I believe that it has been discussed to death
>by
>> > now. To be honest I don't believe that additional discussion will
>do
>> > anything more than consume energy. Feel free to disagree.
>> 
>> 
>> Maybe it's been too long, but I can't recall the WG having anything
>like
>> agreement on the question whether less RTT fairness compared to
>"standard"
>> TCP is OK or not. And I don't have a strong opinion here. What we do
>need
>> though is agreement in the WG what kind of regressions/changes in
>behavior
>> from current TCP we're OK with for this new variant of TCP, and which
>ones we're
>> not. Have we had that discussion?
>> 
>> Thanks,
>> Lars

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.