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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Thanks Mike, this is a great improvement

>  
 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

typically discovered?  Or may be discovered?

> +
+# 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.

PRIORITY is used to manage the streams more than the connection

> +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.
+
+Multiplexing of requests is performed using the QUIC stream abstraction, with
+each request and response consuming a single QUIC stream.  Streams are largely

```suggestion
each request and response consuming a single QUIC stream.  Streams are
```

If you want to explain the QPACK caveat, I'd do that explicitly and/or separately.  But the streams themselves are independent and non-HoL blocking.

> +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.

You list almost all of them, any reason not to list all of them?

> +  {{QUIC-TRANSPORT}}. Where frames from {{QUIC-TRANSPORT}} are referenced, the
+  frame name will be prefaced with "QUIC."  For example, "QUIC CONNECTION_CLOSE
+  frames."  References without this preface refer to frames defined in
+  {{frames}}.
+
+peer:
+: An endpoint.  When discussing a particular endpoint, "peer" refers to the
+  endpoint that is remote to the primary subject of discussion.
+
+receiver:
+: An endpoint that is receiving frames.
+
+sender:
+: An endpoint that is transmitting frames.
+
+server:

nit: I'd put this right after client

> @@ -1774,7 +1898,7 @@ removed. Because stream termination is handled by QUIC, an END_STREAM flag is
 not required.  This permits the removal of the Flags field from the generic
 frame layout.
 
-Frame payloads are largely drawn from {{!RFC7540}}. However, QUIC includes many
+Frame payloads are largely drawn from {{!HTTP2}}. However, QUIC includes many

This section is quite long.  The changes to priority are substantial, so I'd break them out in their own sub-section.

> @@ -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

Below "HTTP/3 departs from HTTP/2 primarily where necessary to
accommodate the differences in behavior between QUIC and TCP (lack of ordering,	accommodate the 
support for streams)."

I'd tweak this to be more along the lines of "We changed it when we thought a new design was better, with particular focus on taking advantage of QUIC's lack of head of line blocking" to reflect the state we're in today.  Don't take my suggestion verbatim, but I think that's the concept?

-- 
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#pullrequestreview-235847760