Re: [tsvwg] ECN encapsulation draft - proposed resolution

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

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?

It all depends on how these marks are used by the congestion controller and what the Network congestion is related to: a bit-rate limit or a packet-rate limit.
If the outer packet size is constant (always a full MSS or ATM cell size) it doesn't matter if the network limit is packet- or bit-rate. Then it depends on the congestion control in the end-system. First does it keep a packet based window, or a byte based window (I assume byte based is usually used now). And then are CE's counted in "at least one mark" per RTT as in Reno/Cubic or in % of bytes marked to the total received (as in DCTCP-like).

As long as all combinations are possible, there won't be a good answer. We should decide what is the simplest for the expected way forward (scalable, marked bytes %). As we are going to have multiple marks per RTT or time interval, and those are measured in the ratio (bytes marked)/(bytes received or even bytes non-marked) I propose to keep that as the future recommendation, and decapsulation should keep this constant. In the near overload situation, which your example can be classified if packets get marked 100%, proper AQMs need to switch to drop anyway, which is rather matching your proposal I think.

Koen.

-----Original Message-----
From: Jonathan Morton <[e-mail]> 
Sent: Friday, June 11, 2021 7:48 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

>>> So for me following simple algorithms would be ok to use:
>>> - only mark if the first (even partial) segment of the reassembled packet is marked (ignore marks on any other segments)
>> 
>> This would mean that any mark applied to a segment that covered only the middle or tail of a packet would reliably have no effect.  I firmly disagree with that approach, due to the possibility of accidentally triggering pathological conditions where a long series of marks is lost.
> 
> It could as well mean that one outer packet marks 2 inner packets. Note that AQMs best apply random marking and that any pathological conditions will be quickly broken by the closed loop.

I would class that as a poor workaround, since you are effectively excluding an entire, successful class of AQM algorithms from use with this approach.

>>> - apply a random probability on the packet based on the ratio of marked bytes in the packet and full packet size
>> 
>> I can see where you're going with that, but I maintain - based on my analysis a couple of posts ago - that maintaining the number of marked bytes is simply the wrong approach.
>> 
>> The interval *between* marks, measured in either bytes or time, is the important property to preserve; this is actually easier to achieve and is natural to perform statelessly.  If the AQM device can rely on that behaviour, it can be designed to perform byte-mode or time-domain marking to match, which dovetails nicely with all existing transport implementations (whether with high-fidelity or conventional congestion control).
> 
> These algorithm preserve the marking probability (whether bytes or packets), which boils down to exactly preserving the interval between marks. Not sure what the difference is?? The interval i=1/p with p the probability. So preserving the probability, preserves the interval... not?

You are (approximately) preserving the number of marked bytes and the interval *in packets* between marks.  That is *not at all* the same thing as preserving the interval *in bytes or in time* between marks, given that the size of each packet changes at reassembly.

To ram this point home - since that is clearly required for understanding - let's take an extreme but realistic example: encapsulating 1500-byte IP packets into 53-byte ATM cells using PPPoA encapsulation (10-byte overhead per IP packet), and transmitting them over a CBR 12Mbps ADSL link (28,300 cells per second).  We will also assume there's a few smaller IP packets mixed in from application-limited flows.  Each ATM cell takes a 48-byte portion of the PPPoA-encapsulated payload, so it requires 32 of them to encapsulate one full-size PPPoA frame, and we can transmit 884 of those per second.  We will further assume, perhaps less realistically, that we have a way to apply congestion signals to individual ATM cells.

In your world, probabilities are sacrosanct.  So at some given AQM state, we apply a 1% marking rate to the ATM cells, and you expect that to be converted into 1% of IP packets being marked.  But that is also converting 283 marked ATM cells per second into just 8.84 marked IP packets per second, and increasing the byte interval between marks from 5300 to 150000.  You can see here that packet intervals are *not* the same as byte or time intervals.

In the world of Reno and CUBIC and Codel that actually makes up much of the Internet today, and even in the world of DCTCP, it is the byte/time interval between marks that is sacrosanct.  Neither of your algorithms above *even approximately* preserves this property in the scenario given (which doesn't even involve frames spanning packets, but the arithmetic is similar).  The RFC-3168 rule, however, *does* preserve it.

 - Jonathan Morton