nanog mailing list archives
Re: Google's QUIC
From: Grzegorz Janoszka <Grzegorz () Janoszka pl>
Date: Sat, 29 Jun 2013 13:53:49 +0200
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:10000+ 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
Current thread:
- Re: Google's QUIC, (continued)
- Re: Google's QUIC Octavio Alvarez (Jun 28)
- Re: Google's QUIC Christopher Morrow (Jun 28)
- Re: Google's QUIC Octavio Alvarez (Jun 28)
- Re: Google's QUIC Christopher Morrow (Jun 28)
- Re: Google's QUIC Octavio Alvarez (Jun 28)
- Re: Google's QUIC Christopher Morrow (Jun 28)
- Re: Google's QUIC Octavio Alvarez (Jun 28)
- Re: Google's QUIC Christopher Morrow (Jun 28)
- Re: Google's QUIC shawn wilson (Jun 28)
- Re: Google's QUIC Michael Thomas (Jun 29)
- Re: Google's QUIC Grzegorz Janoszka (Jun 29)
- Re: Google's QUIC Darius Jahandarie (Jun 29)
- Re: Google's QUIC Saku Ytti (Jun 29)
- Re: Google's QUIC Tony Finch (Jun 29)
- Re: Google's QUIC Saku Ytti (Jun 30)
- Re: Google's QUIC Saku Ytti (Jun 30)
- Re: Google's QUIC Christopher Morrow (Jun 28)
- Re: Google's QUIC Octavio Alvarez (Jun 28)
- Re: Google's QUIC Jim Popovitch (Jun 28)
- Re: Google's QUIC Octavio Alvarez (Jun 29)
- Re: Google's QUIC Leo Bicknell (Jun 28)
- Re: Google's QUIC cb.list6 (Jun 28)
- Re: Google's QUIC Phil Fagan (Jun 28)