Change:
Round Trip Time, but can tolerate delay variation; Constant-Rate Streaming: Prefer paths that are expected to <del> satisy the requested Stream Send or Stream Receive Bitrate, </del> <ins> satisfy the requested Stream Send or Stream Receive Bitrate, </ins> based on the observed maximum throughput; Capacity-Seeking: Prefer adapting to paths to determine the

Discussion:
I'm having difficult parsing "At this point, any constraints or requirements the application may have on the connection are available from pre-establishment." I'm not even sure what meaning is intended. Available? To what and for what? Is this really a forest? I.e., is a possible when, for instance, you have a choice of two hostnames? If so, there should be an example illustrating that. The last example in the section should be augmented to show multiple hostnames as described by the preceding paragraph. Additionally, I think stating that there is a clear/natural dependency relationship between branching operations such that later operations depend on earlier decisions could simplify and clarify the justification for the suggested order of operations. "Scavenger" implies LEDBAT to me: it will take whatever is currently not being used but will defer to everything else. I'm not sure that notion aligns with the preference described. Is the intent of: that a protocol higher in the stack (or a framer?) could use 0-RTT even if the application doesn't want 0-RTT? Are there any security or privacy implications to this? Should there be a mechanism to disable this entirely? I do not understand the syntax employed here. Is in: a global object or something? It appears to be generating a Start event with the Connection object to the system, but isn't the framer the receiver of such an event? (Nit: isn't Event<> with angle brackets the syntax here?) doesn't seem quite right. Protocols possess a property of application-layer data unit, usually as an intrinsic property that is a direct consequence of the protocol design. They don't really define it so much as end up with it. Maybe this is too much of a nit, but it reads weirdly. The use of "unconnected" (or "connectionless") directly adjacent to the phrase "UDP connections" is driving me batty. I understand that the TAPS interface provides only a Connection object, but we should not ever use lowercase-c "connection" to refer to UDP, and be clear when we mean the uppercase-C "Connection" object in relation to an underlying UDP transport.

I rust just read this as "The Implementation now has all constrains it needs to know for attempting to establish a connection in the form of Preconnection parameters (endpoints, security parameters and transport properties) and can now continue." I would imagine that if 0-RTT is set to prohibit that applies to the entire stack (including framers). This is a bit confusing, but basically, as far as I understand, there is the MessageFramer which is part of the TAPS Implementation (this creates the events and has the methods MakeConnectionReady, MakeConnectionClosed etc.) and there is the framer implementation (which is the part the users of the TAPS implementation write themselves, this receives the events and then calls the methods on the MessageFramer). It might be good to find another term for MessageFramer to make that difference more clear.
WFM