基于UDP拥塞控制-LEDBAT

    LEDBAT[1]是Bittorrent客户端上使用的一种拥塞控制机制。大公司在开发基于UDP的网络应用时，应该建立拥塞控制机制。因为网络中的数据流应该遵从以下原则：不给当前的网络制造麻烦；保证数据流的带宽公平性，不恶意竞争带宽。

    P2P应用不知道安慰了多少宅男寂寞无聊的夜晚，在互联网中的流量中p2p流量中占有很大的份额。以至于当年有些ISP要封锁P2P应用。当年Bittorrent要使用UDP进行数据传输时，在网络中引起了骚动。鉴于Bittorrent在网络中占用的流量，再加上无任何拥塞控制机制的UDP协议，Bittorrent会不会导致再次出现1986年的网络崩溃。于是建立在UDP之上的拥塞控制机制LEDBAT横空出世。以上是引子，宅男寂寞无聊的夜，我不关心。

    目标：1在瓶颈链路没有其他流的情况下，能够占满带宽，充分利用网络。2在没有其他数据流的时候，保证较低的排队时延；因TCP流的窗口增加，引入排队时延的情况下，尽量不要增加排队时延。3当TCP竞争带宽的时候，LEDBAT主动出让带宽，降低窗口(The LEDBAT considers itself to be junior to TCP)。

    LEDBAT仍是基于窗口的速率控制，但是比TCP更早地感知网络的拥塞情况，以便更好地做出回应。LEDBAT采用单向时延，估计网络中的排队情况。一个数据包在网络的传输经历的时延有三部分组成：processing delay,propagation delay, queue delay。在网络中不存在排队的时候，没有排队时延，数据包经历的时延最小。

    LEDBAT采用单向时延来衡量网络的拥塞状况，单向时延相比RTT的优势，就是不用考虑ack返回时经历的回路时延。但是单向时延不是够准确测量，因为收发端时钟不同步。LEDBAT的单向时延是这样计算的，接收端接收到数据，回复ack，ack中携带时间差，ack.delay=localtimestamp（接收端收到数据时的本地时间）-remotetimestamp(f发送端在发送时的时戳)。将数据包传输过程中的最小的ack.delay作为base_delay,排队时延queue_delay=current_delay-base_delay，这个差值，就解决了sender、receiver之间的时钟不同步问题。具体的接收端窗口变化如下[1]：

current_delay = acknowledgement.delaybase_delay = min(base_delay, current_delay)queuing_delay = current_delay - base_delayoff_target = TARGET - queuing_delaycwnd += GAIN * off_target / cwnd

    解释下，TARGET就是一个设定的参数值，GAIN为1/TARGET，在queue_delay较小时，第四个是窗口变化公式，保证窗口增长，快速逼近瓶颈链路带宽。GAIN的存在保证LEDBAT不比TCP的窗口了增长速度快。在最好的情况下(queue_delay=0),LEDBAT也是每个RTT，cwnd的大小增加1。LEDBA相比基于丢包的的TCP拥塞控制机制，对于网络的拥塞感知要早。在queue_delay=2*TARGET时，每经一个RTT，cwnd减少1。就是说在队列时延增加的情况下，但是还未到达路由器的队列丢包阈值，TCP还处在拥塞避免阶段，tcp每个RTT，窗口增1，LEDBAT窗口减1。LEDBAT向TCP出让带宽。
   LEDBAT这种机制，保证网络中有带宽可用的时候，尽快占用，网络中存在TCP流的时候，向TCP带宽。The LEDBAT considers itself to be junior to TCP。LEDBAT不向TCP流竞争，因为它是p2p应用中的，过多地竞争带宽，是要被ISP管制的。[3]给出了LEDBADT作为TCP的拥塞控制机制在linux上的实现代码。

[1]LEDBAT: The New BitTorrent Congestion Control Protocol

[2]RFC 6817 - Low Extra Delay Background Transport (LEDBAT)

[3]LEDBAT implements in Linux on TCP

[4]LEDBAT on ns2