Age | Commit message (Collapse) | Author |
|
I UTSL C-tor and it memsets the thing to zero and then fails to write
these timeout fields.
We should recommend that other implementations do the same.
|
|
Congestion control is 0x01 at this moment.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
as suggested by meskio
make clear that the ed25519 file is not relevant for bridges
|
|
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
since contactinfo for bridges is also public now,
we add support for bridges
|
|
|
|
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.
|
|
(Briefly: "Sent" is sometimes unobservable, so we should use
"queued" as a reasonable proxy.)
|
|
(This is largely determined by reverse-engineering tor's current
behavior.)
|
|
Also explain what should happen if those assumptions are violated.
|
|
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.
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Deprecated. Not supported by the network anymore.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
See proposal 332 for more details.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
This has already been discussed somewhat on a pad; now we can move
to an MR and fill in the missing parts.
|
|
(Based on network team discussion, 28 April 2022)
|
|
resolves #116
|
|
Closes #113
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Closes: #81.
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Related to #40312
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Related to https://gitlab.torproject.org/tpo/core/tor/-/issues/40560
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|