A queue flusher
TCP or other protocols can sometimes build "standing queues" in the network: buffers that are filled to a certain level but never allowed to drain because data continuously comes in fast enough to keep the queue filled. This causes a permanent delay growth for all the traffic that traverses the queue. If the sender that causes the standing queue reacts to congestion in some way, it might be best to "flush" the queue, by quickly sending so much data into it that significant loss happens, in the hope that the sender that caused the problem reduces its rate.
An example protocol that produces such a standing queue, which even grows over time, is LEDBAT - famous for being a part of BitTorrent. This strange behavior of LEDBAT is documented here. More aggressive TCP variants such as CUBIC are more likely to produce standing queues than standard TCP, but even standard TCP can do so.
When this happens, users experience a delay growth that remains permanent as long as the transmission that caused the standing queue is active. Under such circumstances, "flushing" the queue could be a better solution.
The goal of this master thesis is to:
- document the problem, by reproducing it in a local testbed
- write a tool that
- runs as a background process, on an OS of your choice
- investigates traffic the delay between outgoing packets and their response with libpcap
- upon noticing a permanent delay growth that is likely to be due to a standing queue, sends out a large number of UDP packets to the destination used by the traffic for which the delay growth was noticed
- evaluate the tool's performance in a local testbed