[Bloat] [Make-wifi-fast] D* tcp looks pretty good, on paper
Bob McMahon
bob.mcmahon at broadcom.com
Thu Jan 7 15:25:57 EST 2021
FYI, one can try this out using iperf 2.1
<https://sourceforge.net/projects/iperf2/> with --trip-times
<https://iperf2.sourceforge.io/iperf-manpage.html>. This gives end/end
delay at the application level. One can use --trip-times when clocks
are sync'd to get the write to read latencies which are the latencies at
the application level.
Note: I set up a Raspberry Pi 4 with a GPS hat from ubutronics for
solderless pulse per second
<https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html>. Then configured it
as a PTP grandmaster. This cost me around $200.
I also added support for a very crude --near-congestion option that paces
the writes based upon the weight of the RTT. The tcp_info struct is
sampled and available
for other experiments though one would have to modify the source a bit.
This current technique used by iperf 2.1 is designed for test networks only
where all
traffic is under script control. We've had too many people measuring bloat
as latency. We really need separate measurements between the two phenomena,
bloat vs latency, because they require different eng actions for a
semiconductor supplier.
Below are examples over a 10G link, first with no write pacing then with
it. The server output, shown first, has the latency data (as well as the
net power
and little's law calculation.) (Note: use --histograms for to get full
distributions.)
*No write pacing*
[rjmcmahon at localhost iperf2-code]$ src/iperf -s -i 1 -e
------------------------------------------------------------
Server listening on TCP port 5001 with pid 24568
Read buffer size: 128 KByte (Dist bin width=16.0 KByte)
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.62 port
50056 (MSS=1448) (trip-times) (sock=4) (peer 2.1.0-rc) on 2021-01-07
12:11:04 (PST)
[ ID] Interval Transfer Bandwidth Burst Latency
avg/min/max/stdev (cnt/size) inP NetPwr Reads=Dist
[ 1] 0.00-1.00 sec 1.09 GBytes 9.34 Gbits/sec 2.959/1.180/3.681/0.388
ms (8905/131072) 3.31 MByte 394522
18480=2459:2580:2475:2354:2203:2192:1974:2243
[ 1] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec 2.993/2.302/3.703/0.359
ms (8978/131072) 3.36 MByte 393209
19482=2526:2850:3102:2622:2344:2297:1867:1874
[ 1] 2.00-3.00 sec 1.10 GBytes 9.42 Gbits/sec 3.010/2.302/3.692/0.347
ms (8978/131085) 3.38 MByte 391047
19387=2563:2757:2928:2708:2432:2244:1829:1926
[ 1] 3.00-4.00 sec 1.10 GBytes 9.41 Gbits/sec 3.009/2.301/3.668/0.348
ms (8979/131060) 3.38 MByte 391094
18821=2456:2585:2660:2545:2270:2239:1906:2160
[ 1] 4.00-5.00 sec 1.10 GBytes 9.42 Gbits/sec 2.985/2.299/3.696/0.359
ms (8979/131070) 3.35 MByte 394295
19441=2509:2886:2959:2728:2336:2200:1971:1852
[ 1] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec 2.977/2.258/3.671/0.363
ms (8978/131082) 3.34 MByte 395352
18509=2352:2602:2464:2380:2263:2142:2095:2211
[ 1] 6.00-7.00 sec 1.10 GBytes 9.41 Gbits/sec 2.980/2.290/3.680/0.363
ms (8978/131072) 3.34 MByte 394873
18522=2407:2499:2565:2334:2213:2268:1999:2237
[ 1] 7.00-8.00 sec 1.10 GBytes 9.42 Gbits/sec 2.980/2.253/3.702/0.362
ms (8979/131073) 3.35 MByte 394972
18615=2427:2592:2493:2460:2281:2057:2062:2243
[ 1] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 2.976/2.277/3.663/0.364
ms (8979/131065) 3.34 MByte 395443
18632=2338:2615:2647:2351:2192:2317:2063:2109
[ 1] 9.00-10.00 sec 1.10 GBytes 9.41 Gbits/sec 2.976/2.293/3.690/0.366
ms (8978/131076) 3.34 MByte 395416
18428=2281:2622:2497:2275:2178:2253:2129:2193
[ 1] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec 2.984/1.180/3.703/0.362 ms
(89736/131072) 3.35 MByte 394014
188367=24320:26609:26793:24757:22712:22211:19916:21049
[rjmcmahon at localhost iperf2-code]src/iperf -c 192.168.1.10 --trip-times -i
1 -e
------------------------------------------------------------
Client connecting to 192.168.1.10, TCP port 5001 with pid 18961 (1 flows)
Write buffer size: 131072 Byte
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.62%enp2s0 port 50056 connected with 192.168.1.10 port
5001 (MSS=1448) (trip-times) (sock=3) (ct=0.41 ms) on 2021-01-07 12:11:04
(PST)
[ ID] Interval Transfer Bandwidth Write/Err Rtry
Cwnd/RTT NetPwr
[ 1] 0.00-1.00 sec 1.09 GBytes 9.37 Gbits/sec 8937/0 0
1508K/1099 us 1065750
[ 1] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec 8975/0 0
1508K/1087 us 1082218
[ 1] 2.00-3.00 sec 1.10 GBytes 9.41 Gbits/sec 8975/0 0
1508K/1081 us 1088225
[ 1] 3.00-4.00 sec 1.10 GBytes 9.42 Gbits/sec 8984/0 0
1508K/1085 us 1085300
[ 1] 4.00-5.00 sec 1.10 GBytes 9.42 Gbits/sec 8980/0 0
1508K/1105 us 1065182
[ 1] 5.00-6.00 sec 1.10 GBytes 9.41 Gbits/sec 8975/0 0
1582K/1100 us 1069428
[ 1] 6.00-7.00 sec 1.10 GBytes 9.42 Gbits/sec 8979/0 0
1582K/1121 us 1049862
[ 1] 7.00-8.00 sec 1.10 GBytes 9.41 Gbits/sec 8976/0 0
1582K/1133 us 1038396
[ 1] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 8978/0 0
1582K/1115 us 1055394
[ 1] 9.00-10.00 sec 1.10 GBytes 9.42 Gbits/sec 8986/0 0
1582K/1122 us 1049744
[ 1] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec 89748/0 0
1582K/1122 us 1048294
*With write pacing*
[rjmcmahon at localhost iperf2-code]$ src/iperf -s -i 1 -e
------------------------------------------------------------
Server listening on TCP port 5001 with pid 24702
Read buffer size: 128 KByte (Dist bin width=16.0 KByte)
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.62 port
50072 (MSS=1448) (trip-times) (sock=4) (peer 2.1.0-rc) on 2021-01-07
12:14:59 (PST)
[ ID] Interval Transfer Bandwidth Burst Latency
avg/min/max/stdev (cnt/size) inP NetPwr Reads=Dist
[ 1] 0.00-1.00 sec 1.08 GBytes 9.31 Gbits/sec 0.401/0.193/2.682/0.168
ms (8876/131084) 456 KByte 2904347
19868=3296:2404:2508:2797:3559:1778:1551:1975
[ 1] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec 0.400/0.219/0.627/0.053
ms (8971/131071) 460 KByte 2937822
19117=3069:2267:2307:2510:3029:1824:1683:2428
[ 1] 2.00-3.00 sec 1.09 GBytes 9.39 Gbits/sec 0.374/0.193/0.541/0.055
ms (8958/131060) 428 KByte 3143030
18942=2846:2423:2304:2417:2927:1831:1856:2338
[ 1] 3.00-4.00 sec 1.09 GBytes 9.39 Gbits/sec 0.385/0.190/0.664/0.070
ms (8952/131072) 441 KByte 3050401
19248=3041:2175:2343:2749:3320:1805:1526:2289
[ 1] 4.00-5.00 sec 1.09 GBytes 9.40 Gbits/sec 0.380/0.197/0.546/0.057
ms (8965/131075) 436 KByte 3095915
19959=3321:2398:2551:2738:3500:1840:1532:2079
[ 1] 5.00-6.00 sec 1.09 GBytes 9.39 Gbits/sec 0.369/0.198/0.536/0.051
ms (8956/131072) 423 KByte 3177431
21060=3627:2456:2886:3189:4246:1813:1190:1653
[ 1] 6.00-7.00 sec 1.09 GBytes 9.39 Gbits/sec 0.380/0.202/0.562/0.054
ms (8959/131077) 436 KByte 3086914
19263=3044:2338:2424:2505:3155:1809:1636:2352
[ 1] 7.00-8.00 sec 1.09 GBytes 9.40 Gbits/sec 0.376/0.198/0.541/0.053
ms (8965/131061) 432 KByte 3122495
19137=3079:2303:2340:2455:3017:1822:1683:2438
[ 1] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 0.381/0.208/0.576/0.054
ms (8974/131073) 438 KByte 3083767
19162=3050:2269:2392:2486:3019:1891:1667:2388
[ 1] 9.00-10.00 sec 1.09 GBytes 9.40 Gbits/sec 0.371/0.194/0.582/0.057
ms (8964/131070) 425 KByte 3169244
19143=3006:2411:2303:2462:3067:1744:1760:2390
[ 1] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 0.382/0.190/2.682/0.076
ms (89544/131072) 437 KByte 3074913
194908=31380:23444:24362:26308:32839:18161:16084:22330
[rjmcmahon at localhost iperf2-code]$ src/iperf -c 192.168.1.10
--near-congestion=0.05
--trip-times -i 1 -e
------------------------------------------------------------
Client connecting to 192.168.1.10, TCP port 5001 with pid 19320 (1 flows)
Write buffer size: 131072 Byte
TCP near-congestion delay weight set to 0.0500
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.62%enp2s0 port 50072 connected with 192.168.1.10 port
5001 (MSS=1448) (trip-times) (sock=3) (ct=0.40 ms) on 2021-01-07 12:14:59
(PST)
[ ID] Interval Transfer Bandwidth Write/Err Rtry
Cwnd/RTT NetPwr
[ 1] 0.00-1.00 sec 1.08 GBytes 9.31 Gbits/sec 8881/0 0
1135K/373 us 3120427
[ 1] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec 8971/0 0
1135K/391 us 3007281
[ 1] 2.00-3.00 sec 1.09 GBytes 9.39 Gbits/sec 8958/0 0
1135K/331 us 3547260
[ 1] 3.00-4.00 sec 1.09 GBytes 9.39 Gbits/sec 8952/0 0
1135K/288 us 4074155
[ 1] 4.00-5.00 sec 1.09 GBytes 9.40 Gbits/sec 8965/0 0
1135K/301 us 3903855
[ 1] 5.00-6.00 sec 1.09 GBytes 9.39 Gbits/sec 8955/0 0
1135K/414 us 2835144
[ 1] 6.00-7.00 sec 1.09 GBytes 9.40 Gbits/sec 8961/0 0
1135K/470 us 2499013
[ 1] 7.00-8.00 sec 1.09 GBytes 9.40 Gbits/sec 8964/0 0
1135K/350 us 3356941
[ 1] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 8973/0 0
1135K/472 us 2491756
[ 1] 9.00-10.00 sec 1.09 GBytes 9.40 Gbits/sec 8964/0 0
1135K/402 us 2922710
[ 1] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 89547/0 0
1135K/402 us 2919642
Bob
On Thu, Jan 7, 2021 at 11:22 AM Taran Lynn via Make-wifi-fast <
make-wifi-fast at lists.bufferbloat.net> wrote:
> The source can be found at https://github.com/lambda-11235/tcp_davis .
>
> The code mentioned in the paper can be found under the tag "arxiv_2020".
> The current master branch has an additional stable mode that I was testing
> out.
>
> On Thu, Jan 7, 2021 at 10:35 AM Dave Taht <dave.taht at gmail.com> wrote:
>
>> See: https://arxiv.org/pdf/2012.14996.pdf
>>
>> Things I really like:
>>
>> * they used flent
>> * Using "variance" as the principal signal. This is essentially one of
>> the great unpublished and unanalyzed improvements on the minstrel
>> algorithm as well
>> * Conventional ecn response
>> * outperforms bbr on variable links
>>
>> Only negative so far is I haven't found any published source to it. :(
>>
>> Otherwise a very promising start to a year.
>>
>> "The choice of feedback mechanism between delay and packet loss has
>> long been a point of contention in TCP congestion control. This has
>> partly been resolved, as it has become increasingly evident that delay
>> based methods are needed to facilitate modern interactive web
>> applications. However, what has not been resolved is what control
>> should be used, with the two candidates being the congestion window
>> and the pacing rate. BBR is a new delay based congestion control
>> algorithm that uses a pacing rate as its primary control and the
>> congestion window as a secondary control. We propose that a congestion
>> window first algorithm might give more desirable performance
>> characteristics in situations where latency must be minimized even at
>> the expense of some loss in throughput. To evaluate this hypothesis we
>> introduce a new congestion control algorithm called TCP D*, which is a
>> congestion window first algorithm that adopts BBR's approach of
>> maximizing delivery rate while minimizing latency. In this paper, we
>> discuss the key features of this algorithm, discuss the differences
>> and similarity to BBR, and present some preliminary results based on a
>> real implementation."
>>
>>
>>
>>
>> --
>> "For a successful technology, reality must take precedence over public
>> relations, for Mother Nature cannot be fooled" - Richard Feynman
>>
>> dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
>>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20210107/bcd34241/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4163 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20210107/bcd34241/attachment-0001.bin>
More information about the Bloat
mailing list