Minutes IETF109: quic
minutes-109-quic-01

# QUIC Working Group - IETF 109

Scribes: Dmitri Tikhonov, Robin Marx, Dan York

## Administrivia - 5 min total

* Blue sheets
  * Meetecho does the bluesheets
* NOTE WELL
* Agenda bashing
  * Lars: I moved MP discussion down

**Lucas**: use Meetecho tool to put yourself in the queue

## Hackathon / Interop Report
5 min - Recap of interpo at hackathon (interop sheet) - Lars Eggert

**Lars**: Nothing special to report.  Interop Runner continously testing.  That
will go on for foreseeable future. **Lars**: congrats: we're past IETF Last Call

## Base Drafts Discussion
30 min - Placeholder for any needed discussion on issues raised during IETF
Last Call

[Slides](https://github.com/quicwg/wg-materials/blob/master/ietf109/quic-issues-status.pdf)

**Jana**: We had 129 issues during last call. Most from area reviews, just a
few from wg participants. Closed 74 of them as they were minor/editorial/no
action issues. Left 55 open, but many are very trivial (26 are proposal ready).
25 in the last 2 days, so no proposals yet (mostly IANA+area review). Only 4
that are older than 2 days that don't have proposals.

**Jana**: of open issues only 2 marked as design, have proposal. 3 issues left
with active discussion on GitHub. Does anyone want to discuss these?

**Magnus**: Can we spend a little more time on issues regarding  IANA registry?

**Lars**: raised by stewart and genart reveiew. For vnums no registrty defined,
just question of which document they should be in. Ideally in invariants, but
there is a bunch of text about policies we define for registries, and that text
is in transport. Question if we need to move/replicate that.

**Jana**: Discussion probably hasn't moved too far on that. Feel this is
discussion with ADs/chairs. Seems it's not a discussion to have with entire wg.

**Magnus**: This is something all people specifying future extensions will have
to deal with, so wg should pay attention to this.

**Martin Thomson**: I put in a PR for this in the Transport doc, because that's
easier to do. Don't see much added value in putting it in invariants.

**Magnus**: I'm fine with that

**Martin**: Saw number of comments but none of them are particularly troubling.
Questions of where to put notes (my pref = nothing). Rules around the first
value (my pref= follow your suggestion). Can we look at the issue?  #4378 (from
memory) - IANA review of -transport, question 3. Provisional assignment or
early allocation. PR saying first value in any space follows standards-action
space: follow RFC7120. Please check.

**Jana**: I haven't had a chance to look at this yet

**Lars**: What makes sense?  We'll settle it one way or the other, none of them
will be terrible

**Jana**: Wanted to support what you said on the other issue about having vnum
descriptions in v1 in transport instead of invariants. Invar is focused on
protocol specific things, this is about process, doesn't belong in invariants.

**Martin**: I've done review of all open issues. Aside from h3 or qpack, I'm
satisfied we've got PRs for most, other questions can be answered via email.

**Lars**: That's it in terms of issues.

**Lucas**: Wrt HTTP issue I raised, I think that'll probably be closed without
action, but maybe small editorial tweak we want to make. Probably not more to
say there. Can Mike Bishop maybe comment?

**Lars**: Intent going forward is, IETF last call is closed, do another
revision of the draft set that rolls in all of the changes. Hopefully that'll
give us a clean slate. Then go to IESG review sometime in December. Probably in
2 steps: taking invariants transport TLS recovery on 1 telechat and H3 qpack on
a 2nd telechat to make easier for IESG to review. Question is what would happen
then. Ideally then to RFC Editor queue, or might have to do new round of
revisions. We'll know in December. Hopefully in the new year we'll have drafs
in RFC Editor queue and hopefully be finished later in Q1.

**Lars**: Have been asked by implementers that want to ship quicv1, what should
they do? My take is that once the drafts are in the RFC editor queue (after
IESG approval), I would consider it safe to call yourself v1. Only editorial
changes would happen in RFC editing. It's your call though.

**David Schinazi**: strongly disagree with that. Fundamentally we need bakin'
time. We need to deploy this and know it works. For TLS 1.3, found out it was
broken. Luckily we found it and fixed before fixed. This -can- happen while
it's in the RFC queue. Probably not huge changes, but still changes. Our goal
is to make a good standard, let's not rush.

**Lars**: Don't remember timeline for TLS. Don't know if that came up during
RFC editing. One point: this question came from implementation that has some
release windows. Question is if they can make that window or have to wait.

**Martin Thomson**: Two things to say.  First, David is too cautious.  If we
have to burn v1, then we are OK to use another version.  No emergency, can add
antoher version.  The salts will have to change between last draft and final
release. Hoped to do it later.  If IESG approves it, we can do it in AUTH48.

**Lars**: We could do it in RFC editor; we can figure it out later.

**EKR**: When TLS interop problems were found, that was before IESG review. I'm
between Martin and David. True that there's nothing special about codepoint 1.
However, problem is if we don't know when people are deploying with cp 1. If
substantial portion does, and we need to make change in RFC editing, and
continue with cp 1 because we don't know about broad deployment. We need to
discourage people from using cp 1 until RFC is shipped. Just continue to use
the -29 cp. Not like it's a large change. We don't have perfect knowledge.

**Matt Mathis**: As example of where too early commitment an fail: language
ambiguity found in an earlier document. Releasing the version before the
document is fully done is dangerous.

**Martin Thomson**: We can interpret my suggestion here that is if we want to
revise the document, we also need to move to a new vnum. Bit confused by what
EKR was suggesting.

**EKR**: Right now, if people deploy... If we're prepared to commit to v1... 
People should wait.  That's why we have things like RFCs.

**Jana Iyengar**: Want to remind people we're already deploying quic -29. So v1
should be just another revision. I don't think v1 is any special in this
regard. We will have change in salt though. Customer aspect: they ask: "is v1
ready?" Doesn't make sense to wait for RFC editor to fix semicolons in the text
to call v1 done. I see no reason to wait for RFC editing before minting v1.

**EKR** There are not just colons and semicolons. Found many non-trivial
changes in TLS 1.3 from looking at it with fresh eyes

**Ian Swett**: We deployed h3-29 quite widely, in Chrome and Google servers.
Performance seems quite good. Don't have overly large concerns about technical
aspects of the draft.

**Spencer Dawkins**: We've had conversations about not having a QUIC v2 anytime
in the foreseeable future but just using extension mechanism a lot and not
rolling new vnums. Seems like that's going to be an important part of this
answer. I agree vnum shouldn't be special, you just need to support them.

**Lars** Queue emtpy, we're pretty much just on time. Will eventually also go
into a late  stage process of the ops drafts. Jana will discuss this with
editors in the coming weeks.

## QUIC-LB: Generating Routable QUIC Connection IDs
10+10 min - Discussion of the QUIC-LB draft - Martin Duke
[Draft](https://tools.ietf.org/html/draft-duke-quic-load-balancers-06)
[Slides](https://github.com/quicwg/wg-materials/blob/master/ietf109/QUIC-LB-IETF109.pdf)

(Martin Duke presents)

**MD**: I presented similar slides at 108.  Got feedback, deleted some
algorithms that were satisfying to delete.  Ian and ? gave good feedback.  I
was able to open-source some impls. encode and decode.  nginx is a load
balancer.  That's available, just waiting for a server impl, let me know when
you have that, we'll interop.

**MD**: next slide.  Addressed Ant critiques.  Request for UDP proxy protocol. 
Ops does not have right people to get feedback.  No feedback from big cloud
providers on L4 balancers. One last appeal for some guidance here.

**MD**: (next slide) First two bits for every CID are for config rotation. If
you're rotating your keys, take a time for servers to catch up. Proposal to
make it into 3 bits to deal with SNI switching.

**MD**: (next slide) MegaCloudCorp with one huge shared config where all
clients could change would lead to security issues. In practice, need to run
different configs. If it's in the ClientHello you're going to need something
that is in every packet. 2 options: a) multiple configs separared by these
config bits. Solves problem of having mutually mistrustful customers able to
reach each other's mappings. But is still globally visible (circumvents things
like ECHO). b) alternative is to share configs manually. More difficult for
attackers to position themselves. Tradeoff, my pref is towards b.

**MD**: (next slide) in violation of QUIC transport.  Keep this in thbe draft
(plaintext CID).  INtroduce TP "hey, I'm doing this, but if you're concerned,
don't migrate."

**Ian**: Any time you have one domain name to one IP, you have immediate
linkability.  I don't know what to do about that -- this is best effort, the
world is not perfect.

**MD**: Agree. One lesson I learned from LB is that there are no guarantees.
But ECHO exists for valid use cases and don't want to break them with this.

**MT**: Two things. 1) this is the same server we're talking to, then it's
indeed just one IP. But this text is about services. You're creating smaller
anonymity sets for diff customers. Analogous to having separate IP for servers
in the backend. At that point you're back to what Ian says. Depends on how many
people are using these servers.

**MD**: I am glad to hear you're comfortable.  I am.  Do you think the TP is
worth having?

**MT**: No probably not worth it. We'll find out in time, but wouldn't start
with something like that .Don't know what we would do with that information.

**MD**: OK, there is PR on GH.  Put comments there.

**Ian**: I agree with MT.  It's not worth it.  We can have 10,000 conn or more
going to same machine.

**MD**: (skipping 4 slides) #35 was resolved recently. (next slide) There's a
list of the things you need to configure to make this work, but no really
config mechanism. Haven't really had any feedback from people on what to do, so
would appreciate some input.

**Eric Kinnear**: We are chatting with our CDN folks.  Hey there is this QUIC
thing, can we make it work?  They are involved in early renditions of ? stuff. 
They are happy with later things.  Thank you for putting so much effort into
this.  We have peolple who care a lot about what's going on.

**MD**: Will wrap up after this meeting.

## Manageability/Applicability of the QUIC Transport Protocol
5+5 min - Final steps on the Applicability and Manageability drafts - Mirja
Kühlewind & Brian Trammell

[Draft
applicability](https://tools.ietf.org/html/draft-ietf-quic-applicability-08)
[Draft
manageability](https://tools.ietf.org/html/draft-ietf-quic-manageability-08) No
slides, see [github issues page](https://github.com/quicwg/ops-drafts/issues)

**Brian Trammell**: 3 open issues. 1 has PR, 1 does require some discussion
(normative language or not), 1 has bit of text to add. Had some discussion on
these docs in hallways and mailing lists and issues. Are getting more
participation than last year. I'm here to say that the train is leaving the
station. After these 3 issues we're planning to submit another revision draft
and have that go to WGLC before next IETF. If you have anything that you'd like
to ask/say, you're running out of time.

**Mirja Kuehlewind**: Think we did address #115, just didn't close it.

**BT** By end of week, we'll have docs ready to rev.

**Lars**: That makes sense. Want to have people take a look at this. Going to
WGLC is a good trigger for that.

**BT**: Look at issue 100, was waiting for base drafts to stabilize, to make
sure section numbers are correct etc. Think we're ready to go now. Thanks to
everyone

**Lars**: Did a show of hands to see who read some version of these drafts this
year. (Results are 16 read and 28 not read). Argues for longer WGLC of 2-3
weeks to let people take a look. Don't have to wait for this though, can
already send feedback now!

**MK**: We've been reading other docs and try to reflect.  Figure out whether
anything needs to be added or removed, not just agree or disagree.

**BT**: WE've cut some things over the time we've been editing.

## As Time Permits
Subject to reordering

* 5+5 min - Discussion of the QUIC Version Aliasing draft - Martin Duke
[Draft](https://tools.ietf.org/html/draft-duke-quic-version-aliasing-04)
[Slides](https://github.com/quicwg/wg-materials/blob/master/ietf109/Version%20Aliasing%20IETF109.pdf)

**MD**: improve greasing and privacy of QUIC. Basic idea is that you start with
v1 and server gives you TP with various random numbers. (next slide) Client
takes all that data and in a subsequent connection uses the random
vnum/salt/token/length offset. Server can then compute salt and offset from
that. For connections after the first, initials are fully protected and cannot
be decrypted by outsiders.

**MD**: (next slide): didn't touch QUIC bit yet, also some issues with doing
this for packet type. (next slide). Makes initial packets entirely private and
immune to ossification (prevents TLS ossification on initials). Deals with
injection attacks. However, doesn't cover first connection, which is a main
concern. Also, if no large deployments are interested on this, probably not
useful to move on. Maybe steal some things from ECHO/use ECHO to apply to the
first connection. Wanted to know if there is any interest in continuing to
invest in this idea.

**Christian Huitema**: It's interesting to find something that makes conn more
robust.  if we want to, add additional checksum to make sure things are not
messed with in transit.  Prevent 3rd party to mess with packets and make
packets not observable by anybody.  The latter is a bridge too far.  To sum:
I'd like to look along those lines, but goes for auth rather than encryption.

**MD**: I'm trying to combine things to maximal results. Some people in chat
are saying this is more about greasing and not about privacy. If that's the
main thing, we can go back to Marten Seemann's original proposal of just having
3 versions per server that are used.

**Lars**:  It'd be intersting to hear what direction people think this should
go towards.

**David**: This is useful. Helps reduce ossification risk, but only slight
privacy improvements (think we're overselling these atm). Just need to do some
evaluation of priv/sec aspects. We should spend some time on this. I'd like for
Google to implement this.

**Lars**: Increase greasing, then?  Is that what you're interested in?

**David**: Mainly interested in making ossification harder. Privacy is
secondary, as it makes observability slightly more limited.

**EKR**: The question to ask... Is this ECH and should it just be QUIC ECH?
Differences I can tell is that it only works from second connection. We looked
at this type of design for ECHO using the PSK mechanism as the seed and
wouldn't need SNI. Same problem: if you lose state, no way to recover. In your
proposal, there is a way to recover _(didn't quite follow this)_.

**MD**: I'm trying to bring in some ECH concepts, but not ready for prime time.
Does have some different properties than ECH. e.g., server initial is also
entirely protected, but not sure this matters.

**EKR**: THe idea would be you'd hoist some of this info into QUIC.  Can you do
that?  I don't know.  This is reasonablty complicated already.  If we don't
have to solve it twice, would be good. I am with David, let's take a look and
see what the options are.

**Eric Kinnear**: I would second David's comment. Interested in greasing. Worth
spending time to see if we can get security and privacy wins. Even if it takes
us v2 to deliver this, it would still be very interesting.

**Christian Huitema**: Just a comment on EKR reuse of ECH or other TLS things. 
I worry if TLS message grows larger than one packet then TLS solution won't be
adequate.  We have to take that into consideration: is it worth it to increase
size of TLS packet?

**Lars**: Let's take it to the list.

**MD**: Cautious enthusiasm.  Please comment on GH or mailing list.

* 5+5 min - Discussion of the Network Address Translation Support for QUIC
draft - Martin Duke
[Draft](https://tools.ietf.org/html/draft-duke-quic-natsupp-03)
[Slides](https://github.com/quicwg/wg-materials/blob/master/ietf109/quic-natsupp-ietf109.pdf)

(Martin Duke presents again) (he's on fire today)

**MD**: NAT can lead to black hole when migration happens or you can end up
breaking QUIC security model. So this draft just says: please don't do this.
(next slide) Not exited about adding PROXY protocol myself. (next slide). Don't
really care where we put this. Currently in separate draft. Could put this in
ops draft or reference it there, etc. Want to hear thoughts from people here.

**Lars**: If we decide we need text along these lines, prefer it in the Ops
drafts.

**MD**: Everyone's indifference is as great as mine

**Gorry Fairhurst**: Having separate draft is good if people just implementing
NAT have something small to look at.

**Lars**: People who build NATs don't look at RFCs.

**MK**: I wouldn't want to ref an expired draft from ops to prefer separate
document. I think we can have a shorter version in ops draft or merge the whole
thing. No real pref.

**Spencer**: Back to Lars' thing about reading RFCs.  However people who buy
NATs might.  Maybe put ? in the abstract.  _(did not get that last part)_

**MD**: I'll send a PR, that's what people would prefer me to do.

* 5+5 min - Discussion of the 0-RTT-BDP draft - Nicolas Kuhn
[Draft](https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-07)
[Slides](https://github.com/quicwg/wg-materials/blob/master/ietf109/draft-0rtt-bdp-vf.pdf)

**Nicholas Kuhn**: Idea is to add new TPs when re-connecting with 0-RTT.
Bandwidth estimations based on in-flight data or RTT estimates. Could be used
to share past parameters so clients could adapt their request or improve 0-RTT
performance. Has been implemented in picoquic with TLS 1.3 and Matt Joras using
BDP_TOKEN. Would like input from the wg.

**NK**: Have some early evaluations using picoquic PR. go from 4.3s (no 0-RTT)
to 3.4s (0-RTT) to 2.9s (0-RTT with this extension).

**NK**: Unclear on the precise mechanism: BDP_TOKEN vs NEW_TOKEN.

**Matt Joras**: Some context:  We're developing something for FB broadly
similar.  But server informs the client about network characterstics.  Use QUIC
frame to do it.  Makes sense for server (for us) to do this stuff.  Ours and
this idea are compatible.  Perhaps send this frame as part of 0-RTT.  either
peer can contain this frame.  I am a proponent of frames for this sort of
thing.  They're easy to add and use.

**CH**: Two parts: There are a bunch of things that come from idea of ...
_(missed this, sorry)_  The other part is remembering what peer did before. 
The consensus it need not be standardzied as it's specific to implementation. 
They can use some sort of cache or token.  They'd do it with NEW_TOKEN as it's
a much better fit because it can be sent at any time in the connection.

**Lars**: Kazuho is agreeing with CH in chat

**Ian Swett**: Doing it in the NEW_TOKEN is relatively safe. Is more of a
tsvarea thing to figure out guidelines. But I don't see why we need to do
anything in QUIC for this. I feel we already provide good mechanisms in QUIC to
accomplish this and think NEW_TOKEN is a good example. Think it's more
dangerous than it's worth to further specify this for QUIC.

**Lars**: A whole bunch of agreement in chat (Praveen, Christian, Dragana) with
what Ian said

**Jana**: Agree with Ian. Why does this need to be explicit? If this is just
going back to the server, we can just make this opaque to the client.

**NK**: Discussion on the list -- clients can adapt their session preference
depeding on what they have.

**NK**: Last slides: next steps might not be what we envisioned before (NK is
disconnected)

* 5+5 min - Discussion of how to progress qlog (main schema, QUIC and HTTP/3
events) - Robin Marx [Draft main
schema](https://tools.ietf.org/html/draft-marx-qlog-main-schema-02) [Draft QUIC
H3
events](https://tools.ietf.org/html/draft-marx-qlog-event-definitions-quic-h3-02)
[Slides](https://github.com/quicwg/wg-materials/blob/master/ietf109/qlog_IETF109.pdf)

Robin Marx presents

**RM**: (slide 2): structured logging review, useful for debugging and
analysis.  Log congestion windows. It's good for privacy: log just what you
care about.  Easy to build tooling.

(slide 3): >70% adoption, notable FB in production -- it can scale and work in
practice.  Implementations that don't use qlog use something similar.  General
concept is solid.

(slide 4): Still just personal drafts.  Few people dealing with day-to-day
work.  Time for additional discussion how to progress it.  Who is going to do
it and where to do it?

(slide 5): four options - nothing - interim/Design Team - adopt in QUIC WG -
adopt in another WG.  Eventually I think we'll go with (4).  It's useful beyond
QUIC.  Were planning to do this initially, but would take too long to do
something generic. Started with QUIC/H3 POC. This is why we're bringing this to
the QUIC wg first.

**Lars**: I think the use case is very much QUIC and specifically TCP-based
workloads already has tooling.  It fills the need for QUIC.  I think (3) is
reasonable.  It does not preclude doing (4) at some point.

**Martin Duke** Want to see qlog QUIC/H3 draft adopted by QUIC WG.  It's the
general tool for this.  As far as main schema qlog draft goes, conceptutally,
not the right place, but practically, why not just do it here?

**Eric Kinnear**: qlog is great, we've adopted it.  Nice privacy win.  Being
able to visualize is very nice, esp. with HTTP/3 priotization.  Both useful and
in helping conceptualize impact of changes.  It's useful for WG and
implementations and deployment. I disagree with Lars.  I want to bring it to
TCP.  Yes, there are existing tools, but qlog/qvis is already as good as most
of those tools.  Quicly becoming apparent that qvis elicits "oh this is cool!"
response.  Value of having all of that in one place.  Let's make it really
robust.

**Robin Marx**: It's not so much TCP for me, it's more new/other app-layer
protocols.  Lots of potential there.  BGP and that kind of stuff.

**Ian Swett**: I support this work.  Having it for HTTP/2 would be amazing. 
Expanding it to more transport would be hugely helpful.  More congestion
control information in there.  I hope to work with you on that.

**Jana**: Thank you for this work Robin.  qlog becoming defacto standard.  Many
impl. support it and continue to support it.  Let's include it as part of QUIC
WG.  We need to have tooling.  Seriously good tooling, qvis is.  Though tooling
is that people love, qlog is what people need.   We're adopting qlog the format
not qvis the tool.  Let's not expand qlog scope, then, to include TCP.  Let's
not cast too wide a net.  Let's have qlog be specific to QUIC.

**Lars**: This distinction is interesting.  What's the model for jointly
developing qvis or similar tools?  Strong deps between format and tools.  Need
to have discussion about it.

**Matt Joras**: Thank you.  qlog is first thing I go to for our debugging
needs.  I support WG adoption.  Defacto standard.  QUIC WG is the logical place
for it.  It's reasonable path fwd.  Another WG not much sense: it would be same
people.

**Lucas Pardue**: I hoped this would come up: it's taken us a year from -01 to
-02.  Large burden on Robin.  Not a criticism.  Hopefully people can contribute
if we have more governance over this text.  As individual, I support adopting
it somewhere.

**Lars**: Robin is doing this by himself in addition to doing his thesis.  If
we're adopting it, we would encourage people to chip in and help out.  Both
spec and developing and visualization tool as well.  Everyone would benefit. 
Will continue discussion on the list.  Leaning toward (3) and (4).

## Planning & Wrap up

**Lars**: Let's see what else we can adopt.  MP is what's left.  We'll try to
recharter now that base drafts are done.  Taliking to ADs about new text in
Charter.  Extensions?  There will be draft versions of charger.  Not planninng
any more interims.  No topic requires an interim.

## QUIC Multipath
30 min - Placeholder for any needed discussion based on the status of the
mailing list discussion min - Future meetings, implementation drafts, etc.

**LE**: It's been freeflowing.  There has been some directions that became
clearer.  SDome people belive that what we have in draft is enough.  It's not
TCP-MP, but some say what we have it's enough.  Other say we need concurrent MP
use.  Let's see if we can come on agreement.  Please be brief and get into
queue.

**Ted Hardie**: Exegesis is not important (?).  Things changed since charter
was written.  QUIC has changed as well.  My take is that MP in QUIC now don't
work without multiple connections.  If you want it within single transport, you
would make it a first-class element of some verion of QUIC.  Decide isn't MP,
but whether it's apps doing MP using QUIC.  Will it be a baseline version of
QUIC or a parallel version of QUIC.  All are on the table.  I'd prefer
concurrent MP as a version of QUIC.

**IS**: Want deployment experience.  New version of QUIC is sensible.  We've
been deploying QUIC for six years.  You can widely deploy something and then
come back to IETF.

**Spencer**: I think one of the Qs to ask was: we're talking QUIC do all the
scheduling for MP or having app do that.  At least 2 people mentioned on list
of coming up with common layer on top of QUIC.  Im curious: how many more other
people thought of that.  Second: agree about experimenting and getting back to
WG.  I thank WG for talking about MP.  I try to do some analysis in draft I
sent to QUIC list today to understand what diff. people mean by MP and how they
hope to use MP.

**Eric Kinnear**: I want people to experiment deploy and get back with
comments.  No need for RFC to get that experience.  Demonstrate benefit.

**Jana**: At high level I don't think MP should be in transport.  Useful in
long term, but long term.  Now, however, we spent a lot of time building conn
migration.  One of two design issues we caught was around migration.  Gift that
keeps on giving.  I expect more dragons be there. If people want to experiment
I encourage them strongly  Consider mechanisms already in place.  Even if we
replace those mechanisms, replace them meaningfully.  There is a distinction
between use and design of protocol that accomplishes MP.  Because MP can be
used with QUIC.  I want to see how it gets used.

**CH**: Question that: should MP be new version of QUIC?  In practice, we can
do a lot with extensions.  Datagrams, delayed acks -- same kind of complexity
as MP.  We can experiment with MP building on extensivility of QUIC protocol. 
See recent discussion with Kazuho on the list.  We're *almost* there.  Let's
experiment.

**Dmitri Tikhonov**: Want to point out that we just had a presentation about
Multipath use of QUIC. Why is that not valid? Didn't you guys like it? I liked
it.

**Lucas Pardue**: (chair hat off, literally). Similar to Jana and Christian:
we're still trying to take this transport layer and map H3 on top as a fully
flexible app layer protocol that mainly uses QUIC for its primary goal of
removing HOLblocking. This will be a good test of implementations to see how
they use congestion and flow control. Too much focus on using MP to solve
performance problems of QUIC impls right now probably throws away bandwidth on
trying to do that by other means (e.g., extensions like delayed ACK). Let's be
careful in applying solutions to problems that are unique _(didn't quite catch
this)

**Erik Kinnear**: I agree with that a lot.  Let's not throw MP at problem.  We
deployed MP.  The problem is not technical, but policy.  And cost.  If we want
industry change, if we want to see a change in cost structure, then more people
would be interested to deploy MP.  If we advocate that it won't be a big policy
problem, we'd be wrong.

**Jana**: Completely agree with Eric. Want to re-emphasize what Lucas pointed
out. One of the thinks that made MPTCP slightly easier was that it was
operating under a single byte-stream. So the constraints on it were pretty
clear on what the receiver needed to do. QUIC has multiple streams and need
priorities. Takes scheduling problem of multiple paths to multiple streams over
mutiple paths. This is a performance problem; Mark Handley did some early work
on this. He found that it was critical to pin some streams on some paths to get
perf benefits for HTTP. For other use cases it might be different, but for
something QUIC generic, we need to consider the basic streams building blocks.

**Spencer Dawkins**: At least one per  IETF meeting I point out that there is a
conv in Jabber to take note of.  One point in slack during virutal interim (I
think it was Matt) that the difference between use cases were that some people 
use H3 versus those who would not.  We hear people say remove path restriction
for connection migrtation.  What's the diff betwen that and MP support?  I
suspect the difference is between those who use H3 vs those who would not be. 
Again, thanks for doing this.

**Mirja Kuehlewind**: Disagree somewhat with Jana. Scheduling is indeed
complex, streams make this slightly worse. But it's not a problem we need to
solve completely now. It's like congestion control; can't optimize fully. Just
looking for basic scheduling schemes that support basic use cases to start with
for now. Also looking into getting signalling into the protocol so
experimentation can start. Signalling itself isn't that difficult, can be
quickly agreed upon, which would be useful for sparking experimentation.

**Lars**: Desire for more experience and experimentation. Questions is if the
WG needs to do anything here. Can just use a private version (e.g., see Alibaba
who's done that). I don't see a need for the WG to do something MP-related to
further enable something. It's very clear we won't change v1 for this,
definitely only future version/extension.

**Ted Hardie**: Example that Martin Duke gave for LB is what I am looking for. 
Share experience, compare implementation notes.  The support does not nee d to
be more than that in the beginning.  Having the context -- MD came to WG to say
there is this thing in the transport Draft I have to relax -- is that OK?

**Lars**: so be a forum for discussion of results and if there are needs to
change the basic specs.

**Mirja**: We don't need experimentation on e.g., if we need multiple PN
spaces. We need experimentation on if and how people would use MP. But that
only happens if people have a ref protocol they can use. Not all applications
that are interested would want to implement their own thing.

**Lars**: there are already impls. that do one version of MP.

**MK**: why have multiple flavors of MP?

**Lars**: I don't see why we need to do any spec work to enable further
experimentation.

**MK**: design question, not experimentation question.

**Lars**: I disagree.

(We are running really short on time now)

**Jana Iyengar**: I agree with Lars. This is 100% question of experimentation.
People can do that today. Just because we specify doesn't mean people show up
and start experimenting. It should be the other way around. So we should do
what Schinazi proposes: let people present experiences but not protocol design.

**Lars** See you on the mailing list and on the Slack.  Bye!