Re: [quicwg/base-drafts] Pull some H2 content into the introduction (#2683)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -88,28 +88,100 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 was a TCP mapping which used whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges were human-readable, the whitespace led to
+parsing difficulties and workarounds to be tolerant of variant behavior.
+Because each connection could be used only for a single HTTP request and
+response at a time, multiple parallel TCP connections were used, reducing the

Kind of.  Where it works, you're still sending a single request at a time and a single response at a time (i.e. they're sent serially); you're just able to start sending the next request before the previous response has been sent.

>  
 This document defines a mapping of HTTP semantics over the QUIC transport
-protocol, drawing heavily on the design of HTTP/2. This document identifies
-HTTP/2 features that are subsumed by QUIC, and describes how the other features
-can be implemented atop QUIC.
+protocol, drawing heavily on the design of HTTP/2.  While delegating stream
+management and flow control issues to QUIC, a similar binary framing is used on

State machine, flow control, ID allocation....

>  
 QUIC is described in {{QUIC-TRANSPORT}}.  For a full description of HTTP/2, see
-{{!RFC7540}}.
-
-
-## Notational Conventions
+{{!HTTP2=RFC7540}}.
+
+# HTTP/3 Protocol Overview
+
+HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.
+
+An HTTP/3 endpoint is discovered using HTTP Alternative Services.  Once a client

Pending the discussion on https://github.com/httpwg/http-core/issues/194; once that discussion settles on core text to describe finding candidate ports and protocols from a URI, this will change to reflect it.  Currently, this document describes Alt-Svc as the only discovery mechanism and the rest proceeds from the assumption that you somehow discovered the port was there.

> +
+# HTTP/3 Protocol Overview
+
+HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.
+
+An HTTP/3 endpoint is discovered using HTTP Alternative Services.  Once a client
+knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC
+connection. QUIC provides protocol negotiation, stream-based multiplexing, and
+flow control.
+
+Within each stream, the basic unit of HTTP/3 communication is a frame
+({{frames}}).  Each frame type serves a different purpose.  For example, HEADERS
+and DATA frames form the frames form the basis of HTTP requests and responses
+({{request-response}}).  Other frame types like SETTINGS, PRIORITY, and GOAWAY
+are used to managed the overall connection.

I can try to wordsmith a little more.  It's used to manage the allocation of connection resources amongst the streams, not to manage the lifetime of any particular stream/request.

> +Within each stream, the basic unit of HTTP/3 communication is a frame
+({{frames}}).  Each frame type serves a different purpose.  For example, HEADERS
+and DATA frames form the frames form the basis of HTTP requests and responses
+({{request-response}}).  Other frame types like SETTINGS, PRIORITY, and GOAWAY
+are used to managed the overall connection.
+
+Multiplexing of requests is performed using the QUIC stream abstraction, with
+each request and response consuming a single QUIC stream.  Streams are largely
+independent of each other, so one stream that is blocked or suffers packet loss
+does not prevent progress on other streams.
+
+Server push is an interaction mode introduced in HTTP/2 {{!HTTP2}} which permits
+a server to push a request-response exchange to a client in anticipation of the
+client making the indicated request.  This trades off network usage against a
+potential latency gain.  Several HTTP/3 frames are used to manage server push,
+such as PUSH_PROMISE, DUPLICATE_PUSH, and CANCEL_PUSH.

```suggestion
such as PUSH_PROMISE, DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH.
```

> +  endpoint is discovered and a connection is established.
+- Stream Mapping and Usage ({{stream-mapping}}) describes the way QUIC streams
+  are used.
+- HTTP Framing Layer ({{http-framing-layer}}) describes the frames used on
+  most streams.
+- HTTP Request Lifecycle ({{http-request-lifecycle}}) describes how HTTP
+  semantics are expressed using frames.
+- Connection Closure ({{connection-closure}}) describes how connections are
+  terminated, either gracefully or abruptly.
+- Extensions to HTTP/3 ({{extensions}}) describes how new capabilities can be
+  added in future documents.
+- Error Handling ({{errors}}) describes how error conditions are handled and
+  expressed, either on a particular stream or for the connection as a whole.
+
+Readers familiar with HTTP/2 will find a more detailed comparison with that
+protocol in {{h2-considerations}}.

I'm struggling to see how the antecedent of "that protocol" is unclear here.

> @@ -1742,7 +1866,7 @@ assigned by IANA.
 
 --- back
 
-# Considerations for Transitioning from HTTP/2
+# Considerations for Transitioning from HTTP/2 {#h2-considerations}
 
 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important

We've gotten a little stretchy in places, but we've been explicitly trying to stay out of the "improve on HTTP/2 in ways unrelated to QUIC" game.  (Some fixes to the more egregious gaps in prioritization are the primary exception.)  I'm trying to reflect that aspiration, though you're correct that we might want to reflect the stretchiness a bit as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2683#discussion_r283002776