Re: Large Frame Proposal

(sorry -- i'm very late to the response queue this evening)

On Thu, Jul 10, 2014 at 11:14 PM, Jeff Pinner <jpinner@twitter.com> wrote:
> This simply isn't true. We run out of stream IDs more than once a day
> between servers.
>
> On Thu, Jul 10, 2014 at 6:12 PM, Greg Wilkins <gregw@intalio.com> wrote:
>> Apparently my latest compromise proposal didn't format well for all.... so
>> here it is again:
>>
>>   0                   1                   2                   3
>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  |    Type (8)   |               Length (24)                     |
>>  +---------------+-----------------------------------------------+
>>  |    Flags(8)   |          Stream Identifier (24)               |
>>  +===============+===============================================+
>>  |                   Frame Payload (0...)
>>  +---------------------------------------------------------------+
>>
>> In summary, we keep the 8 byte header, but reduce the stream ID to 24 bits
>> and increase the length to 24 bits.
>>
>> I don't see how we can argue that "we might need" 31 bits of stream ID and
>> not apply the same "we might need" logic to length.
>>
>> If 31 bits is too large an effective infinity for length, then it is also
>> too large an effective infinity for stream ID.
>>
>> 24 bits of each is still 16MB frames and 16M streams in a connection.... I
>> think both are reasonable guesses for infinity and this is a good compromise
>> between all the concerns.
>>
>>
>> cheers
>>
>>
>>
>>
>>
>>
>>
>> On 11 July 2014 10:53, Rob Trace <Rob.Trace@microsoft.com> wrote:
>>>
>>> The other problem with the experiment was that WebSockets was the basis.
>>> If the UPGRADE header is removed for any reason (compliant or not) then the
>>> WS connection fails.  In HTTP/2, most of the cases where UPGRADE is removed,
>>> it will simply result in a HTTP 1.1 connection.  That itself makes the
>>> "failure" much different.
>>>
>>> Thanks!!
>>>
>>> -Rob
>>>
>>> -----Original Message-----
>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>> Sent: Wednesday, July 9, 2014 11:45 AM
>>> To: "William Chan (陈智昌)"; K.Morgan@iaea.org
>>> Cc: Roberto Peon; Matthew Kerwin; HTTP Working Group
>>> Subject: Re: Large Frame Proposal
>>>
>>> On 2014-07-09 19:15, William Chan (陈智昌) wrote:
>>> > On Wed, Jul 9, 2014 at 3:30 AM, <K.Morgan@iaea.org
>>> > <mailto:K.Morgan@iaea.org>> wrote:
>>> >
>>> >     Hi Roberto-
>>> >
>>> >     On Wednesday,09 July 2014 08:53, grmocg@gmail.com
>>> >     <mailto:grmocg@gmail.com> wrote:
>>> >      > On Tue, Jul 8, 2014 at 10:11 PM, Matthew Kerwin
>>> >     <matthew@kerwin.net.au <mailto:matthew@kerwin.net.au>> wrote:
>>> >      >> Don't forget that some of us are going to be using IE a
>>> >      >> lot more in future, if that lets us use HTTP/2 without TLS.
>>> >
>>> >     We likely fall into that category as well.
>>> >
>>> >      > Sure, good luck with that 85% success rate :)
>>> >      > Makes sense on an intranet. Not so much on the wild,
>>> >      > wild internet, unless things have substantially changed.
>>> >      > -=R
>>> >
>>> >     Success rate of what?  Are you referring to IE?  Does that browser
>>> >     have a particular success rate issue?  Or are you referring to an
>>> >     issue with clear-text HTTP?  Clearly I am missing some context.  If
>>> >     this was already discussed on-list and you can just point me to the
>>> >     discussion I'll gladly go read it.
>>> >
>>> >
>>> > The success rate is HTTP Upgrade in cleartext over the web as tested
>>> > with a single Google server and Google Chrome clients in an experiment.
>>> > And 85% was for a separate port. For port 80, it was 63%. Details here:
>>> > http://www.ietf.org/mail-archive/web/tls/current/msg05593.html. More
>>> > general analysis at my blog:
>>> > https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/
>>> > #Upgrade, including discussions of other deployment options and their
>>> > success rates.
>>> > ...
>>>
>>> It would be interesting to repeat that experiment. It's now 4.5 years
>>> later, and deploying Websockets may have caused broken code to be fixed.
>>>
>>> Best regards, Julian
>>>
>>
>>
>>
>> --
>> Greg Wilkins <gregw@intalio.com>
>> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
>> http://www.webtide.com  advice and support for jetty and cometd.

Received on Friday, 11 July 2014 06:17:26 UTC