Resent-Date: Tue, 21 May 2013 15:02:38 +0000
Resent-Message-Id: <E1Ueo5G-0004Mq-U5@frink.w3.org>
MIME-Version: 1.0
Sender: patrick.ducksong@gmail.com
Date: Tue, 21 May 2013 11:01:53 -0400
Message-ID: <CAOdDvNr4q-=yNjocJ6nMNcnekWDakykHPdvUGZe8Kp8vOphpuA@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a11c2103ed0452f04dd3bba24
Received-SPF: pass client-ip=209.85.214.176;
 envelope-from=patrick.ducksong@gmail.com; helo=mail-ob0-f176.google.com
Subject: notes on http2 draft
Archived-At: <http://www.w3.org/mid/CAOdDvNr4q-=yNjocJ6nMNcnekWDakykHPdvUGZe8Kp8vOphpuA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--001a11c2103ed0452f04dd3bba24
Content-Type: text/plain; charset=ISO-8859-1

Hi All - While I've certainly closely followed the deltas to the http/2
draft I haven't actually sat down and read the thing end to end in a while.
As I have a conflict and won't be able to join you all in CA in June, I sat
down today  to do a full read through and have some feedback on the current
state of the draft. There is a mixture of pure editorial here as well as
some more subtstantive opinion stuff.

First, I want to say thanks to the editors - overall this document is great
progress in terms of readbility and organization.
*
*
*
*
*Section 1.
*
*Furthermore, HTTP/1.1 header fields are often repetitive and verbose,
which, in addition to generating more or larger network packets, can cause
the small initial TCP congestion window to quickly. This can result in
excessive latency when multiple requests are made on a new TCP connection.*

[editorial]
Furthermore, HTTP/1.1 header fields are often repetitive and verbose,
which, in addition to generating more or larger network packets, can cause
the small initial TCP congestion window to quickly fill. This can result in
excessive latency when multiple requests are made on a single new TCP
connection.


1.2
*
message:**A complete sequence of frames.*

I'm not sure that does a lot for me as a definition. It should at least say
something about them sharing the same stream ID.. or am I describing a
stream? Is a message a unidirectional stream? as I said.. it doesn't do a
lot as a definition. The document refers to "window update messages" and
"goaway messages" but I think it means frames in those cases.. it also
talks about "receiver of a message" sending WINDOW_UPDATE which makes it
sound like a message is any data frame (not the complete sequence of
them)... and then again we also talk about "HTTP Messages" which are
something distinct..

I suggest we scrub the term message from the document (and this section)
except when it refers to HTTP messages.


3.2 Connection Magic

Can we make that bikeshed a multiple of 4 bytes long to at least
conveniently align the SETTINGS frame that follows?

3.3.1

* Implementations MUST ignore unsupported and unrecognized frame types. *

I think invalid frame types should be session errors of the MUST NOT send
variety. I know the list has been talking about this lately and I haven't
had an opportunity to chime in. Be liberal in what you receive is overrated
and often fraught with security problems - we can rev the protocol with
ALPN at Internet scale in order to sanely guide extensions as needed. I
know design committees love open ended extensions so my view won't pervail,
but this is exactly the kind of thing that leads to interop doom.

3.3.2

*Implementations with limited resources might not be capable of processing
large frame sizes. Such implementations MAY choose to place additional
limits on the maximum frame size. However, all implementations MUST be
capable of receiving and processing frames containing at least 8192 octets
of data.
*
I'm pretty confident we are just inventing complexity here for no good
reason. The tiny universe of implementations that can cope with 8KB but not
64KB is not worth the complexity. One of the advantages of going with a 16
bit frame size is that it should be small enough for everything to handle
it.

If there is reason to believe 64KB is too big for a population large enough
to care about (remembering of course that HTTP/2 is not a ticket to
Internet admission - if you're really so small that you can't read 64KB
frames the muxing of HTTP/2 is going to be a real challenge too; you're
probably best left using a different protocol. Just coap :)), then let's
lower the max frame size instead of reinventing Path MTU Discovery
complexity. But I think we can just drop this section and require everyone
to deal with 64KB.

3.4

*A "stream" is an independent, bi-directional sequence of frames*

Due to the (expected) compression requirements the frames aren't really
independent of other streams. I know this mistake comes up pretty commonly
on spdy-dev from new implementers of that protocol, so it probably helps to
avoid saying independent here. (section 5.3 does it too).

3.4.1

*Rather, new streams are established by sending a frame whose stream
identifier field references a previously unused stream identifier. *

That's a little too loose. Streams are created by the client through
HEADERS+PRIORITY (4.2.2) and by the server through PUSH_PROMISE. The text
as-is makes it sound more free flowing than that.

*The identifier of a newly established stream MUST be numerically greater
than all previously established streams from that endpoint within the
HTTP/2.0 connection, unless the identifier has been reserved using a
PUSH_PROMISE (Section 3.8.5<http://http2.github.io/http2-spec/#PUSH_PROMISE>)
frame.*

Likewise, PUSH_PROMISE really creates the stream (4.3.1) from the server..
I don't see a reason for the caveat here.


3.4.2

I thought one of the takeaways at Tokyo was to define a change-priority
frame.. Can we do that now? is the intention to use a H+P without any
headers at any point in the stream? If so, I think that should be called
out so that server implementation's don't freak out at seeing H+P at
strange points in the stream.. and I think there is some language in 4.2.2
that could be interpreted as meaning certain colon headers are required to
be in every H+P


3.8.5

*The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in
advance of streams the sender intends to initiate.*

I think I must have missed something on list about this. Why is the
language here general (peer, sender).. why define this so that clients can
generate PUSH_PROMISE ?

3.8.9.4

*After a receiver reads in a frame that marks the end of a stream (for
example, a data stream with a FINAL flag set), it ceases transmission of
WINDOW_UPDATE frames. A sender is not required to maintain the available
flow control window for streams that it is no longer sending on. *

First - since this is a spec, that should be "it MAY/SHOULD/MUST cease
transmission of WINDOW_UPDATE frames". I suggest MUST.

Second - The language isn't clear if this applies to session windows or
just the stream window. I think it is just the stream window and the
receiver still needs to ack^H^H^HWINDOW_UPDATE the session window after the
FINAL flag, but we should say explicitly.

4.2.2

*User-agents MUST support gzip compression. Regardless of the
Accept-Encoding sent by the user-agent, the server may always send content
encoded with gzip or deflate encoding.
[rfc.comment.11<http://http2.github.io/http2-spec/#rfc.comment.11>:
Still valid?]*

I support that still being valid. This is an important performance property
to rely on.

also 4.2.2

*The client initiates a request by sending a HEADERS+PRIORITY frame [...]
if the server receives a data frame prior to a HEADERS or HEADERS+PRIORITY
frame
*

I think that means just "prior to a HEADERS+PRIORITY frame" which is what
is required to open the stream...
4.2.3

*The server responds to a client request using the same stream identifier
that was used by the request. An HTTP response begins with a HEADERS frame.
[...] If the client receives a data frame prior to a HEADERS or
HEADERS+PRIORITY

*
Again, I think that means "prior to a HEADERS" [NOT "or H+P"]. Can server's
send H+P frames? If so, why? and if there is a compelling why, why can't
the response begin with H+P?


hope that helps.

--001a11c2103ed0452f04dd3bba24
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi All - While I&#39;ve certainly closely followed th=
e deltas to the http/2 draft I haven&#39;t actually sat down and read the t=
hing end to end in a while. As I have a conflict and won&#39;t be able to j=
oin you all in CA in June, I sat down today=A0 to do a full read through an=
d have some feedback on the current state of the draft. There is a mixture =
of pure editorial here as well as some more subtstantive opinion stuff.<br>
<br></div><div>First, I want to say thanks to the editors - overall this do=
cument is great progress in terms of readbility and organization.<br></div>=
<div><i><br></i></div><div><i><br></i></div><div><i>Section 1.<br></i></div=
>
<div><i>Furthermore, HTTP/1.1 header fields are often repetitive and verbos=
e,=20
which, in addition to generating more or larger network
         packets, can cause the small initial TCP congestion window to=20
quickly. This can result in excessive latency when multiple
         requests are made on a new TCP connection.</i><br><br></div>[edito=
rial]<br><div>Furthermore, HTTP/1.1 header fields are often repetitive and =
verbose,=20
which, in addition to generating more or larger network
         packets, can cause the small initial TCP congestion window to=20
quickly fill. This can result in excessive latency when multiple
         requests are made on a single new TCP connection.
      <br><br><br>1.2<br><i><br>message:</i><dl><dd><i>A complete sequence =
of frames.</i></dd></dl><p>I&#39;m not sure that does a lot for me as a def=
inition. It should at least say something about them sharing the same strea=
m ID.. or am I describing a stream? Is a message a unidirectional stream? a=
s I said.. it doesn&#39;t do a lot as a definition. The document refers to =
&quot;window update messages&quot; and &quot;goaway messages&quot; but I th=
ink it means frames in those cases.. it also talks about &quot;receiver of =
a message&quot; sending WINDOW_UPDATE which makes it sound like a message i=
s any data frame (not the complete sequence of them)... and then again we a=
lso talk about &quot;HTTP Messages&quot; which are something distinct..=A0<=
/p>

<p>I suggest we scrub the term message from the document (and this section)=
 except when it refers to HTTP messages.<br></p><p><br></p>3.2 Connection M=
agic<br><br></div><div>Can we make that bikeshed a multiple of 4 bytes long=
 to at least conveniently align the SETTINGS frame that follows?<br>

<br>3.3.1<br><br><i> Implementations
            MUST ignore unsupported and unrecognized frame types.
         </i><br><br></div><div>I think invalid frame types should be sessi=
on errors of the MUST NOT send variety. I know the list has been talking ab=
out this lately and I haven&#39;t had an opportunity to chime in. Be libera=
l in what you receive is overrated and often fraught with security problems=
 - we can rev the protocol with ALPN at Internet scale in order to sanely g=
uide extensions as needed. I know design committees love open ended extensi=
ons so my view won&#39;t pervail, but this is exactly the kind of thing tha=
t leads to interop doom.<br>

<br>3.3.2<br><br><i>Implementations with limited resources might not be cap=
able of=20
processing large frame sizes. Such implementations MAY choose
         to place additional limits on the maximum frame size. However,=20
all implementations MUST be capable of receiving and processing
         frames containing at least 8192 octets of data. <br></i><br></div>=
<div>I&#39;m pretty confident we are just inventing complexity here for no =
good reason. The tiny universe of implementations that can cope with 8KB bu=
t not 64KB is not worth the complexity. One of the advantages of going with=
 a 16 bit frame size is that it should be small enough for everything to ha=
ndle it.<br>

<br></div><div>If there is reason to believe 64KB is too big for a populati=
on large enough to care about (remembering of course that HTTP/2 is not a t=
icket to Internet admission - if you&#39;re really so small that you can=
9;t read 64KB frames the muxing of HTTP/2 is going to be a real challenge t=
oo; you&#39;re probably best left using a different protocol. Just coap :))=
, then let&#39;s lower the max frame size instead of reinventing Path MTU D=
iscovery complexity. But I think we can just drop this section and require =
everyone to deal with 64KB.<br>

<br>3.4<br><br><i>A &quot;stream&quot; is an independent, bi-directional se=
quence of frames</i><br><br></div><div>Due to the (expected) compression re=
quirements the frames aren&#39;t really independent of other streams. I kno=
w this mistake comes up pretty commonly on spdy-dev from new implementers o=
f that protocol, so it probably helps to avoid saying independent here. (se=
ction 5.3 does it too).<br>
</div><div><br>3.4.1<br><br><i>Rather, new streams are
         established by sending a frame whose stream identifier field refer=
ences a previously unused stream identifier.
      </i><br></div><div><br></div><div><p>That&#39;s a little too loose. S=
treams are created by the client through HEADERS+PRIORITY (4.2.2) and by th=
e server through PUSH_PROMISE. The text as-is makes it sound more free flow=
ing than that.<br>

</p><p><i>The identifier of a newly established stream MUST be numerically =
greater than all previously established streams from that
         endpoint within the HTTP/2.0 connection, unless the identifier has=
 been reserved using a PUSH_PROMISE (<a href=3D"http://http2.github.io/http=
2-spec/#PUSH_PROMISE" title=3D"PUSH_PROMISE" target=3D"_blank">Section=A03.=
8.5</a>) frame.</i></p>

<p>Likewise, PUSH_PROMISE really creates the stream (4.3.1) from the server=
.. I don&#39;t see a reason for the caveat here.</p><p><br></p><p>3.4.2</p>=
<p>I thought one of the takeaways at Tokyo was to define a change-priority =
frame.. Can we do that now? is the intention to use a H+P without any heade=
rs at any point in the stream? If so, I think that should be called out so =
that server implementation&#39;s don&#39;t freak out at seeing H+P at stran=
ge points in the stream.. and I think there is some language in 4.2.2 that =
could be interpreted as meaning certain colon headers are required to be in=
 every H+P<br>
</p>
<p><br></p><p>3.8.5</p><p><i>The PUSH_PROMISE frame (type=3D0x5) is used to=
 notify the peer endpoint in advance of streams the sender intends to initi=
ate.</i></p><p>I think I must have missed something on list about this. Why=
 is the language here general (peer, sender).. why define this so that clie=
nts can generate PUSH_PROMISE ?</p>
<p>3.8.9.4</p><p><i>After a receiver reads in a frame that marks the end of=
 a stream (for=20
example, a data stream with a FINAL flag set), it ceases
         transmission of WINDOW_UPDATE frames. A sender is not required=20
to maintain the available flow control window for streams that
         it is no longer sending on. </i><br></p><p>First - since this is a=
 spec, that should be &quot;it MAY/SHOULD/MUST cease transmission of WINDOW=
_UPDATE frames&quot;. I suggest MUST.</p><p>Second - The language isn&#39;t=
 clear if this applies to session windows or just the stream window. I thin=
k it is just the stream window and the receiver still needs to ack^H^H^HWIN=
DOW_UPDATE the session window after the FINAL flag, but we should say expli=
citly.</p>
<p>4.2.2<br></p><p><i>User-agents MUST support gzip compression. Regardless=
 of the Accept-Encoding sent by the user-agent, the server may always
         send content encoded with gzip or deflate encoding. <span class=3D=
"" id=3D"rfc.comment.11">[<a href=3D"http://http2.github.io/http2-spec/#rfc=
.comment.11" class=3D"">rfc.comment.11</a>: Still valid?]</span></i></p><p>=
I support that still being valid. This is an important performance property=
 to rely on.</p>
<p>also 4.2.2</p><p><i>The client initiates a request by sending a HEADERS+=
PRIORITY frame [...] if the server receives a data frame prior to a HEADERS=
 or HEADERS+PRIORITY frame <br></i></p><p>I think that means just &quot;pri=
or to a HEADERS+PRIORITY frame&quot; which is what is required to open the =
stream... <br>
</p>4.2.3<br><br><i>The server responds to a client request using the same =
stream identifier that was used by the request. An HTTP response begins
         with a HEADERS frame. [...] If the client receives a data frame pr=
ior to a HEADERS or HEADERS+PRIORITY<br><br></i></div><div>Again, I think t=
hat means &quot;prior to a HEADERS&quot; [NOT &quot;or H+P&quot;]. Can serv=
er&#39;s send H+P frames? If so, why? and if there is a compelling why, why=
 can&#39;t the response begin with H+P?<br>
<br><br></div><div>hope that helps.<br></div></div>

--001a11c2103ed0452f04dd3bba24--