TCP拥塞

TCP拥塞控制机制

端到端的拥塞控制机制

• 路由器不向主机有关拥塞的反馈信息
  • 路由器的负担较轻
  • 符合网络核心简单的TCP/IP架构原则
• 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作

拥塞控制的几个问题

• 如何检测拥塞
  • 轻微拥塞
  • 拥塞
• 控制策略
  • 在拥塞发送时如何动作，降低速率
    • 轻微拥塞，如何降低
    • 拥塞时，如何降低
  • 在拥塞缓解时如何动作，增加速率

TCP拥塞感知

发送端如何探测到拥塞

• 某个段超时了（丢失事件 ）：拥塞
  • 超时时间到，某个段的确认没有来
  • 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
  • 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
  • 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的

• 有关某个段的3次重复ACK：轻微拥塞
  • 段的第1个ack，正常，确认绿段，期待红段
  • 段的第2个重复ack，意味着红段的后一段收到了，蓝段乱序到达
  • 段的第2、3、4个ack重复，意味着红段的后第2、3、4个段收到了 ，橙段乱序到达，同时红段丢失的可能性很大（后面3个段都到了， 红段都没到）
  • 网络这时还能够进行一定程度的传输，拥塞但情况要比上面好

TCP速率控制方法

如何控制发送端发送的速率

• 维持一个拥塞窗口的值(主要手段) ：CongWin （表示发送方往网络中的注入字节数）
• 发送端限制 已发送但是未确认 的数据量（的上限）: LastByteSent - LastByteAcked ≤ CongWin
• 从而粗略地控制发送方的往网络中注入的速率

• CongWin是动态的，是感知到的网络拥塞程度的函数
  • 超时或者3个重复ack，CongWin下降
    • 超时时：CongWin降为1MSS，进入SS阶段然后再倍增到 CongWin(原) / 2（每个RTT），从而进入CA阶段
    • 3个重复ack ：CongWin降为CongWin/2,CA阶段
  • 否则（正常收到Ack，没有发送以上情况）：CongWin跃跃欲试上升（这是为了满足“在不发生拥塞的情况下提高吞吐率”的目的）

TCP拥塞控制和流量控制的联合动作

联合控制的方法

• 发送端控制发送但是未确认的量同时也不能超过接收窗口，满足流量控制要求
  • SendWin = min { CongWin , RecvWin }
  • 同时满足 拥塞控制和流量控制要求

TCP慢启动

• 连接刚建立, CongWin = 1 MSS
  • 如: MSS = 1460bytes & RTT = 200 msec
  • 初始速率 = 58.4kbps
• 可用带宽可能 >> MSS/RTT
  • 应该尽快加速，到达希望的速率
• 当连接开始时，指数性增加发送速率，直到发生丢失的事件
  • 启动初值很低
  • 但是速度很快
• 当连接开始时，指数性增 加（每个RTT）发送速率 直到发生丢失事件
  • 每一个RTT， CongWin加倍
  • 每收到一个ACK时， CongWin加1（相当于每个RTT，CongWin加倍）
  • 慢启动阶段：只要不超时或 3个重复ack，一个RTT， CongWin加倍

• 总结:
  • 初始速率很慢，但是加速却是指数性的
  • 指数增加，SS时间很短，长期来看可以忽略

AIMD

• 乘性减: 丢失事件后将CongWin降为1(ss阶段通常可忽略，故相当于直接减少到 CongWin/2 )，将CongWin/2作为阈值，进入慢启动阶段（倍增直到 CongWin/2）
• 加性增： 当 CongWin >阈值时，一个 RTT 如没有发生丢失事件，将 CongWin 加1MSS : 探测（也就是主键添加，探测是否到达阈值）

改进

• Q：什么时候应该将指数性增长变成线性？
• A：在超时之前，当CongWin变成上次发生超时的窗口的一半

实现:

• 变量：Threshold
• 出现丢失（超时或者3个ACK），Threshold设置成CongWin的1/2

总结：TCP拥塞控制

• 当CongWin＜Threshold, 发送端处于慢启动阶段（ slow-start）, 窗口指数性增长.
• 当CongWin > Threshold, 发送端处于拥塞避免阶段 （congestion-avoidance）, 窗口线性增长.
• 当收到三个重复的ACKs (triple duplicate ACK), Threshold设置成 CongWin/2， CongWin=Threshold+3.
• 当超时事件发生时timeout, Threshold=CongWin/2 CongWin=1 MSS，进入SS阶段

TCP发送端拥塞控制

事件	状态	TCP发送端行为	解释
以前没有收到ACK的data，被ACKed	慢启动(SS)	CongWin = CongWin + MSS,If (CongWin > Threshold)，状态变成“CA”	每一个RTT CongWin 加倍
以前没有收到ACK的data，被ACKed 拥塞避免(CA)	CongWin = CongWin+MSS * (MSS/CongWin)	线性增加, 每一个RTT对CongWin 加一个1 MSS
通过收到3个重复的ACK，发现丢失的事件	SS or CA	Threshold = CongWin/2, CongWin = Threshold+3, 状态变成“CA”	快速重传, 实现乘性的减，CongWin 没有变成1MSS.
超时	SS or CA	Threshold = CongWin/2,CongWin = 1 MSS,状态变成“SS”	进入slow start
重复的ACK	SS or CA	对被ACKed 的segment， 增加重复ACK的计数	CongWin and Threshold不变

TCP拥塞控制FSM

TCP吞吐量

TCP的平均吞吐量是多少，使用窗口window尺寸W和RTT来 描述?
(忽略慢启动阶段，假设发送端总有数据传输)

• W：发生丢失事件时的窗口尺寸（单位：字节）
  • 平均窗口尺寸（#in-flight字节）：3/4W
  • 平均吞吐量：一个RTT时间吞吐3/4W， avg TCP thruput = 3/4 * (W/RTT) bytes/sec
    由下图所示，w/2→w所需要的时间是2RTT

因此 T = (w/2 + w) / (2*RTT) = 3w/4RTT

TCP 公平性

公平性目标: 如果 K个TCP会话分享一个链路带宽为R的 瓶颈，每一个会话的有效带宽为 R/K

2个竞争的TCP会话:

公平性和 UDP

• 多媒体应用通常不是用 TCP
  • 应用发送的数据速率希望 不受拥塞控制的节制
• 使用UDP:
  • 音视频应用泵出数据的速率是恒定的, 忽略数据的丢失
    也就是UDP会抢占TCP的资源

公平性和并行TCP连接

• 2个主机间可以打开多个并行的TCP连接
• 例如: 带宽为R的链路支持了 9个连接;
  • 如果新的应用要求建1个TCP连接,获得带宽R/10
  • 如果新的应用要求建11个TCP连接,获得带宽R/2