Re: Google's QUIC

[Christopher Morrow <morrowc.lists () gmail com>]

On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez
<alvarezp () alvarezp ods org> wrote:
> On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow
> <morrowc.lists () gmail com> wrote:
>
> > On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
> > <alvarezp () alvarezp ods org> wrote:
> > > Sounds like a UDP replacement. If this is true, then OS-level support
> > > will
> > > be needed. If they are on this, then it's the perfect opportunity to fix
> > > some other problems with the Internet in general.
> >
> >
> > I'm no genius, but doesn't the article say it's UDP? (in the name of
> > the protocol even)
>
>
> I was trying to emphasize "replacement", not UDP. This is, that works on
> the same layer, that requires OS-level modifications, as opposed to a

again... not a super smart on this stuff, but..
why does it require OS modifications? isn't this just going be
'chrome' (or 'other application') asking for a udp socket and spewing
line-rate-foo out of that? isn't the application going to be doing all
of the multiplexing and jankiness?

> protocol that could be similar to UDP but work on the application layer.

it's not 'similar to UDP', it is in fact UDP, from what I read in the article.

> My point was that all that work could be focused on a *really* good
> transport (even with end-user multihoming without bloating the routing

how's that sctp going for you?
lisp?
sham6?

> table), and have streamlined TCP and UDP that takes advantage of the new
> protocol.

sure, ilnp?

> Everyone's calling upon SCTP. Implementing similar techniques on multiple
> transport protocols calls for a transport-session separation.

right, and the 1 application using sctp is so wide spread we've all
heard of it even.
possibly this will be a similar diversion into protocol/application
testing even.

-chris