Re: Straw-man for our next charter

Without re-hashing what's already been said, I'll point out that the "Not
as SPDY as You Thought" isn't a test of "what performance do we get in a
world of SPDY" but rather "What performance do we get in a world of partial
SPDY deployment." Mike has a nice in-depth writeup at
http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-you-thought/

-Ian

On Fri, Jul 27, 2012 at 9:34 PM, Larry Masinter <masinter@adobe.com> wrote:

> I'd suggest the HTTP/2.0 work would be best served by first focusing on
> documenting "substantial and measurable improvement".
> I suggest the charter not be extended to accept proposals and start on
> development of the protocol itself until this is done.
>
> There are conflicting characterizations of SPDY performance results (the
> results aren't in conflict as much as whether you could summarize the
> results as "better").
>     http://www.ietf.org/proceedings/83/slides/slides-83-httpbis-3.pdf said  "Google recently reported that SPDY over SSL is now faster than HTTP
> without SSL" plus "BoostEdge paper confirms Google numbers", which I'd take
> to mean that it's always faster.
>
>    but  http://www.guypo.com/technical/not-as-spdy-as-you-thought/  it
> isn't as SPDY as you (Someone) thought, and noted many circumstances where
> it didn't help.
>
> Unless there's agreement on what "improvement" is, it's hard to even
> discuss features for how well they "improve".
>
>
> What can site administrators depend on, expect from a SPDY upgrade?
>
> I'm still concerned about head-of-line blocking that comes from
> multiplexing and doing flow control at two levels of the protocol stack. It
> seems intrinsically a likely problem, for which the only solution is proper
> management and control of performance of all of the sources of data
> ("scheduling").  I think getting an agreement on why that isn't a problem
> here (or at least, how to minimize the problem) first would help, too.
> With head-of-line blocking, the latency has spikes, and averages won't
> suffice if what you care about is common-worst-case.
>
> Larry
> --
> http://larry.masinter.net
>
>
>
>
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
> Sent: Wednesday, July 25, 2012 5:03 AM
> To: ietf-http-wg@w3.org
> Subject: Re: Straw-man for our next charter
>
> On 25/07/2012 7:53 p.m., Mark Nottingham wrote:
> > Next week in Vancouver, we'll discuss both the candidate proposals for
> HTTP/2.0 and whether we should re-charter to begin that work, confirming
> consensus on the list afterwards.
> >
> > Assuming we do choose one, we'll also need to discuss the charter
> itself. To facilitate that, I've pasted a straw-man of what such a charter
> might look like below.
> >
> > Please familiarise yourself with it. We can discuss on-list beforehand,
> of course, but please realise that we need to do this step-by-step, so
> don't get too far ahead of the conversation.
> >
> > Note -- this currently JUST covers the protocol discussion, not the
> authentication half; I've omitted it because there are a few different ways
> that work might end up, and it's going to need discussion before we can
> write even straw-man charter text.
> >
> > Cheers,
> >
> > ---8<---
> > This Working Group is charged with maintaining and developing
> > the "core" specifications for HTTP.
> >
> > The Working Group's specification deliverables are:
> > * A document (or set of documents) that is suitable to supersede RFC
> 2616 as
> >    the definition of HTTP/1.1 and move RFC 2817 to Historic status
> > * A document cataloguing the security properties of HTTP/1.1
> > * A document (or set of documents) that specifies HTTP/2.0, an improved
> >    binding of HTTP's semantics to an underlying transport.
> >
> > HTTP/1.1
> > --------
> >
> > HTTP/1.1 is one of the most successful and widely-used protocols on the
> > Internet today. However, its specification has several editorial issues.
> > Additionally, after years of implementation and extension, several
> > ambiguities have become evident, impairing interoperability and the
> ability
> > to easily implement and use HTTP.
> >
> > The working group will refine RFC2616 to:
> > * Incorporate errata and updates (e.g., references, IANA registries,
> >    ABNF)
> > * Fix editorial problems which have led to misunderstandings of the
> >    specification
> > * Clarify conformance requirements
> > * Remove known ambiguities where they affect interoperability
> > * Clarify existing methods of extensibility
> > * Remove or deprecate those features that are not widely implemented and
> >    also unduly affect interoperability
> > * Where necessary, add implementation advice
> > * Document the security properties of HTTP and its associated mechanisms
> >    (e.g., Basic and Digest authentication, cookies, TLS) for common
> >    applications
> >
> > It will also incorporate the generic authentication framework from RFC
> > 2617, without obsoleting or updating that specification's definition of
> > the Basic and Digest schemes.
> >
> > Finally, it will incorporate relevant portions of RFC 2817 (in
> > particular, the CONNECT method and advice on the use of Upgrade), so
> > that that specification can be moved to Historic status.
> >
> > In doing so, it should consider:
> > * Implementer experience
> > * Demonstrated use of HTTP
> > * Impact on existing implementations and deployments
> >
> > HTTP/2.0
> > --------
> >
> > There is emerging implementation experience and interest in a protocol
> that
> > retains the semantics of HTTP without the legacy of HTTP/1.x message
> > framing and syntax, which have been identified as hampering performance
> and
> > encouraging misuse of the underlying transport.
> >
> > The Working Group will produce a specification of a new expression of
> HTTP's
> > current semantics in ordered, bi-directional streams. As with HTTP/1.x,
> > the primary target transport is TCP, but it should be possible to use
> > other transports.
> >
> > Work will begin using XXX as a starting point; all proposals are to be
> expressed
> > in terms of changes to the that document.
>
> I just think I'll throw a spanner in the general direction of the works
> here....
>
> How realistic is it to expect the HTTPbis 1.1 draft documents fill that
> role? At least we can guarantee that modifications to adjust them for
> 2.0 specifics will not loose or add any features unintentionally that
> could affect HTTP/1.1 compatibility.
>
>
> >
> > It is expected that HTTP/2.0 will:
> > * Substantially and measurably improve end-user perceived latency in most
> >    cases, over HTTP/1.1 using TCP.
>
> "measureably ... perceived" does not stack up.
> Surely we can aim for actual measurable efficiency rather than just
> perceived.
>
> Possibly also improvement over *optimized* 1.1 would be a good aim.
>
> > * Not require multiple connections to a server to enable parallelism.
> +1.
>
> > * Require no more configuration or tuning than current HTTP deployments;
> >     preferably, less.
>
> What do you means by this?
>
> > * Retain the semantics of HTTP/1.1, leveraging existing documentation
> (see
> >    above), including (but not limited to) HTTP methods, status codes,
> URIs, and
> >    where appropriate, header fields.
>
> see above regarding "XXX as a starting point".
>
> > * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in
> >    intermediaries (both 2->1 and 1->2).
> > * Clearly identify any new extensibility points and policy for their
> >    appropriate use.
>
> +1.
>
> >
> > The resulting specification(s) are expected to be meet these goals for
> common
> > existing deployments of HTTP; in particular, Web browsing (desktop and
> > mobile), Web serving (at a variety of scales), and intermediation (by
> proxies,
> > corporate firewalls, "reverse" proxies and Content Delivery Networks).
> >
> > Note that this does not include uses of HTTP where non-specified
> behaviours
> > are relied upon (e.g., connection state such as timeouts or client
> affinity,
> > and "interception" proxies); these uses may or may not be enabled by the
> final
> > product.
> >
> > Explicitly out-of-scope items include:
> > * Specifying the use of alternate transport protocols. Note that it
> >    is expected that the Working Group will define how the protocol is
> used
> >    with the TLS protocol.
> > * Specifying new semantics for HTTP (whether specific to HTTP/2 or not).
> >    However, the Working Group may request a re-charter to start work on
> such
> >    items (during or after work on HTTP/2.0), provided there is consensus
> to
> >    do so, and it does not interfere with work on the "core" (both
> HTTP/1.x and
> >    HTTP/2.0).
>
> +1. Although I predict that having multiplexing on the table will bring
> up the need for new hop-by-hop features on 2.0 connections. Specifically
> flow control features.
>
> Amos
>
>
>