https://notes.ietf.org/notes-ietf-interim-2024-quic-01-quic
", "time": "2024-06-03T14:01:33Z"}, {"author": "Martin Thomson", "text": "I might need to duck out after 90 minutes.
", "time": "2024-06-03T14:02:51Z"}, {"author": "Alessandro Ghedini", "text": "I can also help with scribing
", "time": "2024-06-03T14:04:52Z"}, {"author": "Sean Turner", "text": "I was going to say I thought I recognized that ceiling/wall combo ;)
", "time": "2024-06-03T14:17:30Z"}, {"author": "Christian Huitema", "text": "The parameter is really a \"max path ID\". Maybe we should call it that.
", "time": "2024-06-03T14:18:12Z"}, {"author": "Martin Thomson", "text": "That is what my PR does.
", "time": "2024-06-03T14:19:02Z"}, {"author": "Martin Thomson", "text": "If you have a shared limit, is that workable?
", "time": "2024-06-03T14:20:44Z"}, {"author": "Martin Thomson", "text": "What is the complexity cost of sharing the path IDs?
", "time": "2024-06-03T14:28:52Z"}, {"author": "Martin Thomson", "text": "Can one peer consume all the path IDs on useless paths?
", "time": "2024-06-03T14:29:13Z"}, {"author": "Martin Thomson", "text": "I would characterize this as \"we're going to give a single space a go\"
", "time": "2024-06-03T14:33:56Z"}, {"author": "Christian Huitema", "text": "The path creation has to be somehow cooperative. If te peers are fighting, they can certainly disagree all the way to the point that no path is created.
", "time": "2024-06-03T14:34:09Z"}, {"author": "Martin Thomson", "text": "I'm more concerned about glare cases that end up with poor outcomes
", "time": "2024-06-03T14:34:46Z"}, {"author": "Christian Huitema", "text": "Please define glare, I am not famiiar with use of that name in this context
", "time": "2024-06-03T14:35:12Z"}, {"author": "Christian Huitema", "text": "Are we supposed to see a shared screen?
", "time": "2024-06-03T14:36:05Z"}, {"author": "Antoine Fressancourt", "text": "I don't see it either
", "time": "2024-06-03T14:36:36Z"}, {"author": "Martin Thomson", "text": "Christian: glare is a telephony term that captures when both peers try to initiate a change at the same time
", "time": "2024-06-03T14:37:07Z"}, {"author": "Christian Huitema", "text": "Thanks
", "time": "2024-06-03T14:39:12Z"}, {"author": "Marten Seemann", "text": "Not having CIDs for a path sounds like a bug, not a feature.
", "time": "2024-06-03T14:39:19Z"}, {"author": "Michael Eriksson", "text": "Martin Thomson: I think the main complexity with server initiated paths is the \"race condition\" if both endpoints open the same path at the same time, either the same physical path or the path ID.
", "time": "2024-06-03T14:39:36Z"}, {"author": "Martin Thomson", "text": "That's what I was calling \"glare\"
", "time": "2024-06-03T14:39:54Z"}, {"author": "Christian Huitema", "text": "... but you only have connection IDs if the peer sends them, that's true in RFC9000 as well.
", "time": "2024-06-03T14:40:01Z"}, {"author": "Martin Thomson", "text": "This sounds like it could be a good idea.
", "time": "2024-06-03T14:41:14Z"}, {"author": "Christian Huitema", "text": "We have been looking at that since 2017-2018. The \"fix\" was to bundle a CID with the Path Challenge
", "time": "2024-06-03T14:42:51Z"}, {"author": "Christian Huitema", "text": "We have a knack for creating issues that take 6 months to resolve, don't we?
", "time": "2024-06-03T14:43:58Z"}, {"author": "Michael Eriksson", "text": "Martin Thomson: Issue #180 suggest a PATH_SETUP frame (including relevant parameters) with the possibility for the peer to refuse the new path. No signaling needed in advance.
", "time": "2024-06-03T14:47:42Z"}, {"author": "Martin Thomson", "text": "I just realized that this early binding of CIDs is a problem.
", "time": "2024-06-03T14:50:32Z"}, {"author": "Christian Huitema", "text": "It is a problem but it is also a solution. The problem is distinguishing between NAT traversal and CID rotation. If you see a packet with not-yet-used connection ID, and CIDs are not bound to path, then you have to use heuristics, or maybe trial decryption. That's not easy.
", "time": "2024-06-03T14:52:57Z"}, {"author": "Martin Thomson", "text": "My concern is that you might have a different routing configuration for each of your local addresses.
", "time": "2024-06-03T14:54:02Z"}, {"author": "Martin Thomson", "text": "I can see Mirja's point, but the idea that you can allocate a Path ID without having it bound to an address, or address tuple, is weird.
", "time": "2024-06-03T14:56:27Z"}, {"author": "Marten Seemann", "text": "The load balancer issues the CIDs, not the other way around.
", "time": "2024-06-03T14:59:22Z"}, {"author": "Mike Bishop", "text": "In RFC 9000, the client's random CIDs get it routed to a random backend, which is fine because it's a new connection.
", "time": "2024-06-03T15:02:07Z"}, {"author": "Martin Thomson", "text": "I'm not going to chase this one down now, but it seems like you need to solve this.
", "time": "2024-06-03T15:03:14Z"}, {"author": "Marten Seemann", "text": "I don't buy this argument \"it's fine because you always have a second path\". This doesn't work in the simplest case: a smartphone user walking away from the WiFi.
", "time": "2024-06-03T15:03:22Z"}, {"author": "Martin Thomson", "text": "Yeah, I don't care a whole lot, but binding CIDs to interfaces is what we need to do.
", "time": "2024-06-03T15:06:12Z"}, {"author": "Mike Bishop", "text": "I think the problem is that the CID is bound to a path ID, but the path ID isn't bound to a server endpoint. The draft currently leaves advertisement of endpoints to future work; I think connecting the path ID to that endpoint could also be left to that work.
", "time": "2024-06-03T15:07:07Z"}, {"author": "Quentin De Coninck", "text": "Let's keep CIDs per path limit.
", "time": "2024-06-03T15:07:58Z"}, {"author": "Martin Thomson", "text": "s/server endpoint/endpoint address :)
", "time": "2024-06-03T15:08:04Z"}, {"author": "Christian Huitema", "text": "The binding to interface is a different issue. It would require binding the CID to an address, but we have shied away from handling addresses for a long time, because of NATs.
", "time": "2024-06-03T15:08:54Z"}, {"author": "Martin Thomson", "text": "Christian: At some point you need to put an address in the IP/UDP header...
", "time": "2024-06-03T15:09:33Z"}, {"author": "Christian Huitema", "text": "Yes you do. But the client can do RFC9000 without ever knowing the value of its \"outside of NAT\" address.
", "time": "2024-06-03T15:10:17Z"}, {"author": "Christian Huitema", "text": "In fact, it is not clear that a server behing an LB knows its own IP address.
", "time": "2024-06-03T15:10:41Z"}, {"author": "Michael Eriksson", "text": "FWIW, I've succesfully run QUIC directly on the MAC layer (Ethernet), worked perfectly well :-).
", "time": "2024-06-03T15:12:02Z"}, {"author": "Mike Bishop", "text": "It's modeled after connection close, but as a component of the connection, isn't it actually close to stream close?
", "time": "2024-06-03T15:13:53Z"}, {"author": "Martin Thomson", "text": "Mike: stateless reset kills the connection
", "time": "2024-06-03T15:18:37Z"}, {"author": "Christian Huitema", "text": "Stateless reset is a red herring. If you retire a CID, you retire the stateless reset signature, so the stateless reset will be ignred.
", "time": "2024-06-03T15:19:21Z"}, {"author": "Marten Seemann", "text": "We need to make sure that even a severly (> 3 PTO) reordered packet doesn't kill the connection via a stateless reset. Otherwise this is an attack vector.
", "time": "2024-06-03T15:19:22Z"}, {"author": "Martin Thomson", "text": "Mike : you don't retire until you RECEIVE an abandonment.
", "time": "2024-06-03T15:21:23Z"}, {"author": "Martin Thomson", "text": "Why do you set a timer on send?
", "time": "2024-06-03T15:22:48Z"}, {"author": "Martin Thomson", "text": "I'm still confused.
", "time": "2024-06-03T15:22:52Z"}, {"author": "Martin Thomson", "text": "I would set a timer on receipt of an abandon.
", "time": "2024-06-03T15:23:28Z"}, {"author": "Christian Huitema", "text": "It really is a timer on receive, much like draining.
", "time": "2024-06-03T15:23:35Z"}, {"author": "Martin Thomson", "text": "Yeah, that's what I would have thought.
", "time": "2024-06-03T15:24:01Z"}, {"author": "Martin Thomson", "text": "You just want to ensure that you hang around a little bit to handle reordered packets. This is, of course, an optimization.
", "time": "2024-06-03T15:24:23Z"}, {"author": "Michael Eriksson", "text": "FWIW, the Rask implementation keeps retired CIDs around \"for a while\" to avoid superfluous Stateless Resets. It also ensure that you don't reuse the CID too early.
", "time": "2024-06-03T15:24:48Z"}, {"author": "Christian Huitema", "text": "Wouldn't things be simpler without the two generals?
", "time": "2024-06-03T15:26:13Z"}, {"author": "Martin Thomson", "text": "I'm going to have to drop on the notes.
", "time": "2024-06-03T15:27:15Z"}, {"author": "Martin Thomson", "text": "Magnus are you OK for that?
", "time": "2024-06-03T15:27:21Z"}, {"author": "Magnus Westerlund", "text": "Martin: Yes
", "time": "2024-06-03T15:27:43Z"}, {"author": "Martin Thomson", "text": "Thanks.
", "time": "2024-06-03T15:27:47Z"}, {"author": "Christian Huitema", "text": "Mirja does not like beeing in the rough...
", "time": "2024-06-03T15:41:52Z"}, {"author": "Christian Huitema", "text": "I would like to have breakfast finally!
", "time": "2024-06-03T15:45:10Z"}, {"author": "Zaheduzzaman Sarker", "text": "I would even appreciate :-).
", "time": "2024-06-03T15:45:25Z"}, {"author": "Quentin De Coninck", "text": "Let's wrap up if we are done :-)
", "time": "2024-06-03T15:45:36Z"}]