Original text:
to a single address over a single interface.  They also present a single stream to the application.  Software layers built upon sockets often propagate this limitation of a single-address single-stream <del> model.  The Transport Services architecture is designed to handle multiple candidate endpoints, protocols, and paths; and support multipath and multistreaming protocols. </del>  Transport Services implementations are meant to be flexible at connection establishment time, considering many different options and <del> trying to select the most optimal combinations (gathering and racing).  This requires applications to provide higher-level endpoints than IP addresses, such as hostnames and URLs, which are used by a Transport Services implementation for resolution, path selection, and racing.  Transport services implementations can further implement fallback mechanisms if connection establishment of one protocol fails or performance is detected to be unsatisfactory. </del>  Flexibility after connection establishment is also important. Transport protocols that can migrate between multiple network-layer

Reviewer comments:
In (Arch) section 3.3, you are talking about racing before you've described what it is. At the point where you note that racing should only happen over stacks with identical security properties, note when doing so might introduce privacy issues and what can be done about them.
Describe what you mean by caching and why you might want to isolate sessions earlier.

Revised text:
to a single address over a single interface.  They also present a single stream to the application.  Software layers built upon sockets often propagate this limitation of a single-address single-stream  <ins> model.  The Transport Services architecture is designed: to handle multiple candidate endpoints, protocols, and paths; to support candidate protocol racing to select the most optimal stack in each situation; to support multipath and multistreaming protocols; to provide state caching and application control over it. </ins> Transport Services implementations are meant to be flexible at connection establishment time, considering many different options and  <ins> trying to select the most optimal combinations by racing them and measuring the results (see gathering and racing).  This requires applications to provide higher-level endpoints than IP addresses, such as hostnames and URLs, which are used by a Transport Services implementation for resolution, path selection, and racing.  Transport Services implementations can further implement fallback mechanisms if connection establishment of one protocol fails or performance is detected to be unsatisfactory. Information used in connection establishment (e.g. cryptographic resumption tokens, information about usability of certain protocols on the path, results of racing in previous connections) are cached in the transport services implementation.  Applications have control over whether this information is used for a specific establishment, in order to allow tradeoffs between efficiency and linkability. </ins> Flexibility after connection establishment is also important. Transport protocols that can migrate between multiple network-layer