[Bloat] In terms of bufferbloat-aware buyer constructing a RFP

[Erik Auerswald]

Hi Dave,

On 18.05.21 15:48, Dave Taht wrote:
> No cloudy provider (I know of) has a SLA regarding bufferbloat related
> issues. They sell things by the cpu, and do not
> guarantee bandwidth or latencies. No chipmaker tests comprehensibly
> for bufferbloat. Most downstream vendors have no clue, nor the users.

Please see a few suggestions below.

> [...]
> VENDOR BUFFERBLOAT[1] STRATEGY QUESTIONS
> [...]
> Are you currently measuring Rate Vs Range Vs TCP RTT Latency across
> your wireless and wifi products as google does?

It seems strange to ask a WiFi vendor to compare its measuring
to whatever Google may be doing.  I'd suggest to remove the
last three words, or replace them with a more helpful reference.

> What do you use to benchmark TCP RTT latency under load?

I'd suggest to ask for benchmark results with a description of the
benchmarking methodology instead.

I am not sure how useful the original question is.

Let's say, for example, the answer is "Spirent" or "Ixia" (referring
to their comprehensive testing equipment that can be used to measure
bufferbloat (I've done that), but is often not used to do this, but
to measure maximum throughput and minimum latency, because nobody
seems to care about bufferbloat).  Would that be a useful answer?
I don't think so.

The three words "benchmark TCP RTT" imply quite a lot, e.g., TCP
seeking to maximise throughput, and using end points able to overload
the network.  It more or less implies drop based congestion control
with AIMD in the congestion avoidance phase.  There most probably
are quite a few assumptions behind the question, but the answer may
evade any of those, without this being obvious.  Benchmarking with
TCP Vegas may give good results even with bufferbloat.  Using some
unknown testing tool, or a testing tool that allows selecting TCP
Vegas or other CC algorithms without specifying the settings,
answers the question without providing any insight.

> Do you presently have in your offloaded forwarding engines any support
> for the following AQM or FQ or FQ+AQM technologies?
> 
> RED

There is often WRED (weighted red, used with different queues),
so I'd suggest to add "WRED" to the list.

> [...]
> Assuming you support one or more of these, do any have RFC3168 ECN
> support? DCTCP ECN support?

I'd suggest to add the reference "RFC 8257" to DCTCP.

Section 3.1 of that RFC describes marking all packets with CE
if the queue length is over some threshold value.  I think that
is what you have in mind with this question.

[This seems to be widely available in so called "switches" with
(W)RED support.]

> [...]
> Can you demonstrate BQL in operation on your Linux based products
> during your benchmarks? (tool: bqlmon)

Is "https://github.com/ffainelli/bqlmon" the tool you have in mind?
Perhaps you cloud add a reference to where to find bqlmon, since it
is not packaged in, e.g., Debian at the moment.  (I did not know
such a tool existed, and there may be others who don't know either.)

> [...]

All in all I think having such a questionnaire could be helpful. :-)

HTH, HAND
Erik