From 7ea74b99bd6ef356feb8f66a23ff985c9b056f69 Mon Sep 17 00:00:00 2001 From: Mike Perry Date: Wed, 17 May 2023 21:29:05 +0000 Subject: Prop329: Document Snowflake exemption to Guard restriction. --- proposals/329-traffic-splitting.txt | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/proposals/329-traffic-splitting.txt b/proposals/329-traffic-splitting.txt index 63d7aab..93655f0 100644 --- a/proposals/329-traffic-splitting.txt +++ b/proposals/329-traffic-splitting.txt @@ -275,7 +275,21 @@ Status: Needs-Revision To link exit circuits, two circuits to the same exit are built, with additional restrictions such that they do not share Guard or Middle - relays. When each circuit is opened, we ensure that congestion control + relays. This restriction applies via specific relay identity keys, + and not IP addresses, families, or networks. (This is because the purpose + of it is to avoid sharing a bottleneck *inside* relay circuit queues; + bottlenecks caused by a shared network are handled by TCP's congestion + control on the OR conns). + + Bridges also are subject to the same constraint as Guard relays; + the C-Tor codebase emits a warn if only one bridge is configured, unless + that bridge has transport "snowflake". Snowflake is exempt from this + Guard restriction because it is actually backed by many bridges. In the + bridge case, we only warn, and do not refuse to build conflux circuits, + because it is not catastrophic that Bridges are shared, it is just + sub-optimal for performance and congestion. + + When each circuit is opened, we ensure that congestion control has been negotiated. If congestion control negotiation has failed, the circuit MUST be closed. After this, the linking handshake begins. @@ -307,6 +321,17 @@ Status: Needs-Revision use Prop340, we will have to raise the limit on number of intros per client circuit to 2, here, at intropoints). + When rendezvous circuits are built, they should use the same Guard, + Bridge, and Middle restrictions as specified in 2.2, for Exits. These + restrictions SHOULD also take into consideration all Middles in the path, + including the rendezvous point. All relay identities should be unique + (again, except for when the Snowflake transport is in use). The one + special case here is if the chosen rendezvous points by a client + are the same as the service's guards. In this case, the service SHOULD + NOT use different guards, but instead stick with the guards it has. + The reason for this is that we do not want to create the ability + for a client to force a service to use different guards. + The first rendezvous circuit to get joined SHOULD use Proposal 340 to append the RELAY_BEGIN command, and the service MUST answer on this circuit, until RTT can be measured. -- cgit v1.2.3-54-g00ecf