Your SlideShare is downloading. ×
0
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Google QUIC
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Google QUIC

2,836

Published on

Paper (Portuguese) …

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

0 Comments
15 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,836
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
69
Comments
0
Likes
15
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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?

×