Google's QUIC

Sat Jun 29 18:07:10 UTC 2013

On (2013-06-29 10:27 -0400), Darius Jahandarie wrote:
> On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka <Grzegorz at 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