Bufferbloat solution

Solution to buffer bloat problem can be divided into two categories

1. Active Queue Management        ( AQM )

2. End to End Congestion Control  ( E2E )

AQM technique such as RED (Random Early Detection) or DRR (DeficitRound-Robin) selectively schedule/mark/drop packets to both reduce size.

Random early detection , also known as random early discard or random early drop. RED monitors the average queue size and drops (or marks when used in conjunction with ECN) packets based on statistical probabilities. If the buffer is almost empty, all incoming packets are accepted. As the queue grows, the probability for dropping an incoming packet grows too. When the buffer is full, the probability has reached 1 and all incoming packets are dropped. In the conventional tail drop algorithm, a router or other network component buffers as many packets as it can, and simply drops the ones it cannot buffer. If buffers are constantly full, the network is congested. Tail drop distributes buffer space unfairly among traffic flows. RED addresses these issues.

Despite multiple AQM techniques, adoption has been slow so far. E2E solution instead generally employ a delay based controller : TCP Vegas,TCP-LP and LEDBAT.TCP-Vegas is one of the first protocol that was know to have a smaller sending rate than standard TCP when both protocol share a bottleneck.However, while TCP Vegas aims at being more efficient than standard TCP, both NICE,TCP-LP and LEDBAT aims at lower priority with respect to TCP. The main difference b/w NICE,Vegas,TCP-LP and LEDBAT is that the former two react on round-trip-delay (RTT), while the latter two on one-way-delay (OWD) difference. OWD measurement is preferred  to a RTT measurement as congested reverse path may also result in an erroneous assessment of the congestion state of the forward path. Our research topic is LEDBAT which E2E solution for gauging the urgent issue of buffer bloat delays.

Low Extra Delay Background Access (LEDBAT) implement a distributed congestion control mechanism tailored for the transport of non-interactive traffic with lower than Best Effort (i.e lower than TCP) priority. it operate under the assumption that the queue delay at end-to-end delay and the access router does not employ action queue management. 
The need to adopt LEDBAT motivated in remarking the difference, in terms of bandwidth requirements, b/w interactive application and "background" application.

The main design goal of LEDBAT are:

• Saturate the bottleneck when no other traffic is present, but quickly yield to TCP and other UDP real time traffic sharing the same bottleneck queue.
• Keep delay low when no other traffic is present and add little to the queuing delay induced by TCP traffic .
• Operate well in drop-tail FIFO networks, but use explicit congestion notification (e.g. ECN) where available.

 Intuitively, to saturate the bottleneck it is necessary that queue build up: otherwise when the queue is empty, at least sometimes no data is being transmitted and the link is under-exploited. At the same time, in order to operate friendly toward interactive applications, the queuing delay needs to be low as possible: LEDBAT is therefore designed to introduce non-zero target queuing delay. In order to achieve this goal, LEDBAT follow a simple strategy, first of all it exploits the ongoing data transfer to estimate the one-way delay, by time stamping packets from which it derive an estimate of the queuing dealy on forward path. Using one-way delay instead round-trip time has the main advantage of preventing unrelated traffic on the background path form interfering with data transmission. Second it employs a linear controller derivative to modulate the congestion window and consequentially the sending rate according to measured delay.