Build My Own Wireless Emulator 0.0 - DataRateLimit
date
slug
tags
summary
type
status
作为一个Emulator，首先要做到的是速率限制。这篇文章对比了三种现有实现方案。
Emane
EMANE RF-Pipe模型采用的速率限制算法基于数据包的大小和预定的速率来计算处理延迟。具体来说，这个算法首先根据每个数据包的大小和指定的速率计算出一个特定的延迟时间。然后，EMANE使用这个延迟时间来调整数据包的处理调度。通过这种方式，它确保了每个后续的数据包都至少在这个计算出的延迟时间之后被发送或处理，从而有效地维持了设定的网络速率限制。
Replacing HTB with EDT and BPF
第二种方案是利用ebpf实现速率限制，基本思路是队列会根据包的timestamp进行发送，因此只需要调整好每个包的timestamp，保证包与包之间的延迟大于某个根据速率计算出来的延迟就可以做到速率限制。
具体来说，这个方案通过维护每条链路上的
next_tstamp（即下一个数据包的预定发送时间戳）来控制数据包的发送速率。具体操作流程如下：- 检查
next_tstamp与当前时间： - 当一个新的数据包到达时，首先检查
next_tstamp是否小于当前时间。 - 如果
next_tstamp小于当前时间，这意味着next_tstamp已经过时，且当前数据包的时间戳自然满足速率限制。因此，可以立即处理这个数据包。
- 对比数据包时间戳和
next_tstamp： - 如果
next_tstamp显著大于数据包的时间戳（即超过了预设的时间阈值），则表明该数据包发送得过快。 - 在这种情况下，为了维持设定的发送速率，该数据包将被丢弃。
- 调整数据包发送时间和更新
next_tstamp： - 如果
next_tstamp比数据包的时间戳略大，这表示需要轻微调整（延后这个包的发送）以满足速率限制。 - 此时，将数据包的发送时间设置为
next_tstamp，以确保不超过速率限制。 - 然后，更新
next_tstamp为其当前值加上根据数据包大小和速率计算出的延迟。这确保了下一个数据包也将遵守同样的速率限制。
通过这种机制，每个数据包的处理都会根据链路的速率限制进行调整。这样可以有效地控制整个链路上的数据流，保证发送速率不会超过设定的限制
Network Emulation in Large-Scale Virtual Edge Testbeds: A Note of Caution and the Way Forward
第三个方案和第二个方案类似，也是通过控制包的timestamp来控制速率。
时间戳计算方法：
每条链路（例如基于IP地址区分的链路）维护一个记录，用于存储上一个数据包的时间戳。当一个新的数据包到达时，其时间戳被设定为这个链路上最后一个数据包的时间戳加上一个延迟。这个延迟是根据数据包的大小和预定速率计算出的，目的是保持数据包的发送频率符合链路的速率限制。
这里的算法感觉有点问题，如果上次tlast + gap小于当前时间，不就无效了吗？
Summary
三种速率限制方法的核心都是将速率转化为延迟，确保发送间隔不小于这个延迟。从实现上看，第一种方法直接延迟处理整个包，可能效率不高。后续方法利用队列和时间戳，仅调整发送时间，更有效率。
Loading...