QUIC BOF - IETF 96 Berlin. Wed 20 July 2016 - 10:00 CEST (UTC+2) Proponents: Ted Hardie, Christian Huitema, and Jana Iyengar Co-chairs: Lars Eggert and Brian Trammell Responsible Area Director: Spencer Dawkins (TSV) Minute takers: Aaron Falk and Patrick McManus Time | Speaker | Item ------+-----------------+----------------------------------------------------- 10:00 | Chairs | Note well, intro, charter/BoF overview 10:05 | J. Iyengar | A QUIC Overview 10:20 | C. Huitema | Implementing QUIC for fun and planning 10:30 | M. Ponec | QUIC deployment at Akamai 10:40 | I. Swett | QUIC deployment at Google 10:55 | M. Thomson | Using TLS for QUIC 11:05 | J. Iyengar | Review of proposed document organization 11:15 | Open Mic/Chairs | Discussion of the problem's fit for the IETF 11:30 | Open Mic/Chairs | Charter Review and Discussion TOPIC: Note well, intro, charter/BoF overview - Lars slides: https://www.ietf.org/proceedings/96/slides/slides-96-quic-0.pdf Agenda review save discussion for discussion agenda slot; clarification questions only review charter highlights: develop a stds track protocol; consensus needed to adopt or change proposed mechanism charter schedule runs 30 months, maybe not so realistic review of standard BoF questions TOPIC: A QUIC Overview - Jana Iyengar slides: https://www.ietf.org/proceedings/96/slides/slides-96-quic-5.pdf experiment was to create a transport protocol over UDP that would support HTTP now need to componentize and propose standardizing with support for TLS 1.3 design goals: deployability, evolvability, quick connection establishment, better congestion control & loss recovery, support NAT rebinding, multipath Notable difference from TCP: retransmitted packets get new sequence number. Eliminates retransmission ambiguity.. Jana notes this provides a deployment mechanism for accumulated TCP congestion control developments protocol drafts available for more detail than bof slides provide "All design elements will be in the hands of the wg, if adopted as an IETF work item" Implementations: Chromium (open source), quic-go, Christian Huitema -- (links to code in slides) Debug in wireshark & Chrome (chrome://net-internals) No questions or discussion TOPIC: Implementing QUIC for fun and planning - Christian Huitema Implemented QUIC to understand protocol & verify spec; not intended as a product; attempted to implement without looking at Chrome code Microsoft attempted and failed at peer-to-peer TCP because of problems with middlebox traversals QUIC + UDP header is smaller than TCP at the expense of a lot of 'bit twiddling that needs to be clearly expained" Even though QUIC is user-space, it is beneficial to ship it with the OS to have an effective path for deploying bugfixes Centralization of transport security on TLS is major recent change for the good Spec was improved: FEC was removed (ed: from the protocol too or just the spec?) TCP and TLS performance is probably equivalent to QUIC with all of queued TCP changes, but FEC etc may provide things TCP cannot easily do as it evolves. Plans: interop tests, design extensibility, multipath, performance Questions Mat Ford: Was FEC removed? A: was removed from spec. but different algorithms from how it was speced are possible TOPIC: QUIC deployment from Akamai - Mirosolav Ponec goal: compatability with Chrome QUIC implementation, documentation lagged so used Chromium code as point of comparison Added some mods to support Akamai congestion control algorithms; SDK for media acceleration on mobile platforms deployed to Akamai edge servers for HTTP delivery, slowly enabling for production traffic (not results to share yet) Challenges: chrome changing quickly, PCI compliance (TLS 1.3 will help), missing parity with TCP & IPv6 features, load balancing Things that helped: ability to fallback to TCP, slective enablement via alt-service Fine grained control of how much QUIC is used in server env via application layer HTTP/2 mechanisms (Alt-Svc) Question: Lars - Does need to duplicate some TCP services become a problem because of HTTP/2 combination A: yes, need to be efficient requires some layer boundary violation TOPIC: QUIC deployment at Google - Ian Swett Deployment timeline -- April 2014: Chrome desktop; 2015: Chrome Android & Android search; 2016: YouTube (in progress) and Google+ QUIC disabled for domains requireing PCI QUIC used for every major Google site on desktop and android chrome; many google android apps: 85% chrome requests If UDP is blocked: seamless fallback to HTTP/TCP If P MTU is too small: fallsback to TCP QUIC works 93% of the time. UDP rate limited 0.3% UDP blocked at AS 0.2% UDP blocked for user 4.5% Since initial launch, UDP rate limiting has decreased by 2/3rds Lots of controlled experiments, monitoring errors on client and server Performance: 5% faster page load times on average; 1 second faster for web serarch at 99th %-tile 0-RTT provides over half the improvement Improved loss recovery helps with YouTube timeouts www.chromium.org/quic no clarifying questions from floor TOPIC: Using TLS for QUIC - Martin Thomson Primary benefit from QUIC crypto: 0-RTT: 1RTT on first contact, 0RTT on subsequent contacts -- a HUGE win TLS 1.3 provides same performance improvements and some additional ones over QUIC crypto complications arise from strict layering - leads to inefficiencies TLS as a service separates handshake from exchange during established keying material state (material available to quic in that stage instead of encapsulated in tls) quic multistreaming is used for this quic is tls based on udp not native dtls version negotiation has integrity exposure unlike most quic control data. handshake is not flow controlled keying and retransmissions are complicated (and a wip) when transitioning keys Questions: Allison Mankin - are the 0 rtt restrictions on quic and tls1.3 in terms of psk only? a: yes cullen jennings - clarify extensibility wrt is tls the only plugin secuirty - integrity is outside of tls, yes? A: this version of quic is tls 1.3 - might be bale to use 1.4 depending on 1.4 transparency. not aware of being able to plug non-tls in. ted hardie - mostly a wg decision, but would want same guarantees Jana - Crypto spec is separate from QUIC basic protocol spec lars underscores that the purpose of the thomson presentation was to show a existence proof of reusing an IETF security protocol in QUIC Eric Rescorla - TLS 1.3 encryptes everything, QUIC some things are allowed to be non-encrypted, to support that in TLS will need to add the flexibility to support that exclusion. possible but still work. TOPIC: Proposed Work Split for a Working Group - Jana Four initial docs: draft-hamilton-quic-transport-protocol - core protocol description, excludes crypto draft-iaengar-quic-loss-recovery - congestion control and loss recovery mechanisms (new reno and standard tcp loss recovery) draft-thomson-quic-tls - using TLS for QUIC cyprto handshake draft-shade-quic-http2-mapping - how to map HTTP/2 semantics over QUIC (in particular h2 multi streaming) Note: this is mostly transport work (vs. apps) Questions Paul Hoffman: looking for entangelements in docs: looks like the core protocol can't finish before the other docs, they should be one doc. Is there a reason to split the docs? A: the scope of the work items is different and requires different expertise (e.g., congestion control) and to be replaceable as best practices evolve. TOPIC: OPEN MIC Rich Salz - multisecond lag in newtork PHB - like this for many reasons. TLS is too hard for me to understand. Starting again is good. Separate out key agreement into different doc to allow them to share mechanism if possible. Are we going to share commonality with other IETF crypto mechanisms. Tom Herbert - generally going in the right direction. oversold: UDP is the answer for everything in the Internet. Everything should be in userspace. Hard to get ICMP to a user-space transport. getting other stuff from lowerlayers into userspace is also hard. TCP works same in data center and internet. Suggest giving QUIC a separate protocol number for use in data center without UDP. Also allow UDP for Internet use. Jana - agree with userspace is oversold. but big win is able to ship to clients without an OS update. Data centers can do what they want. No objectino to separate protocl number. Ted - Sometimes the having the protocol in the OS is a benefit; but the proponents want to permit it to not be forced that way. Brian: show of hands: kernel vs. user space debate? (none) Dave Crocker: request for the future.... user v. kernel: was taught that userspace is less efficient; focus on HTTP is understandable, justifiable, sufficient. Worth hearing about support for other protocols, such as SMTP. Ted: DNS is something to discuss in the future Lars: charter should include something about thinking about other protocol support beyond H2 (maybe as a test case) Michael Tuexen: would like to see a requirements discussion. MUST it be supported in kenel, user space, ... Think about other requirements. Is FEC in or out? Have working group nail this down. Ted: does the design aspirations slide cover this? Michael: meh, just think we should add requirements analysis to charter Joe HIldebrand: agree with Michael. Cisco is implementing to advantage QUIC vs. other UDP traffic in firewalls. Would have some input on a requirements discussion. Will share code with community in next week or so for experimentation. Trying to ossify as little as possible. Look at things like version migration. Ted: thank you for letting folks try their implementation against you code. Middlebox folks invited to give input on how to make protocol useful. Joe: look more at managability; pull request for charter pending. Mark Nottingham: slide says 'predominantly transport work'. Yes, but. Oh, and by the way you are doinga new version of HTTP that is not wireformat compatible with HTTP/1 or HTTP/2. Don't let that get lost. Open qustions: Extensibility, H2 is evolving, are we forking it? Some HTTP community folks are involved, but not all. BTW, I think this is great. Jana: also true for TLS mapping? Wg needs serious enagement, not layering so we need to collaborate. A new model for the IETF. Mark: IETF leadership should think about this. W3C has supergroups that glom a lot of work. Advantages some highly active participants, but not others. Ted: IESG has been thinkinga about this for a while. IESG considering having ADs from multiple areas. Mark: careful coordination can split up work to separate lists, eg. Spencer: affirm what Mark is saying. IAB and IESG is in the room. And leadership will think about the points raised. Mirja: there are other groups that are cross area. this isn't unique. Jana: wg should consider adding many applications early (beyond H2) Rich Barnes: Agree with Mark. Concerned with multidisciplinary effort: TSV, APPS, SEC. Need appropriate oversight. PHB's point about convergence is a good one. Don't ignore compliance. TLS 1.3 is the way to address it. Jana: agree Magnus Westerlund: very client server architecture. Haven't discussed how it will work in a p2p use model. Christian: should develop this use case, maybe not right away. Jana: Version negotiation is key since it will allow design to evolve. Ted: Need to think carefully about the extensibility model. has to go beyond version number. Pat McManus: really excellent work. Passes bar of running code at a Bof at a much higher level than usually seen. We want to help and participate. H2 experience is the most successful example with ~dozen interoperable implemantations. Very valuable. Re: structure & cross-area - that's an opportunity to build a better protocol as well as a functional challenge. Need to figure out how to negotiate versions and experiments in a scalable way. Colin Perkins: one point with two subpoints. Lots of discussion about broadening out from HTTP. Also need to go the other way. Are there any application domains where this is not suitable. Are there any that you do not intende to support? Ted: eg., any apps that can not use an encrypted transport (e.g., TFTP). Worth epanding on. Jana: e.g., multicast Colin: eg, very low latency apps Colin: 2nd point: lots of learning from TCP here. many media apps (MPEG DASH) interact poorly with TCP congestion control. THink about how these applications will interact with QUIC. Lorenzo: observe that everyone is here because we can't change TCP anymore (as of 10 years ago). neeed to make this protocol future-proof and camoflauged. Middleboxes that 'accelerate QUIC' will create new ossification. Want to avoid those vendors from blocking protocol. Encrypt everything. Christian: version number is not the best use for negotiaion since it is only a single access. THink more like TCP options. Ted: 2 crypto envelopes. one is just integrity. need to figure out which pieces go into which crypto envelope. See PLUS bof tomorrow for more discussion. Our proposal does not intend to signal the end of transport evolution. Göran Eriksson - emphasizes migration and multipath. concerned multipath will be lost and would like to see a requirements and use case document inclduing it as a charter item lars suggests whether including known working mechanisms for sctp could work Schwartz (jigsaw) - evolution is key item - preserve evolvability to userspace p2p applications. Port numbers are concern for ossification Magnus Westerland - The wg should include cration of an API(?) [need help] Mat Ford: Some deployment on android, does it 'just work' on the vast majority of mobile & cellular networks? Is there data? Some operators say they block UDP as a swamp... Ian: yes, we have data that shows it does work. We see data as about the same as for desktop. Sometimes less usage of 0-RTT Dan Druta: wg should have an objective to cover manageability and troubleshooting aspects of protocol. Not just the endpoints that need to work correctly for protocol to work. Ted: to chairs: show pull request, please... "This work will consider deployability, manageability, and diagnosability of the wire format, including how the wirefeoact will be processed by devises on the path." Brian: this is broad, need help to make i narrower Dan: the charter wording should allow us to describe some requirements. Lars:give me an example of a requirement Dan: sigh. Schedulers do resource allocation... need to take this into account. Ted: wireformat should allow on path devcies to distinguish between QUIC and attach traffic. Suggest "This work will consider deployablability and diagnosability both end-stations and path elements." Lars - different set of exposures for network vs end elements - uncomfortable putting them in same charter sentence Jana: many of these issues are shared by WebRTC and DTLS. QUIC wg isn't the right placde for this. Spencer: am sponsoring AD for QUIC and PLUS, am aware that there is a relationship. Adam Roach: comment for the IESG. re: managing groups that cross multiple areas. This room is like a plenary. two other groups moved out of the way on the agenda. Need to think about scheduling if this group happens. Cullen Jennings: re: peer-to-peer. understand desire to minimize scope but p2p should be thought about early. RTLS is a counter example of how to do this. re: encryption. want to maximize odds of success. Note presos all said fallback was always encryptino over TCP. Firewalls want stream state as basic item. Jana: yes, universal UDP reachability would be wonderful but don't hold your breath. Note that QUIC reaches 93% users between Google and Chrome. Cullen: my data doesn't match that. 5% miss is a problem. The point is maximizing the number of places this works. lars notes mptcp doesn't work for ~5% - ok with IETF Brian: please send data. to MAPRG. Cullen: firewalls should be able to identify this in one flow Wouter Cloutens - pushing a draft this afternoon on how operators are going to .... Kevin Smith Vodafone- QUIC is running in 30+ countries. WOrking fine. Provides significant performance improvements. PHB - may want to consider more than one group. More interesteed in security / keying than transport protocol format. Lorenzo - If a firewall requires a sequence of packets, you have killed 0-RTT mobility. Evolution is more important that 100% reachability Joe Hildebrand - there are design approaches for quick restart on new links (mobility?), a nice topic when wg engineering starts. might happen in a PLUS wg. ADs will have to sort this out. lee howard - should collaborate more with operators - there is info we don't want to see afterall. enterprises have different requirements and are not represented here. supports adding managing network elements to the charter Jana: recommend we distinguish data encryption from transpoert header encryption Ted: re: PLUS - this is a general problem not specific to QUIC. Come to PLUS BoF to discuss. That work will take time to come to fruition if it is accepted. Can discuss now what you need to undesrtand about the packet to recognize the flow. Joe is asking for help in getting ways to describe QUIC flos. Mark Nottingham: difference between protocols with and without fallbacks (aka quic to tcp) - might simplify things as there is a fallback here Ted: note that many protocols proposed as use cases do have a fallback. (e.g., SCTP/DTLS/UDP or TLS/TCP). Q: are there any examples that do not have a fallback? None so far. Jana: Mark's point is very good. May want to charter to require use cases to identify a fallback. Adam: existing protocols will of course have a fallback. But if we had created WebRTC post-QUIC, we might not have created a fallback and it might have been a lot of work. SUMMARY Hums to be on the charter text as-posted. Know there are edits coming. Rechartering is not that hard. Joe H: concerned about how concerns about things being out of the scope of the charter will be handled - asks Spencer (re recharting or modification of charter) Spencer: the question is whether this charter is ready to send out for comments. Brian: charter is likely to evolve before finalization Ted: Joe want to know whether the conversation about diagnozability etc is permitted under this charter Is the problem statement clear, well-scoped, solvable, and useful to solve Yes - many hums No - very few hums Lars: rough consensus clearly established. Who is willing to review documents to the list? ~50 hands Who is willing to edit documents? ~dozen hands Should the IETF form a WG with the charter as posted to the mailing list? Yes - very many hums No - a few hums Lars: very clear consensus Dan York: a number of yes hums in the jabber room Spencer: I think I've got enough information. Look for call for consensus on charter on mail list.