Re: multiplexing -- don't do it

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