Minutes for QUIC at IETF-96
minutes-96-quic-1

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