Re: HTTP -> Messages -> Transport factoring

On Thu, Apr 5, 2012 at 9:46 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
> 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")?
>

I think you're basically talking about sections 2 & 3 of the SPDY spec?
 I'm okay with that, and I think any reasonable protocol will do this as a
mechanism to ensure reasonable HTTP/1.1 to HTTP/2.0 transition.

In general, I think we should stop talking about unknown transports or
transports which we don't think are targets (and I put SCTP into this
category).  Designing for transports that don't exist is likely to make our
implementations on the transports that do exist (TCP) watered down or
worse.  In other words, the least-common-denominator sucks....  Further,
NOBODY is going to implement HTTP/2.0 on the unknown transport.  So
whatever we do design for these unknown transports will be untested and
purely theoretical.

Mike




>
>
> 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
> http://www.mnot.net/
>
>
>
>
>