Google QUIC
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Google QUIC

on

  • 1,558 views

 

Statistics

Views

Total Views
1,558
Views on SlideShare
1,509
Embed Views
49

Actions

Likes
10
Downloads
28
Comments
0

3 Embeds 49

https://twitter.com 47
http://www.linkedin.com 1
https://br.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Google QUIC Presentation Transcript

  • 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?