Re: [tsvwg] ECN encapsulation draft - proposed resolution

[Jonathan Morton <[e-mail]>]

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