Re: Large Frames, Continuations, Flow Control, and changing HPACK

> Can you please explain why the SYN_STREAM frame is necessary? It seems to me that just removing the reference set would get rid of the need for CONTINUATION frames since there would no longer be a requirement to process all headers together as one big "jumbo block", just a requirement to process frames in order.
>
> To be short, it seems to me that getting rid of the reference set also solves 5, 6, & 7??

There are two benefits of SYN_STREAM (one is desirable, the other is
necessary given some caveats).

1) One of the design drivers for CONTINUATION over multiple frames
initially was that there were certain fields you didn't want repeated.
Take PUSH_PROMISE as an example where SID = StreamID and PID =
Promised Stream ID. It was preferable to send

PUSH_PROMISE(SUI 2, PID 3) CONTINUATION(SID 2, END_HEADERS)

over

PUSH_PROMISE(SID 2, PID 3) PUSH_PROMISE(SID 2, PID 3, END_HEADERS)

because it avoided having to discuss what to do if the promised id's
were different, i.e.

PUSH_PROMISE(SID 2, PID 3) PUSH_PROMISE(SID 2, PID 1000, END_HEADERS)

There is a similar but less compelling argument for HEADERS if they
have different priority field data.

2) This one is necessary if you want to flow control HEADERS.
Currently HEADERS acts both as a "data" frame and a "control" frame
since it both carries the header block and also opens the stream. If
you flow control HEADERS then it may be that there is not a large
enough window size to send the HEADERS frame. This implicitly blocks
opening the stream as well. In fact there is no way to even signal
that you want to increase the window size (for example by sending
BLOCKED on the stream) because the stream can't be opened.

Introducing SYN_STREAM solves both of these problems:

Separating stream creation from HEADERS means it becomes a "data"
frame, making it possible to flow control without blocking stream
creation. Doing so also removes the race condition between opening the
stream and prioritizing it, so the only thing a HEADERS frame now has
to carry is the header block fragment itself. This allows us to also
remove the header block from PUSH_PROMISE (another control frame that
we don't want to flow control) and replace it by a sequence of HEADERS
frames, removing the need for text on what to do if the control fields
(like promised stream id) vary within the sequence.

Received on Tuesday, 8 July 2014 21:48:35 UTC