TCP拥塞控制

TCP拥塞控制：机制

【TCP采用的是端到端的拥塞控制，ATM采用的是网络辅助信息的拥塞控制】

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

拥塞控制的几个问题

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

TCP拥塞控制：拥塞感知

发送端如何探测到拥塞？

• 某个段超时了（丢失事件）：拥塞
  • 超时时间到，某个段的确认没有来
  • 原因1：网络拥塞（某个路由器缓存区没空间了，被丢弃）概率大
  • 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小【段所在的分组，分组所在的帧，在传输的过程当中由于收到了干扰，0变成了1，1变成了0，然后没有通过某些级别的校验，而被抛弃掉】
  • 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的【原因2的情况，网络没有发生拥塞，这时候不应该降低发送速度，如果降低发送速度，网络当中可用的有效吞吐量就没有把他用起来，但是这种情况相对来说非常少】

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

TCP拥塞控制：速率控制方法

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

• 维持一个拥塞窗口的值：CongWin【以字节为单位，发送方在对方未确认的情况下，可以往网络当中注入多少个字节】【除上往返延迟（RTT），就是拥塞控制限制了发送方单位时间内能够往网络注入多少字节的数量】
• 发送端限制已发送但是未确认的数据量（的上限）：
  • LastByteSent-LastByteAcked ≤ CongWin
• 从而粗略地控制发送方的往网络中注入的速率

• CongWin是动态的，是感知到的网络拥塞程度的函数
  • 超时或者3个重复ack，CongWin↓
    • 超时时：CongWin降为1MSS，进入SS阶段（慢启动阶段）然后再倍增到CongWin/2（每个RTT），从而进入CA阶段
    • 3个重复ack：CongWin将为CongWin/2，CA阶段（拥塞避免阶段）
  • 否则（正常收到Ack，没有发送以上情况）：CongWin跃跃欲试↑
    • SS阶段：加倍增加（每个RTT）
    • CA阶段：线性增加（每个RTT）

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

【拥塞窗口值决定了由于拥塞控制的因素，发送方一次可以向网络当中，在未经确认的情况下往网络当中注入字节的数量，对方接收窗口空闲的尺寸告诉发送方，在未确认的情况下，我能够向对方发送多少字节，到了对方一定有缓冲区可以存下，从而满足流量控制的功能】

联合控制的方法：

• 发送端控制发送但是未确认的量同时也不能够超过接收窗口，满足流量控制要求
  • SendWin = min{CongWin，RecvWin} 【RecvWin是对方告知的，通过流量控制的机制捎带，在对方传送给我的段当中有一个RecvWin的字段，这个字段描述了它的接收缓冲区空闲的大小】【CongWin和RecvWin两个值的最小值是发送方在未确认的情况下可以够往网络当中注入字节的数量】
  • 同时满足 拥塞控制和流量控制要求

TCP拥塞控制：策略概述

拥塞控制策略：

• 慢启动
• AIMD：线性增、乘性减少
• 超时事件后的保守策略

TCP慢启动

• 连接刚建立，CongWin = 1MSS
  • 如：MSS = 1460bytes & RTT = 200 msec
  • 初始速率 = 58.4kbps
• 可用带宽可能 >> MSS/RTT
  • 应该尽快加速，到达希望的速率
• 当连接开始时，指数性增加发生速率，直到发生丢失的事件
  • 启动初值很低
  • 但是速度很快
• 当连接开始时，指数性增加（每个RTT）发送速率直到发生丢失事件
  • 每一个RTT，CongWin加倍
  • 每收到一个ACK时，CongWin加1（why）【每收到一个确认，拥塞窗口值加1，从而每一个RTT，拥塞窗口值加倍。所以每收到一个ACK时，CongWin加1和每一个RTT，CongWin加倍概念上是一样的】
  • 慢启动阶段：只要不超过或3个重复ack，一个RTT，CongWin加倍
• 总结：初始速率很慢，但是加速却是指数性的
  • 指数增加，SS时间很短，长期来看可以忽略

【指数增加网络一定会发送拥塞】

TCP拥塞控制：AIMD

乘性减：

丢失事件后将CongWin降为1，将CongWin/2作为阙值，进入慢启动阶段（倍增直到CongWin/2）

加性增：

当CongWin > 阙值时，一个RTT如没有发生丢失事件，将CongWin加1MSS：探测

• 当收到3个重复的ACKs：
  • CongWin减半
  • 窗口（缓存区大小）之后线性增长
• 当超时事件发生时：
  • CongWin被设置成1MSS，进入SS阶段
  • 之后窗口指数增长
  • 增长到一个阙值（上次发生拥塞的窗口的一半）时，再线性增加

思路：

• 3个重复的ACK表示网络还有一定的段传输能力
• 超时之前的3个重复的ACK表示“警报”

改进

Q：什么时候应该将指数性增长变成线性？

A：在超时之前，当CongWin变成上次发生超时的窗口的一半

实现：

• 变量：Threshold
• 出现丢失，Threshold设置成CongWin的1/2

总结：TCP拥塞控制

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

TCP发送端拥塞控制

总结：TCP拥塞控制

TCP吞吐量

• TCP的平均吞吐量是多少，使用窗口window尺寸W和RTT来描述？
  • 忽略慢启动阶段，假设发送端总有数据传输
• W：发生丢失事件时的窗口尺寸（单位：字节）
  • 平均窗口尺寸（#in-flight字节）：3/4W [(W/2 + W) / 2 = 3/4 W]
  • 平均吞吐量：RTT时间吞吐3/4W

TCP未来：TCP over “long, fat pipes”

• 例如：1500字节/段，100ms RTT，如果需要10Gbps吞吐量
• T = 0.75 W/R -> W = TR/0.75 = 12.5M字节 = 83333段
• 需要窗口大小 W = 83333 in-flight段

TCP公平性

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

【每个会话获得1/R带宽】

为什么TCP是公平的？

2个竞争的TCP会话：

• 加性增加，斜率为1，吞吐量增加
• 乘性减，吞吐量比例减少

公平性和UDP

• 多媒体应用通常不是用TCP
  • 应用发送的数据速率希望不受拥塞控制的节制
• 使用UDP
  • 音视频应用泵出数据的速率是恒定的，忽略数据的丢失
• 研究领域：TCP友好性【UDP对TCP来说是不友好的】

公平性和并行TCP连接

• 2个主机间可以打开多个并行的TCP连接
• Web浏览器
• 例如：带宽为R的链路支持了9个连接；
  • 如果新的应用要求建1个TCP连接，获得带宽R/10
  • 如果新的应用要求建11个TCP连接，获得带宽R/2【相对公平】

Explicit Congestion Notification（ECN）

网络辅助拥塞控制：

• TOS字段中2个bit被网络路由器标记，用于指示是否发送拥塞
• 拥塞只是被传送到接收主机
• 在接受方-到发送方的ACK中，接收方（在IP数据报中看到了拥塞指示）设置ECE bit，指示发送方发生了拥塞