Evaluation LEDBAT congestion control on ns3

 LEDBAT[1]是Bittorrent客户端上使用的一种拥塞控制机制。大公司在开发基于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.delay
base_delay = min(base_delay, current_delay)
queuing_delay = current_delay - base_delay
off_target = TARGET - queuing_delay
cwnd += 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管制的。[2]给出了LEDBADT作为TCP的拥塞控制机制在linux上的实现代码。

---

  I evaluate the performance ledbat on ns3 platform.
 A point to point channle is built (3Mbps, 50ms propgation dealy，100ms*3Mbps buffer length). Three flows are tested.

The three flows all take ledbat for rate control.

 The seding rate of all flows：

 packets receiving rate got form receiver（calculated at every five seconds）:

 one way delay of received packets:

When two ledbat flows share links with a reno flow

The flow3 takes reno for rate control.
 The seding rate of all flows：

 packets receiving rate got from receiver（calculated at every five seconds）:

 The third flow (reno) can get higher rate.

test on link with longer buffer

 Another link is tested with longer buffer (3Mbps, 50ms propgation dealy，200ms*3Mbps buffer length).
 Unexpected behaviro is observerd. Flow2 keeps yielding and flow3 keeps occupying. And I do not found any theory to analysis the reason behind such rate oscillation.
 The seding rate of all flows：

 one way delay of received packets:

[1] LEDBAT: The New BitTorrent Congestion Control Protocol
[2] LEDBAT implements in Linux on TCP
[3] simulation code on ledbat