FW: [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)

I don't see a public archive of iesg@Ietf.org, but following "note well",
I believe the conversation is public, so for the archives, my comments
on the new HTTPBIS working group recharter and the IESG reply.


-----Original Message-----
From: Larry Masinter 
Sent: Wednesday, September 26, 2012 10:09 PM
To: 'Mark Nottingham'; iesg@ietf.org
Cc: 'Julian Reschke'
Subject: RE: [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)

My comments on the draft charter
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0840.html
(and threads that follow) 
are substantially not addressed.

Line-by-line:

> The Hypertext Transfer Protocol Bis (httpbis) working group in the
> Applications Area of the IETF is undergoing rechartering. The IESG has
> not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2012-09-25.
> 


> 
> 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.

Where has the "misuse of the underlying transport" been described or quantified?
Unless there is some clarity on what problem is being solved, solutions will be elusive

 
> The Working Group will produce a specification of a new expression of HTTP's
> current semantics in ordered, bi-directional streams. 

I don't know how to parse this. What does "in ordered, bi-directional streams" mean? Or is this code for "over TCP or TLS-using-TCP" ?



> As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use
> other transports.

What is the relationship to IPv6 and NAT traversal? Shouldn't those be mentioned explicitly?

> Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point;

I think people want to start with SPDY-as-deployed, and take this draft as if it's a standin for the actual SPDY implementation. But presentations made it clear that this draft doesn't capture a lot of what SPDY actually is. So I wonder if this is really the starting point? Shouldn't it say "start with the current implementation of SPDY as the starting point, with draft-mbleshe- ... the current best document of that?" 


> proposals are to be expressed in terms of changes to that document. Note that
> consensus is required both for changes to the document and anything that
> remains in the document.

I think we form consensus around protocols, not 'things' that are in a document. It's the whole protocol that has (or doesn't have) particular deployment, performance, network utilization models, and the whole isn't the sum of some parts.  And we're looking for "rough consensus" (and "running code"), right?


> As part of that work, the following issues are explicitly called out for discussion:

What does it mean, in a charter, to call things out for discussion? Are these requirements? Things some people want t kick around?


> * A negotiation mechanism that is capable of not only choosing between
>  HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other
>  transports (for example).

Where does the requirement for 'binding of HTTP URLs to other transports' come from? IS the assumption that HTTP/1.x (really? Not just 1.1?) is mandatory to implement?
Is this really just an acceleration path for HTTP/1.1 ?


> * Header compression (which may encompass header encoding or
> tokenisation)

OK, this isn't a requirement, it's a technique.

> * Server push (which may encompass pull or other techniques)

How is this fit in with HTTP/1.1 semantics? Which server-push semantics do you want to capture?

 
> It is expected that HTTP/2.0 will:

Are these requirements, goals, good ideas? I think they have to be requirements

> * Substantially and measurably improve end-user perceived latency in most
>  cases, over HTTP/1.1 using TCP.

The accounts of SPDY performance measurements are sufficiently divergent that this needs refinement or people will be talking past each other.  
Will HTTP/2.0 ever be slower than HTTP/1.1? Which sites will help? I think it's important to get some agreement on common measaurements, and some characterization of which kinds of sites will benefit more and which ones less, and to document that.

> * Address the "head of line blocking" problem in HTTP.

This isn't a "problem in HTTP" as much as it is a problem in having two flow control mechanisms at different layers of the protocol stack.


> * Not require multiple connections to a server to enable parallelism,  thus improving its use of TCP, especially regarding congestion control.

I don't think the problem has been stated clearly and thus getting agreement on improvements will be difficult.


> * 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.

Again, "retain the semantics" is slippery. I believe the requirements mainly fall to requiring the ability to have HTTP 1.1 <-> HTTP 2.0 gateways that do not lose information.


> * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in  intermediaries (both 2->1 and 1->2).

That is "clearly define" is insufficient, it must not only define it, but it must minimize information loss.


> * Clearly identify any new extensibility points and policy for their appropriate use.

This is a mystery? How do you retain semantics and enable gateways while adding extensibility points?

> 
> The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP; 

What does "common" refer to? In which deployments will these goals not be met?


> in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of
> scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content
> Delivery Networks). Likewise, current and future semantic extensions to
> HTTP/1.x (e.g., headers, methods, status codes, cache directives) should  be
> supported in the new protocol.


> 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.

I think these need to be clearly identified and documented, or else there will be a lot of breakage during deployment.


> Explicitly out-of-scope items include:


> * Specifying the use of alternate transport-layer protocols. 

I don't see how this can be a discussion item while it is "out of scope". Perhaps it is not a requirement.

> Note that it  is expected that the Working Group will work with the TLS working group
>  to define how the protocol is used with the TLS Protocol.

Unless this is in the TLS working group charter, it will not happen. Who expects who to do what?

> * Specifying how the HTTP protocol is to be used or presented in a specific
>  use case (e.g., in Web browsers).

What is this referring to?


> The Working Group will coordinate this item with:
> * The TLS Working Group, regarding use of TLS.
> * The Transport Area, regarding impact on and interaction with transport  protocols.


> * The HYBI Working Group, regarding the possible future extension of
> HTTP/2.0   to carry WebSockets semantics.

Is this in scope or not?

> The Working Group will give priority to HTTP/1.1 work until that work is
> complete.


-----Original Message-----
From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
Sent: Thursday, September 27, 2012 11:21 AM
To: Larry Masinter
Cc: Mark Nottingham; iesg@ietf.org; julian.reschke@gmx.de
Subject: Re: [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)

> My comments on the draft charter
> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0840.html
> (and threads that follow) are substantially not addressed.

I believe that, in general, that is because you're in the rough on
them.  Much of what you suggest is text nitpicking, which we could do
forever... and for each item that you might re-word one way, other
want re-worded differently.

There are a few items I'll address directly here:

> Where has the "misuse of the underlying transport" been described or quantified?
> Unless there is some clarity on what problem is being solved, solutions will be elusive

This is background information, and doesn't address the substance of
the WG's work.  I don't see a change as needed.

>> As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use
>> other transports.
>
> What is the relationship to IPv6 and NAT traversal? Shouldn't those be mentioned explicitly?

No.

>> Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point;
>
> I think people want to start with SPDY-as-deployed, and take this draft as if it's a standin
> for the actual SPDY implementation. But presentations made it clear that this draft doesn't
> capture a lot of what SPDY actually is. So I wonder if this is really the starting point?
> Shouldn't it say "start with the current implementation of SPDY as the starting point,
> with draft-mbleshe- ... the current best document of that?"

Not really.  The point is to use technology that's been prototypes as
SPDY, not to "use SPDY" directly, and I think the charter does say
that.  We have added text to that paragraph to clarify that
compatibility with existing SPDY is NOT the goal.  And, yes, we say
"consensus" in the charter; we all understand that to be "rough
consensus", as the IETF works.  I see no need to explicitly change
that.

>> As part of that work, the following issues are explicitly called out for discussion:
>
> What does it mean, in a charter, to call things out for discussion? Are these
> requirements? Things some people want t kick around?

Nitpicking, for sure.  But I've changed it from "discussion" to "consideration".

>> * Substantially and measurably improve end-user perceived latency in most
>>  cases, over HTTP/1.1 using TCP.
>
> The accounts of SPDY performance measurements are sufficiently divergent
> that this needs refinement or people will be talking past each other.

I think this is clear: it is a *goal* (not a requirement) that
HTTP/2.0 generally appear faster to the end user.  It is up to the
working group whether it can achieve that and how, and how it can be
measured.

The IESG approved the httpbis recharter, with a few changes that
include the ones I mentioned above, today.

Barry

Received on Thursday, 4 October 2012 21:12:36 UTC