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

[Neal Cardwell <[e-mail]>]

On Thu, Aug 11, 2022 at 9:30 AM rrs <[e-mail]> wrote:

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

I'm not sure what can be concluded from this kind of analysis, since the
delay "which other packets will feel" is entirely dependent upon whether
those other packets arrive at the bottleneck soon enough after the packets
in question (with an inter-arrival time less than the serialization time of
the packet in question, so that the other packets are likely to be queued)?

neal