Re: [cryptography] Google's QUIC
- Forwarded message from ianG i...@iang.org - Date: Wed, 03 Jul 2013 13:24:54 +0300 From: ianG i...@iang.org 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 s...@ytti.fi - Date: Tue, 2 Jul 2013 21:35:58 +0300 From: Saku Ytti s...@ytti.fi 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 a href=http://leitl.org;leitl/a 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
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
On Tue, Jul 2, 2013 at 2:35 PM, Saku Ytti s...@ytti.fi 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
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
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
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org 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
On 06/28/2013 09:54 PM, shawn wilson wrote: On Jun 29, 2013 12:23 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com 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
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
On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka grzeg...@janoszka.pl 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
On (2013-06-29 10:27 -0400), Darius Jahandarie wrote: On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka grzeg...@janoszka.pl 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
On Fri, 28 Jun 2013 19:31:35 -0700, Jim Popovitch jim...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org 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
Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/
Google's QUIC
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
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 m...@mtcc.com 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
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 m...@mtcc.com 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
On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com 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
On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com 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
On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@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 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
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 morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com 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
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 m...@mtcc.com 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
On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@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
Re: Google's QUIC
On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan philfa...@gmail.com 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
I took that as path agnostic. On Fri, Jun 28, 2013 at 3:00 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan philfa...@gmail.com 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
- Original Message - From: Michael Thomas m...@mtcc.com 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
On 06/28/2013 02:07 PM, Jay Ashworth wrote: - Original Message - From: Michael Thomas m...@mtcc.com 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
--- m...@mtcc.com wrote: From: Michael Thomas m...@mtcc.com On 06/28/2013 02:07 PM, Jay Ashworth wrote: - Original Message - From: Michael Thomas m...@mtcc.com 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
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 m...@mtcc.com 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
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
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 m...@mtcc.com 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
On Fri, Jun 28, 2013 at 1:23 PM, Michael Thomas m...@mtcc.com 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.h3jsxme7rovmhttps://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 m...@mtcc.com wrote: http://arstechnica.com/**information-technology/2013/** 06/google-making-the-web-**faster-with-protocol-that-** reduces-round-trips/?comments=**1http://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
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
On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow morrowc.li...@gmail.com 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
On Jun 28, 2013 6:24 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow morrowc.li...@gmail.com 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
On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com 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
On Jun 28, 2013, at 5:24 PM, Octavio Alvarez alvar...@alvarezp.ods.org 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
On Fri, Jun 28, 2013 at 8:00 PM, Leo Bicknell bickn...@ufp.org wrote: On Jun 28, 2013, at 5:24 PM, Octavio Alvarez alvar...@alvarezp.ods.org 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
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com 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
On Jun 29, 2013 12:23 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com 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
