“Bufferbloat” is the growth in buffer size that has led Internet delays to occasionally exceed the light propagation delay from the Earth to the Moon. Manufacturers have built in large buffers to prevent losses on Wi-Fi, cable and ADSL links. But the combination of some links' limited bandwidth with TCP's tendency to saturate that bandwidth results in excessive queuing delays. In response, new congestion control protocols such as BitTorrent's uTP/LEDBAT aim at explicitly limiting the delay that they add at the bottleneck link. This work proposes a methodology to monitor the upstream queuing delay experienced by remote hosts, both those using LEDBAT, through LEDBAT's native one-way delay measurements, and those using TCP, through the Timestamp Option. We report preliminary findings on bufferbloat-related queuing delays on an Internet measurement campaign involving a few thousand hosts.

Recently, the “bufferbloat” term has been coined to describe very large queuing delays (up to several seconds) experienced by Internet users. This problem has pushed protocol designer to deploy alternative (delay-based) models to the standard (lossbased) TCP best effort congestion control. In this work, we exploit timestamp information carried in the LEDBAT header, a protocol proposed by BitTorrent as replacement for TCP data transfer, to infer the queuing delay suffered by remote hosts. We conduct a thorough measurement campaign, that let us conclude that (i) LEDBAT delay-based congestion control is effective in keeping the queuing delay low for the bulk of the peers, (ii) yet about 1% of peers often experience queuing delay in excess of 1s, and (iii) not only the network access type, but also the BitTorrent client and the operating system concurr in determining the bufferbloat magnitude.

Nowadays, due to excessive queuing, Internet delays grow sometimes as large as the propagation delay from moon to earth - for which the bufferbloat term was recently coined. Some points to active queue management (AQM) as its solution, others propose end-to-end congestion control techniques - like BitTorrent that recently replaced TCP with the LEDBAT transport protocol. In this demo, we implement a methodology to monitor the upstream queuing delay experienced by remote hosts, both those using LEDBAT, through LEDBAT's native one-way delay measurements, and those using TCP, through the timestamp option. By actively taking part into torrent downloads as leechers, our software is able to infer (and visualize) the amount of access delay suffered by the remote peers.