注意
本提案已被批准并已纳入 API 0.9.65 版本的 Tunnel Creation ECIES specification 规范中。 目前尚无已知的实现；实现日期/API 版本待定。
概述
随着我们在过去几年中通过新协议、加密类型和拥塞控制改进提升网络性能， 视频流这样的快速应用变得可能。 这些应用在其客户端隧道的每一步都需要高带宽。
然而，参与路由器在收到隧道构建消息时并没有关于隧道会使用多少带宽的信息。 它们只能基于当前所有参与隧道使用的总带宽和为参与隧道设置的总带宽限制来接受或拒绝一个隧道。
请求路由器也没有关于每一步可用带宽的信息。
此外，目前路由器无法限制隧道上的入站流量。 在服务过载或遇到 DDoS 攻击时，这将非常有用。
本提案通过在隧道构建请求和答复消息中添加带宽参数来解决这些问题。
设计
在隧道构建选项映射字段中的 ECIES 隧道构建消息记录中添加带宽参数 (参见 Tunnel Creation ECIES specification)。 因为选项字段可用空间有限，请使用缩短的参数名称。 隧道构建消息为固定大小，所以这不会增加消息的大小。
规范
如以下更新 ECIES 隧道构建消息规范：
对于长和短的 ECIES 构建记录：
构建请求选项
以下三个选项可以在记录的隧道构建选项映射字段中设置： 请求的路由器可以包含任何、全部或无。
- m := 本隧道所需的最小带宽（以字符串表示的正整数 KBps）
- r := 本隧道请求的带宽（以字符串表示的正整数 KBps）
- l := 本隧道的限制造带宽；仅发送给 IBGW（以字符串表示的正整数 KBps）
约束：m <= r <= l
如果指定了“m”并且不能提供至少那么多的带宽，参与的路由器应拒绝该隧道。
请求选项被发送到对应的加密构建请求记录中的每个参与者，对其他参与者不可见。
构建答复选项
以下选项可以在记录的隧道构建答复选项映射字段中设置， 当响应为 ACCEPTED 时：
- b := 本隧道可用的带宽（以字符串表示的正整数 KBps）
如果在构建请求中指定了“m”或“r”，参与的路由器应包含此信息。 该值应至少与指定的“m”值相等，但可能小于或大于指定的“r”值。
参与的路由器应尝试为隧道保留并提供至少这么多的带宽，但这不保证。 路由器无法预测 10 分钟后的状况，且参与流量的优先级低于路由器自有流量和隧道。
如果需要，路由器也可能超分配可用带宽，而这可能是理想的，因为隧道中的其他跳可能会拒绝它。
基于这些原因，参与的路由器的答复应被视为尽力而为的承诺，但不是保证。
答复选项被发送到请求路由器作为对应的加密构建答复记录，对其他参与者不可见。
实施说明
带宽参数是看到参与路由器在隧道层的，即每秒固定大小 1 KB 隧道消息的数量。 传输（NTCP2 或 SSU2）开销不包含在内。
此带宽可能远大于或小于客户端看到的带宽。 隧道消息包含大量开销，包括来自更高层的棘轮和流式处理。 间歇性的小消息，例如流式确认将被扩展到每个 1 KB。 然而，I2CP 层的 gzip 压缩可能会大大减少带宽。
请求路由器中最简单的实施可以使用 池中当前隧道的平均、最小和/或最大带宽来计算请求中要放入的值。 可能有更复杂的算法，由实施者决定。
目前没有为客户端定义的 I2CP 或 SAM 选项来告知路由器所需的带宽，此处也没有提出新的选项。 如果需要，选项可能会在以后的日期定义。
实现可能会使用可用带宽或其他任何数据、算法、本地策略， 或本地配置来计算在构建响应中返回的带宽值。本提案未另行指定。
此提案要求入站网关实现按要求的“l”选项进行每个隧道节流。 不要求其他参与的跳实施每个隧道或全球节流的任何类型， 或指定特定的算法或实现，如果有的话。
此提案也不要求客户端路由器按参与的跳返回的“b”值来节流流量， 根据应用程序，这可能不可能，特别是对于入站隧道。
本提案仅影响由发起者创建的隧道。没有定义方法来请求或分配带宽给“远端”隧道， 这些隧道是由端到端连接另一端的拥有者创建的。
安全分析
基于请求，可能会出现客户指纹识别或关联。 客户端（发起）路由器可能希望随机化“m”和“r”值，而不是向每个跳发送相同的值； 或发送一组有限的代表带宽“桶”的值，或两者的某种组合。
过度分配 DDoS：虽然现在可能通过构建和 使用大量隧道来对路由器进行 DDoS 攻击，但本提案可以说让这种攻击变得更加容易， 只需请求一个或多个具有大带宽请求的隧道。
实现可以并且应该使用一个或多个以下策略来减轻这种风险：
- 可用带宽的过度分配
- 将每个隧道的分配限制为可用带宽的某个百分比
- 限制分配带宽增加的速度
- 限制使用带宽增加的速度
- 如果在隧道的生命周期早期未使用，则限制隧道的分配带宽（使用它或失去它）
- 追踪每个隧道的平均带宽
- 追踪请求与每个隧道的实际使用带宽
兼容性
没有问题。所有已知的实现目前都忽略构建消息中的映射字段， 并正确跳过非空选项字段。
迁移
无须协调，实施可随时添加支持。
由于目前没有定义 API 版本，其中要求此提案的支持， 路由器应检查“b”响应以确认支持。