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

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

[Dave Taht]

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.

Perhaps this document, presented as part of an RFP (request for
proposal) by buyers, would be a start, much like iso 9001 compliance
once was. Or, reconstructed as a survey of the industry, distributed
widely?

https://docs.google.com/document/d/1i9-9M8589pEX_u7vKuwDFoQqbhJRlNPdLqXcxuDP73s/edit?usp=sharing

It's presently short enough to repaste here, but I would prefer
comments and additions be made directly on the url above.

VENDOR BUFFERBLOAT[1] STRATEGY QUESTIONS


What is your bufferbloat-fighting strategy across your product lines?

On Cable?

On DSL?

On Fiber ONTs?

On Ethernet?

On RocE?

On WiFi?

On Powerline Ethernet?

On Thread?

To what extent have you adopted the recommendations of IETF RFC7567 (
https://datatracker.ietf.org/doc/html/rfc7567)

Across your product lines?

In your cloud?

In your end user products?

Are you currently measuring Rate Vs Range Vs TCP RTT Latency across
your wireless and wifi products as google does?

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

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

RED

HTB

SFQ (dscp)

SFQ (5 tuple)

DRR (dscp)

DRR (5 tuple)

Pie (RFC8033)

DOCSIS-Pie (RFC8034)

Codel (RFC8289)

Fq_codel (RFC8290)

Cake

Fq_pie

Dualpi


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



Have you successfully managed to offload “SQM” (Smart Queue
Management) support in anything?


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


What Linux network scheduler is commonly used in your cloud, or end
user products, or testing regimes?

Sch_pfifo

Sch_fq

Sch_fq_codel

Sch_pie

Sch_tbf

Sch_htb

Sch_cake

Other


What operating systems are used to test with?

Windows 7

Windows 10

OSX

IOS

Android

Linux


What TCP congestion controls are in use in your cloud, end user
products, and testing regimes?

Reno

Cubic

CDG

Vegas

BBRv1

BBRv2

Other


Is ATF (airtime fairness) in your latest 802.11ac and ax router AP products?


Do you support the Linux APIs for fq_codel for wifi? Presently we only
observe Intel, QCA, and Mediatek support in the Linux mainline. If
not, what are your equivalents for queue management between fast (high
mcs rates) and slow (low mcs rate) stations? Does apple have support
for your equivalents?


Are there APIs and cross compilers to add these features available to
developers? How may they gain access?


[1] https://bufferbloat-and-beyond.net/



-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

Re: [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