Re: [tsvwg] ECN encapsulation draft - proposed resolution

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Jun 11, 2021, at 12:39, 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...
> 
>>> 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.

	[SM] I would agree that it is the endpoints that interpret the marks, but it clearly is the function of the AQM to actually set the marks, no? And for this to work, end-points need to interpret the marks in an agreed upon fashion so that AQMs can expect specific per-flow behavior to marking to occur, so the AQM can achieve its own goals (what ever these are). If push comes to shove all AQMs will need to drop packets (even in a fully L4S world there can be situations with queues exceeding available memory or similar). So marking is a way for an AQM to be nicer/gentler to flows (talking softly) but if the flow (or the aggregate) does not respond quickly enough the AQM will use the big stick it carries and start dropping packets (as dropping is the only solution to a bottleneck node's immediate problem if ingress traffic exceeds egress capacity for too long). 


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

	[SM] Only in the case of a single flow, other wise you have the interaction of multiple endpoints happening in the bottleneck buffers which are potentially outside of the control of each individual endpoint...

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

	[SM] Not sure what you mean with Codel fails, though.My homenet work has been sitting behind a codel-style AQM for almost a decade now (first sfq, then fq_codel, then cake) and generally this works well. Sure for individual (under-responsive) flows codel can be a bit too gentle, but that mostly is ironed out by stochastic fair queueing, which tends to isolate the fall-out from misbehaving flows mostly to those misbehaving flows them selves. 

Regards
	Sebastian



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