comments on draft-mbelshe-httpbis-spdy-00

I have a stack of comments and questions for the SPDY document.  This is
a taste of what needs to get done to get this document through the
standardization process.  Before I get to what's there, let me get to
what's not, first:

Most importantly, there needs to be clarity in the connection model, and
currently there is nothing.  The HTTP scheme implies use of port 80. 
What next?  Seems to me there are many choices:

1.  Try sending a 2.0 message and see what happens
2.  Wait for a response from the server that has the right version #
3.  Use some sort of DNS trickery to divine the appropriate version –
AND port.
4.  Go with a happy eyeballs approach and try BOTH 1.1 and 2.0
initially, perhaps with a slight delay on 1.1 with caching of state.

But we have to pick one.

Rinse and repeat for TLS, albeit the mechanism may be better advertised.

Speaking of advertising, it'd be nice if there was a capabilities
exchange.  SETTINGS sort of goes there but requires more round trips.


In Section 2.2.1:

With "Version" defined in Control frames, what are the semantics for a
mismatch?  Is an error generated?

There is discussion of a both a minimum and maximum frame size, but
there is no negotiation defined.

In Section 2.2.2:

Under "Data frame processing requirements", experience shows that it is
better to shut down a connection when the protocol goes awry, and no
more so is this the case than with multiplexed connections.

Section 2.3:

Nit: "Streams may be cancelled."  I think you meant closed.

2.3.1 (and elsewhere):

I think RST_STREAM should be removed in favor of dropping a connection
with an error when one side or the other just gets it wrong.  This is
not protocol school.  There should be enough diagnostics produced to
indicate what the problem is, and then go off.

2.3.2:

I don't know about anyone else, but first I laughed about the sentence
about streams not wrapping, and then I stopped, when I realized that
thus far we have stretched every possible HTTP parameter to its max, so
why not this too?  What I don't understand is why all the verbiage about
the ordering of streams in the first place.  What's the goal?  Again,
when sending protocol errors, best to shut down the connection afterwards.

This paragraph requires additional discussion:

>    Upon receipt of a SYN_STREAM, the recipient can reject the stream by
>    sending a stream error (Section 2.4.2) with the error code
>    REFUSED_STREAM.  Note, however, that the creating endpoint may have
>    already sent additional frames for that stream which cannot be
>    immediately stopped.

This means the sender MUST retain any data transmitted and accepted at
the TCP layer until the application sends "REFUSED_STREAM".

Finally a nit: do you really mean "monotonic" or do you mean "linearly"
or "in increments of two"?

Section 2.3.3:

Oh where to begin?  First of all, why not match nearly every other
network protocol out there, especially IP, and have at least the higher
value match higher priority?  But beyond this, experience shows that
stream priority behaviors have to be defined.  Also, once we have
streams some fool, quite possibly this one, will ask the question: and
is there a need for a mapping to DSCPs should someone try to tunnel IP
through one of these streams?


Section 2.3.6:

I like that in this particular instance you produce a specific error
STREAM_ALREADY_CLOSED where elsewhere you state a simple
PROTOCOL_ERROR.  However, in this case, since it *is* a protocol error,
as I've argued previously, the connection should be closed.


Section 2.4.1: This needs work.  You want to handle several different
types of errors:

1.  Protocol errors (shut down the connection and go away)
2.  Application errors (these are errors that occur above the framing
layer, but are NOT protocol errors).  An application error may be a
resource constraint, a permissions problem, or some other
application-layer error (e.g, "451 my boss is a jerk").

Each of these sorts of errors can happen at either the stream or session
level.  1 is easy: just shut down the connection.  2 is the one that
needs to be clarified, IMHO.  GOAWAY may not be the entirely correct
approach.  This is something that BEEP got right, IMHO.  There's a
pretty clean separation between the BEEP layer and the layer above.


Section 2.5: Huh?  What is the actual meaning of "intelligently" here?

Section 2.6.1: how do you derive the size for "slot"?  Also, this should
be reviewed by the TLS folks.  How does it relate to the
SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE setting?

Section 2.6.3:

Why is there a CANCEL and also FLAG_FIN?

Error code 10: Invalid credentials.  Is this best left to "permission
denied" without getting into the reasons in the protocol (just log them).

Section 2.6.5:

If either side can send this, then a server is open to any number of
resource attacks, especially as regards to persistent settings.

Section 2.6.9 needs to be reworked with the assumption that TLS may not
be there at all.

Section 3.1: Connection management

You might want to amend this to allow clients to open an additional
connection once all stream values are used. 

Skipping along...

In Section 3.3:

What does it mean: "Browsers MUST implement throttles to protect against
unreasonable push attacks"?  How shall browsers throttle?  By delaying
response?

Received on Tuesday, 14 August 2012 14:35:39 UTC