• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Google QUIC
 

Google QUIC

on

  • 1,110 views

 

Statistics

Views

Total Views
1,110
Views on SlideShare
1,061
Embed Views
49

Actions

Likes
9
Downloads
18
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 Google QUIC Presentation Transcript

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