Home page logo
/

nanog logo nanog mailing list archives

Re: Google's QUIC
From: Christopher Morrow <morrowc.lists () gmail com>
Date: Fri, 28 Jun 2013 16:57:48 -0400

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]