Re: Framing and control-frame continuations

On 8/02/2013 12:42 p.m., James M Snell wrote:
> +1 .. the minimum data size was a bit strange to me as well.
>
> On Thu, Feb 7, 2013 at 3:39 PM, David Morris <dwm@xpasc.com> wrote:
>>
>> On Thu, 7 Feb 2013, Martin Thomson wrote:
>>
>>> One potential concern with this is that the opaque id is too small. We
>>> haven't discussed this, but the current design relies on the fact that
>>> stream identifiers are not reused. A 16 bit id would lead to connections
>>> being rendered useless very quickly. Jeff mentioned that even at 31 bits,
>>> this happens too often anyway.
>>>
>>> That could mean that we need to consider other options anyway, but I
>>> thought the information useful to surface, regardless.
>> I was concerned abut the 16bit Opaque ID as well, it seems small to me.

You seem to be looking at this ID with the SPDY limitation of no re-use 
in mind.

This frame design differs from SPDY in that the IDs are hop-by-hop and 
can be re-used. The F=1 flag on any frame signals that the ID is not 
going to be sent from that direction anymore and the recipient should 
separate the state associated with it from the next frame receive with 
that same ID - which would be constructing a new session.

Our view was that if you are juggling more than 64K active client 
sessions on one TCP connection the latency involved would lead to HOL 
blocking issues. It is more useful to simply open a second connection 
through the same uplink than to complicate scheduling, increase state, 
and packet size. Whats more you can open this second connection with a 
higher expectation that it be HTTP/2 from the start than a new 
connection is able to have.
  Remember this is an ID for grouping a whole pipeline of transactions, 
not just a single page load or request/response pair. So the data 
transfer involved with each ID value is significant.

Okay. This does limit clients to accessing about 2 billion servers 
concurrently. Which is within the limits we face today on high speed 
load balancers. So I understand if it fees a bit cramped.


>>
>> I also noted a comment when this frame header was suggested that frame
>> data must be a minimum of 16 bits. I'm perhaps not yet aware of the
>> bigger picture, but I don't understand that constraint. But it is
>> a desire to maintain 64bit alignment, then just expand the ID and remove
>> the 16 bit minimum constraing.

"should" was the wording used, not "must".

It was for alignment.  24-bit should be enough length, but I still see 
that debate going on about 32-bit or not. If we need 32-bit length field 
we are going to have to shuffle the length and ID down leaving an 8-bit 
hole for future reserved use.


Amos

Received on Friday, 8 February 2013 03:27:39 UTC