Re: Large Frame Proposal

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.