【如何确定端到端的延迟？】03-10 - Packet Switching - Principles - Delay Guarantees

主要内容：如何确定端到端的延迟？

对一个不会溢出的漏水桶来说，一段时间内的进水量总是小于水桶容量加上这段时间的出水量

推广一下这个漏水桶的原理，于是我们用**（σ，ρ）regulation表示：这种类似的模型中，一条曲线在任意时间总是无法在垂直方向上超过(σ+ρt)的值

在本例中σ就是B（队列容器的最大容量），ρ是队列输出的速率

下图中A(t)-D(t)=Bmax**,单位时间内入列减去出列就等于队伍容量的最大值
tA-tB=dmax每个bit的最大延迟是两条曲线水平向的差（时间差）

且

也就是说，在没有丢包的情况下，σ的最大值是，因为队列有没装满的时候，此时(σ+ρt)中的σ肯定是小于最大值的
如果离开队列的速度R1>=ρ,那么d(t)，也就是延迟不会超过B/R1，因为B/R1就是队列装满的情况，当R1（离队速度）取最小值ρ时，B/R1就是最大值。

注意在这个例子中，我们站在包的入口端（也就是水桶）的角度，可以控制的变量只有两个，B（队伍容量）和 R1（离队速率）
这里说是“包的入口端”，是因为在上一节内容中提到，因为性能原因，我们把缓存packet的队列放在router的入口处
我们有如下规律

不着急看明白这句话，下面用一个模型和一个实例来详解

其中的leaky-buket constrainer是一种模型，那么这种模型该怎样构建呢？
下图展示了一个leaky bucket regulator（机翻中文名“漏水桶调节器”，确实是个很形象的比喻）

上图中的绿色小球，被称作 token（代币） ，你每需要从队列中输出一个packet，就要消耗一个代币，而这些代币的生产速度，被限制在了ρ，装这些代币的容器大小设定为σ—————“要想从此过？留下买路财”

也就是说packet被输出的速率，也被限制在了ρ之下，包的入口端实现了“限制器”的功能，就能实现对原本到达速率不确定的包有了一个相对确定的输出速率。

当我们把前一节的内容联系起来，发送端的输出速率就被限制在ρ之下，发送的包被按照权重分配至对应的router入口，router的输出又再一次被限制，如此往复，在整个数据传输的路径上交替使用漏水桶限制器和WFQ分配原则，成功把包从A送到B，并且（尽量）控制了包的延迟（因为输出速率相对确定了）。

在这个例子中，题目要求则会1000byte的包的end-to-end（端到端）延迟不得高于5ms
我们知道，端到端延迟 = 分组延迟（Packetization Delay）+ 传播延迟（Propagation Delay）+ 排队延迟（Queueing Delay）
经过计算可知，前两者的延迟之和是0.696ms，那么排队延迟就不能大于4.404ms

我们假设两个router处的延迟是相等的，此处根据利特尔法则（ https://blog.****.net/stpeace/article/details/45921227），Buffer的最小值（因为buffer可以越大越好）应该等于整个系统的传输速率（进水速率-漏水速率）乘上平均排队队列延迟（单位量的水待在水桶里的时间）计算结果是2690bytes，也就是说，为了保证低于4.04ms的排队延迟，两个router任一个的buffer都不能小于这个值。
注意，则有一个容易困惑的点，为什么传输的速率只有10m/s，因为根据WFQ(weight fair queueing)分配原则，一个application的数据传输通道只是根据所占权重分配到router处理包的一部分能力，所以10m/s的速率是正常的，不要把这个传输速率和线缆上标注的传播速率搞混了。

那么，确保延迟或者说时延保证到底有什么用？它告诉我们在实际操作中，我们要确保：

每个router不能缓存超过2960bytes的数据，要达成这个目的，我们可以使用“漏水桶调节器”
每个router的buffer必须有缓存超过2960bytes数据的能力，也就是容量应该超过这个值，这样才能保证高于这个值的数据不会丢失。

虽然理论上可行，但是很遗憾，在实际网络环境中，我们却没有使用这种控制端到端延迟的方法。
两点原因：

工作原理复杂，需要各部分协调
在大多数网络中，有超大缓存和权重（priorities）处理就够了

但还是有好消息！

这一节有助于我们理解端到端延迟和包的传输过程。
个人认为这在未来的理想化网络中，控制延迟是相当有价值的（视频中也提到了这一点），比如在需要严格控制延迟的情境下，我们不需要依赖于盲目升级硬件，而是通过这种机制来有效掌握延迟。

---

constrained 驱使，束缚
Propagation 传播