Session Erros vs Stream Errors

[Ryan Hamilton]

Hi All,

I'm working on a framework for testing SPDY servers to ensure that they meet the requirements of the SPDY spec, and have a question for the group.  Section 2.4 of the spec describes two types of errors: Session and Stream.  Session errors result in GOAWAY, and Stream errors result in RST_STREAM.  Quoting from the spec:

• A session error is any error which occurs outside the context of a specific stream.
• A stream error is an error which occurs within the context of a stream

This seems reasonable, though it's not entirely clear what "the context of a specific stream" means.  I might have thought that any problems handling a frame with a Stream ID should be considered a Stream error (in the context of that stream id), all other problems should be considered Session errors.  However, Section 2.3.2 Stream Creation says:

It is illegal for the stream-id to not increase with each new stream. If an endpoint receives a SYN_STREAM with a stream id which is less than any previously received SYN_STREAM, it MUST issue a session error (Section 2.4.1) with the status PROTOCOL_ERROR.

It is a protocol error to send two SYN_STREAMS with the same stream-id. If a recipient receives a second SYN_STREAM for the same stream, it MUST issue a stream error (Section 2.4.2) with the status code PROTOCOL_ERROR.

So this muddies the issue of what "the context of a specific stream" means.  Here's a concrete example.  The spec requires that that a SYN_STREAM frame have a value for flags of either 0x00, 0x01 or 0x02.  If a SYN_STREAM frame (which is otherwise well formed) is received with a flags value of 0xFF, should this be considered a stream error in the context of the StreamID specified in the SYN_STREAM frame, or a session error?  I would guess this would be a stream error, but I would not be surprised if it were a session error.

I would appreciate any thoughts on this subject.

Cheers,

Ryan

 

[William Chan (陈智昌)]

"Context of a specific stream" is indeed not well specified. I have personally evaluated these on a case by case basis. In a previous pass through the spec, I think I tried to label each error as a stream or session error as I saw fit, in order to try to clarify the situation.

On Tue, Jan 31, 2012 at 1:29 PM, Ryan Hamilton <r...@google.com> wrote:

Hi All,

I'm working on a framework for testing SPDY servers to ensure that they meet the requirements of the SPDY spec, and have a question for the group.  Section 2.4 of the spec describes two types of errors: Session and Stream.  Session errors result in GOAWAY, and Stream errors result in RST_STREAM.  Quoting from the spec:

• A session error is any error which occurs outside the context of a specific stream.
• A stream error is an error which occurs within the context of a stream

This seems reasonable, though it's not entirely clear what "the context of a specific stream" means.  I might have thought that any problems handling a frame with a Stream ID should be considered a Stream error (in the context of that stream id), all other problems should be considered Session errors.  However, Section 2.3.2 Stream Creation says:

It is illegal for the stream-id to not increase with each new stream. If an endpoint receives a SYN_STREAM with a stream id which is less than any previously received SYN_STREAM, it MUST issue a session error (Section 2.4.1) with the status PROTOCOL_ERROR.

This is a good question. It's not clear to me we should have this be a session error, unless the concern is that the peer has unrecoverably horked the shared compression context somehow (compressed the frames in a different order than they are written out to the socket). I guess an argument for using a session error is a wrong stream id may be indicative of a more pervasive problem which would lead to all future stream ids being corrupt and getting rejected, in which case it's probably better just to terminate the session earlier.

 

It is a protocol error to send two SYN_STREAMS with the same stream-id. If a recipient receives a second SYN_STREAM for the same stream, it MUST issue a stream error (Section 2.4.2) with the status code PROTOCOL_ERROR.

So this muddies the issue of what "the context of a specific stream" means.  Here's a concrete example.  The spec requires that that a SYN_STREAM frame have a value for flags of either 0x00, 0x01 or 0x02.  If a SYN_STREAM frame (which is otherwise well formed) is received with a flags value of 0xFF, should this be considered a stream error in the context of the StreamID specified in the SYN_STREAM frame, or a session error?  I would guess this would be a stream error, but I would not be surprised if it were a session error.

I would consider it a stream error.

[Mike Belshe]

This is interesting indeed.

I have updated the specification to clarify "context of a stream".  Unfortunately, I believe this is going to remain a little unclear and also a little implementation dependent.  That sounds horribly wrong at first, but here is why.

The idea is to separate errors which can be confined to a specific stream from errors which break all streams.  As Will points out, one of the biggest session-level errors is when the compression context gets out of sync.  This should never happen, of course.  But imagine you're processing a SYN_STREAM frame, and you see flags that you do not understand in your implementation.  A good implementation will process the entire SYN_STREAM anyway, and process the compressed header block.  By doing this, the overall SPDY session can continue.  However, a lesser implementation may barf immediately upon seeing the bad flags.  If  it does not continue processing, and does not process the compressed headers, the compression context will fall out of sync.  In this case, the error becomes a session-level error, as future streams are also corrupted.

Obviously, we should encourage implementations to be "good" implementations.  But, I don't think I can fully enumerate all ways that a receiver of a frame might need to barf internally.  So, depending on the type of error, and the implementation, it seems reasonable that sometimes this error would corrupt the whole session and not be isolated.

Mike