Re: [tsvwg] ECN encapsulation draft - proposed resolution

[Jonathan Morton <[e-mail]>]

> On 11 Jun, 2021, at 1:39 pm, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
>>> Let me turn that around and ask you what would happen if 3% of the ATM cells were *lost*.
> 
> So you are still limit your thinking in terms of CE == DROP, which I thought was accepted not to be the most optimal and useful way forward... We can and MUST use ECN in a much better way if you want ECN to get really deployed AND used...

Funnily enough, nearly all current ECN deployment is using conventional TCP congestion control (RFC-5681, RFC-8312), a time-domain marking strategy (RFC-8289) and the RFC-3168 reassembly rules, and it seems to work pretty well.  Since that is what's currently standardised in published RFCs, don't knock it until you've actually tried it.

>>> Stop thinking in terms of "probability per packet", and start thinking in bytes or seconds instead.  Everyone else is.
>>> There are two currently known AQM designs which implement this approach:
> 
> I think you are missing the point here: It is not the AQM that determines the marks. It is the end-system congestion control.

I agree, that is the correct way around to analyse the system.  Which is what I did in a previous post, using Dimensional Analysis.  That is precisely what I've been trying to get you to read and understand.

What I found, in brief, was that DCTCP has a steady state that is dimensioned in marks per second, while Reno and CUBIC have steady states dimensioned in byte-seconds per mark.  None of them are directly sensitive to packet or byte marking probability - that is just an emergent property of empirical measurement on an inappropriate assumed basis.

> If that uses the packet probability it will DRIVE the AQM to whatever it needs to converge. It is a closed loop, and the end system determines the rate/probability.

You're right that the AQM is effectively driven to the state needed to control the actual transport.  Which is why the AQM in my PPPoA example would never be driven to a 3% cell-marking probability except under extreme circumstances.  Instead, it would select a probability that resulted in a reasonable number of marks per second, or if you prefer, a reasonably large number of bytes between marks.  Codel simply operates directly in the time domain, neatly bypassing a few awkward steps on the way.

> We only can hope the AQM is responsive enough to quickly set that rate or probability. This is where CoDel clearly fails, so not a good example to use. We need to learn from our mistakes and forget "rules from the past" that are not useful...

I'll accept the Codel is not perfect.  However, it's the first AQM that matches with the problem domain well enough to deploy successfully with universal defaults, which I think accounts for its popularity.  If you continue to claim that it "fails", you're going to have to back that up with empirical data.

 - Jonathan Morton