Draft: draft-ietf-webtrans-http2

Commentary: Moved the later section up , fixed up some sections , and consolidated some of the text . 
 When I did , I had n't read Section 8 . My suggestion is that this be merged into the material from the ( current ) Sections 4 and 5 . Also , this is the first use of Http2Transport . I think that we should remove that . It 's a fine class name for a C++ implementation , but we do n't use it elsewhere . 
 Just to make sure I understand , the idea is for this " what properties do we provide and how do they satisfy the WT requirements " part to be up front with 4/5 ? Seems good to me . Yeah , that 's mostly leftover from previous versions where we had a more defined name . Can clean up and not lose anything of value , I think .
Because WebTransport over TCP-based HTTP semantics relies on the
underlying protocols to provide in order and reliable delivery, there
are some notable differences from the way in which QUIC handles
application data.
Endpoints MUST send stream data in order.  As there is no ordering
mechanism available for the receiver to reassemble incoming data,
receivers assume that all data arriving in capsules is contiguous and
in order.
DATAGRAM capsules are delivered to the remote WebTransport endpoint
reliably, however this does not require that the receiving
implementation deliver that data to the application in a reliable
manner.
The WebTransport framework OVERVIEW defines a set of optional
transport properties that clients can use to determine the presence
of features which might allow additional optimizations beyond the
common set of properties available via all WebTransport protocols.
Because WebTransport over TCP-based HTTP semantics relies on the
underlying protocols to provide in order and reliable delivery, there
are some notable differences from the way in which QUIC handles
application data.  For example, endpoints send stream data in order.
As there is no ordering mechanism available for the receiver to
reassemble incoming data, receivers assume that all data arriving in
capsules is contiguous and in order.
Below are details about support in WebTransport over HTTP/2 for the
properties defined by the WebTransport framework.
WebTransport over HTTP/2 does not support stream independence, as
HTTP/2 inherently has head-of-line blocking.
WebTransport over HTTP/2 does not support partial reliability, as
HTTP/2 retransmits any lost data.  This means that any datagrams
sent via WebTransport over HTTP/2 will be retransmitted regardless
of the preference of the application.  The receiver is permitted
to drop them, however, if it is unable to buffer them.
WebTransport over HTTP/2 supports pooling, as multiple transports
using WebTransport over HTTP/2 may share the same underlying
HTTP/2 connection and therefore share a congestion controller and
other transport context.  Note that WebTransport streams over
HTTP/2 are contained within a single HTTP/2 stream and do not
compete with other pooled WebTransport sessions for per-stream
resources.
WebTransport over HTTP/2 does not support connection mobility,
unless an underlying transport protocol that supports multipath or
migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS.
Without such support, WebTransport over HTTP/2 connections cannot
survive network transitions.
The WebTransport capsulework OVERVIEW defines a set of optional
transport properties that clients can use to determine the presence
of features which might allow additional optimizations beyond the
common set of properties available via all WebTransport protocols.
Below are details about support in Http2Transport for those
properties.
Http2Transport does not support stream independence, as HTTP/2
inherently has head of line blocking.
Http2Transport does not support partial reliability, as HTTP/2
retransmits any lost data.  This means that any datagrams sent via
Http2Transport will be retransmitted regardless of the preference
of the application.  The receiver is permitted to drop them,
however, if it is unable to buffer them.
Http2Transport supports pooling, as multiple transports using
Http2Transport may share the same underlying HTTP/2 connection and
therefore share a congestion controller and other transport
context.
Http2Transport does not support connection mobility, unless an
underlying transport protocol that supports multipath or
migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS.
Without such support, Http2Transport connections cannot survive
network transitions.