Re: Large Frame Proposal

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:15:24 UTC