Matt - you're too CLOSE to the mic - it's distorting
", "time": "2023-07-25T16:34:03Z"}, {"author": "Martin Thomson", "text": "Yet another RFC
", "time": "2023-07-25T16:34:25Z"}, {"author": "Robin Marx", "text": "is the video feed on the online client supposed to switch to the speaker instead of the room/mic automatically?
", "time": "2023-07-25T16:36:05Z"}, {"author": "Lorenzo Miniero", "text": "Robin: no it's manual, fixed
", "time": "2023-07-25T16:36:24Z"}, {"author": "Robin Marx", "text": "thanks :)
", "time": "2023-07-25T16:36:27Z"}, {"author": "Matt Joras", "text": "Robin doesn't like looking at us
", "time": "2023-07-25T16:36:36Z"}, {"author": "Robin Marx", "text": "Lucas makes me nervous
", "time": "2023-07-25T16:36:55Z"}, {"author": "Matt Joras", "text": "try sitting next to him
", "time": "2023-07-25T16:37:05Z"}, {"author": "Lucas Pardue", "text": "0.0
", "time": "2023-07-25T16:37:23Z"}, {"author": "Robin Marx", "text": "Why do you think I stayed in Belgium...
", "time": "2023-07-25T16:37:25Z"}, {"author": "James Gruessing", "text": "@Robin and you get to miss out on the diverse and exotic beers they have!
", "time": "2023-07-25T16:39:29Z"}, {"author": "Mike Bishop", "text": "Something something smurfs chocolate?
", "time": "2023-07-25T16:39:37Z"}, {"author": "Robin Marx", "text": "Don't forget the fries and waffles though!
", "time": "2023-07-25T16:40:25Z"}, {"author": "Mike Bishop", "text": "Haven't had a mitraillette in about two decades, for better or worse.
", "time": "2023-07-25T16:42:09Z"}, {"author": "Antoine Fressancourt", "text": "One side question, apart from reading RFC 9000, do you have a paper / article / survey / introduction to advise for someone willing to dig into QUIC ?
", "time": "2023-07-25T16:42:46Z"}, {"author": "Daniel Gillmor", "text": "chairs, can you encourage quentin to stand on the pink X ?
", "time": "2023-07-25T16:43:00Z"}, {"author": "Robin Marx", "text": "@Antoine: at the risk of touting my own horn: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
", "time": "2023-07-25T16:43:19Z"}, {"author": "Lucas Pardue", "text": "thanks for the reminder Daniel
", "time": "2023-07-25T16:43:33Z"}, {"author": "Martin Thomson", "text": "Stand in the PINK BOX!
", "time": "2023-07-25T16:43:42Z"}, {"author": "Antoine Fressancourt", "text": "@Robin Thanks (from a Belgian neighbour from Lille)
", "time": "2023-07-25T16:44:59Z"}, {"author": "Martin Thomson", "text": "can you skip sequence numbers?
", "time": "2023-07-25T16:45:45Z"}, {"author": "Mike Bishop", "text": "Don't need to skip sequence numbers if the frame is reliably delivered. Can't have unknown frame types, so you should be able to parse every item in the sequence.
", "time": "2023-07-25T16:46:50Z"}, {"author": "Kazuho Oku", "text": "There's always reorder so I think we need sequence numbers?
", "time": "2023-07-25T16:47:13Z"}, {"author": "Martin Thomson", "text": "@Mike Bishop I'm not concerned about whether there is a need (there is no point in skipping), only what logic is applied.
", "time": "2023-07-25T16:47:32Z"}, {"author": "Martin Thomson", "text": "Presumably, we're OK with just if last_status.seq < new_status.seq { do something }
", "time": "2023-07-25T16:48:14Z"}, {"author": "Kazuho Oku", "text": "^^ this is what is specified in the doc I think, and that we are not changing that regardless of how we send the state
", "time": "2023-07-25T16:48:45Z"}, {"author": "Martin Thomson", "text": "Yes, please rename this error code.
", "time": "2023-07-25T16:48:53Z"}, {"author": "Martin Thomson", "text": "The conclusion I reached from the discussion over the weekend was that error codes can be sent without \"negotiation\" (that is, you can send a new error code without necessarily receiving an indication from the peer that the error code will be understood).
", "time": "2023-07-25T16:51:51Z"}, {"author": "Christian Huitema", "text": "Makes sense. Just call it protocol violation, and document the frame type that caused it.
", "time": "2023-07-25T16:54:03Z"}, {"author": "Ted Hardie", "text": "Can you send the ACK_MP across more than one connection? So on the validated and unvalidated path?
", "time": "2023-07-25T16:54:17Z"}, {"author": "Lucas Pardue", "text": "Mathis Engelbert has a similar matter of error code consideration with the RTP over QUIC draft. That application mapping wants to fail when QUIC transport parameter is not present when it was expected (such as via out of band agreement)
", "time": "2023-07-25T16:54:27Z"}, {"author": "Kazuho Oku", "text": "@Ted Hardie Yes we can, however for the sake of having good RTT estimate we recommend ACKs to be sent conistently on one path
", "time": "2023-07-25T16:56:11Z"}, {"author": "Ted Hardie", "text": "The use case I'm thinking of is when someone is using multipath because of path instability on the validated path; isn't it possible that waiting for the validated path ACK_MP will delay the validation?
", "time": "2023-07-25T16:56:25Z"}, {"author": "Martin Thomson", "text": "I missed the conclusion on that one
", "time": "2023-07-25T16:56:58Z"}, {"author": "Ted Hardie", "text": "@Kazuho That's why you would do it across both--you still get consistency.
", "time": "2023-07-25T16:56:59Z"}, {"author": "Christian Huitema", "text": "Eric, you are confusing validation and continuity check. In 9000, these are separate concepts
", "time": "2023-07-25T16:57:18Z"}, {"author": "Antoine Fressancourt", "text": "@Ted I have been working on such a use case with MP-TCP, and sending keepalives on a stable yet expensive path was very handy
", "time": "2023-07-25T16:57:38Z"}, {"author": "Christian Huitema", "text": "If we have status frames, we should use them, not rely on other packet types and guesswork
", "time": "2023-07-25T16:58:16Z"}, {"author": "Kazuho Oku", "text": "ACK_MP is not used for validating paths. Path validation is exchange of PATH_CHALLENGE and PATH_RESPONSE. ACK_MP is a bi-product that carries RTT estimate.
", "time": "2023-07-25T16:58:35Z"}, {"author": "Ted Hardie", "text": "@Kazuho; thanks for the correction.
", "time": "2023-07-25T16:59:31Z"}, {"author": "Mirja K\u00fchlewind", "text": "We only use the mp error for the case where there is no cid in the handshake packet. Was the proposal to rename that?
", "time": "2023-07-25T17:02:34Z"}, {"author": "Martin Thomson", "text": "I'm not sure that I agree with @Marten Seemann about not needing a new CC for the address tuple that is created by migration
", "time": "2023-07-25T17:04:03Z"}, {"author": "Martin Thomson", "text": "Presumably, this approach would allow a client to migrate to a completely different address tuple, without signaling the path
", "time": "2023-07-25T17:05:10Z"}, {"author": "Magnus Westerlund", "text": "Martin Thomson said:
\n\n\nI'm not sure that I agree with Marten Seemann about not needing a new CC for the address tuple that is created by migration
\n
So RFC 9000 makes the distinction for re-use as long as the IP address hasn't changed, only ports. As that is a sign of NAT rebinding.
", "time": "2023-07-25T17:05:18Z"}, {"author": "Martin Thomson", "text": "@Magnus Westerlund exactly my point. It is only under certain _assumptions_ that retaining the congestion controller state is permitted.
", "time": "2023-07-25T17:06:01Z"}, {"author": "Martin Thomson", "text": "A client can move to a completely different path (see preferred address) where you might ideally want to reset state.
", "time": "2023-07-25T17:06:24Z"}, {"author": "Marten Seemann", "text": "You also need to reset the congestion controller if the NAT rebinding switches you to a completely different path.
", "time": "2023-07-25T17:07:14Z"}, {"author": "Marten Seemann", "text": "@Christian Huitema The key-per-path proposal is orthogonal to path IDs.
", "time": "2023-07-25T17:07:39Z"}, {"author": "Kazuho Oku", "text": "Right, from the viewpoint of loss recovery and CC, each \"sub connection\" as identified by \"path ID\" behaves exactly like each QUIC v1 connection.
", "time": "2023-07-25T17:07:46Z"}, {"author": "Kazuho Oku", "text": "(as well as their own connection IDs)
", "time": "2023-07-25T17:08:10Z"}, {"author": "Matt Joras", "text": "meetecho: can you change the slides again for reliable resets?
", "time": "2023-07-25T17:13:32Z"}, {"author": "Christian Huitema", "text": "Is the silence intentional, or is my connection gone?
", "time": "2023-07-25T17:14:26Z"}, {"author": "Jonathan Hoyland", "text": "And they didn't even pause his timer. Harsh
", "time": "2023-07-25T17:14:31Z"}, {"author": "Robin Marx", "text": "Time to crack some jokes, Marten
", "time": "2023-07-25T17:14:57Z"}, {"author": "Christian Huitema", "text": "What if the reliable reset happens during a windows OS update?
", "time": "2023-07-25T17:15:28Z"}, {"author": "Magnus Westerlund", "text": "Marten Seemann said:
\n\n\nYou also need to reset the congestion controller if the NAT rebinding switches you to a completely different path.
\n
I am uncertain what you refer to here Martin. Yes, a NAT rebinding can result in a path change due to ECMP routing, but it is likely not something the peer can reliably discern. A NAT-rebinding would only result in a change of the source port as seen from the perspective of the peer to the one being NATed. Thus, one can't determine if this is a path change due to further routing in the network, or if it has made no different to the actual path other then how the NAT binding looks.
", "time": "2023-07-25T17:15:34Z"}, {"author": "Alejandro Sede\u00f1o", "text": "Has this presentation been reliably reset?
", "time": "2023-07-25T17:16:27Z"}, {"author": "Christian Huitema", "text": "If you have a hard path-ID, then the client can send data on a new 4-tuple while keeping the hard path ID constant. If the server then keeps the congestion state, that's a bug.
", "time": "2023-07-25T17:17:28Z"}, {"author": "Mike Bishop", "text": "I agree, this should have an error code. If we want to omit it, make the other type have an implicit NO_ERROR.
", "time": "2023-07-25T17:20:53Z"}, {"author": "David Schinazi", "text": "+1 to what MT is saying (about the 1 byte, not the shed)
", "time": "2023-07-25T17:22:46Z"}, {"author": "Matt Joras", "text": "QUIC doesn't specify a NO_ERROR existing...
", "time": "2023-07-25T17:22:49Z"}, {"author": "David Schinazi", "text": "@Matt this is application error code, we have H3_NO_ERROR
", "time": "2023-07-25T17:23:36Z"}, {"author": "Christian Huitema", "text": "We may think of frames per connection, per stream or per packet. Per packet definitely qualifies for 1 byte. Per stream, maybe. Per connection, probably not.
", "time": "2023-07-25T17:23:59Z"}, {"author": "Mike Bishop", "text": "https://www.rfc-editor.org/rfc/rfc9000.html#section-22.5 says 0x00 is NO_ERROR.
", "time": "2023-07-25T17:24:34Z"}, {"author": "Matt Joras", "text": "Right, but that is an application thing. This new semantic introduces an inconsistency to stream termination in that it forces it to have an application error of some sort, whereas normal stream termination does NOT always need an error
", "time": "2023-07-25T17:24:34Z"}, {"author": "Matt Joras", "text": "I.e. FINs do not have an error
", "time": "2023-07-25T17:24:41Z"}, {"author": "Mike Bishop", "text": "Ah, right, this is an application error code, so it's up to the app to specify the error code space. Never mind me.
", "time": "2023-07-25T17:25:13Z"}, {"author": "Mike Bishop", "text": "Have to send it.
", "time": "2023-07-25T17:25:17Z"}, {"author": "Matt Joras", "text": "it would not be inconsistent if our streams always terminated with error codes, but they don't
", "time": "2023-07-25T17:25:31Z"}, {"author": "Christian Huitema", "text": "ACK Frequency is 2 bytes now. SHould it be 1?
", "time": "2023-07-25T17:26:51Z"}, {"author": "Alan Frindell", "text": "Unsure if this is a QUIC question or a WebTransport question or a WC3 question - is if this is now a piece of the transport API surface that a web transport application would expect to be able to use for its own streams
", "time": "2023-07-25T17:29:14Z"}, {"author": "Jonathan Lennox", "text": "Better than the Oppenheimer Update.
", "time": "2023-07-25T17:29:52Z"}, {"author": "David Schinazi", "text": "+1 Jonathan was going to say that
", "time": "2023-07-25T17:30:12Z"}, {"author": "Matt Joras", "text": "I'm not going to die on the CLOSE_STREAM always having an error, but I just want people to realize that this _is_ fundamentally an philosophical divergence.
\nIt also allows an application to awkwardly leverage partially reliable streams by always sending CLOSE_STREAM with a small reliable size, and then it will have an error for no reason
", "time": "2023-07-25T17:30:24Z"}, {"author": "Matt Joras", "text": "and my argument for having a no-error option is that the normal close path doesn't need an error, so this shouldn't either
", "time": "2023-07-25T17:31:08Z"}, {"author": "Magnus Westerlund", "text": "Christian Huitema said:
\n\n\nIf you have a hard path-ID, then the client can send data on a new 4-tuple while keeping the hard path ID constant. If the server then keeps the congestion state, that's a bug.
\n
Well, there are a couple of corner cases where an actual path change might not be known by the sending client, but readily detectable by the peer. So this would be true for just using the CID as well as having the path ID redirecton layer. The peer would need to change their path ID and do a path validation in this case would it not. The question I can't answer is if this forces the unaware sending party here to actually classify this as a new path?
", "time": "2023-07-25T17:31:28Z"}, {"author": "Matt Joras", "text": "And I don't find \"APIs are hard\" a convincing argument for introducing that philosophical inconsistency
", "time": "2023-07-25T17:31:29Z"}, {"author": "Martin Thomson", "text": "ACK Frequency can stay as 2 bytes, it is an infrequently-used frame (in my experience)
", "time": "2023-07-25T17:32:08Z"}, {"author": "Mike Bishop", "text": "FINs reflect that the data was fully sent and will be delivered. If the stream terminates abruptly, there's an error code to explain why. This is an abrupt termination, despite reliably delivering part of the data. I don't see this as a problem, personally, and I don't think that's \"APIs are hard.\"
", "time": "2023-07-25T17:32:22Z"}, {"author": "Matt Joras", "text": "Mike: it's explicitly _not_ an abrupt termination. There is a reliable size.
", "time": "2023-07-25T17:32:44Z"}, {"author": "Mike Bishop", "text": "But I also don't object to having an errorless version, because I can understand the semantics of \"I sent this normally, I just don't care if you get it.\"
", "time": "2023-07-25T17:32:53Z"}, {"author": "Matt Joras", "text": "You could set the reliable size to everything you sent - 10, and send 10 TB
", "time": "2023-07-25T17:32:57Z"}, {"author": "Matt Joras", "text": "that's not very abrupt
", "time": "2023-07-25T17:33:06Z"}, {"author": "Martin Thomson", "text": "reliable size <= bytes sent is a surprising condition
", "time": "2023-07-25T17:33:16Z"}, {"author": "Alan Frindell", "text": "Alan Frindell said:
\n\n\nUnsure if this is a QUIC question or a WebTransport question or a WC3 question - is if this is now a piece of the transport API surface that a web transport application would expect to be able to use for its own streams
\n
Bernard filed this with W3C: https://github.com/w3c/webtransport/issues/531
", "time": "2023-07-25T17:33:29Z"}, {"author": "Martin Thomson", "text": "@Alan Frindell That sounds like something that is worth considering for WT. It might even be easy to do.
", "time": "2023-07-25T17:34:05Z"}, {"author": "Matt Joras", "text": "Martin: if you are leveraging this as a cheap PR for streams, how is that a surprisng condition?
", "time": "2023-07-25T17:34:12Z"}, {"author": "Matt Joras", "text": "\"Reliably give me X bytes, you can have the rest if you have it already, I guess\"
", "time": "2023-07-25T17:34:32Z"}, {"author": "Martin Thomson", "text": "@Matt Joras if your application expectation is that each stream has a non-deterministic number of bytes that are delivered, sure
", "time": "2023-07-25T17:34:59Z"}, {"author": "Matt Joras", "text": "If you view this as a PR stream feature I think the error code being required makes a lot less sense
", "time": "2023-07-25T17:35:01Z"}, {"author": "Martin Thomson", "text": "but that's fundamentally surprising (and I agree that this is a subjective call)
", "time": "2023-07-25T17:35:17Z"}, {"author": "Matt Joras", "text": "Sure, I think it is subjective. But I can also imagine some application designers are going to realize they can use this for stream PR and use it like that
", "time": "2023-07-25T17:35:46Z"}, {"author": "Martin Thomson", "text": "@Matt Joras are you concerned about saving that byte for the error code?
", "time": "2023-07-25T17:35:54Z"}, {"author": "Matt Joras", "text": "No I'm not
", "time": "2023-07-25T17:36:35Z"}, {"author": "Martin Thomson", "text": "OK, good
", "time": "2023-07-25T17:36:39Z"}, {"author": "Mike Bishop", "text": "Fundamentally, I think any time an application doesn't reliably deliver all the bytes, it should have to indicate why to the other side. The \"why\" might well be a non-error condition, like \"too old to be useful,\" but interpretation of the reason is an application question.
", "time": "2023-07-25T17:38:17Z"}, {"author": "Rui Paulo", "text": "Where's Ken?
", "time": "2023-07-25T17:38:28Z"}, {"author": "Kazuho Oku", "text": "Re #313, +1 to removing .well-known, there are security concerns that have to be addressed and we do not need to do that work inside qlog.
", "time": "2023-07-25T17:39:49Z"}, {"author": "Rui Paulo", "text": "I see Martin's point where's having a separate UDP doc makes sense. TCP is a different beast and requires a separate doc
", "time": "2023-07-25T17:41:04Z"}, {"author": "Alex Chernyakhovsky", "text": "Am I confused, or doesn't Martin's question imply that datagrams should not be in a udp-subnamespace
", "time": "2023-07-25T17:41:04Z"}, {"author": "Alejandro Sede\u00f1o", "text": "Rui Paulo said:
\n\n\nWhere's Ken?
\n
There he is!
", "time": "2023-07-25T17:41:35Z"}, {"author": "Matt Joras", "text": "Mike: That's okay but the current framing of the implementation of the frame is that it is \"moving the FIN\". Under that framing, I would argue that such an application does not really have a good meaning for \"all the bytes\". Fundamentally, \"all the bytes\" is not completely deterministic.
", "time": "2023-07-25T17:41:54Z"}, {"author": "Lucas Pardue", "text": "Alex: my understanding is that martin would like a full UDP schema but in the absence of someone volunteering to write the whole thing, he is happy with some partial support as proposed
", "time": "2023-07-25T17:42:25Z"}, {"author": "Alex Chernyakhovsky", "text": "RIght, but doesn't that also imply that QUIC datagrams should not be squatting the udp namespace?
", "time": "2023-07-25T17:44:15Z"}, {"author": "Lucas Pardue", "text": "there are QUIC datagram frames and UDP datagrams, and right now they both sit in the same namespace, which is confusing
", "time": "2023-07-25T17:45:18Z"}, {"author": "Alex Chernyakhovsky", "text": "Right, and wasn't the proposal on the slide to put them all in the udp namespace?
", "time": "2023-07-25T17:46:01Z"}, {"author": "Rui Paulo", "text": "And finally the barbenheimer reference.
", "time": "2023-07-25T17:46:29Z"}, {"author": "Robin Marx", "text": "Good things come to those who wait
", "time": "2023-07-25T17:46:48Z"}, {"author": "Lucas Pardue", "text": "no, the proposal was just to move the UDP datagrams to udp and keep QUIC datagram frames in quic
Oh. That's not what I thought it was saying and that makes a lot more sense. Thanks.
", "time": "2023-07-25T17:47:58Z"}, {"author": "Robin Marx", "text": "Sorry that was unclear Alex. Lucas of course has the right of it.
", "time": "2023-07-25T17:48:28Z"}, {"author": "Lucas Pardue", "text": "thanks for asking Alex, good to know we are aligned
", "time": "2023-07-25T17:48:44Z"}, {"author": "Robin Marx", "text": "(bit disappointed David didn't announce himself as Barbie enthusiast tbh...)
", "time": "2023-07-25T17:48:51Z"}, {"author": "Lucas Pardue", "text": "ack_frequency frequency
", "time": "2023-07-25T17:49:45Z"}, {"author": "Alejandro Sede\u00f1o", "text": "I,I Kenthusiast.
", "time": "2023-07-25T17:49:59Z"}, {"author": "Martin Thomson", "text": "I believe that a random sample from the 2 byte space (62-16483) is fine.
", "time": "2023-07-25T17:52:50Z"}, {"author": "Rui Paulo", "text": "I really enjoyed 0xaf, so we could continue the joke with 0xacfe
", "time": "2023-07-25T17:59:27Z"}, {"author": "Christian Huitema", "text": "0xaf is two bytes.
", "time": "2023-07-25T18:00:05Z"}, {"author": "Christian Huitema", "text": "(the varint encoding of 0xaf is 2 bytes)
", "time": "2023-07-25T18:00:41Z"}, {"author": "Rui Paulo", "text": "the slides for ACK_FREQUENCY that were presented were not exactly the slides that are on github, or am I missing something?
", "time": "2023-07-25T18:05:02Z"}, {"author": "Matt Joras", "text": "yeah Ian updated them and we have yet to update github
", "time": "2023-07-25T18:05:18Z"}, {"author": "Rui Paulo", "text": "Matt: I'm just confused because the slide about Meta deployment experience talked about regressions with ACK_FREQUENCY but the takeaway slide painted a different picture
", "time": "2023-07-25T18:06:17Z"}, {"author": "Matt Joras", "text": "There were regressions and then we changed things and there were no longer obvious regressions.
", "time": "2023-07-25T18:07:01Z"}, {"author": "Matt Joras", "text": "the main thing to note is the PTO IMMEDIATE_ACK and not using windowed min RTT
", "time": "2023-07-25T18:07:34Z"}, {"author": "Kazuho Oku", "text": "FTR, my comment regarding 3 bits would be that:
\nCouldn't this be done at the IP layer (DSCP)?
", "time": "2023-07-25T18:12:51Z"}, {"author": "John Border", "text": "Should avoid thinking of it as priority and just think of it as a path indicator.
", "time": "2023-07-25T18:13:44Z"}, {"author": "Jonathan Hoyland", "text": "Surely this leaks security info?
", "time": "2023-07-25T18:13:53Z"}, {"author": "Christian Huitema", "text": "It could -- when setting the path, have a specific 4-tuple+priority code, and then set path status to \"priority only\"
", "time": "2023-07-25T18:14:05Z"}, {"author": "Antoine Fressancourt", "text": "From my understanding the idea is to give apps a means to influence the QoS policy
", "time": "2023-07-25T18:14:08Z"}, {"author": "Antoine Fressancourt", "text": "@Jonathan it leaks a strong hint on the app using the QUIC connection
", "time": "2023-07-25T18:14:59Z"}, {"author": "John Border", "text": "Is the existence of multiple paths exposed to the application?
", "time": "2023-07-25T18:15:19Z"}, {"author": "Daniel Gillmor", "text": "so we want some networks to understand the priorities but not other networks?
", "time": "2023-07-25T18:16:04Z"}, {"author": "Martin Thomson", "text": "Looking at the length of the queue AND the remaining time, you each have 2 seconds.
", "time": "2023-07-25T18:16:27Z"}, {"author": "Ted Hardie", "text": "Due to a mis-click, I lost my place and dropped to the body. So I fear that my concerns here will be lost in the noise.
", "time": "2023-07-25T18:16:30Z"}, {"author": "Christian Huitema", "text": "Of course, the whole idea of network QOS is orthogonal to QUIC. QUIC view is that the network is a set of path through marshes infested with mosquitoes, caymans, and middleboxes. The last thing you want is mark paths as important, because the caymans and the middleboxes will get you!
", "time": "2023-07-25T18:16:48Z"}, {"author": "Martin Thomson", "text": "What is wrong with per-packet DSCP now?
", "time": "2023-07-25T18:16:58Z"}, {"author": "Matt Joras", "text": "ACK Ted
", "time": "2023-07-25T18:16:58Z"}, {"author": "Daniel Gillmor", "text": "high-entropy variable-length connection IDs are proving to be an attractive nuisance
", "time": "2023-07-25T18:17:05Z"}, {"author": "Antoine Fressancourt", "text": "@Martin Apps lack capacity to set DSCP properly, maybe
", "time": "2023-07-25T18:17:33Z"}, {"author": "Ted Hardie", "text": "Among them: this leaks information; this does not justify using a single QUIC connection; the limitation to pre-determining the number of server identified queues and coordination that will be a massive pain; it doesn't work outside a single SRv6 domain; and so many, many more.
", "time": "2023-07-25T18:17:39Z"}, {"author": "Jonathan Lennox", "text": "Presumably if you can set ECN you can set DSCP? Unless your API is very weird
", "time": "2023-07-25T18:18:02Z"}, {"author": "Christian Huitema", "text": "@Martin Thomson: if you define a path as 4-tuple plus DSCP code, and set the path status to \"priority\", you get pretty much that.
", "time": "2023-07-25T18:18:05Z"}, {"author": "Martin Thomson", "text": "@Daniel Gillmor you mean that you don't want people using connection IDs to execute a cleartext protocol with arbitrary eavesdroppers?
", "time": "2023-07-25T18:18:15Z"}, {"author": "Jonathan Lennox", "text": "(Note: As I recall the Windows APIs in this space are indeed weird.)
", "time": "2023-07-25T18:18:31Z"}, {"author": "Daniel Gillmor", "text": "it's not my favorite design pattern
", "time": "2023-07-25T18:18:32Z"}, {"author": "Antoine Fressancourt", "text": "Oh, and DSCP are filtered most of the time
", "time": "2023-07-25T18:18:42Z"}, {"author": "Daniel Gillmor", "text": "@Ted Hardie ++
", "time": "2023-07-25T18:19:39Z"}, {"author": "Martin Thomson", "text": "MP-QUIC + whatever seems like the right answer
", "time": "2023-07-25T18:20:12Z"}, {"author": "Dragana Damjanovic", "text": "I agree with the comments
", "time": "2023-07-25T18:20:57Z"}, {"author": "David Schinazi", "text": "Such an enthusiastic group today
", "time": "2023-07-25T18:25:01Z"}, {"author": "John Border", "text": "An underlying idea is that the application is smart enough...
", "time": "2023-07-25T18:25:03Z"}, {"author": "John Border", "text": "Application versus application is not the point.
", "time": "2023-07-25T18:26:02Z"}, {"author": "Lucas Pardue", "text": "such enthusiasm, wow
", "time": "2023-07-25T18:26:13Z"}, {"author": "David Schinazi", "text": "Should I start making \"Ted Hardie Enthusiast\" stickers?
", "time": "2023-07-25T18:26:16Z"}, {"author": "John Border", "text": "I think a colored dot would be more appropriate.
", "time": "2023-07-25T18:26:50Z"}, {"author": "Peter Thatcher", "text": "I'm presenting a similar draft about p2p QUIC at AVTCORE tomorrow if anyone is interested.
", "time": "2023-07-25T18:27:51Z"}, {"author": "John Border", "text": "Similar to the NAT document or the previous one?
", "time": "2023-07-25T18:28:35Z"}, {"author": "Peter Thatcher", "text": "The NAT one
", "time": "2023-07-25T18:28:41Z"}, {"author": "Peter Thatcher", "text": "About how to do ICE+QUIC together.
", "time": "2023-07-25T18:29:02Z"}, {"author": "Peter Thatcher", "text": "My draft is basically \"MODE 1\" here.
", "time": "2023-07-25T18:30:31Z"}, {"author": "David Schinazi", "text": "@Peter I'd suggest you mention this at the mic after Marten is done so folks in the room know - not everyone sees the chat
", "time": "2023-07-25T18:31:08Z"}, {"author": "John Border", "text": "That is what I thought but wanted to be sure.
", "time": "2023-07-25T18:31:18Z"}, {"author": "Peter Thatcher", "text": "I'm remote, so I guess I'll raise my hand
", "time": "2023-07-25T18:32:04Z"}, {"author": "Matt Joras", "text": "we'll mention it on the mic
", "time": "2023-07-25T18:32:20Z"}, {"author": "David Schinazi", "text": "thx
", "time": "2023-07-25T18:33:35Z"}]