Re: [tsvwg] ECN encapsulation draft - proposed resolution

[Sebastian Moeller <[e-mail]>]

Hi Koen,

see below, prefixed [SM].

> On Jun 14, 2021, at 18:04, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
>>> Which is what I did in a previous post, using Dimensional Analysis. 
> Dimensional analysis is what you can use to check the validity of equations and further derivations from them. I didn't see any equation in your explanation. 
> 
> But I understand your point about the interval being constant for Classic CCs. The Congestion Controls determine if a "packet/byte probability per RTT" or an "RTT intervals between mark/drops" is used:
> - DCTCP-like CCs use the marked byte (or packet) ratio per RTT (or other time interval), but marks are expected during every RTT (or other time interval)
> - Classic CCs trigger reduction on occurrence of any number of bytes/packets dropped/marked per RTT (whether it is a packet of only 1 byte that is marked in that RTT or all packets and bytes marked in that RTT, the result is the same), and need a number of RTTs to recover from the reduction. If the flow is split in small packets and those are marked with the same random prob, they get smaller RTT intervals and a lower rate.
> 
> There were recommendations for AQMs to marking packet based on their size, to overcome this unfairness, but this is not often applied I understood. Probably better is to solve this again in the end system: by only triggering a congestion event if 1MSS of data is marked.

	[SM] Question, since the decapsulator node is not guaranteed to be the the endpoint for tunneled flows, how would it know each flow's MSS? Especially since flows can have quite different MSS. Sure, we could keep state per flow, but that seems pretty costly and intensive... 

Regards
	Sebastian



> This solves both cases:

	[SM] But will need an MSS-oracle to work well ;)


> So it needs to collect at least 1500 bytes of marked packets  which come from either a series of 32 marks in a row (a large 1500b outer packet was marked and all 32 46b

	[SM] ATM payload is 48 bytes (in a 53 byte cell)...


> inner packets too) or it was NOT encapsulated in a tunnel, and an AQM is used that marks the small packets directly or it was encapsulated and a decapsulation works as a normal AQM and marks the packets with a probability (and in both cases marks 32 times more packets). Assuming the small packets are separately ACKed the 32 factor can be "undone" in the sender by only triggering after 1500 bytes were ACKed CE.
> 
> For scalable CCs this isn't needed, as the proportion of marked bytes and total bytes per interval is used. And for Classic it would only be needed if the TCP/QUIC sender is sending small packets (not if they are split in tunnels in the NW, assuming they keep the proportional factor.
> 
> I think this could be a simple way out of this otherwise already broken and complex mix of strategies...??
> 
> Koen.
> 
> 
> -----Original Message-----
> From: Jonathan Morton <[e-mail]> 
> Sent: Friday, June 11, 2021 2:13 PM
> 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 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
>