In the rare event that a user resumes activity after a period between the
"reduced connection timeout" and the full value, and that user has not set
reduced padding, this is a distinguisher on circuits that have been held idle
and open for that long.
The main points here are:
* We assume that flow measurements are unidirectional, so
each side must make sure to send traffic.
* So we restart our timer when sending, only.
* We restart the timer whether we're sending real traffic or
padding traffic.
* The logic for `max(X,X)` timing applies even though we aren't
using a bidirectional trigger for timing.
Changes:
- Rework exit negotiation logic a bit
- Specify using ntorv3 with extension fields for negotiation
- Clients only request congestion control; exits and services
control sendme_inc
- Rework onion service negotiation for descriptor-controlled
FlowCtrl protover and sendme_inc value
- Add bounds checks on sendme_inc for clients
- Update parameter values based on Shadow results
- Improvements to TOR_VEGAS algorithm based on simulation testing
- Additional consensus parameters for RTT N-EWMA smoothing and
TOR_VEGAS queue use caps
- Clarify N_EWMA smoothing, and relocate it to its own sub-section.
- TOR_VEGAS now defaults to CWND/RTT BDP estimator
- Minor TOR_VEGAS alg bugfixes
- Add a 'delta' parameter to TOR_VEGAS for steady-state backoff
- Consensus param update notes and param range fixes.
- Add glossary of common congestion control acronyms
- Misc clarifications
These patch changes describe new default behaviors for extension
field lists, as appear in ntor3 and in many places throughout the
ntor3 protocol. In general:
* Unrecognized extensions MUST be ignored.
Additionally, all the following rules apply _unless otherwise stated
in the documentation for an extension.
* Extensions are sent in sorted order.
* Extensions should only be sent once in a message
* If you receive multiple copies of an extension, only the first
one counts.
This comes out of discussions on tor!525.
The descriptor format uses a curve25519->ed25519 conversion
algorithm to cross-certify descriptors with their ntor onion keys.
This patch clarifies two aspects of the algorithm:
1. When deriving a private key, how to derive the part of the
private key that _isn't_ a point on the curve.
2. That there are two algorithms here, one for private->private and
one for public->public.
In particular, this commit clarifies that the ranges of some
parameters are such that choosing a very high value will, in effect,
disable parts of the circuit timeout inference code.
