Re: Straw-man for our next charter

On Sun, Jul 29, 2012 at 10:45 AM, Larry Masinter <masinter@adobe.com> wrote:

> Your post is consistent with the assertion that there isn't agreement yet
> about what "faster than HTTP/1.1" means, or how to compare proposals for
> improvement. And neither measured worst case latency or real network
> traffic with buffer bloat, or situations that would detect the impact of
> HOL blocking.
>

While SPDY leaves a tiny HOL issue, it fixes the massive one from HTTP/1.1,
which can only load a couple of resources in parallel per domain (2 by
spec, 6 by implementation best practices).  The tradeoff turns out to be a
boon in terms of reduced latency while also using fewer network resources.

I haven't seen any data that suggests otherwise.  Did I miss something?

For bufferbloat, using 1 TCP connection is strictly better than many - TCP
implementations don't throttle with multiple connections in mind; so while
HTTP systematically circumvents slow start by way of more and more
connections, SPDY embraces TCP's throttling and enables future enhancements
at the transport layer.


> Features like sniffing where the receiver needs to look at initial
> segments of traffic before dispatching exacerbate the impact of uneven
> latency by imposing an otherwise unnecessary serialization constraint.
>


>
>

> deployment issues are in scope... they are what drive the push for SSL in
> the first place.
>
> And if sites wont see improvement  (or even a performance hit) in a world
> of partial deployment of HTTP 2.0, who (that isn't already using SPDY as
> is) would deploy it?
>

We should expect that on the road to full deployment of HTTP/2.0 we will
see partial deployment of HTTP/2.0.  It seems perfectly fine to me that as
you deploy it more completely the benefit increases.

Mike



>
> -----Original message-----
>
> *From: *"ifette@google.com" <ifette@google.com>*
> To: *Larry Masinter <masinter@adobe.com>*
> Cc: *"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>*
> Sent: *Sun, Jul 29, 2012 07:14:02 GMT+00:00
> *
> Subject: *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
>>
>>
>>
>