W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

HTTP -> Messages -> Transport factoring

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 5 Apr 2012 11:46:28 -0500
Cc: William Chan (陈智昌) <willchan@chromium.org>, Willy Tarreau <w@1wt.eu>, patrick mcmanus <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mike Belshe <mike@belshe.com>, Peter L <bizzbyster@gmail.com>
Message-Id: <C8D8A787-7C1B-486B-8231-83852A03F6B1@mnot.net>
To: Roberto Peon <grmocg@gmail.com>

It seems like a set of deliverables for us could then be:

1. A format for HTTP messages that shows how to get one into a set of bits, but doesn't show how to get those bits onto a transport protocol
2. A specification of how to get those messages across a reliable, in-order, not-multiplexed transport 
3. Details of #2 on TCP

leaving the specification of #2 on other suitable transports for future / other work, as well as leaving #1 on multiplexed transport for future / other work.

How do people feel about this? In particular, is the separation between #2 and #3 necessary and good? Does anyone want to attempt more in this WG (I'm hearing many people saying "no")?

On 05/04/2012, at 11:32 AM, Roberto Peon wrote:

> So long as we provide an appropriate mapping onto transports that either do or do not multiplex, I think we can take advantage of any improvements in transports.
> I think that we should be able to assume reliable and in-order guarantees are provided for any stream of a transport that we'd use, however... the use of any transport that does not offer those guarantees would add much complexity for dubious gain.
> -=R
> On Apr 5, 2012 6:29 AM, "William Chan (陈智昌)" <willchan@chromium.org> wrote:
> On Thu, Apr 5, 2012 at 3:13 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> On Thu, 2012-04-05 at 10:25 +0200, William Chan (陈智昌) wrote:
> >  stack. The real solution is to fix the transport (new UDP-based
> > protocol anyone?), but that's beyond the scope of this work.
> Although I agree a udp based proposal is unlikely to bear fruit, I don't
> see that it is a priori beyond the scope of the HTTP/2 work. I think our
> charter asks for proposals that reduce TCP connection count - that would
> certainly qualify :) WebRTC is doing something kind of similar with
> LOL :)
> sctp/dtls/udp layering, right?
> There are a huge amount of unknowns there, which is a terrific argument
> for rallying around spdy because it is well experimented with already
> and is known to solve some hard problems. But if someone were to invest
> in a prototype, a spec, and some test results of a udp system I would
> find that a much more interesting thing to consider than another
> proposal for some variation of spdy-lite.
> It's still vaporware so I'm not going to say much more than "we (Google) know and we're looking into it." The publicly visible updates can be seen here: http://code.google.com/p/chromium/issues/detail?id=121577 && http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/net/network_stats.h.
> I'd prefer we focus on SPDY over TCP for now, and we can discuss what SPDY might look like over different transports in the future when we have a concrete proposal and data, rather than diving into that rathole right now. I'm personally a big fan of proposing things when you have data to back up your claims.
> My weak understanding of dtls is that it has the potential to save
> another rtt over the tcp version :)
> -Patrick

Mark Nottingham
Received on Thursday, 5 April 2012 16:46:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC