From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6E29F3B2A4 for ; Tue, 18 May 2021 11:16:14 -0400 (EDT) Received: from [10.122.7.100] (rhrk.router.fg-networking.de [131.246.199.18]) (authenticated bits=0) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 14IFGAFH079427 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 May 2021 17:16:11 +0200 To: bloat@lists.bufferbloat.net References: From: Erik Auerswald Message-ID: <4b50842f-a1d5-3f2f-3a47-7e4d77346ba4@unix-ag.uni-kl.de> Date: Tue, 18 May 2021 17:16:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.001, tests=ALL_TRUSTED=-1,NICE_REPLY_A=-0.001 X-Spam-Score: (-1.001) X-Spam-Flag: NO Subject: Re: [Bloat] In terms of bufferbloat-aware buyer constructing a RFP X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 15:16:14 -0000 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