Re: Framing and control-frame continuations

I've certainly had proxies using up all ephemeral ports for HTTP to
multiple IPs before, causing queuing and blocking, so 16 bits of concurrent
ID space is definitely too small.
While I admit I'm not as worried as Jeff about having to do something every
2 billion transactions or so, I can say that 64k would cause more
connection open/close than I feel comfortable with.
Note that the flag you're proposing would require waiting for a FIN-ACK
from the other side, else you have a nasty race.
-=R


On Thu, Feb 7, 2013 at 7:27 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> 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
>
>