FLOWER — Fuzzy Lower-than-Best-Effort Transport Protocol
Dedicated to carrying non-critical traffic, the Lower-than-Best-Effort (LBE) service seeks to use, in a non-intrusive manner, the remaining network capacity unused by best-effort flows.
Hence, LBE service leads to many applications such as data backup, prefetching, Internet content distribution, peer-to-peer file transfer, and more .
Among the different transport protocols providing an LBE service, Low Extra Delay Background Transport (LEDBAT)  is the most widely deployed protocol.
Developed by BitTorrent and later standardized by the Internet Engineering Task Force (IETF), LEDBAT rapidly gains notoriety and plays an important role in Internet traffic.
Unfortunately, the tuning of LEDBAT parameters is revealed to highly depend on network conditions , .
In the worst scenario, LEDBAT flows can starve other traffic in case of misconfiguration.
LEDBAT also suffers from an intra-unfairness issue, called the latecomer advantage .
Therefore, we design Fuzzy LOWer-than-Best-EffoRt Transport (FLOWER) , a new delay-based transport protocol, as an alternative to LEDBAT.
By using a fuzzy controller to modulate the sending rate, FLOWER aims to solve LEDBAT issues while fulfilling the role of an LBE protocol.
Our simulation results show that FLOWER can carry LBE traffic in a wide range of network conditions where LEDBAT usually fails.
2. Evaluation of FLOWER
2.1. Interaction with TCP
Figure 1a illustrates the good LBE behavior of FLOWER in the presence of TCP, in the case where B = BDP.
Clearly, the fuzzy controller with the loss detection scheme allows FLOWER to be LBE compliant.
In this standard configuration, LEDBAT does not behave as an LBE protocol and is too aggressive as shown in Figure 1b.
This figure also illustrates that the LEDBAT P-type controller does not react correctly to congestion events.
2.2. Intra-protocol fairness
Figure 2b shows the LEDBAT latecomer issue.
The first LEDBAT flow starts when the bottleneck queue is empty, and as a result, senses a base delay.
When the second LEDBAT flow starts at t = 20 s, the queue is filled with about 50 packets.
Consequently, the second flow estimates a higher base delay including the queuing delay of the first one.
Since its estimated queuing delays are below the target delay, the second flow raises its sending rate.
As a result, the first one senses an increasing queuing delay and begins to decelerate.
Finally, it reaches its minimum rate at t = 131 s as shown in Figure 2b.
On the contrary, FLOWER does not inherit this latecomer issue thanks to the loss detection scheme as shown in Figure 2a.
Two FLOWER flows can now share fairly the link capacity.
FLOWER code is based on ns-2 implementations of LEDBAT and TCP Vegas and is available for ns-2 and GNU/Linux