Remove BLOCKING flag and Depends

[martinthomson]

I can find no good use for the "Depends" field in header blocks. Base is sufficient.

[afrind]

Here's a scenario where it is useful:

1. Encoder sends two HEADERS frames on the table update stream, each inserting one header. The first one is delivered and the second one is lost/awaiting retransmission.

2. Encoder sends a HEADERS frame on a request stream that depends on the header inserted in the first block. Here Base=2 and Depends=1. The Decoder has all of the headers required to process this request, so the use of depends allows it to avoid HoL blocking in this case.

[martinthomson]

In that case, sending base=1 is better in all respects. It can even make header references smaller and more efficient.

If base-depends is the value that the decoder actually needs, send that as the base and do away with depends.

You don't need to signal where your encoder is up to, just where the decoder needs to be up to.

[MikeBishop]

Thought of another way, we're dropping Base and always encoding offsets relative to Depends.

[afrind]

I see your point, and I agree that it works. The problem I have with this approach is that it requires the encoder to make two passes over the headers. In the first pass, it generates all the table updates and calculates Depends, then it encodes all the references relative to Depends.

But the more I thought about it, the encoder must make two passes over the headers even if you use Base and Depends, since Base must also account for any table insertions generated by encoding the current block.

This wasn't true in earlier drafts of QCRAM, where a request stream header block did both inserts and references, and all references in the block were relative to the base prior to encoding the block (this language is still in the draft). This means that some references might be negative relative to Base -- as currently defined any references inserted by the current block would be larger than Base. HPACK doesn't support encoding negative numbers. My QCRAM prototype (and Buck's, which is based on mine), did something truly bizarre to make this work (https://goo.gl/nghK89) - using the maximum length of the dynamic table (MAX_HEADER_TABLE_SIZE / 32) to normalize.

I mention all of this here because if we want the encoder to work in one pass, I still thing we need to have both Base and Depends, and figure out a sane way to reference headers larger than Base.

[martinthomson]

I think that we probably want a separate issue for that last bit. I agree that streaming processing of a header block is a desirable feature.

[afrind]

Filed #1138