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