diff --git a/i2p2www/spec/proposals/168-tunnel-bandwidth.rst b/i2p2www/spec/proposals/168-tunnel-bandwidth.rst index d4eb040d15463fbab4d1b9f6e97912999f04bc93..6561696733097d654f4beb1a3f807690f5a210dd 100644 --- a/i2p2www/spec/proposals/168-tunnel-bandwidth.rst +++ b/i2p2www/spec/proposals/168-tunnel-bandwidth.rst @@ -37,7 +37,7 @@ the tunnel build request and reply messages. Design ====== -Add bandwidth parameters to the ECIES tunnel build messages [Tunnel-Creation-ECIES]_ +Add bandwidth parameters to the records in ECIES tunnel build messages [Tunnel-Creation-ECIES]_ in the tunnel build options mapping field. Use short parameter names since the space available for the options field is limited. Tunnel build messages are fixed-size so this does not increase the @@ -51,12 +51,12 @@ Specification Update the ECIES tunnel build message specification [Tunnel-Creation-ECIES]_ as follows: -For both long and short ECIES build messages: +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. +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. - m := minimum bandwidth required for this tunnel (KBps positive integer as a string) @@ -69,7 +69,8 @@ provide at least that much bandwidth. Build Reply Option --------------------------- -The following option may be set in the tunnel build reply options mapping field. +The following option may be set in the tunnel build reply options mapping field of the record, +when the response is ACCEPTED: - b := bandwidth available for this tunnel (KBps positive integer as a string) @@ -82,8 +83,8 @@ much bandwidth for the tunnel, however this is not guaranteed. Routers cannot predict conditions 10 minutes into the future, and participating traffic is lower-priority than a router's own traffic and tunnels. -Routers may also over-allocate available bandwidth if necessary. - +Routers may also over-allocate available bandwidth if necessary, and this is +probably desirable, as other hops in the tunnel could reject it. @@ -100,6 +101,24 @@ including ratchet and streaming. Intermittent small messages such as streaming a will be expanded to 1 KB each. However, gzip compression at the I2CP layer may substantially reduce bandwidth. +The simplest implementation at the requesting router is to use +the average, minimum, and/or maximum bandwidths of current tunnels in the pool +to calculate the values to put in the request. +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. + +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 +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, +that may not be possible, particularly for inbound tunnels. @@ -107,6 +126,9 @@ Security Analysis ================= Client fingerprinting 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 conbination of both. Avoid over-allocation ddos.