RE: Straw-man for our next charter

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

Received on Saturday, 28 July 2012 04:35:19 UTC