Re: [iccrg] draft-briscoe-iccrg-prague-congestion-control: CE-marked bytes or packets?

[rrs <[e-mail]>]

Neal:


Just a couple of thoughts on your toy example  .. inline :)

On 8/10/22 6:11 PM, Neal Cardwell wrote:
> Re:
>    https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01
>
> and the passages:
>
> "2.3.2.  Moving Average of ECN Feedback
> ...it measures the fraction, frac, of ACKed bytes that carried ECN
> feedback over the previous round trip. ...
>
> 2.4.3.  Additive Increase and ECN Feedback
> ...a Prague CC applies additive increase irrespective of its CWR
> state, but only for bytes that have been ACK'd without ECN feedback.
> ...  This approach reduces additive increase as the marking
> probability increases..."
>
> I was curious about the design choice to specify that the algorithm
> reacts to the fraction of *bytes* that have been CE-marked instead of
> the fraction of *packets*. IMHO it would be useful for the document to
> outline the motivation.
>
> Apologies if I have missed this in previous e-mail discussions or
> presentations. I may well have. :-)
>
> I can imagine a number of potential reasons why it could be
> advantageous to react to the fraction of packets CE-marked rather than
> the fraction of bytes CE-marked:
>
> (1) AFAICT byte counters distort the path's ECN marking probability
> more than using packet counters. For example, suppose we have a round
> trip with 100 packets sent at roughly uniform intervals across the
> round trip time:
>
> o  99 packets of 1 byte each, all CE-marked
> o 1 packet of 1000 bytes that was not CE-marked
>
> Then the byte-based Prague "frac" ("the fraction, frac, of ACKed bytes
> that carried ECN feedback over the previous round trip") is:
>
>    99 bytes / 1099 bytes ~= .09
>
> Whereas the fraction of ACKed packets that carried ECN feedback is:
>
>     99 packets / 100 packet = .99
>
> So in this toy example there is a >10x difference in the CE "frac"
> signal depending on whether bytes or packets are counted.
>
> And given that these packets were spaced uniformly across the round
> trip, 99% of the time the bottleneck had excess queuing. This 99%
> number is well reflected in a packet-based "frac", but seems to imply
> that the byte-based "frac" approach dramatically underestimates the
> probability that a packet will encounter excessive queuing, aka the
> packet CE marking probability.

So lets make this a bit more concrete of a toy. Lets say the bottleneck 
is 20Mbps.

Now your 99 packets of 1 byte (assuming v4 and no timestamps enabled) 
are going to each take 22 microseconds to traverse the bottleneck 
(assuming bytes of 14<enet>, 20 <ip>, 20 <tcp> 1 <data>). Your 1000 byte 
packet is going to take 421 microseconds. So you have a delay through 
the bottleneck for a total of 2,599 microseconds which other packets 
will feel.

Now lets compare that to someone who sent all 1000 byte packets i.e. 421 
x 100. So the delay held by those packets preventing the bottleneck from 
forwarding other packets is 42,100 microseconds or about 1:16.

I suspect when you look at the number of bytes as indicating how long 
your packets take to send through the link thus blocking others the 
situation looks a bit different (at least not near as lopsided as your 
simple example illustrated)

:-)

R