HTTP/2 States and Frame Types <draft-ietf-httpbis-http2-17>

Co-authors & editors,

This is the last of my review postings.

We're working on a generic framing protocol within the TCP Data. The 
main reason I was reading HTTP/2 was to understand it as a set of 
requirements for what we're doing. I don't expect many (any?) of the 
comments below to change the protocol spec, but if someone could 
spare the time to answer my questions, it will help us understand 
what you were trying to do with HTTP/2, so we can better meet its 
needs in future.

I found it very hard to understand the HTTP/2 spec, because it was 
largely a stream of assertions, with hardly any rationale. I read a 
book on SPDY to try to understand some of the rationale, but I got a 
similar barrage of assertions.

All that said, you might want to try to improve the spec with some of 
these answers, because poor comprehensibility leads to bugs, 
particularly bearing in mind non-English implementers need to 
understand the spec too.

Apologies if these questions have been raised before. I tried to 
check with a quick search of the archives and I read the IESG 
reviews, but I may have missed stuff.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-2.1>2.1. 
Document Organization
"...this specification does not define a completely generic framing layer..."

Given the prevalence of HTTP, was the design of HTTP/2 framing 
designed for hardware (or software) offload (i.e. required to be 
possible to implement separately from the contents of the frames)? 
Was this a requirement? It's not mentioned. I'm sure it will be done 
now that HTTP/2 is specified.

A great shame it won't be generic, but that's water under the bridge now.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.1.2>5.1.2. 
Stream Concurrency
"   Streams in either of the "reserved" states do not count toward the
    stream limit."
Why? Once reserved, they require stream state.
In fact, it would be useful to enumerate the amount of state needed 
for each stream.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6>6. 
Frame Definitions
Why the particular set of frame types, and not more or less?

This raises the question of why the frame types have all been defined 
as completely independent. A multi-part frame structure could have 
been used that constrains the order of frames to that required (I've 
done a back of envelope design for this). Without structural ordering 
constraints, it will be necessary to define a very large number of 
ordering errors (many more than the draft currently states).

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.1>6.1. DATA
Why does padding have to be filled with zeros? There are good 
cryptographic reasons for not requiring this. And random padding 
could help ensure that retransmissions are significantly different 
from the original transmission.

Why is the pad length and padding field included in flow control? An 
http receiver (client or intermediate) can discard padding without 
consuming buffer memory, and an intermediate node can then 
reconstruct (a potentially different amount of) padding.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.2>6.2. 
HEADERS
Why is the END_HEADERS flag needed? Given HEADERS frames MUST be 
contiguous, why can't the Length field of the HEADERS frame specify 
the length of one frame for all http headers, without all the 
complexity of CONTINUATION frames and an END_HEADERS flag?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.5>5.3.5. 
Default Priorities
Why is the default stream weight 16?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.3>6.3. 
PRIORITY
"The PRIORITY frame can be sent on a stream in any state, though it
    cannot be sent between consecutive frames that comprise a single
    header block"
Why?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-6.5>6.5. 
SETTINGS
"     ACK (0x1):  [...] When this
       bit is set, the payload of the SETTINGS frame MUST be empty.
       Receipt of a SETTINGS frame with the ACK flag set and a length
       field value other than 0 MUST be treated as a connection error
"
Why? It would be more efficient, and surely cause no harm, to ack on 
the same frame as sending a setting in the other direction.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.6>6.6. 
PUSH_PROMISE
Why is the whole PUSH_PROMISES approach needed? Given a request 
doesn't have to use the same stream ID as a response.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.7>6.7. PING

I don't see the point of the two apparently arbitrary restrictions below.

"  PING frames are not associated with any individual stream.
"
Why prevent an implementer from monitoring the round trip of a specific stream?

"  PING responses SHOULD be given higher priority than any
    other frame.
"
This prevents an implementation from using PING to measure the buffer 
that all other frames have to endure.





Bob



________________________________________________________________
Bob Briscoe,                                                  BT