Minutes IETF110: quic
minutes-110-quic-00

# QUIC at IETF 110

[Agenda](https://github.com/quicwg/wg-materials/blob/main/ietf110/agenda.md)
Scribes: Robin Marx, Spencer Dawkins
Chairs: 🪑🪑🪑 (Lars Eggert (for the last time), Lucas Pardue, Matt Joras)

## Administrivia - 5 min total

**Lucas**: Welcome to our new chair, Matt Joras!

* Blue sheets
  * Meetecho does the bluesheets
* NOTE WELL
* Agenda bashing

**Magnus Westerlund**: Recharter on agenda?
**Lars**: no, because nothing to do, Proposal is out, no non-editorial
suggestions yet. Wait until 18th March. **Lars**: For those that don't know:
Now that we've finished v1, we're changing gear and HTTP/QPACK are handed over
to httpbis. We will maintain other documents, as well as operability and
manageability and some extensions. **Lucas**: Core docs are now past IESG
(thanks Magnus!). So no issues on those docs today, because they're pretty much
done. No more opportunities to open new feature requests/issues if they're not
e.g., serious security issues **Lars**: Talked to RFC editor. Expectation is
that first batch goes to AUTH48 in weeks, not months. H3 and QPACK however are
waiting for httpbis work, so those won't be part of the initial batch.

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

**Lars**: Hackathons are less busy than they used to be. Partly because
switched to using v1 and not all stacks have made that change. A lot of
[interop testing is also happening in an automated
fashion](https://interop.seemann.io/) (thanks Marten Seemann) and most of those
tests are succeeding.

**Christian Huitema**: Did have perf interop/testing. msquic, lsquic, picoquic,
ngtcp2 and quinn did [perf interop organized by
Microsoft](https://tools.ietf.org/html/draft-banks-quic-performance-00).
Measurements of QUIC performance were done on dedicated hardware. Good news:
all achieve speeds between 1-5 Gbps with just software implementations, no
hardware assist. Shows two things: a) hackathon is moving from basic interop to
performance. b) work done by various OSes to make UDP perform better is
starting to pay off. A year ago we'd get 500 Mbps, not Gbps. Especially in
Windows and Linux with things like UDP GSO has been paying off.

## WGLC changes to
[manageability](https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/)
and
[applicability](https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/).
[Slides](https://datatracker.ietf.org/meeting/110/materials/slides-110-quic-quic-applicability-and-manageability-wglc-update-00)
- *Brian Trammell*

**Gorry**: Not sure we need to talk about priming a CC. If we don't say it, we
can still do it and specify in future. If we say it here, need to be careful to
explain what it means and that we know what happens if you do this badly and
that we give good advice. Not sure we can do last two? **Brian**: Punting it to
the future is a good option. **Mirja**: Intention is to mention what probe
packets can be used for. Not at position where we want to recommend specific
mechanism, but still think it's valuable and like to keep it (though without
saying more). **Christian**: Don't think this is ready for primetime. Don't
think we have a lot of implementation experience with it, so it's speculative,
and would rather not have that in an RFC. **Gorry**: making it more blunt
"assist in determining cc state of a new path" or not hinting at what the
mechanism would be, is also a possible solution here **Mirja**: Could actually
just say that: probing packets can be padded with padded data and thus increase
CC data, without saying much more **Brian**: Want to have something here to
provide a hint so people don't have to independently re-invent this. **Mirja**:
It's not just internal, since some applications might want to influence how
this happens (re: comment in chat)

**Magnus**: Comment on PR 279: simpler if we get previously used draft versions
in official IANA registry and then point to that. **Mirja**: Wasn't there
discussion that we -don't- want to do that? **Magnus**: Some discussion but I
don't know, so that's why I want to bring it back up **Martin Thomson**:
getting all versions in the registry should be straightforward. We can then
scrap the wiki. In the process of appointing experts for those registries now,
should be ready in time for when the docs get published.

**Gorry**: comment on PRs 240 and 178. Still don't know right answers. First
one: more to do with environment/deployment context. Willing to help contribute
to text for both.

**Brian**: After these issues are merged, we think we're ready on
applicability. Have to wait for resolution on changes on manageability to see
if we need to issue a new WGLC.

## Open issues, updates to
[DATAGRAM](https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/).
[Slides](https://datatracker.ietf.org/meeting/110/materials/slides-110-quic-quic-datagrams-00)
- *Tommy Pauly*

**Tommy**: Few [open issues](https://github.com/quicwg/datagram/issues).
Targetting shipping in July 2021.

#### [Issue 6](https://github.com/quicwg/datagram/issues/6)
**Tommy**: Propose to add explicit indication why we're not providing a
demuxing identifier in this draft. **Eric Rescorla (ekr)**: not advocating for
one or other. Need to specify what benefits and costs are. (Robin: not sure
what was said here. Think it's about new applications having to re-define Flow
IDs again and again if they use Datagrams, which has a cost in terms of
document count) **Tommy**: Similar discussions about H3 Datagram what these
identifiers mean: flow id, application label on set of messages, ...? Puts a
bit of burden on app, but also a lot of freedom. Maybe even be that H3 won't
strictly use it as flow ID and go broader. This is one of the reasons not to
put it in here **Ekr**: Sure. Can point to H3 Datagram maybe. Say that if you
need something similar for something new, that you need to copy that document
and adopt it to new use case. If in the future we find the same pattern being
repeated, we can suggest that a new extension will be defined with a new frame
type that uses that pattern. **Tommy**: We can highlight that. Looks like H3
will use VLI for this, which is convenient. But up to new extensions to define
what that means. **David Schinazi**: Most use cases for Flow ID seem to be
multiplexing applications over QUIC. Intentionally ruled out of scope for QUIC
v1. Makes more sense to have it at application layer. Wrt people wanting to
re-use this: H3 Datagram doc has 1 section on the flow ID. The rest is about
how to integrate with H3 itself. IF another application wants to use this, we
don't need to clone and get a fully new document: just need to define what the
Flow ID means in their application. No value in centralizing this. Just having
each application saying "we also start with a flow id" is the right way to go.
**Tommy**: agree. And just spelling that out seems best. **Omer Shapira**: In
future, if there are more, we might want to provide best practices. But if for
now the approach is just 1 integer, then that's probably not needed.

#### [Issue 8](https://github.com/quicwg/datagram/issues/8)
**Martin Thomson**: Not sure why the Loss Recovery PTO is necessary in this
case. Is there a succint explanation you can provide? **Jana Iyengar**: PTO
isn't required: it's about what to do when PTO is triggered. Seen this problem
before, want to specify how to handle packets you typically don't retransmit.
If you want to invoke an ACK, you send a PING frame. **MT**: This is in
recovery, but what benefit does this provide. If you only ever send DGRAMS,
what possible value is there. Recovering bytes? **Jana**: It's mainly for
cleanup. Two positions: a) don't do anything if nothing to send, just take
conservative stance (e.g., cut back cwnd after some time) b) just send a ping,
evoke an ACK, and use that. In transport, we've chosen b) so you can do math
correctly. Unless we have a reason not to, let's keep b) here. **MT**: Makes
sense. Slide just looked like new behaviour. So some explanatory text there
would help. **Ian Swett**: If not already referenced, link back to recovery
document.

#### [Issue 3](https://github.com/quicwg/datagram/issues/3)
**ekr**: Why would you want to say "I only support DGRAMs of size 0"? Is there
another indicator you only support DGRAMS? **Tommy**: No, no separate one. So
this asks if we can switch to a boolean **ekr**: Saying that you can say you
don't support them, but not sending this TP at all. And you can set it to
something very large if you don't care. Don't know if there's a reason to say I
only support dgrams of size x. **Tommy**: Main question: does anyone actually
intend to use a limited dgram size? For H3 the use cases currently probably
don't require, but could be useful down the line maybe? **David**: To explain
reason why 0 means not allowed: to make implementations easier. All of the core
spec varint TPs have a default value. Make 0 default here makes that easier: if
not received, just set it to 0. Otherwise, you'd need another approach.
**ekr**: Seems that 0 and not present have different semantics? Because TP with
value 0 means I support it, but you can't send it, while omission would be "I
don't support it". If we change this to only payload, we would lose those
semantics, and we would have a new problem. Annoying to take into account other
side when you want to send, probably where the idea to change to boolean comes
from? Do we have other things that have forbidden minimum values? **David**:
yes. E.g., min payload size cannot be below 1200 bytes. **ekr**: right, so that
would also resolve this: say min value is 1, and default is 0? **David**: is
already deployed. If change this, have to switch TP value, but we have a nice
value now, so let's just keep as-is **Nick Banks**: I never saw good reason to
actually have the size limit at all. Would have pref to just have
enable/disable boolean TP

#### [Issue 15](https://github.com/quicwg/datagram/issues/15)
**David**: implementation experience. In WebTransport we use DGRAMS and QUIC
stack and JavaScript that consumes DGRAMs are not in the same process in
Chrome. So application and transport are running separately and no synchronous
interface between them. No option for QUIC to wait for async call to app before
ACKing the DGRAM (too complex). Proposed resolution of telling implementation:
with DGRAMs you don't want inifinite buffers. If app is busy and queue gets too
full, we don't want that to grow unboundedly, so you can get loss. But how
useful is it to let the app know? What would it do with that? **Tommy**: At
least a way to query "did you drop any packets?", would allow app to do app
level signalling (e.g., video streaming with missing frames) to e.g., request
retransmission. **Lucas**: We're at time. cutting queue. **Nick**: Already have
ACK mechanisms at transport. Sad to hear we couldn't leverage that and that
application has to build own acks on top of that. For us it was easy to support
this, but not for others.

## Open issues, updates to [version
negotiation](https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/).
[Slides](https://datatracker.ietf.org/meeting/110/materials/slides-110-quic-quic-version-negotiation-00)
- *David Schinazi*

#### [Issue 19](https://github.com/quicwg/version-negotiation/issues/19)
**MT**: I think we need a much simpler design. I realize this is the maximal
design. Lot of work to be done on getting transformation between 2 versions
working properly. What actually will happen in practice is that a V2 thing that
offers a V1 first flight, would have to apply V2 contraints in its V1 flight to
enable conversion; nothing in the draft about that **David**: Something
concretely in mind for simpler design? Are there features you could drop to
have a simpler design? **MT**: Version upgrade: typical principle is client
offers list, server chooses. For incompatible: you invert that: server offers
list, client chooses. That gets us 99% of the way. **Christopher Wood**: Wonder
how much this has been analyzed (i.e., downgrade attacks) **David**: Has been
zero analysis on this, apart from me looking at it, and I'm definitely not a
security expert. So yes, before shipping we would definitely want to have folks
look at this. reason for adding long header version in here comes from research
showing that might be unsafe. Still need to do formal analysis here. **ekr**: 3
issues. 1) do we actually need all the functionality? (compat and incompat). My
opinion is we don't need incompat. 2) is this the right interpretation of
compatible? transformable vs valid. In other protocols they are synonyms. e.g.,
in TLS 1.3 CHello is a valid 1.2 CHello. Is a simpler concept. 3) Given all
these functional constraints, is this the simplest design that provides the
intended security value? A little unclear if MT is just challenging point 3),
but I agree the design overall is too complex. **David**: Totally agree.
Encourage anyone who thinks this is too complicated to propose alternate
designs.

**Mike Bishop**: Comes down to what restrictions we intend to put on futue
versions of QUIC. If we intend to make it more strict, best hurry, because
invariants has already been sent to RFC editor. Problem: invariants say that
vneg (Robin: didn't quite follow this). Don't think we have the option to go
back on this now, so we can't really toss incompat vneg out anymore. This does
make it more complicated, but not sure we can simplify at this point. Path to
simplification is to retcon the invariants so implementations need to know
about all previous versions. **David**: Is indeed not always true. GQUIC uses
Google Crypto and so we do need incompat for that for example. One thing that
comes to mind is splitting into 2 drafts (separate for compat and incompat).
**Christian Huitema**: Strongly in favor of simplification. 1) this is a
security feature. There is no such thing as complicated security features 2) it
has to be simple. Client should say: I propose A and can also do B and C. If
it's more complicated than that, it shouldn't happen. If server wants to say "I
also support v42 even though you didn't mention that", that should be a
different mechanism. **Matt Joras**: Clear consensus that we need something
simpler. Please suggest concrete designs.

## Open issues, implementation experience, possible WGLC of
[QUIC-LB](https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers).
[Slides](https://datatracker.ietf.org/meeting/110/materials/slides-110-quic-quic-load-balancers-00)
- *Martin Duke*

**Benjamin Schwartz**: choose the safest option and get implementation
experience with that **Martin Duke**: we've reached limits of what we can do
without implementation (see first extra slide). LB community is not really
here, but server community is here. Could really use someone with a server that
supports mobility to test with this. Should surface the key use cases. Don't
know if we can make a lot more progress on this document without this. Stuck
untill we get more reviews and implementation experience. Don't want to go to
WGLC without that.

**Benjamin Schwartz**: Also some privacy concerns for some of the options. Some
break privacy guarantees that QUIC has previously made. Should be conscious
about making recommendations that violate security/privacy promises we made in
different documents. Especially because servers and LBs often closely
collaborate and generally don't require too much standards guidance. If people
want to do something unsafe, they can do so on their own. Mainly concerned
about plaintext CID, but also some concerns how it interacts with ECH. In
general, for an ECH QUIC implementation with split-mode architecture, it seems
like ECH processing needs to be coupled to QUIC-LB handling and seems like
relatiely easily to break guarantees of ECH with this. **Martin Duke**: Can't
comment out of hand, but definitely don't want to break ECH. Plaintext CID hsa
been in there since start and has lots of support from QUIC community, who are
privacy sensitive. Consider this more of a privacy continuum rather than
discrete private vs non-private.

## Adoption: [QUIC bit
greasing](https://datatracker.ietf.org/doc/draft-thomson-quic-bit-grease/)
[Slides](https://github.com/quicwg/wg-materials/blob/main/ietf108/quic-bit-grease.pdf)
*Martin Thomson*

No presentation after some discussion about waiting for recharter and asking
for adoption.

## Adoption: [Delayed
ACK](https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack) *Jana
Iyengar*

No presentation after some discussion about waiting for recharter and asking
for adoption.

## Planning & Wrap up
**Lars**: running out of time. Can't really do a call for adoption of QUIC bit
greasing or Delayed ACK at this time anyway, so won't waste time on that
(during recharter), but will do so in the future, so please read the drafts. If
people have major objections now, please let us know now though.

**Christian Huitema**: What about the timestamp draft? We already have two
implementations. Would like some additional visibility of that in the WG

**Lars**: Let put that on the agenda for an interim or 111 then.

**Lars**: Maybe we should do an interim discussion on vneg before 111, since it
seems likes it needs more work? (chat indicates interest). Will do Google poll
for a meeting slot then.

**Lucas**: There's also qlog that's up for adoption. Drafts are more or less
ready, just holding until after recharter.

**Lars**: Logging is indeed mentioned in the new charter as well. That's mainly
there because we intend to adopt (part of) qlog here.