MikeBishop
commented
8 years ago Just pushed a commit that addresses some of this. There are also items here that I disagree with a little bit, and I welcome discussion:
- Added text around causality and ordering. I'd love to flesh out the Semantic section to enumerate items at that layer, but frankly, I'm not entirely sure what to say belongs there. Do you have suggestions?
- Added addressing as a core transport service. Expanded on in-order and partial delivery a little bit. Added a discussion of session creation/termination to the flow control part and retitled the whole thing as "connection management."
- I actually don't see Full Duplex as a required capability for HTTP. In fact, semantic HTTP is conceptually half-duplex -- clients often don't examine server responses until they're done sending the requests, even if the server is able to respond early. It's certainly a useful optimization, and obviously needed underneath a multiplexing layer like HTTP/2 framing, but I don't think it's core.
- For flow control, I'm not clear what you mean. The HTTP layer is just dumping bytes into the pipe -- it's the transport (or mapping) that is actually acting on signals from the network and/or peer to moderate the amount that actually gets delivered as time goes on.
- Priority/fairness is ancillary to parallelism; mentioned it there.
A whole world of discussion lies in your last point. Fundamentally, is QUIC a new HTTP-over-UDP mapping, or is it a new transport? That's the question I'm trying to capture in the title of 4.5. Depending on the context, QUIC may be "equivalent to HTTP/2," or it may be "a modern general-purpose transport." In fact, the I-D submitted in Prague calls it both, in the same paragraph.
You're entirely correct that the HTTP/2 framing layer could be used independently of HTTP. That was a low-priority design goal of the working group, and part of why the spec is so delineated between the framing layer itself and how HTTP semantics get mapped onto a stream. At the same time, some very HTTP-grounded concepts (primarily headers) made it into the framing layer, because we ultimately concluded that there was no negotiation mechanism for selecting something other than HTTP over the framing layer. ALPN permitted you to select "h2," which defined both layers at once. Selecting something different, while perhaps startlingly similar, would be a different protocol and a different RFC.
QUIC seems to have the option to go the other direction. Seen as a transport, it's very SCTP-like. By submitting it to the TSV WG and describing it as a "general-purpose transport," it seems clear that there's again an eye toward reusing this beyond HTTP. In that case, we should talk about it like a transport, with a (very thin) mapping defined. (HPACK frames on a dedicated stream, for example.) However, it has so far been used exclusively for HTTP transactions, and it may ultimately go the same path as HTTP/2 -- in which case it gets dropped from the transport table, and it's a rich mapping rather than a transport.
wenbozhu
Very nice work! Did a first pass, on this long-overdue subject ...
////////////
Maybe mention the RPC semantics: any part of the response message causally happens-after the request data. E.g. no unsolicited response (true for spdy or http2 push too?), no success completion of the response before the request is completed ....
Also, this doc would be more useful if all the HTTP semantics that require transport support/mapping are listed, for completeness.
////////////
== Addressing / Session
The transport needs support URLs in locating a server, whose network address may change during a single request/response exchange between the client and server.
The concept of "session" needs be understood by the transport to correlate and deliver a request and response message.
== Reliable Delivery
"Weakened guarantees": seem to be that we should not be concerned about those extended semantics, for now.
== In-order Delivery
"The body is typically exposed as a bytestream": Use of metadata to decode the body in segments etc is not the concern of the core transport support, IMO.
== Partial Delivery
Maybe mention the two different scenario: headers v.s. body; partial body delivery.
Also, IMO framing should be considered the responsibilities of the transport service. E.g. if we were to layer HTTP/1.1 properly, then its transport service (non-multiplexed TCP) should include the elements of transfer-encoding, connection: keep-alive etc.
== Half-close or EOF
The transport (or the mapping semantics thereof) needs signal the completion of the request or response message.
== Abort
The transport needs be able to abort the request or response delivery when an error occurs.
== Keep alive or failure detection
The transport may be able to detect when a peer is gone (during a request/response). The failure detection may not be reliable or timely.
== Full-duplex
The transport needs be able to deliver request/response message at the same time, as data gets generated by the application.
== Flow control and throttling
Seems to me that the role of transport service is merely to propagate flow-control events of the peer (or the network) to the application. App to App (process to process) flow-control is beyond the scope of transport service. And flow control affects both the client and server process, equally.
=== Priority or fairness ..
////////////
If QUIC is considered a transport, then the framing part of HTTP/2 should be considered as a separate transport, IMO. Things like HOL blocking, priorities are the properties of such a transport.
So, it would be more clear to have a comparison table for the following "transport services":
HTTP/1.1 over TCP HTTP/2 over TCP QUIC HTTP over SCTP HTTPU & CoAP