Transcript 第十五讲

拥塞控制
E-mail：[email protected]
主页：xgxy.cug.edu.cn/rjgcx/lzw
1
TCP重温
相同的讲义, 更加聚焦….
“Know This”
2
TCP Header
此段中携带数
据的起始序列
号 (字节偏
移)
This is the
number of the
first byte of
data in
packet!
Source port
Destination port
Sequence number
Acknowledgment
HdrLen 0
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
Data
3
TCP Header
Acknowledgme
nt （应答）给出
接收到的最高有
序序列号后的序
列号
“下一个是什么”
Source port
Destination port
Sequence number
Acknowledgment
HdrLen 0
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
Data
4
3次握手
Passive
Open
Active
Open
Client (initiator)
Server
listen()
connect()
accept()
5
序列号
主机A
ISN (初始序列号)
序列号 =首字节
TCP Data
TCP
HDR
TCP Data
主机B
应答（ACK） 序列
号 = 下一个期望
的字节
TCP
HDR
6
数据和ACK在同一包中
• 序列号指示包中的数据
– A中的包将数据带到B
• ACK表示接收到另一方向的数据
– 从B中接收到的acking数据
7
TCP头
Source port
Destination port
Sequence number
TCP滑动窗口用于
接收数据的可用
缓冲区空间.
被解释成应答字
段值之外的偏移
Acknowledgment
HdrLen 0
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
Data
8
TCP段（Segment）
IP Data
TCP Data (segment)
TCP Hdr
IP Hdr
• IP包
– 不大于最大传送单元 (MTU)
– 如, 在以太网中最多1,500字节
• TCP包
– IP包中带有TCP头和数据
– TCP头 20字节长
• TCP段（segment）
– 不多于最大段尺寸 (MSS) 字节
– 例, 流中的最大1460个连续的字节
– MSS = MTU – (IP头) – (TCP头)
9
拥塞控制概述
Ask Questions!!!!!
10
流控制 vs 拥塞控制
• 流控制防止一个快速发送端冲垮一个慢速接收端
• 拥塞控制防止一组发送端冲垮网络
11
有关此问题的大量文献
• 80年代中Jacobson用拥塞控制“拯救”了Internet
• 理论有助益的极少几个主题之一; 网络中很多受挫
的数学家
• 现在很少人关注(瓶颈是访问链路?)
• …但离学术上解决还很远
– 例. battle over “fairness” with Bob Briscoe…
12
拥塞是自然的
• 因为Internet流量是跳变的（bursty）!
• 如果两个包同时到达
– 结点只能发送一个
– … 对另一个只能是缓存或者丢弃
• 如果多个包在短时间内到达
– 结点跟不上到达的速度
– … 延时, 并且缓存区可能最终溢出
13
负载与延时
带有突然到达的典型查询系统
Average
Packet delay
Average
Packet loss
Load
必须平衡效率 versus 延时和丢失
Load
14
谁管拥塞?
• 网络?
• 端主机?
• 两者?
15
答案
• 端主机调整发送率
• 基于网络的反馈
• 探测网络来测得拥塞的水平
– 当没有拥塞时加速
– 当有拥塞时减速
16
缺点
• 次优 (总比最优点高或低)
• 依赖于端系统的合作
• 复杂的动力学
– 所有端系统同时调整
– 大型,复杂动力系统
– 能够工作真是一个奇迹!
17
TCP拥塞控制基础
• 拥塞窗口 (CWND)
– 在飞行中的未应答字节的最大号码
– 接收端窗口拥塞控制等价物
– MaxWindow = min{拥塞窗口, 接收端窗口}
 典型地假定接收端窗口比cwnd大很多
• 适应拥塞窗口
– 当没有拥塞时增加: 优化探索
– 检测到拥塞时减少
18
侦测拥塞
• 网络能告诉源 (ICMP Source Quench)
– 危险, 因为在超载时，信号本身可能被丢弃(从而增加拥
塞)!
• 包延时上升 (负载-延时曲线的转折点)
– 小技巧: 噪声信号 (延时经常有大的变化)
• 包延时
– TCP已经需要检测失效安全信号
– 复杂性: 没有拥塞丢失(校验和错误)
19
不是所有的延时都一样
• 重复ACKs: 孤立丢失
– 仍然得到ACK
• 超时: 可能的灾难
– 重复包不够
– 必然遇到一些丢失
20
如何调整CWND?
• 大尺寸的窗口比小尺寸窗口结果更不好
– 大尺寸窗口: 包丢弃并重发
– 小尺寸窗口: 某种程度上带宽低一点
• 增加时线性进行（做加法）, 减少时翻倍(AIMD)
– 当未拥塞时，慢慢增加 (exploration)
– 拥塞时，快速减少
• 后面还会讲
21
AIMD
• 增加时做加法（Additive increase）
– 最后窗口数据成功收到后, 增加one MS
• 成倍减少
– 丢包时,拥塞窗口减半
22
导致TCP“Sawtooth”
Window
Loss
halved
t
23
AIMD 启动太慢!
开始时需要一个小CWND以避免网络负载过重.
Window
It could take a long
time to get started!
t
24
“Slow Start”阶段
•开始时一个小的拥塞窗口
–初始时, CWND是1 MSS
–因此,初始传输率是MSS/RTT
•这可能太浪费时间
–可能比实际带宽小很多
–线性增加会花费很长的时间加速
•Slow-start状态(事实上是“fast start”)
–发送端开始于慢的速率(因此而得名)
–… 但直至丢包前，以指数增加
25
慢启动行为
每次来回时间CWND翻倍
简单实现:
每次应答, CWND += MSS
Src
1
D
2
A
D D
3 4
A A
D D
8
D
A
D
A
A
A
Dest
26
慢启动与TCP Sawtooth
Window
Loss
Exponential
“slow start”
t
为何称为slow-start? 因为TCP最开始没有拥塞控制机制.
源开始时仅发送整个窗口大小的数据.
27
这样做非常成功
• 导致理论上的疑惑:
如果TCP拥塞控制是答案,
那么什么是问题呢？
• 不是关于优化,而是关于鲁棒性
– 很难处理（capture）…
28
拥塞控制细节
29
增加CWND
• 每次成功窗口，增加MSS
• 每接收到一个ACK，增加MSS一部分
• # packets (thus ACKs) per window: CWND / MSS
• 每个ACK的增量:
CWND += MSS / (CWND / MSS)
• 名词: 拥塞避免
– 非常缓慢地增加
30
快速重传
• 发送端看到3个重复应答（dupACKs）
• 成倍减少: CWND减半
31
快速重传的CWND
cwnd = 1
cwnd = 2
cwnd = 3
cwnd = 4
3 duplicate
ACKs
cwnd = 2
32
超时检测丢包
• 发送端开启一个时钟运行RTO秒
• 每收到新数据的应答重启时钟
– 知道此…..
• 如果时钟超时:
– 设置 SSTHRESH  CWND / 2 (“Slow-Start Threshold”)
– 设置 CWND  MSS
– 重传首个丢失包
– 执行慢启动只到 CWND > SSTHRESH
– 此后，切换到Additive Increase
33
减少小结
• 在通过dupacks检测到丢包时，将CWND减半
– “快速重传”
• 在超时后，减半CWND 直到1 MSS
– 设置ssthresh为cwnd/2
• 永远不要将CWND减到比1 MSS还低
34
增加小结
• “Slow-start”: 每次收到ack对cwnd增加MSS
• 在以下任一情况下，离开slow-start领域:
– cwnd > SSThresh
– 丢包
• 进入AIMD领域
– 对每个窗口的应答数据，增加MSS
35
在超时后，重复Slow Start
Window
Fast
Retransmission
Slow start in operation until
it reaches half of previous
CWND, I.e., SSTHRESH
Timeout
SSThresh
Set to Here
t
Slow-start重启: CWND回到1 MSS, 但利用之前已知的
CWND值.
36
更高级的快速重启
• 设置 ssthresh 为 cwnd/2
• 设置 cwnd 为 cwnd/2 + 3
– 针对已经看到的3次重复应答(ack)
• 对每个附加的重复ACK，对cwnd增加1 MSS
• 在接收到新的ACK后, 将cwnd重置为ssthresh
37
5 Minute Break
Questions Before We Proceed?
38
Throughput Equation
In what follows refer to cwnd in units of MSS
39
简单模式计算 (已知!)
• 假定当cwnd到达W时，发生丢失
– 通过快速重传恢复
• 窗口: W/2, W/2+1, W/2+2, …W, W/2, …
– W/2 RTTs, then drop, then repeat
• 平均吞吐量: .75W(MSS/RTT)
– 每隔 (W/2)*(3W/4)丢一个包
– 丢包率 p = (8/3) W-2
• 吞吐量 = (MSS/RTT) sqrt(3/2p)
40
Why AIMD?
In what follows refer to cwnd in units of MSS
41
三个拥塞控制挑战
• 单个流调整以适应带宽瓶颈
– 没有任何先验知识
– Could be a Gbps link; could be a modem
• 单个流调整以适应带宽变化
– 当带宽减少时, 必须降低发送率
– 当带宽增加时, 必须增加发送率
• 多个流共享带宽
– 必须避免网络超载
– 并且，在多个流中“公平地”共享带宽
42
问题1: 单个流, 固定带宽
• 希望得到可用带宽的一阶估计
– 假定带宽固定
– 忽略其他流的存在
• 希望开始时慢速,但快速增加直到产生丢包
(“slow-start”)
• 调整:
– cwnd 初始时设置为 1 (MSS)
– 在接收到ACK时cwnd++
43
Slow-Start的问题
• Slow-start会产生许多丢包
– 约等于cwnd的大小 ~ BW*RTT
• 例:
– 某个点, cwnd 足够填满“管道pipe”
– 下次RTT, cwnd 将其之前的值翻倍
– 所有多余的包被丢弃!
• 一旦对带宽有了一个粗略的估计，就需要进行更精
细的调整
– 余下的设计讨论集中于此
44
问题2: 单个流,可变带宽
希望跟踪可用带宽
• 在其当前值附近振荡
• 如果从未发过比当前速率更高的,你将不知道是否有
更多的带宽可用
可能的变化: (in terms of change per RTT)
• 成倍增加或减少:
cwnd
cwnd * / a
cwnd
cwnd +- b
• 加法增加或减少:
45
四种可能
• AIAD: 缓慢增加,缓慢减少
• AIMD: 缓慢增加,快速减少
• MIAD: 快速增加,缓慢减少
– too many losses: eliminate
• MIMD: 快速增加,快速减少
46
问题3: 多个流
• 希望稳定状态时是 “公平的fair”
• 关于公平有多种说法, 但这里仅需要两个相同的流
最后带宽相同
• 这就淘汰了MIMD和AIAD
– 我们后面会看到…
• AIMD 是唯一余下的解!
– 并非真的, 但已经足够接近了….
47
缓冲和动态窗口
A
B
x
C = 50 pkts/RTT
•
无拥塞  x每次RTT增加一个包。
•
拥塞
 成倍减少x
Rate (pkts/RTT)
60
50
40
30
Backlog in router (pkts)
Congested if > 20
20
10
487
460
433
406
379
352
325
298
271
244
217
190
163
136
109
82
55
28
1
0
48
AIMD 动态共享
x1
x2
A
D
B
E
无拥塞  x每次RTT增加一个包。
拥塞
 成倍减少x
60
Rates equalize  fair share
50
40
30
20
10
487
460
433
406
379
352
325
298
271
244
217
190
163
136
109
82
55
28
1
0
49
AIAD 动态共享
x1
x2
A
D
B
E
• 无拥塞  x每次RTT增加一个包。
• 拥塞
 x每次RTT减少一个包
60
50
40
30
20
10
487
460
433
406
379
352
325
298
271
244
217
190
163
136
109
82
55
28
1
0
50
拥塞控制的简单模型
• 两路TCP连接
2 user example
– 传输率 x1 and x2
• 效率: 和近似 1
User 2: x2
• 当sum>1时拥塞
overload
underload
• 公平性: x收敛
Efficiency
line
User 1: x1
51
Example
1
fairness
line
Efficient: x1+x2=1
Fair
• 总带宽 1
User 2: x2
Congested:
x1+x2=1.2
(0.2, 0.5)
(0.7, 0.5)
(0.5, 0.5)
Inefficient:
x1+x2=0.7
(0.7, 0.3)
Efficient: x1+x2=1
Not fair
User 1: x1
efficiency
line
1
52
AIAD
(x1h-aD+aI),
x2h-aD+aI))
• 增加: x + aI
• 减少: x - aD
(x1h,x2h)
User 2: x2
• 不收敛到公平
fairness
line
(x1h-aD,x2h-aD)
efficiency
line
User 1: x1
53
MIMD
fairness
line
• 增加: x*bI
(x1h,x2h)
• 减少: x*bD
User 2: x2
• 未收敛到公平
(bIbDx1h,
bIbDx2h)
(bdx1h,bdx2h)
efficiency
line
User 1: x1
54
AIMD
(x1h,x2h)
• 增加: x+aD
(bDx1h+aI,
bDx2h+aI)
User 2: x2
• 减少: x*bD
• 收敛到公平
fairness
line
(bDx1h,bDx2h)
efficiency
line
User 1: x1
55
其它拥塞控制主题
56
AIMD的问题
• 公正: Tput 与RTT成反比
• 公正: Tput 与流的个数成正比
• 公正依赖于合作
• 高速时无法工作 (HW3)
– 从丢包恢复太长时间
• 早期随机丢包
57
其他主题
• TCP兼容性
– 每个人都需要使用拥塞控制来实现共享公正
• 基于公式的拥塞控制
• Signaling congestion without packet drops
– ECN
• 涉及拥塞控制的路由器
– 确保公正 (对单个标准不必要)
– 计算公平共享 (而非平衡)
• 扩展TCP到更高速度
• 经济学模型 (Kelly)
58