[{"author": "Robin Marx", "text": "

Link to the notes: https://notes.ietf.org/notes-ietf-118-quic

", "time": "2023-11-08T13:30:46Z"}, {"author": "Robin Marx", "text": "

I can help out with the notes today, but can't guarantee I can be on point the whole time, so ideally someone else would be the \"main note taker\" today

", "time": "2023-11-08T13:31:42Z"}, {"author": "Jonathan Morton", "text": "

I can relay stuff from chat if needed; prefix with \"mic\" or similar if you want me to.

", "time": "2023-11-08T13:34:35Z"}, {"author": "Christian Huitema", "text": "

There is yet another option -- don't version negotiation. Because it is a clear text packet that can be spoofed, and thus an attack vector.

", "time": "2023-11-08T13:38:40Z"}, {"author": "Martin Duke", "text": "

I think @Christian Huitema just volunteered for RFC9000bis

", "time": "2023-11-08T13:42:48Z"}, {"author": "Ted Hardie", "text": "

I don't think there is any difference between 3 and 4 because the escape clause is the same. MUST unless is really SHOULD unless you have OOB knowledge.

", "time": "2023-11-08T13:42:54Z"}, {"author": "Ted Hardie", "text": "

(And I am fine with 4)

", "time": "2023-11-08T13:43:17Z"}, {"author": "Jonathan Morton", "text": "

or maybe \"MUST unless\" is equivalent to just \"SHOULD\"

", "time": "2023-11-08T13:43:28Z"}, {"author": "Lucas Pardue", "text": "

thanks jonathan morton for volunteering to jabber scribe

", "time": "2023-11-08T13:46:54Z"}, {"author": "Jonathan Morton", "text": "

:ok:

", "time": "2023-11-08T13:47:44Z"}, {"author": "Antoine Fressancourt", "text": "

Do you have a link to Rask that is mentionned among QUICclients / servers in interop tests ?

", "time": "2023-11-08T13:52:46Z"}, {"author": "Jonathan Hoyland", "text": "

So dumb question for the notes. Isn't #273 already closed? https://github.com/quicwg/multipath/issues/273

", "time": "2023-11-08T13:58:54Z"}, {"author": "Jonathan Morton", "text": "

the slide says that #273 is already closed\u2026

", "time": "2023-11-08T13:59:35Z"}, {"author": "Abdussalam Baryun", "text": "

yes we need sense

", "time": "2023-11-08T14:05:04Z"}, {"author": "Abdussalam Baryun", "text": "

of meeting

", "time": "2023-11-08T14:05:13Z"}, {"author": "Abdussalam Baryun", "text": "

yes that is important point

", "time": "2023-11-08T14:06:31Z"}, {"author": "Jonathan Morton", "text": "

interested in exploring path IDs: 20 yes, 11 no

", "time": "2023-11-08T14:09:04Z"}, {"author": "Jonathan Morton", "text": "

interested in interim/interop on path IDs: 9 yes, 19 no

", "time": "2023-11-08T14:10:12Z"}, {"author": "Robin Marx", "text": "

From a qlog perspective, an explicit Path ID would also be nice :P

", "time": "2023-11-08T14:12:43Z"}, {"author": "Marten Seemann", "text": "

I'd be happy to work on a PR

", "time": "2023-11-08T14:15:48Z"}, {"author": "Christian Huitema", "text": "

The \"retire cid\" mechanism very much assume that there is a 1-1 relation between CID and sequence number.

", "time": "2023-11-08T14:16:31Z"}, {"author": "Nick Banks", "text": "

Christian, for your comments about offloading complexity, are you saying that it would require essentially pushing down both a CID table and a path ID table, and express the mappings between them?

", "time": "2023-11-08T14:18:16Z"}, {"author": "Jonathan Hoyland", "text": "

Was that StableDiffusion?

", "time": "2023-11-08T14:19:22Z"}, {"author": "Christian Huitema", "text": "

kinda. The problem is that you know the relation between CID and sequence number when CID is created, but the relation to a path ID will be ngotiated later. SO you need to complete the negotiation before you use the CID.

", "time": "2023-11-08T14:19:36Z"}, {"author": "Nick Banks", "text": "

So you can't offload encryption for a CID until after this negotiation?

", "time": "2023-11-08T14:20:12Z"}, {"author": "Christian Huitema", "text": "

Yes

", "time": "2023-11-08T14:20:19Z"}, {"author": "Nick Banks", "text": "

Is that something the peer could attack?

", "time": "2023-11-08T14:20:37Z"}, {"author": "Christian Huitema", "text": "

In fact, you cannot decryp the packet before that

", "time": "2023-11-08T14:20:45Z"}, {"author": "Christian Huitema", "text": "

It is additional complexity, so yes it can probably be attacked. And it can certainly cause bugs.

", "time": "2023-11-08T14:21:23Z"}, {"author": "Mike Bishop", "text": "

Christian Huitema said:

\n
\n

The \"retire cid\" mechanism very much assume that there is a 1-1 relation between CID and sequence number.

\n
\n

@Ted Hardie can clarify, but I think the suggestion is a 5-tuple of (CID sequence, ...UDP 4-tuple), where changing any of those represents a different path. I suspect that the rules in RFC 9000 amount to CID sequence being equally unique modulo the round-trip it takes to realize it happened, but I'd need to work through it to be sure.

", "time": "2023-11-08T14:22:30Z"}, {"author": "Christian Huitema", "text": "

You don't need a path-id so much as a number-space ID...

", "time": "2023-11-08T14:24:57Z"}, {"author": "Luke Curley", "text": "

+1 Victor

", "time": "2023-11-08T14:26:00Z"}, {"author": "Mike Bishop", "text": "

Agree with Victor -- I definitely would support text that says STOP_SENDING can elicit either a RESET_STREAM or a RESET_STREAM_AT.

", "time": "2023-11-08T14:27:02Z"}, {"author": "Nick Banks", "text": "

+1 David

", "time": "2023-11-08T14:27:41Z"}, {"author": "Christian Huitema", "text": "

+1 David

", "time": "2023-11-08T14:28:02Z"}, {"author": "Jonathan Lennox", "text": "

+1 Mirja, nothing stops us from doing this in the future

", "time": "2023-11-08T14:28:19Z"}, {"author": "Alan Frindell", "text": "

+1 kazuho, I think you can get what you want just by waiting for byte N, then send a regular STOP_SENDING

", "time": "2023-11-08T14:29:10Z"}, {"author": "Ted Hardie", "text": "

So why not wait and send STOP_SENDING after you get those bytes?

", "time": "2023-11-08T14:29:43Z"}, {"author": "David Schinazi", "text": "

Or have the application layer protocol such that receipt of STOP_SENDING leads to RESET_STREAM_AT(n) where n is after metadata

", "time": "2023-11-08T14:30:28Z"}, {"author": "Jonathan Lennox", "text": "

My counter-argument would be that if you lost the packet that contained the bytes you need, you might end up wasting bandwidth on the packets from the rest of the stream if you had to wait for the STOP_SENDING. But I don't think the use case is good enough for it.

", "time": "2023-11-08T14:31:01Z"}, {"author": "Jonathan Hoyland", "text": "

Sounds like a https://xkcd.com/937/ question.

", "time": "2023-11-08T14:31:40Z"}, {"author": "Jonathan Morton", "text": "

STOP_SENDING_AT: 2 yes, 30 no

", "time": "2023-11-08T14:32:46Z"}, {"author": "Brian Trammell", "text": "

@David Schinazi just because we shouldn't make things to be pretty, we shouldn't necessarily make them gratuitously ugly :D

", "time": "2023-11-08T14:32:55Z"}, {"author": "Jonathan Lennox", "text": "

Are these two RESET_STREAM_AT messages reliably ordered with each other?

", "time": "2023-11-08T14:33:31Z"}, {"author": "Jonathan Lennox", "text": "

N/M

", "time": "2023-11-08T14:33:54Z"}, {"author": "Robin Marx", "text": "

@meetecho: feedback: this new interface is really MUCH better for notetakers than the previous ones, well done :)

", "time": "2023-11-08T14:35:07Z"}, {"author": "Lorenzo Miniero", "text": "

Thanks for the kind words Robin, we're glad you like it!

", "time": "2023-11-08T14:35:37Z"}, {"author": "Jonathan Morton", "text": "

@meetecho: as a counterpoint, the emoticon input and output in the chat don't seem to correspond

", "time": "2023-11-08T14:36:04Z"}, {"author": "Lorenzo Miniero", "text": "

Jonathan: that's indeed a known issue, it's on the todo list! Sorry about that...

", "time": "2023-11-08T14:37:08Z"}, {"author": "Christian Huitema", "text": "

Really? I thought it was the parasol mushroom update...

", "time": "2023-11-08T14:37:18Z"}, {"author": "Mike Bishop", "text": "

Aren't you required to have an IANA section that says there are no actions?

", "time": "2023-11-08T14:37:34Z"}, {"author": "Mike Bishop", "text": "

Yes, in fact:

\n
\n

The RFC Editor will remove an IANA Considerations section that says
\n there are no IANA considerations (although such a section is required
\n in the Internet-Draft preceding the RFC).

\n
", "time": "2023-11-08T14:38:33Z"}, {"author": "Lucas Pardue", "text": "

this section intentionally left blank

", "time": "2023-11-08T14:38:48Z"}, {"author": "Lucas Pardue", "text": "

nobody fantasises about QPACK, except maybe Alan

", "time": "2023-11-08T14:39:20Z"}, {"author": "Robin Marx", "text": "

Fair point Mike.

", "time": "2023-11-08T14:41:04Z"}, {"author": "Martin Duke", "text": "

I am pleased Robin did not do the \"Oppenheimer update\" in Japan

", "time": "2023-11-08T14:52:24Z"}, {"author": "Robin Marx", "text": "

TBH I was a bit on the fence doing it at all...

", "time": "2023-11-08T14:53:02Z"}, {"author": "Jonathan Hoyland", "text": "

I like the idea of a meetecho feature where people with multiple roles can join the queue with different (or no) \"hats\".

", "time": "2023-11-08T14:53:44Z"}, {"author": "Lucas Pardue", "text": "

I want one of these https://www.kaufland.cz/product/448981406/?kwd&source=pla&sid=31333993&gad_source=1&gclid=Cj0KCQiAgK2qBhCHARIsAGACuzmWuqRrgmqzxe9QJeX-argpYQxOmLkDAjvt5hKsbIc96_KF9O_tSa4aAq4YEALw_wcB

", "time": "2023-11-08T14:54:51Z"}, {"author": "Mike Bishop", "text": "

Note that this is also resilient to NATs which don't have consistent port mapping to different destinations. (Albeit the information you get back may be less useful in that case.)

", "time": "2023-11-08T14:55:32Z"}, {"author": "Ted Hardie", "text": "

I was wondering how the client would know if the nat had rebound it because of nat state change (reboot or similar). The Observed_Address approach would make that easy.

", "time": "2023-11-08T14:57:19Z"}, {"author": "Ted Hardie", "text": "

I will note that it sounds to me like Kazuho's use of sequence number there is very much a pathid use case.

", "time": "2023-11-08T14:58:31Z"}, {"author": "Christian Huitema", "text": "

No problem, just port the other applications to use QUIC...

", "time": "2023-11-08T14:59:09Z"}, {"author": "Ted Hardie", "text": "

I disagree with Colin.

", "time": "2023-11-08T14:59:09Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Robin I don\u2019t want to make you life harder. your design actually works (for the current draft) if you always only have one cid per path but in that case you can just have an cid field instead of an path id field. Or if you want to have a path id as defined right now you also need a cid field in all event that have a packet number.

", "time": "2023-11-08T14:59:35Z"}, {"author": "Antoine Fressancourt", "text": "

I agree with Colin here. Unless something is really disrupting from STUN / TURN / ICE, I think it will cause harm

", "time": "2023-11-08T14:59:42Z"}, {"author": "Ted Hardie", "text": "

Well, I don't disagree that we should think about it, but I don't think using this will cause people to drop support for STUN, since this would not change the flow of packets to stun servers until those use cases moved to QUIC.

", "time": "2023-11-08T14:59:57Z"}, {"author": "Mike Bishop", "text": "

IIRC, in RFC9000, the server is supposed to change CIDs if it sees a port change by the client, which hints to the client that it should (have already) change CID to reflect the new port.

", "time": "2023-11-08T15:00:28Z"}, {"author": "Martin Duke", "text": "

@Mike Bishop I don't think so? It wouldn't provide any unlinkability advantage

", "time": "2023-11-08T15:01:04Z"}, {"author": "Kazuho Oku", "text": "

This can be sent in 0.5 RTT data, right?

", "time": "2023-11-08T15:01:53Z"}, {"author": "Kazuho Oku", "text": "

Esp. if we move to SETTINGS

", "time": "2023-11-08T15:02:07Z"}, {"author": "Jonathan Lennox", "text": "

I think if you're using MASQUE instead of TURN you'd want to use this instead of STUN?

", "time": "2023-11-08T15:02:20Z"}, {"author": "Martin Duke", "text": "

you still need a frame for path probes

", "time": "2023-11-08T15:02:30Z"}, {"author": "Christian Huitema", "text": "

Regarding the path ID discussion, what we really need is not just a path ID but rather a sequence number space ID. That sequence number space has to be identified before decrypting the packet -- the decryption module need to know the number space ID to mix in the nonce, and it also need the state of the number space to convert from short PN to 64 bit PN. ACK MP also needs the seuqnece number space ID. Making that the CID is a significant simplification.

", "time": "2023-11-08T15:02:34Z"}, {"author": "Mike Bishop", "text": "

The server can send 1-RTT in its first return flight, so the client can see this after a single RTT if the server sends it immediately.

", "time": "2023-11-08T15:02:59Z"}, {"author": "Jonathan Lennox", "text": "

There's nothing that stops the signaling server from being QUIC, it just needs to be in a datacenter or something.

", "time": "2023-11-08T15:06:08Z"}, {"author": "Mike Bishop", "text": "

@Martin Duke, we went through a lot of iteration on that part, so I was a little rusty what was final. Just double-checked -- for that case, the server MAY continue using the same CID if the client has already accidentally linked the paths.

", "time": "2023-11-08T15:07:27Z"}, {"author": "altanai", "text": "

How would an application over such a QUIC session ( pre binded with STUN ) know that it doesn't need to do any further ICE negotiation, for example : consider WebRTC in QUIC. Since WebRTC control plane also has candidates gathering , it will try to do extra validation of STUN which was pre discovered in QUIC. This can be avoided right ?

", "time": "2023-11-08T15:10:46Z"}, {"author": "Antoine Fressancourt", "text": "

Do you test the behavior of the NAT in case of IP migration (as in ICE) ? Because you may need to keep the CONNECT-UDP proxy in the path if the binding is IP-dependent

", "time": "2023-11-08T15:11:03Z"}, {"author": "Jonathan Morton", "text": "

@altanai: I get the sense that that's something that would be considered specifically for WebRTC-over-QUIC; this is just foundational.

", "time": "2023-11-08T15:13:57Z"}, {"author": "Christian Huitema", "text": "

That's why I like using multipath in that scenario, it allows you to maintain the proxy path, maybe as standby. But Marten is right, it is not strictly needed.

", "time": "2023-11-08T15:14:07Z"}, {"author": "Kazuho Oku", "text": "

Is use of encrypted traffic a benefit?

", "time": "2023-11-08T15:15:13Z"}, {"author": "Christian Huitema", "text": "

Yes, it may be a lot of work, but if people (including me) are willing to do it, why stop them?

", "time": "2023-11-08T15:15:36Z"}, {"author": "Christian Huitema", "text": "

Encrypting ICE/STUN does reduce the attack surface quite a bit, so that's a clear benefit.

", "time": "2023-11-08T15:16:25Z"}, {"author": "altanai", "text": "

@Jonathan_morton Ok, that makes sense. Also WebRTC usecase was just discussed by @jonathan_lennox

", "time": "2023-11-08T15:16:31Z"}, {"author": "Jonathan Morton", "text": "

I think that if WebRTC knows that it's running over QUIC, it can assume that QUIC has done what'ever's necessary for NAT traversal

", "time": "2023-11-08T15:17:31Z"}, {"author": "Luke Curley", "text": "

but +1 to Johnathan, you still need a signaling server to exchange certs, candidates, auth, and possibly media info

", "time": "2023-11-08T15:19:37Z"}, {"author": "Peter Thatcher", "text": "

ICE is a combination of techniques and packet format. You can't avoid using the same techniques as ICE to get the same results. You can change the packet format. But doing the same techniques withing QUIC is not going to be easy, especially when considering web endpoints.

", "time": "2023-11-08T15:19:53Z"}, {"author": "Lars Eggert", "text": "

There should be distinct benefits in doing \u201cNAT-related things\u201d in QUIC compared to just applying existing techniques for QUIC.

", "time": "2023-11-08T15:21:20Z"}, {"author": "Lars Eggert", "text": "

Otherwise meh

", "time": "2023-11-08T15:21:44Z"}, {"author": "Peter Thatcher", "text": "

There was an entire WG for ICE. This could possibly be enough work to be its own WG. If the it's done in the QUIC WG, it could easily end up consuming a lot of time, similar to how ICEbis did in MMUSIC prior to the ICE WG breaking out into its own WG.

", "time": "2023-11-08T15:21:49Z"}, {"author": "Luke Curley", "text": "

20 yes and 17 no; I think Lucas read out the results of a previous poll

", "time": "2023-11-08T15:22:08Z"}, {"author": "Jonathan Morton", "text": "

+1 Lars - this could turn out to be a layering violation or \"NIH syndrome\"

", "time": "2023-11-08T15:23:16Z"}, {"author": "Jonathan Morton", "text": "

part of the quoted justification is that ICE takes a lot of round-trips - is that inherent to the technique?

", "time": "2023-11-08T15:24:05Z"}, {"author": "Jonathan Morton", "text": "

(not familiar with ICE myself)

", "time": "2023-11-08T15:24:18Z"}, {"author": "Lucas Pardue", "text": "

sorry yes I read out the wrong numbers. Luke stated the correct ones

", "time": "2023-11-08T15:25:10Z"}, {"author": "Luke Curley", "text": "

ICE itself is 1-2 RTTs

", "time": "2023-11-08T15:25:21Z"}, {"author": "Antoine Fressancourt", "text": "

@Jonathan I am also curious how the number of round trips could be reduced (especially since multipath is not considered)

", "time": "2023-11-08T15:25:22Z"}, {"author": "Jonathan Morton", "text": "

1-2 RTTs seems reasonable for a \"complex\" connection setup

", "time": "2023-11-08T15:26:00Z"}, {"author": "Luke Curley", "text": "

From memory, for WebRTC you need 2-3 RTTs for the signal server, 1-2 RTTs for ICE, 2 RTTs for DTLs, 2 RTTs for SCTP, and 0/1 RTTs for data channels

", "time": "2023-11-08T15:26:32Z"}, {"author": "Luke Curley", "text": "

ICE is fine, it's the rest of WebRTC that needs to be optimized, because there's too many layers that are unaware of each other

", "time": "2023-11-08T15:27:39Z"}, {"author": "Jonathan Morton", "text": "

yeah, that's important context for the debate

", "time": "2023-11-08T15:27:39Z"}, {"author": "Luke Curley", "text": "

ex. DTLS, SCTP, and ICE all have IP spoofing mitigation, because they're all designed to run on top of UDP not each other

", "time": "2023-11-08T15:28:08Z"}, {"author": "Jonathan Morton", "text": "

and that feeds back to what I suggested previously about WebRTC-over-QUIC

", "time": "2023-11-08T15:28:51Z"}, {"author": "Luke Curley", "text": "

speaking of WebRTC-over-QUIC, we absolutely need this extension to reach parity with WebRTC (to implement GCC)

", "time": "2023-11-08T15:29:50Z"}, {"author": "Luke Curley", "text": "

pls revive

", "time": "2023-11-08T15:30:10Z"}, {"author": "Peter Thatcher", "text": "

I'm very interested in this extension

", "time": "2023-11-08T15:31:32Z"}, {"author": "Peter Thatcher", "text": "

I agree with Luke that it's needed to implement googcc (AKA GCC), which would be very good for realtime use over QUIC (like MoQ and RoQ and WebTransport).

", "time": "2023-11-08T15:32:05Z"}, {"author": "Mike English", "text": "

++

", "time": "2023-11-08T15:32:27Z"}]