Re: SPDY Review

On Thu, Jun 7, 2012 at 9:18 AM, Martin Nilsson <nilsson@opera.com> wrote:

> <snip>
> 4.1. Handshake
>
>  We believe the versioning semantics needs to be better formalized,
>  and that the version information can be moved into a connection
>  handshake. In its simplest form a SETTINGS frame is always sent
>  first in the connection, establishing the version and connection
>  parameters. A connection should be rejected if the version is out of
>  range for the server. The server should respond with the highest
>  supported protocol version before closing.
>

SETTINGS frames are always optional, so we can't rely on them for
discovering unsupported versions. However, I agree that the "version" field
should only appear in SYN_STREAM frames, as the spec specifically states it
should be ignored in all others.

4.2. Field sizes
>
>  Define a reasonable range for each field, based on statistics where
>  possible, and resize them where appropriate.
>

Agreed.

4.3. Specialized HTTP frames
>
>  For the common case of using SPDY as an HTTP substitute, create
>  special frames to open HTTP request-response and HTTP push
>  streams. This removes the need for explicit unidirectional flag and
>  mandatory header values.
>

The UNIDIRECTIONAL flag is set to be removed in spdy/4. Elsewhere, you
advocate moving information specific to request-response and pushed streams
to the headers section, which appears to conflict with this proposal.

4.4. Typed key-value pairs
>
>  Create a better structure for the key-value pair lists where it is
>  possible to have binary values and typed values. The types can
>  include binary string, integer and list. Standardize how all
>  standard HTTP headers should be normalized and typed, including
>  which ones are disallowed to be in lists of multiple values.
>

This sounds like a can of worms. Depending on the serialization format you
look at, there's already a zoo of possible "types" to encode data as - and
what if you want something outside the norm, like JSON? The only problem
you raised with the current encoding is that binary data would have to be
escaped; this looks like overkill.

 Introduce a mechanism that allows headers to be properties of the
>  stream, to be used internally in SPDY, and move optional parameters
>  and parameters that seldom deviate from default value to use
>  internal headers (e.g. priority, slot, associate-to-stream-id). This
>  also provides a mechanism for easy extension.
>

I'll admit, the criteria for choosing which parameters become headers and
which become binary fields has always been a bit murky. It appears to
depend on whether the parameter is framing-specific, and whether it's
variable-length. I agree that this needs more discussion.

4.5. Push
>
>  The client needs to be in control of what pushed data to accept. A
>  simple accept flag may be too simplisitc, as it prevents tricks like
>  redirect collapsing, but would be an improvement nevertheless.
>

The client can already RST_STREAM+CANCEL unwanted pushed streams (and may
do so selectively after reading their :scheme/:host/:uri headers). More
fine-grained control is the domain of cache directives.

4.6. Flow control
>
>  Remove the SPDY flow control and instead introduce a control
>  mechanism to actively put a stream on hold. If priority is moved to
>  stream properties, as suggested in 3.4., dynamic reprioritization is
>  possible.
>

We've been discussing possible changes to the flow control mechanism on
spdy-dev, and this idea for a txon/txoff signal did come up. Although some
still support it, others (including myself) have pointed out that it
requires receivers to buffer at least a BDP's worth of data for each
stream. For endpoints sitting on high-bandwidth pipes that handle large
numbers of concurrent requests (like gateways or non-blocking servers),
this is logistically impossible.

4.7. Header compression
>
>  Remove the header compression dictionary. It creates little benefit
>  for the added complexity it introduces.
>

This paper (http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf)
claims 8% size reduction of the request header and an additional 15%
reduction of the reply header. Giving more detail on the benchmarks you
cited earlier would help us evaluate the differing results.

4.8. Asynchronous headers
>
>  Specify the asynchronous header feature stricter so that overwriting
>  HTTP headers isn't allowed and the receiver knows in advance what
>  headers will be generated later.


Sending duplicate headers, whether within the same SYN_REPLY/HEADERS frame
or across HEADERS frames, is already explicitly disallowed, though perhaps
the language could be moved to a more prominent place in the specification.

Alek