Paper (Portuguese) http://drive.google.com/file/d/0B0KQBLvi00nhbEYyVHdBOUFMUUk

1. QUIC
Quick UDP Internet Connections
Aluno: Felipe Rayel
Professores: Christian Esteve Rothenbeg, Maurício Ferreira
Magalhães
IA368- Tópicos em Engenharia de Computação V
Faculdade de Engenharia Elétrica e de Computação UNICAMP
Nov/2013

2. AGENDA
•
•
•
•
•
•
Overview
Motivations
Goals
Specification
Adoption
Conclusion

3. OVERVIEW
• HTTP 1.1 (1999)

4. OVERVIEW
•
•
•
•
•
Google SPDY (2009)
Over TCP
Multiplexing (requests not waiting for previous GETs to complete)
Server Push
Header compression

5. MOTIVATIONS
• SPDY over TCP has problem
• On TCP: 1 packet delay/loss affect all streams
• Next HTTP Request need wait
• 3-way-handshake
• TCP=1.5 RTT / SSL = 3 RTT
• Single congestion window
• One window for all streams

6. GOALS
• QUIC (2013) = Build reliable layer on UDP
• Widespread deployability in today’s internet
• Middlebox = tipically block anything other than TCP or UDP
• Modification over TCP = Need kernel changes
• TCP Extension = Over 10 years or more
• Packet loss dosen’t effects all streams
• One stream for each request. Packets sent out of order
• Less RTT
• Ack dont needed. No handshake. 0RTT
• Separate congestion window
• One window for each stream.

7. GOALS
• SSL layer
• Packet level error correction
• Reduced latency achieved by using error correction, rather
than retransmission.
• Improved support for mobile
• Mobile Clients = tendency to turn off a radio communications
• TCP connections = closed during radio shutdowns + latency
costs for session continuations
• Reduced bandwidth consumption
• Reduced packetcount

8. SPECIFICATION
• Connection :
•
•
•
•
QUIC framing layer runs atop UDP
Session Initiated by client
Bidirectional exchange of packets identified by a GUID
When a server decides to terminate an idle session, it should
not notify the client to avoid waking up the radio on mobile
devices.

9. SPECIFICATION
• GUID (Globally Unique Identifier):
• 64 bit pseudo random number selected by the client
• Is the key to the connection.
• QUIC sessions are designed to remain established even if
the client roams
• The IP 4tuple (source IP, source port, destination IP,
destination port) may be insufficient to identify the
connection

10. SPECIFICATION
• Framing:
• data packets (contain stream payload data, ACK data,
and control data)
• ACK Frame = Used to coordinate packet loss recovery
• Not identical to an ACK packet in TCP
• ACK in QUIC is always cumulative
• FEC packets (contain parity data which allows dropped
packets to be recovered.)

11. SPECIFICATION
• Packet Header
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
0
1
2
3
4
5
6
7
8
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
| Public | GUID (0, 8, 32, or 64)
| ->
|Flags(8)| (variable length)
|
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
9
10
11
12
13
14
15
+--------+--------+--------+--------+--------+--------+--------+
| Quic Version (32)
| (cont) ->
| (optional)
|
+--------+--------+--------+--------+--------+--------+--------+
16
17
18
19
20
+--------+--------+--------+--------+--------+
Sequence (8,16,32,or 48)
|Private | FEC (8)|
Number (variable length)
|Flags(8)| (opt) |
+--------+--------+--------+--------+--------+

12. SPECIFICATION
• Data Packet
•
•
•
+--------+.........+--------+.........+
| Type
| Payload | Type
| Payload |
+--------+.........+--------+.........+
• After a header in a packet, there is always a payload block of ciphertext
authenticated by an AEAD (Authenticated Encryption with Associated Data )
algorithm.

13. SPECIFICATION
• FEC (Forward Error Correction) Packet
•
16
•
•
•
+............+
| Redundancy |
+............+
• QUIC can send periodic FEC packets which contain
redundant data.
• Can allow lost packets to be recovered without needing to be
retransmitted.
• TCP requires the client to wait for a retry timeout to expire.
• FEC packets (FLAG_FEC set) have a payload that simply
contains an XOR of the nullpadded payload of each Data
Packet in the FEC group.

14. SPECIFICATION
• Streams
• Are independent sequences of bidirectional data;
• Can be created either by the client or the server;
• To avoid collisions when creating new streams:
• Initialized by the client start with an odd number;
• Initialized by the server with an even number;
• In either case, the numbers must always increase.
• Priority
• A stream may be dependent on another stream.
• Parent streams have an explicit priority over child streams.

15. DEPLOYMENT
• Planned: UDP port 80 or UDP port 443
• In both cases, will be encrypting the traffic (to avoid
accidental damage by middle boxes)
• Wide deployment as being plausible within 1-2 years
• To specify QUIC as an alternate protocol available on port
123, use:
• Alternate-Protocol: 123:quic
• When a client receives a AlternateProtocol header advertising
QUIC, it should attempt to use QUIC for future secure
connections on that domain.

16. ADOPTION
• Client
• Has been part of version 29 (released on August 20, 2013) of Chrome.

17. ADOPTION
• Server
• Google published a prototype
• https://code.google.com/p/chromium

18. CONCLUSIONS
• Latency Reduction
• SPDY is good, QUIC is better
• Fast adoption
• In 2012, SPDY supported in Chrome, Firefox, and Opera,
• Many large web destinations (e.g., Google, Twitter, Facebook) were offering SPDY to
compatible clients.
• Patent
• SPDY is not patented
• FAST TCP is Patented, nobody uses
• HTTP 2.0
• HTTP Working Group (HTTP-WG) kicked off the new HTTP 2.0 effort in early 2012 to take
the lessons learned from SPDY and apply them to the official standard.
• Lost FEC Packet
• What Happens?