fix some logic errors and typos in specs+proposals

      return either a sequence of newline-terminated hex encoded digests, or

      a "serialized download status" as follows:

       SerializedDownloadSatus =

       SerializedDownloadStatus =

         -- when do we plan to next attempt to download this object?

         "next-attempt-at" SP ISOTime CRLF

         -- how many times have we failed since the last success?

5. Authentication

  To defend against cross-protocol attacks on the Extended ORPOrt,

  To defend against cross-protocol attacks on the Extended ORPort,

  proposal 213 defines an authentication scheme that should be used to

  protect it.

        "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce)

  + ServerNonce is 32 random octets.

  Upon receiving that data, the client computers ServerHash herself and

  Upon receiving that data, the client computes ServerHash herself and

  validates it against the ServerHash provided by the server.

  If the server-provided ServerHash is invalid, the client MUST

      HMAC-SHA256(CookieString,

        "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce)

  Upon receiving that data, the server computers ClientHash herself and

  Upon receiving that data, the server computes ClientHash herself and

  validates it against the ClientHash provided by the client.

  Finally, the server replies with:

reflecting their loads from different component of tor.

Then, we propose that 3 new lines be added to the extra-info document (see

dir-spec.txt, section 2.1.2) if only the overload case arrise.

dir-spec.txt, section 2.1.2) if only the overload case arises.

This following describes a series of metrics to collect but more might come in

The following describes a series of metrics to collect but more might come in

the future and thus this is not an exhaustive list.

# 1.1. General Overload

   - Control port overload (too many messages queued)

The format of the overloaded line added in the extra-info document is as

follow:

follows:

```

"overload-general" SP version SP YYYY-MM-DD HH:MM:SS NL

   [At most once.]

```

The timestamp is when at least one metrics was detected. It should always be

The timestamp is when at least one metric was detected. It should always be

at the hour and thus, as an example, "2020-01-10 13:00:00" is an expected

timestamp. Because this is a binary state, if the line is present, we consider

that it was hit at the very least once somewhere between the provided

The "{read|write}-overload-count" are the counts of how many times the reported

limits of burst/rate were exhausted and thus the maximum between the read and

write count occurances. To make the counter more meaningful and to avoid

write count occurrences. To make the counter more meaningful and to avoid

multiple connections saturating the counter when a relay is overloaded, we only

increment it once a minute.

  The design space is broken into two orthogonal parts: congestion control

  algorithms that apply to each path, and traffic scheduling algorithms

  that decide when to send packets to send on each path.

  that decide which packets to send on each path.

  MPTCP specifies 'coupled' congestion control (see [COUPLED]). Coupled

  congestion control updates single-path congestion control algorithms to

  accomplishing this have been proposed and implemented in the Linux

  kernel.

  Because Tor's congestion control only concerns itself with bottnecks in

  Because Tor's congestion control only concerns itself with bottlenecks in

  Tor relay queues, and not with any other bottlenecks (such as

  intermediate Internet routers), we can avoid this complexity merely by

  specifying that any paths that are constructed SHOULD share any

  specifying that any paths that are constructed SHOULD NOT share any

  relays. In this way, we can proceed to use the exact same congestion

  control as specified in Proposal 324, for each path.

  XXX: Note that BLEST uses total_send_window where we use secondary.cwnd

  in this check. total_send_window is min(recv_win, CWND). But since Tor

  does not use receive windows and intead uses stream XON/XOFF, we only

  does not use receive windows and instead uses stream XON/XOFF, we only

  use CWND. There is some concern this may alter BLEST's buffer

  minimization properties, but since receive window only matter if

  the application is slower than Tor, and XON/XOFF will cover that case,