Google QUIC

  • View
    1.498

  • Download
    0

  • Category

    Internet

Preview:

DESCRIPTION

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

Citation preview

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

AGENDA

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

OVERVIEW

• HTTP 1.1 (1999)

OVERVIEW

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

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

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.

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

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.

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

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

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

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.

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.

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.

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.

ADOPTION

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

Chrome.

ADOPTION

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

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?

Recommended