Prop. 168 updates after 12/3 review
This commit is contained in:
zzz
@ -5,7 +5,7 @@ Tunnel Bandwidth Parameters
|
||||
:author: zzz
|
||||
:created: 2024-07-31
|
||||
:thread: http://zzz.i2p/topics/3652
|
||||
:lastupdated: 2024-07-31
|
||||
:lastupdated: 2024-12-09
|
||||
:status: Open
|
||||
:target: 0.9.65
|
||||
|
||||
@ -29,7 +29,10 @@ used by all participating tunnels and the total bandwidth limit for participatin
|
||||
Requesting routers also do not have any information on how much bandwidth
|
||||
is available at each hop.
|
||||
|
||||
This proposal addresses the issue by adding bandwidth parameters to
|
||||
Also, routers currently have no way to limit inbound traffic on a tunnel.
|
||||
This would be quite useful during times of overload or DDoS of a service.
|
||||
|
||||
This proposal addresses these issues by adding bandwidth parameters to
|
||||
the tunnel build request and reply messages.
|
||||
|
||||
|
||||
@ -56,15 +59,21 @@ For both long and short ECIES build records:
|
||||
Build Request Options
|
||||
---------------------------
|
||||
|
||||
The following two options may be set in the tunnel build options mapping field of the record:
|
||||
A requesting router may include either or both.
|
||||
The following three options may be set in the tunnel build options mapping field of the record:
|
||||
A requesting router may include any, all, or none.
|
||||
|
||||
- m := minimum bandwidth required for this tunnel (KBps positive integer as a string)
|
||||
- r := requested bandwidth for this tunnel (KBps positive integer as a string)
|
||||
- l := limit bandwidth for this tunnel; only sent to IBGW (KBps positive integer as a string)
|
||||
|
||||
Constraint: m <= r <= l
|
||||
|
||||
The participating router should reject the tunnel if "m" is specified and it cannot
|
||||
provide at least that much bandwidth.
|
||||
|
||||
Request options are sent to each participant in the corresponding encrypted build request record,
|
||||
and are not visible to other participants.
|
||||
|
||||
|
||||
Build Reply Option
|
||||
---------------------------
|
||||
@ -86,6 +95,11 @@ participating traffic is lower-priority than a router's own traffic and tunnels.
|
||||
Routers may also over-allocate available bandwidth if necessary, and this is
|
||||
probably desirable, as other hops in the tunnel could reject it.
|
||||
|
||||
For these reasons, the participating router's reply should be treated
|
||||
as a best-effort commitment, but not a guarantee.
|
||||
|
||||
Reply options are sent to the requesting router in the corresponding encrypted build reply record,
|
||||
and are not visible to other participants.
|
||||
|
||||
|
||||
Implementation Notes
|
||||
@ -108,31 +122,49 @@ More complex algorithms are possible and are up to the implementer.
|
||||
|
||||
There are no current I2CP or SAM options defined for the client to tell the
|
||||
router what bandwidth is required, and no new options are proposed here.
|
||||
Options may be defined at a later date if necessary.
|
||||
|
||||
Implementations may use available bandwidth or any other data, algorithm, local policy,
|
||||
or local configuration to calculate the bandwidth value returned in the
|
||||
build response. Not specified by this proposal.
|
||||
|
||||
This proposal does not require participating hops to implement per-tunnel or global
|
||||
This proposal requires inbound gateways to implement per-tunnel
|
||||
throttling if requested by the "l" option.
|
||||
It does not require other participating hops to implement per-tunnel or global
|
||||
throttling of any type, or specify a particular algorithm or implementation, if any.
|
||||
|
||||
This proposal also does not require client routers to throttle traffic
|
||||
to the limit returned by the participating hop, and depending on application,
|
||||
to the "b" value returned by the participating hop, and depending on application,
|
||||
that may not be possible, particularly for inbound tunnels.
|
||||
|
||||
This proposal only affects tunnels created by the originator. There is no
|
||||
method defined to request or allocate bandwidth for "far-end" tunnels created
|
||||
by the the owner of the other end of an end-to-end connection.
|
||||
|
||||
|
||||
|
||||
Security Analysis
|
||||
=================
|
||||
|
||||
Client fingerprinting based on requests.
|
||||
Client fingerprinting or correlation may be possible based on requests.
|
||||
The client (originating) router may wish to randomize the "m" and "r" values instead of sending
|
||||
the same value to each hop; or send a limited set values that represent bandwidth "buckets",
|
||||
or some combination of both.
|
||||
|
||||
Avoid over-allocation ddos.
|
||||
Over-allocation DDoS: While it may be possible to DDoS a router now by building and
|
||||
using a large number of tunnels through it, this proposal arguably makes it much easier,
|
||||
by simply requesting one or more tunnels with large bandwidth requests.
|
||||
|
||||
Implementations can and should use one or more of the following strategies
|
||||
to mitigate this risk:
|
||||
|
||||
- Overallocation of available bandwidth
|
||||
- Limit per-tunnel allocation to some percentage of available bandwidth
|
||||
- Limit rate of increase in allocated bandwidth
|
||||
- Limit rate of increase in used bandwidth
|
||||
- Limit allocated bandwidth for a tunnel if not used early in a tunnel's lifetime (use it or lose it)
|
||||
- Tracking average bandwidth per tunnel
|
||||
- Tracking requested vs. actual bandwidth used per tunnel
|
||||
|
||||
|
||||
Compatibility
|
||||
@ -147,6 +179,9 @@ Migration
|
||||
|
||||
Implementations may add support at any time, no coordination is needed.
|
||||
|
||||
As there is currently no API version defined where support for this proposal is required,
|
||||
routers should check for a "b" response to confirm support.
|
||||
|
||||
|
||||
|
||||
References
|
||||
|
||||
Reference in New Issue
Block a user