TCP/IP之拥塞控制拥塞的成因和代价拥塞控制的方法TCP拥塞控制

拥塞(Congestion) 给一个非正式定义就是：“太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理” 如果网络中发生了拥塞，会出现如下表现：

• 分组丢失（路由器缓存溢出）
• 分组延迟过大（在路由器缓存中排队）

和可靠数据传输一样都是网络领域中的top-10的问题。

拥塞现象是指到达[通信子网]中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现[死锁]现象。这种现象跟公路网中经常所见的交通拥挤一样，当节假日公路网中车辆大量增加时，各种走向的车流相互干扰，使每辆车到达目的地的时间都相对增加（即延迟增加）,甚至有时在某段公路上车辆因堵塞而无法开动(即发生局部[死锁]

我们先讨论一下拥塞的成因和代价

拥塞的成因和代价

我们通过假设不同的场景渐进式分析拥塞的成因和代价

场景一

我们假设

• 两个senders,两个receivers
• 一个路由器, 无限缓存
• 没有重传

image.png

我们假设原始数据的发送速度为in,到达接受方的速度为out，由于路由器的速度限制，即使无限缓存，到达的最大速度也无法超过路由器的速度

image.png

即使发送速度再快，到达速度也无法超过路由器的速度，所以时延在拥塞发生的时候会无限增大。

• 拥塞时分组延迟太大
• 达到最大throughput

场景2

我们假设

• 一个路由器, 有限buffers
• Sender重传分组

image.png

可以分为一下几种情况讨论

• 情况a: Sender能够通过某种机制获知路由器buffer信息，有空闲才发

image.png

• 情况b: 丢失后才重发，显然这样到达速度会减小

image.png

• 情况c：分组丢失和定时器超时后都重发，显然到达速度进一步减小

image.png

拥塞的代价:

• 对给定的”goodput”，要做更多的工作 (重传)
• 造成资源的浪费

场景三

• 四个发送方
• 多跳
• 超时/重传

image.png

随着拥塞的严重，整个网络可能陷入瘫痪，到达速度趋近于0，类似于死锁的状态

image.png

拥塞的另一个代价:

• 当分组被drop时，任何用于该分组的“上游”传输能力全都被浪费掉，相当于白传了，浪费了资源和传输能力

拥塞控制的方法

端到端拥塞控制：

• 网络层不需要显式的提供支持
• 端系统通过观察loss，delay等 网络行为判断是否发生拥塞
• TCP采取这种方法 *网络辅助的拥塞控制： *路由器向发送方显式地反馈网络 拥塞信息 *简单的拥塞指示(1bit)：SNA,DECbit, TCP/IP ECN, ATM) *指示发送方应该采取何种速度

案例：ATM ABR拥塞控制

• ABR：available bit rate  “弹性服务”  如果发送方路径“underloaded” 使用可用带宽  如果发送方路径拥塞 将发送速率降到最低保障速率
• RM(resource management)cells  发送方发送  交换机设置RM cell位(网络辅助) • NI bit: rate不许增长 • CI bit: 拥塞指示  RM cell由接收方返回给发送方

TCP拥塞控制

TCP拥塞控制的基本原理

Sender限制发送速率

image.png

CongWin可以动态调整以改变发送速率，并且反映所感知到的网络拥塞。

那么问题来了，如何感知网络拥塞：

• Loss事件=timeout或3个重复ACK
• 发生loss事件后，发送方降低速率

感知到网络拥塞后，需要动态调整发送速率，以减轻网络的拥塞状况，如何调整发送速率，一般有两个方法：

• 加性增—乘性减: AIMD
• 慢启动: SS

加性增—乘性减: AIMD

顾名思义，这种方法就是先简单的增加，遇到拥塞的情况，就乘性减少。 原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生loss。 Additive Increase: 每个RTT将CongWin增大一个MSS——拥塞避免 Multiplicative Decrease: 发生loss后将CongWin减半。 AIMD方法会使congwin呈锯齿状的波动

image.png

首先慢慢增加，当遇到拥塞时，减为一半，然后又继续慢慢增加，直到遇到拥塞后又减为一半，这样往复就会出现锯齿状的波动。

TCP慢启动: SS

我们考虑下面这种情况： TCP连接建立时， CongWin=1  例：MSS=500 byte, RTT=200msec  初始速率=20k bps 我们发现在这种情况下，可用带宽可能远远高于初始速率，如果我们采用加性增的方法就太慢了，我们希望快速增长到可用带宽。 这就慢启动算法的思想： 当连接开始时，指数性增长。指数性增长。每个RTT将CongWin翻倍。收到每个ACK进行操作。初始速率很慢，但是快速攀升。

image.png

那么问题来了，我们什么时候才进行线性增长来避免拥塞控制？ 我们通过设置一个变量 Threshold，Loss事件发生时, Threshold被设为Loss事件前CongWin值的1/2。然后如果cogwin到了Threshold，就开始线性增长。

image.png

如图所示，初始的Threshold变量为8，所以当指数增长大于等于8的时候，就开始线性增长，然后直到发生loss事件，Threshold变为发生loss事件时的一半，也就是6，然后继续指数增长到Threshold，又开始线性增长。

那么我们如何判断loss事件的发生呢？ 我们分为两种情况来处理：

• 3个重复ACKs: CongWin切到一半，然后线性增长
• Timeout事件: CongWin直接设为1个MSS，然后指数增长，达到threshold后, 再线性增长

我们想想这样做的原因，因为3个重复ACKs表示网络还能够传输一些 segments ，timeout事件表明拥塞更为严重。

慢启动算法：

Th = ?
CongWin = 1 MSS
/* slow start or exponential increase */
While (No Packet Loss and CongWin < Th) {
send CongWin TCP segments
for each ACK increase CongWin by 1
}
/* congestion avoidance or linear increase */
While (No Packet Loss) {
send CongWin TCP segments
for CongWin ACKs, increase CongWin by 1
}
Th = CongWin/2
If (3 Dup ACKs) CongWin = Th;
If (timeout) CongWin=1;

 一个TCP连接总是以1 KB的最大段长发送TCP段，发送方有足够多的数据要发 送。当拥塞窗口为16 KB时发生了超时，如果接下来的4个RTT（往返时间）时 间内的TCP段的传输都是成功的，那么当第4个RTT时间内发送的所有TCP段 都得到肯定应答时，拥塞窗口大小是多少？  解：threshold=16/2=8 KB, CongWin=1 KB, 1个RTT后， CongWin=2 KB ，2 个RTT后， CongWin=4 KB ，3个RTT后， CongWin=8 KB ，Slowstart is over; 4个RTT后， CongWin=9 KB