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

Re: multiplexing -- don't do it

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 5 Apr 2012 09:32:37 -0700
Message-ID: <CAP+FsNda0SXsRe-nhjxQ-GodT4Cjzx4JZH9o4oxEdtcTFMP=jQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: 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>
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
>>
>>
>>
>>
>
Received on Thursday, 5 April 2012 16:33:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:59 GMT