[j-nsp] Output queue drops and temporal buffers

[Saku Ytti]

On (2013-10-01 13:12 -0600), John Neiberger wrote:

> As I understand it, the formula to determine available buffer space is this:
> 
> bandwidth * transmit-rate percent * temporal buffer size

You are right. So they are not really temporal at all, temporal would imply
that buffer is always 50ms, regardless of offered rate (offered rate might be
lot more or lot less contract)
This means that if offered rate changes say during office hours and
out-of-office hours, you just have to accept that BE buffers too much during
office hours and not enough outside office hours.
True temporal buffer which changes as function of offered rate would be
amazing.

All of the options to configure buffer size are just syntactic sugar for
configuring flat, static, exact byte size in the QX or MQ (you can check this
from PFE). I'd personally love to have direct way to configure the buffer
value, now we have to calculate buffer value we want then recalculate what it
is, when expressed with some of the convenience methods.

So essentially what we do is, we decide how deep buffers we need, then we
solve X for: scheduler_rate * class_percentage * X = desired bytes. And we
configure temporal X in class to get desired buffer depth. Sometimes it gives
completely counter-intuitive figures, like when we reserve very very little
for BE, but we know often most of traffic will actually be BE, the temporal
value will be considerably high.

> My question regarding the config is this: if we are already setting the
> transmit rate percentage, why would we also configure a temporal
> allocation? Isn't a percentage of the available bandwidth sufficient? What
> does adding a temporal allocation buy us? Is the transmit rate percent just
> setting how often that queue is serviced, while the buffer-size configures
> the queue depth?

Then it's same as buffer percent 100 iirc, and in my testing I've seen Trio
buffer excess of 4s in cases. I hardly think you want to arbitrarily delay
packets, packet drops are crucial to signal congestion (otoh QUIC suggests
method of using increased latency as signal of congestion, but that would
starve QUIC if TCP is in-play too).

For each class you need to decide what is acceptable delay over this link,
then configure buffer depth and RED curve to satisfy that decision.

-- 
  ++ytti