Google's QUIC

[morrowc.lists at gmail.com (Christopher Morrow)]

On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez
<alvarezp at alvarezp.ods.org> wrote:
> On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>
>> On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
>> <alvarezp at 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