网络通信(Telematik)-传输层协议(Transportprotokoll)2

网络阻塞(Stau im Internet)

网路中传输的数据包过多，导致超出网路的承受能力。

简单的队列管理

Router:
当router的Puffer满了，那么下一个到达的数据包将被直接扔掉
发送者(Sendeinstanz):
设置重传计数器(Retransmission Timer)，当时间到了则从新发送数据包
问题:同步
大量不同TCP连接的数据包会几乎同时被扔了

积极的队列管理

基本措施:
1.网络能反馈当前的阻塞状况(在Router过载之前)
2.Router在其Puffer满之前就进行扔包
随机扔包，以防止多个Sender同时重传
缩短队列的平均长度
提前识别阻塞状况
**具体措施:**RED(Random Early Detection)

Random Early Detection(RED)

处理方法:
1.当等待队列长度 <qmin <script type="math/tex" id="MathJax-Element-286"> 2.当 $q_{min}<$等待队列长度< $q_{max}$，随着等待队列长度的增长，丢弃包的概率呈线性增长
3.当等待队列长度 $>=q_{max}$，丢弃所有新到的包(丢包概率为1)
存在的问题:
参数的大小具体应该如何设定比较合理

Prinzip:Conservation of Packets

目标:连接的双方在工作时应该能够保持平衡，具体如下：
始终保持一个完整的流控制窗口的数据在传输线上，所谓Conservative的意思就是在一个旧的数据包被完全接受之前不会发送新的数据包
**具体方法:**self clocking
发送方使用接受方的回复作为发送新数据包的信号
接收方产生回复的速度不能比数据包在网络中传播的快//比较双方分别是数据包从发送方到接收方的事件和回复数据从接收方到发送方的时间。

例子：TCP self-Clocking

场景:
发送方和接收方都拥有很快的网络连接
双方之间只有很慢得网络连接
过程:
1.发送方直接把整个数据窗口中得数据依序向接收方发送
2.因为网络传输速度相对于发送和接收的速度来说很慢，整个数据基本上都滞留在网络上
3.数据以一定的间隔事件抵达接收方//因为接收速度也远大于传输速度，于是不同数据包之间就产生了间隔时间(zwischenankunftszeit)
4.接收方为接收到的数据生成回复(Quittung)
5.发送方应该一直等待直到他得到所有的回复才能发送下一个数据

为什么没办法实现平衡呢

1.连接无法实现平衡
2.发送方过早发送新的数据
3.资源限制阻碍了平衡的实现

连接无法实现平衡

可能的方法:
1.建立新的连接
2.重启已经存在的连接
Conservation of Packet:
要求能够根据数据传输率和延迟自动调整发送速度
存在的问题是，发送方发送信息的条件是得到接收方的回复，而相应的在没有接收到信息的条件下接收方也无法生成回复

Slow-Start

基本思路:
并不一开始就把整个发送窗口的数据都发送，而是随之时间逐渐增大发送的数量
方法:
1.为每个TCP连接引入一个阻塞控制窗口(Staukontrollfensters,Congestion Window,CWnd)
2.在连接刚开始时，或者在丢失一个包后把阻CWnd重置为1(为1MSS)
3.每当收到一个顺利传输的回复后是Cwnd++
4.传送数据的大小由CWnd和流控制窗口的最小值决定
MSS:
指TCP数据包中Nutzdate的大小
TCP包由TCP头文件(最大60B)和Nutzdaten组成
//在IPV4中这个有点理解有点出入回改
对比试验
问题
为什么叫Slow，明明window是以指数级增长的 //不知？？

发送方过早发送新的数据包

slow start使TCP连接达到平衡，那么现在的问题就是如何使这个平衡保持下去，但是网络的状况是随着时间不断改变的，而且路径也不是唯一的，不同路径其状况也是不同的
问题:
网络自身不能很好的反馈其阻塞状况，网络的承受能力只能通过观察后进行猜测
关键: retransmission Timer
太小：出现没必要的重传
太大：不能及时反应网络的阻塞(包丢失)
何为好的计时器: //s54
Round Trip Time(RTT):
sampleRTT：重发送数据包直到收到该数据包的回复共使用的时间(忽视数据重发的测试)
EstimatedRTT：测试得到的数据一般会有比较大得波动，因此经常通过多组测试，并根据这些测试的结果，推出一个RTT，称为EstimatedRTT
$EstimatedRTT=(1-\alpha)*EstimatedRTT+\alpha *SampleRTT$
Exponential Weighted Moving Average(EWMA):
测量值的影响随时间呈指数增长 //不动EWMA是干嘛的
$\alpha 一般取值0.125$
一般设定
$RetransmissionTimer=\beta *EstimatedRTT$
对比试验:
结果：效果并不佳，偶尔会出现波动
波动估计:
目的：减少观测中偶尔出现的波动
观察：//没看明白 有空加图
方法:
$Deviation=(1-\gamma)*Deviation+\gamma *|SampleRTT-EstimatedRTT|$
RetransmissionTimer=EstimatedRTT+$\beta *Deviation$
问题1:两次重传之间的时间应该是多长
exponentieller Backoff：在每次新的重发时，使
RetransmissionTimer=2*RetransmissionTimer
问题2:重发后收到一个回复，那么他是首发的回复呢还是重发的
Karn’s Algorithmus: //不太理解 s60 61

资源限制妨碍了平衡

Motivation //回看 连续写了n小时后质量就成这了
//可就这还得继续写下去，因为时间根本不够
Congestion Avoidance:
是阻塞控制窗口(staukonstrollfenster)线性增长
在收到回复的时候：CWnd += 1/CWnd
对比试验: s69

Fast Retransmit

motivation:
并不是每个不按顺序到达的数据包都暗示着网络阻塞
一般情况下是等待retransmission时间到然后重传，但是这个时间要比RTT还要大
目的:
快速反应：当收到一定数量的同一sequenznummer的回复时，就进行重传//多个回复的ack都相同

总结：阻塞控制

隐含的阻塞控制(Implizite Staukontrolle)

没有明显的网络支持
使用隐含的阻塞表现：比如RTT，和重复请求回复
经典的方法有：TCP-Tahoe,TCP-Reno

TCP-Tahoe

用于阻塞控制的机制有:
Slow Start
Timeout
Congestion Avoidance
Fast Restransmit
在Timeout或收到重复请求回复是使用Slow Start
另外应该始终保持：
LastByteSent-LastByteAcked<=min{CWnd,RcvWindow}
使用的变量:
Congestion Window CWnd
Schwellenwert SSThres(slow start Theras)
//当CWnd达到SSThres时从slow start转用congestion avoidance
基本的方法:
additive increase, multiplicative decrease(AIMD):
收到回复时逐渐加法增大CWnd，但估计出现包丢失时乘法降低CWnd
初始化:
CWnd= 1 MSS
SSThres 初始化为无限大
重复请求数量(Anzahl duplizierter Quittung) 为3
运行:
1.只要CWnd<=SSThresh并且能过收到回复(Quittung)使用：Slow Start
2.当CWnd>SSThresh且收到回复时使用Congestion Avoidance
3.Timeout或收到3次重复请求回复时：
使用slow start
猜测出现阻塞
SSThresh=max(FlightSize/2,2*MSS)
FlithtSize是指发送了但还没有得到回复的数据
注意数据流控制
CWnd=1 MSS
如果是收到3个重复请求回复，则还有重传数据

TCP-Reno

新内容:
对一下情况进行区分：
严重的阻塞(schweren Stausituationen):Timeout
轻的阻塞(leichteren Stausituationen):重复请求回复
在轻的阻塞时和TCP-Tahoe的区别:
1.没有重新设置为Slow Start，接到重复请求回复说明后面的信息是顺利送达的
2.使用行的机制：Fast Recovery
尽管错误还没被处理，但是新的数据还是要发送(fast retransmit)
保持self clocking
SSThresh=max(FlightSize/2,2*MSS)//具体看一下
CWnd=SSTresh，重发没送达的数据，并观察后续发展
-没收到新的回复：CWnd+=3，然后每收到一个重传请求，CWnd++
-收到新的回复：CWnd恢复到Fast Recovery刚开始时的大小(Congestion Avoidance)

在严重的阻塞的情况:
和在TCP-Tahoe一样，使用Slow Start

明显的阻塞控制(Explizite Staukontrolle)

可以得到关于网络状况的明显的信息
经典的方法有：ECN