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

Google QUIC

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Google QUIC

A l u n o : F e l i p e R a y e lP r o f e s s o r e s : C h r i s t i a n E s t e v e R o t h e n b e g , M a u r í c i o F e r r e i r a M a g a l h ã e s

QUICQuick UDP Internet Connections

IA368- Tópicos em Engenharia de Computação V Faculdade de Engenharia Elétrica e de Computação UNICAMP

Nov/2013

Page 2: Google QUIC

AGENDA

• Overview• Motivations• Goals• Specification• Adoption• Conclusion

Page 3: Google QUIC

OVERVIEW

• HTTP 1.1 (1999)

Page 4: Google QUIC

OVERVIEW

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

Page 5: Google QUIC

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

Page 6: Google QUIC

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.

Page 7: Google QUIC

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

Page 8: Google QUIC

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.

Page 9: Google QUIC

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

Page 10: Google QUIC

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.)

Page 11: Google QUIC

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) |• +--------+--------+--------+--------+--------+

Page 12: Google QUIC

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.

Page 13: Google QUIC

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.

Page 14: Google QUIC

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.

Page 15: Google QUIC

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.

Page 16: Google QUIC

ADOPTION

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

Chrome.

Page 17: Google QUIC

ADOPTION

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

Page 18: Google QUIC

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?