Re: [tsvwg] ECN encapsulation draft - proposed resolution

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

>> 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...

>> 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. 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. 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...

Koen.

-----Original Message-----
From: Jonathan Morton <[e-mail]> 
Sent: Friday, June 11, 2021 11:19 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Cc: Bob Briscoe <[e-mail]>; [e-mail]; Markku Kojo <[e-mail]>
Subject: Re: [tsvwg] ECN encapsulation draft - proposed resolution

> On 11 Jun, 2021, at 11:59 am, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Did you consider the consequences too? With your approach it means that if you just mark 3% of the ATM cells, 100% of the inner 1500 bytes packets will get marked?
> Is that what you intended?
> While if there are small packets mixed in the inner stream of say 48 bytes size, they still get 3% marked. Is this what you intended too?

Let me turn that around and ask you what would happen if 3% of the ATM cells were *lost*.  In that case, very few of the full-size packets could be reassembled, and throughput would drop to almost nothing.  The analogous congestion response from a high percentage of ECN marked packets is a natural and obvious consequence of applying 849 marks per second.

So don't do that, then.  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:

1: Calculate a time-domain marking schedule, as Codel does.

2: Scale the marking probability by the size of the unit being marked.  This would naturally scale down a "3% per 1500 bytes" marking rate to be more suitable for 53-byte cells.  Small packets would also be marked less often, but a capacity-seeking flow using smaller packets would still receive the same number of marks.

Incidentally, I am getting somewhat weary of having to explain everything from multiple angles separately to each interlocutor.  I already made the above points a few posts ago, and I do wish you would have read and absorbed the argument instead of just ignoring it.

> We should decide what is the simplest for the expected way forward…

The simplest rules to implement happen to be the ones that preserve the time/bytes interval between marks.

> …(scalable, marked bytes %).

The 1/p congestion response is sensitive to time between marks, *not* to the percentage of marked bytes.

 - Jonathan Morton