[164213] in North American Network Operators' Group
Re: Google's QUIC
daemon@ATHENA.MIT.EDU (Grzegorz Janoszka)
Sat Jun 29 07:54:29 2013
Date: Sat, 29 Jun 2013 13:53:49 +0200
From: Grzegorz Janoszka <Grzegorz@Janoszka.pl>
To: nanog@nanog.org
In-Reply-To: <51CEB56F.7090201@mtcc.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
