QUIC

Question 1

what are the motivations for using QUIC

Answer 1

• Application context has changed
• TCP handshake is too expensive
• TCP ill-equipped for mobility
• It’s near impossible to change TCP (‘narrow waist’)

Question 2

how does QUIC solve HTTP2’s HOL blocking?

Answer 2

HTTP/2 does however still suffer from another kind of HOL, namely on the TCP level. One lost packet in the TCP stream makes all streams wait until that package is re-transmitted and received. This HOL is being addressed with the QUIC protocol…

QUIC is a “TCP-like” protocol implemented over UDP where each stream is independent so that a lost packet only halts the particular stream to which the lost packet belongs, while the other streams can go on.

Question 3

how does a QUIC handshake differ from TCP + TLS

Answer 3

TCP + TLS 1.2 / 1.3 has 3/2 RTTS
QUIC has 1RTT
for subsequent connections, each has 1 less
so QUIC has a 0RTT handshake :o
sends authentication stuff (public key etc) at the same time as request.
server might reject but that only adds 1 RTT

Question 4

how might 0RTT be insecure? solutions?

Answer 4

• One attack vector: Replay attacks*

solved by QUIC servers keeping a “strike register” of nonces, but when it comes to real-world settings where a server entity is implemented in a cluster of, potentially distributed, servers this falls flat

solutions?
Only 3 solutions:
1. maintain global + temporal consistency on all servers
2. Don’t solve it (A): allow only idempotent ops with 0-RTT
3. Don’t solve it (B): let the application deal with it

Question 5

how is QUIC better than TCP for mobility?

Answer 5

TCP
• TCP connection is bound
to IP address
if IP addr changes we fuckd

QUIC
• UDP says, “gimme destination IP+port and
I’ll do the rest.”
• QUIC is built atop UDP
• QUIC implements “connectionID”
• separate from IP, built at
handshake.

Question 6

what problems do middleboxes cause

Answer 6

• Middleboxes ‘recognise’
TCP and do stuff
• (note: this breaks end-to-end
semantics!)

instead we can take tcp and stick it in the body of UDP, with QUIC headers that satisfy some middlebox requirements

Question 7

what are the targets of BBR? whats the problem

Answer 7

its not loss based, instead it builds a model of the networking and adjusts accordingly

Two competing targets
1. Find a rate balance such that
buffer fill rate = drain rate
2. Fill the pipe such that
bytes in-flight = min-RTT x bottleneckBW
Problem: There exists no way to measure both
RTTprop and Bottleneck BW at the same time

Question 8

give a BBR algorithm

Answer 8

BBR Algorithm Overview:
• Some form of slow start (i.e. discovery)
• Measure RTT when throughput is increasing
• Measure throughput when RTT starts to increase
• Pace packets at the BDP
• Occasionally probe faster (x1.25) for 1 RTT, then slower
(x0.75) to allow queue to drain.

Question 9

problems with bbr

Answer 9

BBR is efficient and fast, but its fairness to non-BBR streams is disputed. While Google’s presentation shows BBR co-existing well with CUBIC,[23] researchers like Geoff Huston and Hock, Bless and Zitterbart finds it unfair to other streams and not scalable.oheil Abbasloo et al. (authors of C2TCP) show that BBR doesn’t perform well in dynamic environments such as cellular network