netdev - TC TBF calculates wrong buffer limit when "latency" is provided

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAO0k2uyGmi_8=KuX=mHqCKy4yRr_J6b9dA5jRuCXWdXNdRrfXw@mail.gmail.com>
Date:   Fri, 18 Jan 2019 16:01:46 +0200
From:   Roi Gabay <roigby@...il.com>
To:     netdev@...r.kernel.org
Subject: TC TBF calculates wrong buffer limit when "latency" is provided

I noticed that when providing "latency" instead of "limit", tc utility
adds burst size to the token buket's queue limit (q_tbf.c, line 215):
    lim = rate64*(double)latency/TIME_UNITS_PER_SEC + buffer;

This results in a bigger buffer than expected, yielding latency higher
than requested.

To show that the achieved latency is higher than expected, I
configured 10kbps with 10kb burst and 1 second latency, and sent 30kb
instantanously.
(network configuration: host1----switch----host2)

switch: tc qdisc add dev s1-eth2 root tbf rate 10kbps burst 10kb latency 1s

host1: ping host2 -s 1500 -l 20
PING 10.0.0.2 (10.0.0.2) 1500(1528) bytes of data.
1508 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.287 ms
1508 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.018 ms
1508 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.007 ms
1508 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.007 ms
1508 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.006 ms
1508 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=0.006 ms
1508 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=78.6 ms
1508 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=236 ms
1508 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=393 ms
1508 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=551 ms
1508 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=709 ms
1508 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=867 ms
1508 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=1024 ms
1508 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=1181 ms
1508 bytes from 10.0.0.2: icmp_seq=15 ttl=64 time=1339 ms
1508 bytes from 10.0.0.2: icmp_seq=16 ttl=64 time=1497 ms
1508 bytes from 10.0.0.2: icmp_seq=17 ttl=64 time=1655 ms
1508 bytes from 10.0.0.2: icmp_seq=18 ttl=64 time=1812 ms
1508 bytes from 10.0.0.2: icmp_seq=21 ttl=64 time=982 ms
1508 bytes from 10.0.0.2: icmp_seq=22 ttl=64 time=140 ms
1508 bytes from 10.0.0.2: icmp_seq=23 ttl=64 time=0.057 ms
^C
--- 10.0.0.2 ping statistics ---
23 packets transmitted, 21 received, 8% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.006/593.931/1812.417/611.926 ms, pipe 20

As you can see in icmp #18 - the latency peaked at 1.8 seconds even
though i requested 1 second max.

Proposed solution:
I think that burst size should not be added to the lim parameter
(q_tbf.c, line 215):
    lim = rate64*(double)latency/TIME_UNITS_PER_SEC;

Is this sensible?