W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Framing and control-frame continuations

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 7 Feb 2013 19:56:00 -0800
Message-ID: <CAP+FsNf5ok-VfztpW69VpFip2n2V-nz7JCy+xMS4Sdn4Ma+DJQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
>
>
Received on Friday, 8 February 2013 03:56:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 February 2013 03:56:31 GMT