Re: [tsvwg] [tcpPrague] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Jonathan,

Indeed, FQ is ensuring (actually enforcing) per 5 tuple equal BW. Do you suggest we need to have FQ per 5 tuple in every bottleneck? This would indeed be a simple solution for CC developers. But not sure if every NW box would like to implement this functionality. From the moment flows are treated as an aggregate, the rates that CC's will get is exactly based on their respective behavior (say their formula), and if they are vastly different, so will their rates be...

As long as there is no consensus about universal FQ, I think we need to discuss what the formula should be.

Regards,
Koen.

-----Original Message-----
From: Jonathan Morton <[e-mail]> 
Sent: Monday, November 2, 2020 1:52 AM
To: Christian Huitema <[e-mail]>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; iccrg IRTF list <[e-mail]>; Bob Briscoe <[e-mail]>; tsvwg IETF list <[e-mail]>; TCP Prague List <[e-mail]>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

> On 2 Nov, 2020, at 2:10 am, Christian Huitema <[e-mail]> wrote:
> 
>> In any case, you have a scaling issue. Let's consider a 1.5Gbps link, with 15 ms delay and 1500 bytes packets. The nominal sending rate is 125,000 packets per second. The marking rate with your formula shall be p = 2/(r*0.015), which is about 0.0008%. Over the last 10 RTT, the connection will on average see 0.14 marks -- that is, no mark over the last 10 RTT 86% of the time. This falls well short of the requirement to provide frequent feedback!
> 
> Sorry, bug in my spreadsheet. The marking rate is actually 0.1%, about 2 packets per RTT. Still not frequent enough for my taste, but much better than 0.0008%. Nevertheless, the inverse relation between marking rate and data rate is not great.

A property of both Reno and DCTCP is that a particular CE marking probability results in a particular average cwnd, over some reasonably long period.  The relationship formula is of course very different for each one, but that qualitative rule happens to be the same.  It is a property that DualQ's coupled AQM design relies on.  CUBIC is a little different in its high-BDP regime, but acts like Reno otherwise.

What this means is that competing flows experiencing the same marking probability will converge to the same cwnd, and their relative throughputs will be inversely proportional to their effective RTTs.  This convergence is not necessarily very fast, but given a single queue and a single AQM, it's about as good as you can expect.

When you have an AQM per flow, you can do a bit better by applying a different marking probability to each flow.  This makes convergence faster, and you can make them converge to the same throughput, not merely the same cwnd.  When you have a separate queue per flow, you can additionally prevent one "fat" flow from affecting the latency of sparser flows, and *enforce* the throughput equality on short timescales, even with flows that are unresponsive to congestion signals.  This is all established practice.

And that is the key to achieving RTT independence with the minimum of added complexity.

 - Jonathan Morton