Re: Google's QUIC

2013-07-09 Thread Darrel Lewis (darlewis)

On Jun 28, 2013, at 7:12 PM, Octavio Alvarez  wrote:

>> 
>> Lisp is actually very much about multihoming... In fact that was one of the 
>> key reasons it got started. It actually could make >multihoming and mobility 
>> very much simpler at the applications if it were used.
> 
> Yeah, but LISP is as [in]accessible to end-users as BGP is and it will
> be like that forever. It requires ISPs to opt-in to provide this. LISP
> is not a universal option.
> 
> LISP matters to the Internet core, it doesn't matter to the whole Internet.
> It is just not universal.

LISP does not require your physical ISP to support LISP in order to receive 
service.  It is available in open source as well as low end CPE routers, in 
addition to larger, more expensive (and capable) routers sold by various 
vendors.

I don't know what you mean by universal, so I can't really respond to that.  
However, if you'd like a list of LISP service providers to provide you the 
benefits of multi-homing in a non BGP environment, or to deliver IPv6 packets 
over an IPv4 intent connection, please contact me off line.

-Darrel


Re: [cryptography] Google's QUIC

2013-07-03 Thread Eugen Leitl
- Forwarded message from ianG  -

Date: Wed, 03 Jul 2013 13:24:54 +0300
From: ianG 
To: cryptogra...@randombit.net
Subject: Re: [cryptography] Google's QUIC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) 
Gecko/20130509 Thunderbird/17.0.6

On 3/07/13 12:37 PM, Eugen Leitl wrote:
> - Forwarded message from Saku Ytti  -
> 
> Date: Tue, 2 Jul 2013 21:35:58 +0300
> From: Saku Ytti 
> To: nanog@nanog.org
> Subject: Re: Google's QUIC
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> On (2013-06-29 23:36 +0100), Tony Finch wrote:
> 
>> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf
> 
> Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu.
> 
> QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to
> attribute as chance, considering both are DJB's work, both are used by his
> NaCl library and by extension by MinimaLT. Neither is particularly common
> algorithm.

It's not the choice of algorithm that is "by chance" it is the choice
of suite as a design decision that matters.

I also would like to use the same ciphersuite, but the reason is that
DJB has already done the work to define the entire suite, saving me
from doing it.  This is quite a saving for me, and hasn't hitherto
existed as an external service.  Last time it took over a month of
hard research and learning to settle on
RSA/AES128/CBC/SHA1/HMAC/Encrypt-then-mac.

As an added bonus, DJB came up with a shorter, catchier name:

curve25519xsalsa20poly1305

In the past, things like TLS, PGP, IPSec and others encouraged you to
slice and dice the various algorithms as a sort of alphabet soup mix.
Disaster.  What we got for that favour was code bloat, insecurity at
the edges, continual arguments as to what is good & bad, focus on
numbers & acronyms, distraction from user security, entire projects
that rate your skills in cryptoscrabble, committeeitus, upgrade
nightmares, pontification ...

Cryptoplumbing shouldn't be like eating spagetti soup with a toothpick.

There should be One Cipher Suite and that should do for everyone,
everytime.  There should be no way for users to stuff things up by
tweaking a dial they read about in some slashdot tweakabit article
while on the train to work.


> I'm not implying QUIC plagiarizes MinimaLT, there are differences in the
> protocol, just choice of the algorithm implies QUIC authors are aware of
> MinimaLT.



Picking curve25519xsalsa20poly1305 is good enough for that One True
CipherSuite motive alone, and doesn't imply any other sort of copying
one might have seen.  It's an innovation!  Adopt it.



iang
___
cryptography mailing list
cryptogra...@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5



Re: Google's QUIC

2013-07-02 Thread Darius Jahandarie
On Tue, Jul 2, 2013 at 2:35 PM, Saku Ytti  wrote:
> On (2013-06-29 23:36 +0100), Tony Finch wrote:
>
>> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf
>
> Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu.
>
> QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to
> attribute as chance, considering both are DJB's work, both are used by his
> NaCl library and by extension by MinimaLT. Neither is particularly common
> algorithm.

Taking into consideration these are the best algorithms in their class
currently, it would be more surprising to me if they weren't used.

--
Darius Jahandarie



Re: Google's QUIC

2013-07-02 Thread Saku Ytti
On (2013-06-29 23:36 +0100), Tony Finch wrote:

> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf

Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu.

QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to
attribute as chance, considering both are DJB's work, both are used by his
NaCl library and by extension by MinimaLT. Neither is particularly common
algorithm.

I'm not implying QUIC plagiarizes MinimaLT, there are differences in the
protocol, just choice of the algorithm implies QUIC authors are aware of
MinimaLT.

-- 
  ++ytti



Re: Google's QUIC

2013-06-30 Thread Saku Ytti
On (2013-06-30 11:15 +0300), Saku Ytti wrote:

> But MinimaLT does not support multiplexing, which seems to be critical
> design goal for QUIC.

Mea culpa, it does support multiplexing.

-- 
  ++ytti



Re: Google's QUIC

2013-06-30 Thread Saku Ytti
On (2013-06-29 23:36 +0100), Tony Finch wrote:

> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf

ACK. Any cryptobased 0 RTT will necessarily have many things similar, and
indeed crypto is the key for low latency without major attack vectors.

But MinimaLT does not support multiplexing, which seems to be critical
design goal for QUIC.


I wonder how many years until this work materializes in practical NGL4, 10?
I'd really hate the final solution to be something riding on top of UDP,
because changing stuff is too hard.
Or should L4 be just 32b (16b SPORT, 16b DPORT) and L5 headers where magic
should live?

-- 
  ++ytti



Re: Google's QUIC

2013-06-29 Thread Tony Finch
Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf

Tony.
--
f.anthony.n.finchhttp://dotat.at/


Re: Google's QUIC

2013-06-29 Thread Octavio Alvarez

On Fri, 28 Jun 2013 19:31:35 -0700, Jim Popovitch  wrote:


On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
 wrote:


I wish my Debian mirror would just be the "mirror.debian.net" *service*
(not host), and the network could choose the best for me.


Try http.debian.net   see:  http://http.debian.net


Interesting! Didn't know of that.

However, http.debian.net is still a host that redirects me every time. If
46.4.205.43 goes down, I have no way to connect anymore.


--
Octavio.

Twitter: @alvarezp2000 -- Identi.ca: @alvarezp



Re: Google's QUIC

2013-06-29 Thread Saku Ytti
On (2013-06-29 10:27 -0400), Darius Jahandarie wrote:
> On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka  
> wrote:

> > I am surprised nobody mentioned security issues. To minimize latency the
> > following would be best: the client sends one UDP packet and receives
> > stream of UDP packets with page code, styles, images and whatever else
> > could be needed. The waiting time is just RTT plus browser processing.
> >
> Of course they consider this. Read the "CONNECTION ESTABLISHMENT and
> RESUMPTION" section of their design document [1]. If you're familiar
> with TCP Fast Open, many of its techniques are reused.
> 
> [1] 
> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit

tl;dr

Initial connection is not 0 RTT, 0 RTT only works if you already knew
public key of server (and may require additional degree of proof of
ownership of SourceIP, SourcePort, which may be fuzzy, so you might accept
192.0.2.42 as being 192.0.42.66)

Considering the terribly demanding restrictions of being deployable today,
QUIC looks pretty good to me. But I hope some 'ngl4' will eventually
replace TCP and UDP.
As far as I know SCTP fails in comparatively common scenario where your IP
changes unannounced without overlapping time using both IP addresses.

Seems like one major reasons for QUIC is same problem that affects SPDY and
ssh session multiplexing, TCP guarantees order and all sessions will be
penalized when one session has loss, this is huge huge cost. How I suffer
from this is I QoS at home small packets, so that my interactive ssh works
great even though I congest link with 'scp', but with session multiplexing,
I'll still suffer lag, as kernel won't give the reordered interactive ssh
packet to application until the large scp packet has been received.

Other takeaways I took from the document 

 - tries to be terse/compact, use flags to have dynamic set of headers,
   e.g. we don't need to always tell what version of QUIC we use

 - handles addresses changes, port changes (it's non-trivial problem, so
   leaves some corner cases)

 - copes with NAT boxes regularly ditching your session 

 - 0 RTT (send hello + send data packets immediately after), assumes you've
   already cached the private key

 - 64b GUID used as discriminator address/port not really. Could we
   leverage IPv6 host portion in future for this? Finally giving actual
   benefit to the huge LANs we have. Making IPv6 location/service.

 - Reflected amplifications heavily considered, benefit mitigated by
   forcing padding of packets when trust has not been established
 
 - bandwidth estimation used, packet loss not key/only metric, increased
   latency observed and considered as reduced bandwidth. Packet pacing used
   as way to reduce packets (this has problematic implications a) quic
   might be prone to starvation if buffer-bloat and b) operator might not
   know their network is performing as sub-par way, as you could have 0
   packet loss, while clients could be forced to reduce transmit rates,
   you'd need to monitor queue sizes)

 - raid5 style simple error correction, read-solomon was considered but
   deemed too high overhead. Especially useful in comparison to TCP when
   last packet is lost

 - 90-95% of end users can use UDP/quic, implementation will race with TCP
   to decide which one to use

 - uses UDP 80/443, capability announced in HTTP headers (how the heck does
   GOOG multiplex UDP port, I'd really love it for mosh)

 - sometimes will resend without observed packet loss, when packet loss
   would have very high cost (crypto rekey etc)

 - no packet level resend, resend is data-level

 - session-tear down has code _and_ phrase to help troubleshooting

 - as address can change, how to handle malicious middle-box forging
   address, potential reflection attack by middle-box. Should address
   change observe RTT penalty to avoid it?
-- 
  ++ytti



Re: Google's QUIC

2013-06-29 Thread Darius Jahandarie
On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka  wrote:
> I am surprised nobody mentioned security issues. To minimize latency the
> following would be best: the client sends one UDP packet and receives
> stream of UDP packets with page code, styles, images and whatever else
> could be needed. The waiting time is just RTT plus browser processing.
>
> I am sure Google considered it, so I am really curious how they are
> going to solve it.

Of course they consider this. Read the "CONNECTION ESTABLISHMENT and
RESUMPTION" section of their design document [1]. If you're familiar
with TCP Fast Open, many of its techniques are reused.

[1] 
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit

--
Darius Jahandarie



Re: Google's QUIC

2013-06-29 Thread Grzegorz Janoszka

I am surprised nobody mentioned security issues. To minimize latency the
following would be best: the client sends one UDP packet and receives
stream of UDP packets with page code, styles, images and whatever else
could be needed. The waiting time is just RTT plus browser processing.

It is a great amplification tools, isn't it? There are pages which
require loading megabytes of data just for one request, so definitely
more than 1000 UDP packets (MTU 1500). Amplification factor 1:1000+ in
packets, 1:1+ in octets :)

Of course you can add to the protocol some small initial response, key
exchange, whatever, but then the page appears after N*RTT, which is
already happening with TCP now.

I am sure Google considered it, so I am really curious how they are
going to solve it.

-- 
Grzegorz Janoszka



Re: Google's QUIC

2013-06-29 Thread Michael Thomas

On 06/28/2013 09:54 PM, shawn wilson wrote:

On Jun 29, 2013 12:23 AM, "Christopher Morrow" 
wrote:

On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
 wrote:

On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
 wrote:


"Runs in top of UDP"... "Is not UDP"...

If it has protocol set to 17 it is UDP.


So QUIC is an algorithm instead of a protocol?

it's as much a protocol as http is.. I suppose my point is that it's
some protocol which uses udp as the transport.

Because of this I don't see any (really) kernel/stack changes
required, right? it's just something the application needs to work out
with it's peer(s). No different from http vs smtp...


SCTP was layer 4, if QUIC is the same, than it will too. If QUIC is layer 5
up, it won't. That might be the difference (I haven't looked into QUIC).



From the FAQ, QUIC is an experiment that they're building on top of UDP
to test out what a new layer 4 transport protocol built with modern http
in mind  ought to look like. They say that they eventually want to fold
the results back into TCP (if possible, but given their goals it doesn't seem
especially likely that the result would still be TCP).

Mike



Re: Google's QUIC

2013-06-28 Thread Jim Popovitch
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
 wrote:
>
> I wish my Debian mirror would just be the "mirror.debian.net" *service*
> (not host), and the network could choose the best for me.

Try http.debian.net   see:  http://http.debian.net

-Jim P.



Re: Google's QUIC

2013-06-28 Thread shawn wilson
On Jun 29, 2013 12:23 AM, "Christopher Morrow" 
wrote:
>
> On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
>  wrote:
> > On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
> >  wrote:
> >
> >>
> >> "Runs in top of UDP"... "Is not UDP"...
> >>
> >> If it has protocol set to 17 it is UDP.
> >
> >
> > So QUIC is an algorithm instead of a protocol?
>
> it's as much a protocol as http is.. I suppose my point is that it's
> some protocol which uses udp as the transport.
>
> Because of this I don't see any (really) kernel/stack changes
> required, right? it's just something the application needs to work out
> with it's peer(s). No different from http vs smtp...
>

SCTP was layer 4, if QUIC is the same, than it will too. If QUIC is layer 5
up, it won't. That might be the difference (I haven't looked into QUIC).

> -chris
>


Re: Google's QUIC

2013-06-28 Thread Christopher Morrow
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
 wrote:
> On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
>  wrote:
>
>>
>> "Runs in top of UDP"... "Is not UDP"...
>>
>> If it has protocol set to 17 it is UDP.
>
>
> So QUIC is an algorithm instead of a protocol?

it's as much a protocol as http is.. I suppose my point is that it's
some protocol which uses udp as the transport.

Because of this I don't see any (really) kernel/stack changes
required, right? it's just something the application needs to work out
with it's peer(s). No different from http vs smtp...

-chris



Re: Google's QUIC

2013-06-28 Thread cb.list6
On Fri, Jun 28, 2013 at 8:00 PM, Leo Bicknell  wrote:
>
> On Jun 28, 2013, at 5:24 PM, Octavio Alvarez  
> wrote:
>
>> That's the point exactly. Google has more power and popularity to
>> influence adoption of a protocol, just like with SPDY and QUIC.
>
> This is the main reason why I'm very supportive of this effort.  I'm a bit 
> skeptical of what I have read so far, but I know that it's nearly impossible 
> to tell how these things really work from theory and simulations.  Live, real 
> world testing is required competing with all sorts of other flows.
>
> Google with their hands in both things like www.google.com and Chrome is in 
> an interesting position to implement server and client side of these 
> implementations, and turn them on and off at will.  They can do the real 
> world tests, tweak, report on them, and advance the state of the art.
>
> So for now I'll reserve judgement on this particular protocol, while 
> encouraging Google to do more of this sort of real world testing at the 
> protocol level.
>

+1, Google is smart for doing this.  It is important to push the
boundaries on performance.

QUIC is UDP, and UDP is the right step for now.

And, hopefully this stuff gets rolled up into ILNP stack features.
Yes ILNP needs stack changes, think big.  Not all things can NOT be a
simple incremental tweaks.  ILNP will be a revolution.  QUIC is simply
a revolt on performance issues with TCP in today's low-loss, high
latency (mobile), and middle box encumbered networks.

CB

> Now, how about an SCTP test? :)
>
> --
>Leo Bicknell - bickn...@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
>
>
>
>
>



Re: Google's QUIC

2013-06-28 Thread Leo Bicknell

On Jun 28, 2013, at 5:24 PM, Octavio Alvarez  wrote:

> That's the point exactly. Google has more power and popularity to
> influence adoption of a protocol, just like with SPDY and QUIC.

This is the main reason why I'm very supportive of this effort.  I'm a bit 
skeptical of what I have read so far, but I know that it's nearly impossible to 
tell how these things really work from theory and simulations.  Live, real 
world testing is required competing with all sorts of other flows.

Google with their hands in both things like www.google.com and Chrome is in an 
interesting position to implement server and client side of these 
implementations, and turn them on and off at will.  They can do the real world 
tests, tweak, report on them, and advance the state of the art.

So for now I'll reserve judgement on this particular protocol, while 
encouraging Google to do more of this sort of real world testing at the 
protocol level.

Now, how about an SCTP test? :)

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Google's QUIC

2013-06-28 Thread Octavio Alvarez

On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
 wrote:



"Runs in top of UDP"... "Is not UDP"...

If it has protocol set to 17 it is UDP.


So QUIC is an algorithm instead of a protocol?


SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is
IPv6-specific and can help you "recover" an already successful  
connection.


LISP... I can't still grasp LISP, although it doesn't have anything to  
do with multihoming. :-)


Lisp is actually very much about multihoming... In fact that was one of  
the key reasons it got started. It actually could make >multihoming and  
mobility very much simpler at the applications if it were used.


Yeah, but LISP is as [in]accessible to end-users as BGP is and it will
be like that forever. It requires ISPs to opt-in to provide this. LISP
is not a universal option.

LISP matters to the Internet core, it doesn't matter to the whole Internet.
It is just not universal.


ILNP is new for me. Looks interesting, thanks.


Mind that ilnp is v6only also requires stack changes...


I just read about ILNP. ILNP is nice if you want to multihome nodes, but
virtualization (or spanning, for that matter, similar to anycasting) over
multiple data-centers will reach the limitations of ILNP. It is a step
ahead, but it is not an integral approach.

I wish my Debian mirror would just be the "mirror.debian.net" *service*
(not host), and the network could choose the best for me.


--
Octavio.



Re: Google's QUIC

2013-06-28 Thread Christopher Morrow
On Jun 28, 2013 6:24 PM, "Octavio Alvarez" 
wrote:
>
> On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow
>  wrote:
>
>> again... not a super smart on this stuff, but..
>>
>>> 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.
>
>
> Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is
> needed just to work through NAT.
>
>

"Runs in top of UDP"... "Is not UDP"...

If it has protocol set to 17 it is UDP.

>>> 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?
>
>
> That's the point exactly. Google has more power and popularity to
> influence adoption of a protocol, just like with SPDY and QUIC.
>
> Neither of the three are widely implemented. That said, neither of those
> enable full path resiliency. Path resiliency requires the end-point to be
> available through different paths and being able to detect those paths
> *before* the first connection is established.
>
> SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is
> IPv6-specific and can help you "recover" an already successful connection.
> LISP... I can't still grasp LISP, although it doesn't have anything to do
> with multihoming. :-)
>

Lisp is actually very much about multihoming... In fact that was one of the
key reasons it got started. It actually could make multihoming and mobility
very much simpler at the applications if it were used.

It is a bit complex though... At least for normal ivp4/6 routing minded
folk.

>
>>> table), and have streamlined TCP and UDP that takes advantage of the new
>>> protocol.
>>
>>
>> sure, ilnp?
>
>
> ILNP is new for me. Looks interesting, thanks.

Mind that ilnp is v6only also requires stack changes...


Re: Google's QUIC

2013-06-28 Thread Octavio Alvarez

On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow
 wrote:


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?


I hope not. What would be the point of only letting one application take
the benefit of all those improvements?

"If we're able to identify clear performance wins, our hope is to
collaborate with the rest of the community to develop the features and
techniques of QUIC into network standards."

So yes, QUIC itself doesn't require OS-level modifications, but letting
stay there is pointless.


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.


Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is
needed just to work through NAT.


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?


That's the point exactly. Google has more power and popularity to
influence adoption of a protocol, just like with SPDY and QUIC.

Neither of the three are widely implemented. That said, neither of those
enable full path resiliency. Path resiliency requires the end-point to be
available through different paths and being able to detect those paths
*before* the first connection is established.

SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is
IPv6-specific and can help you "recover" an already successful connection.
LISP... I can't still grasp LISP, although it doesn't have anything to do
with multihoming. :-)


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


sure, ilnp?


ILNP is new for me. Looks interesting, thanks.


--
Octavio.



Re: Google's QUIC

2013-06-28 Thread Nikolay Shopik


On 29.06.2013, at 1:38, valdis.kletni...@vt.edu wrote:

> On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said:
> 
>> SCTP is used successfully for the purpose for which it was intended,
>> which is connecting SS7 switches over IP. It's not as much a posterchild
>> for an application agnostic transport as some people would like to think.
> 
> OK, I'll bite... does anything else notable actually use it?
> 
> 

Well it mostly non-user stuff, Netflow exporting, diameter, sip. Wait webrtc 
using it, firefox and chrome have sctp code, last time a checked 


Re: Google's QUIC

2013-06-28 Thread Scott Whyte
On Fri, Jun 28, 2013 at 1:23 PM, Michael Thomas  wrote:

> On 06/28/2013 01:16 PM, Josh Hoppes wrote:
>
>> My first question is, how are they going to keep themselves from
>> congesting links?
>>
>
> The FAQ claims they're paying attention to that, but I haven't read the
> details. I sure hope they grok that not understanding Van Jacobson dooms
> you to repeat it.
>

Van is at Google.  Much grokking is going on.

-Scott


>
> https://docs.google.com/**document/d/**1lmL9EF6qKrk7gbazY8bIdvq3Pno2X**
> j_l_YShP40GLQE/preview?sle=**true#heading=h.h3jsxme7rovm
>
> Mike
>
>
>
>> On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas  wrote:
>>
>>> http://arstechnica.com/**information-technology/2013/**
>>> 06/google-making-the-web-**faster-with-protocol-that-**
>>> reduces-round-trips/?comments=**1
>>>
>>> Sorry if this is a little more on the dev side, and less on the ops side
>>> but
>>> since
>>> it's Google, it will almost certainly affect the ops side eventually.
>>>
>>> My first reaction to this was why not SCTP, but apparently they think
>>> that
>>> middle
>>> boxen/firewalls make it problematic. That may be, but UDP based port
>>> filtering is
>>> probably not far behind on the flaky front.
>>>
>>> The second justification was TLS layering inefficiencies. That definitely
>>> has my
>>> sympathies as TLS (especially cert exchange) is bloated and the way that
>>> it
>>> was
>>> grafted onto TCP wasn't exactly the most elegant. Interestingly enough,
>>> their
>>> main justification wasn't a security concern so much as "helpful" middle
>>> boxen
>>> getting their filthy mitts on the traffic and screwing it up.
>>>
>>> The last thing that occurs to me reading their FAQ is that they are
>>> seemingly trying
>>> to send data with 0 round trips. That is, SYN, data, data, data... That
>>> really makes me
>>> wonder about security/dos considerations. As in, it sounds too good to be
>>> true. But
>>> maybe that's just the security cruft? But what about SYN cookies/dos?
>>> Hmmm.
>>>
>>> Other comments or clue?
>>>
>>> Mike
>>>
>>>
>
>


Re: Google's QUIC

2013-06-28 Thread Michael Thomas

On 06/28/2013 02:28 PM, joel jaeggli wrote:

On 6/28/13 2:15 PM, Michael Thomas wrote:

On 06/28/2013 02:07 PM, Jay Ashworth wrote:

- Original Message -

From: "Michael Thomas" 
My first reaction to this was why not SCTP, but apparently they think

Simple Computer Telephony Protocol?  Did anyone ever actually implement that?


No:


http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol


SCTP is used successfully for the purpose for which it was intended, which is 
connecting SS7 switches over IP. It's not as much a posterchild for an 
application agnostic transport as some people would like to think.


Well, I'm pretty sure that Randy Stewart has a more expansive take on SCTP
than SS7oIP, but I get the impression that there just weren't enough other 
things
that cared  about head of line blocking. But now, 15 years later, it seems like 
maybe
there is.

In any case, if what you're worried about is head of line blocking, SCTP 
definitely
does that, and there are kernel implementations so for an *experiment* it seems
like you could get a long way by ignoring its warts.

But I think the most provocative thing is the idea of sending data payloads 
prior
to handshake. That sort of scares me because of the potential for an 
amplification
attack. But I haven't actually read the protocol paper itself.

Mike



Re: Google's QUIC

2013-06-28 Thread Valdis . Kletnieks
On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said:

> SCTP is used successfully for the purpose for which it was intended,
> which is connecting SS7 switches over IP. It's not as much a posterchild
> for an application agnostic transport as some people would like to think.

OK, I'll bite... does anything else notable actually use it?




pgpb1GCjZJePG.pgp
Description: PGP signature


Re: Google's QUIC

2013-06-28 Thread joel jaeggli

On 6/28/13 2:15 PM, Michael Thomas wrote:

On 06/28/2013 02:07 PM, Jay Ashworth wrote:

- Original Message -

From: "Michael Thomas" 
My first reaction to this was why not SCTP, but apparently they think
Simple Computer Telephony Protocol?  Did anyone ever actually 
implement that?


No:


http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

SCTP is used successfully for the purpose for which it was intended, 
which is connecting SS7 switches over IP. It's not as much a posterchild 
for an application agnostic transport as some people would like to think.


*Mike*







Re: Google's QUIC

2013-06-28 Thread Scott Weeks
--- m...@mtcc.com wrote:
From: Michael Thomas 
On 06/28/2013 02:07 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Michael Thomas" 

>> My first reaction to this was why not SCTP, but apparently they think
> Simple Computer Telephony Protocol?  Did anyone ever actually implement that?

No:
  http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
---


C'mon Jay!  Get with the plan!  >;-)

scott



Re: Google's QUIC

2013-06-28 Thread Michael Thomas

On 06/28/2013 02:07 PM, Jay Ashworth wrote:

- Original Message -

From: "Michael Thomas" 
My first reaction to this was why not SCTP, but apparently they think

Simple Computer Telephony Protocol?  Did anyone ever actually implement that?


No:


 http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol


*Mike*




Re: Google's QUIC

2013-06-28 Thread Jay Ashworth
- Original Message -
> From: "Michael Thomas" 

> My first reaction to this was why not SCTP, but apparently they think

Simple Computer Telephony Protocol?  Did anyone ever actually implement that?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274



Re: Google's QUIC

2013-06-28 Thread Phil Fagan
I took that as path agnostic.


On Fri, Jun 28, 2013 at 3:00 PM, Christopher Morrow  wrote:

> On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan  wrote:
> > "In the presence of layer-3 load-balancers, a multiplexed transport has
> the
> > potential to allow the different data flows, coming and going to a
> client,
> > to be served on a single server." - Google
> >
> > I'll drink the juice
>
> i don't think much juice is required... doesn't that just say that the
> same 'flow' will follow the same path through the network? and that
> most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at
> best)? so keeping things in a single flow/stream/5-tuple will drop
> packets from one host deterministicaly on a single other host at the
> far side?
>



-- 
Phil Fagan
Denver, CO
970-480-7618


Re: Google's QUIC

2013-06-28 Thread Christopher Morrow
On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan  wrote:
> "In the presence of layer-3 load-balancers, a multiplexed transport has the
> potential to allow the different data flows, coming and going to a client,
> to be served on a single server." - Google
>
> I'll drink the juice

i don't think much juice is required... doesn't that just say that the
same 'flow' will follow the same path through the network? and that
most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at
best)? so keeping things in a single flow/stream/5-tuple will drop
packets from one host deterministicaly on a single other host at the
far side?



Re: Google's QUIC

2013-06-28 Thread Christopher Morrow
On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez
 wrote:
> On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow
>  wrote:
>
>> On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
>>  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



Re: Google's QUIC

2013-06-28 Thread Tassos Chatzithomaoglou
The idea reminds me of uTP in terms of congestion handling.

--
Tassos

Josh Hoppes wrote on 28/6/2013 23:16:
> My first question is, how are they going to keep themselves from
> congesting links?
>
> On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas  wrote:
>> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
>>
>> Sorry if this is a little more on the dev side, and less on the ops side but
>> since
>> it's Google, it will almost certainly affect the ops side eventually.
>>
>> My first reaction to this was why not SCTP, but apparently they think that
>> middle
>> boxen/firewalls make it problematic. That may be, but UDP based port
>> filtering is
>> probably not far behind on the flaky front.
>>
>> The second justification was TLS layering inefficiencies. That definitely
>> has my
>> sympathies as TLS (especially cert exchange) is bloated and the way that it
>> was
>> grafted onto TCP wasn't exactly the most elegant. Interestingly enough,
>> their
>> main justification wasn't a security concern so much as "helpful" middle
>> boxen
>> getting their filthy mitts on the traffic and screwing it up.
>>
>> The last thing that occurs to me reading their FAQ is that they are
>> seemingly trying
>> to send data with 0 round trips. That is, SYN, data, data, data... That
>> really makes me
>> wonder about security/dos considerations. As in, it sounds too good to be
>> true. But
>> maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm.
>>
>> Other comments or clue?
>>
>> Mike
>>
>




Re: Google's QUIC

2013-06-28 Thread Phil Fagan
"In the presence of layer-3 load-balancers, a multiplexed transport has the
potential to allow the different data flows, coming and going to a client,
to be served on a single server." - Google

I'll drink the juice


On Fri, Jun 28, 2013 at 2:39 PM, Christopher Morrow  wrote:

> On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
>  wrote:
> > On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas 
> wrote:
> >
> >>
> >>
> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
>
> >
> > 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)
>
> -chris
>
>


-- 
Phil Fagan
Denver, CO
970-480-7618


Re: Google's QUIC

2013-06-28 Thread Octavio Alvarez

On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow
 wrote:


On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
 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
protocol that could be similar to UDP but work on the application layer.

My point was that all that work could be focused on a *really* good
transport (even with end-user multihoming without bloating the routing
table), and have streamlined TCP and UDP that takes advantage of the new
protocol.

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

--
Octavio.



Re: Google's QUIC

2013-06-28 Thread Christopher Morrow
On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
 wrote:
> On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas  wrote:
>
>>
>> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1

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

-chris



Re: Google's QUIC

2013-06-28 Thread Octavio Alvarez

On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas  wrote:


http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1

Sorry if this is a little more on the dev side, and less on the ops side  
but since

it's Google, it will almost certainly affect the ops side eventually.

My first reaction to this was why not SCTP, but apparently they think  
that middle
boxen/firewalls make it problematic. That may be, but UDP based port  
filtering is

probably not far behind on the flaky front.


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.

My reaction is: why, oh why, repeat the same mistake of merging everything
on the transport layer and let the benefits be protocol-specific instead
of separating the "transport" from "session".

I mean, why not let redundancy and multipath stay on the transport layer
through some kind of end-user transport (like the Host Identification
Protocol, RFC 5201) and let a simpler TCP and UDP live on top of that, on
the session layer.

Streamline the protocols and separate their functionality.

It's easier than it sounds.


--
Octavio.



Re: Google's QUIC

2013-06-28 Thread Michael Thomas

On 06/28/2013 01:16 PM, Josh Hoppes wrote:

My first question is, how are they going to keep themselves from
congesting links?


The FAQ claims they're paying attention to that, but I haven't read the
details. I sure hope they grok that not understanding Van Jacobson dooms
you to repeat it.

https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#heading=h.h3jsxme7rovm

Mike



On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas  wrote:

http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1

Sorry if this is a little more on the dev side, and less on the ops side but
since
it's Google, it will almost certainly affect the ops side eventually.

My first reaction to this was why not SCTP, but apparently they think that
middle
boxen/firewalls make it problematic. That may be, but UDP based port
filtering is
probably not far behind on the flaky front.

The second justification was TLS layering inefficiencies. That definitely
has my
sympathies as TLS (especially cert exchange) is bloated and the way that it
was
grafted onto TCP wasn't exactly the most elegant. Interestingly enough,
their
main justification wasn't a security concern so much as "helpful" middle
boxen
getting their filthy mitts on the traffic and screwing it up.

The last thing that occurs to me reading their FAQ is that they are
seemingly trying
to send data with 0 round trips. That is, SYN, data, data, data... That
really makes me
wonder about security/dos considerations. As in, it sounds too good to be
true. But
maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm.

Other comments or clue?

Mike






Re: Google's QUIC

2013-06-28 Thread Josh Hoppes
My first question is, how are they going to keep themselves from
congesting links?

On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas  wrote:
> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
>
> Sorry if this is a little more on the dev side, and less on the ops side but
> since
> it's Google, it will almost certainly affect the ops side eventually.
>
> My first reaction to this was why not SCTP, but apparently they think that
> middle
> boxen/firewalls make it problematic. That may be, but UDP based port
> filtering is
> probably not far behind on the flaky front.
>
> The second justification was TLS layering inefficiencies. That definitely
> has my
> sympathies as TLS (especially cert exchange) is bloated and the way that it
> was
> grafted onto TCP wasn't exactly the most elegant. Interestingly enough,
> their
> main justification wasn't a security concern so much as "helpful" middle
> boxen
> getting their filthy mitts on the traffic and screwing it up.
>
> The last thing that occurs to me reading their FAQ is that they are
> seemingly trying
> to send data with 0 round trips. That is, SYN, data, data, data... That
> really makes me
> wonder about security/dos considerations. As in, it sounds too good to be
> true. But
> maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm.
>
> Other comments or clue?
>
> Mike
>



Google's QUIC

2013-06-28 Thread Michael Thomas

http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1

Sorry if this is a little more on the dev side, and less on the ops side but 
since
it's Google, it will almost certainly affect the ops side eventually.

My first reaction to this was why not SCTP, but apparently they think that 
middle
boxen/firewalls make it problematic. That may be, but UDP based port filtering 
is
probably not far behind on the flaky front.

The second justification was TLS layering inefficiencies. That definitely has my
sympathies as TLS (especially cert exchange) is bloated and the way that it was
grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their
main justification wasn't a security concern so much as "helpful" middle boxen
getting their filthy mitts on the traffic and screwing it up.

The last thing that occurs to me reading their FAQ is that they are seemingly 
trying
to send data with 0 round trips. That is, SYN, data, data, data... That really 
makes me
wonder about security/dos considerations. As in, it sounds too good to be true. 
But
maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm.

Other comments or clue?

Mike