[{"author": "Brian Trammell", "text": "good morning all
", "time": "2022-03-22T09:02:16Z"}, {"author": "Sean Turner", "text": "@lucas Where's your HAT?
", "time": "2022-03-22T09:02:17Z"}, {"author": "David Schinazi", "text": "Hello fellow QUIC enthusiasts, if you would like your message relayed at the mic, please type it here and prefix it with \"mic:\"
", "time": "2022-03-22T09:05:04Z"}, {"author": "Sean Turner", "text": "@brian morning - thanks for taking notes
", "time": "2022-03-22T09:06:35Z"}, {"author": "David Schinazi", "text": "Where do we file an issue about the chair not wearing their QUIC hat?
", "time": "2022-03-22T09:07:15Z"}, {"author": "Martin Thomson", "text": "there was also a talk on website fingerprinting in PEARG
", "time": "2022-03-22T09:07:39Z"}, {"author": "Martin Thomson", "text": "for those that missed it, the paper: https://arxiv.org/pdf/2203.07806.pdf
", "time": "2022-03-22T09:08:40Z"}, {"author": "Sean Turner", "text": "I think we should just leave it to the chairs. Things seem to be progressing.
", "time": "2022-03-22T09:08:56Z"}, {"author": "David Schinazi", "text": "+1 to Sean
", "time": "2022-03-22T09:09:12Z"}, {"author": "Martin Thomson", "text": "Yes, I think that the chairs should decide.
", "time": "2022-03-22T09:09:59Z"}, {"author": "Martin Thomson", "text": "Also, what Lucas wants to do seems good.
", "time": "2022-03-22T09:10:09Z"}, {"author": "Eric Kinnear", "text": "+1, ordered but undated seems fine
", "time": "2022-03-22T09:10:55Z"}, {"author": "Martin Thomson", "text": "loosely ordered, yeah
", "time": "2022-03-22T09:11:12Z"}, {"author": "Craig Taylor", "text": "Perhaps a rough effort indication may be useful?S M L
", "time": "2022-03-22T09:12:48Z"}, {"author": "Martin Thomson", "text": "Craig: we all know how big things are; usually the page count is a good indication
", "time": "2022-03-22T09:13:41Z"}, {"author": "Matt Joras", "text": "\"effort amount\" does not correlate strongly with how long something takes to complete.
", "time": "2022-03-22T09:13:49Z"}, {"author": "Martin Thomson", "text": "Matt: yep, see the quic bit draft
", "time": "2022-03-22T09:14:03Z"}, {"author": "Matt Joras", "text": "Exactly.
", "time": "2022-03-22T09:14:16Z"}, {"author": "Mike Bishop", "text": "Does David get video somewhere?
", "time": "2022-03-22T09:15:27Z"}, {"author": "Jonathan Lennox", "text": "Meetecho can you repoint the camera at the speaker?
", "time": "2022-03-22T09:15:46Z"}, {"author": "Sean Turner", "text": "He must not be in the pink box ;)
", "time": "2022-03-22T09:15:46Z"}, {"author": "Jana Iyengar", "text": "no pink box?
", "time": "2022-03-22T09:15:54Z"}, {"author": "Lucas Pardue", "text": "there is a pink x
", "time": "2022-03-22T09:16:09Z"}, {"author": "Christian Huitema", "text": "EKR is right, David is wrong.
", "time": "2022-03-22T09:16:57Z"}, {"author": "Martin Thomson", "text": "yes, ekr is right
", "time": "2022-03-22T09:17:07Z"}, {"author": "Martin Thomson", "text": "I hate saying that, but it is often the case
", "time": "2022-03-22T09:17:14Z"}, {"author": "Jana Iyengar", "text": "it's early THERE? It's 2AM PST
", "time": "2022-03-22T09:17:15Z"}, {"author": "Ted Hardie", "text": "Jana, that's late, not early.
", "time": "2022-03-22T09:17:30Z"}, {"author": "Matt Joras", "text": "PDT Jana, we live in a (broken) society
", "time": "2022-03-22T09:17:34Z"}, {"author": "dkg", "text": "i think ekr is right as well, but i don't see how to make the decision without knowing what the implication of the term is.
", "time": "2022-03-22T09:17:53Z"}, {"author": "Jana Iyengar", "text": "Ted, it's both.
", "time": "2022-03-22T09:17:59Z"}, {"author": "dkg", "text": "Matt Joras: are you sure that Jana isn't in his own TZ?
", "time": "2022-03-22T09:18:15Z"}, {"author": "Eric Rescorla", "text": "Already did
", "time": "2022-03-22T09:18:19Z"}, {"author": "dkg", "text": "TZ=America/Iyengar
", "time": "2022-03-22T09:18:28Z"}, {"author": "Mike Bishop", "text": "It's a distinction without a difference, IMO. Compatible negotiation is anything you can map the flight to, and the mapping to the same version is trivial.
", "time": "2022-03-22T09:18:54Z"}, {"author": "Jana Iyengar", "text": "What Mike said.
", "time": "2022-03-22T09:19:19Z"}, {"author": "Mike Bishop", "text": "But you can as easily say that the server accepts the offered version without an attempt to negotiate.
", "time": "2022-03-22T09:19:21Z"}, {"author": "Eric Rescorla", "text": "I was just gonna agree with MT agreeing with me. I'll try to figure out what the heck is wrong with my mic
", "time": "2022-03-22T09:19:32Z"}, {"author": "Martin Thomson", "text": "My opinion on this draft: it's technically complete, but in dire need of some editorial cleanup
", "time": "2022-03-22T09:19:50Z"}, {"author": "Eric Rescorla", "text": "Yeah, I agree with that assessment
", "time": "2022-03-22T09:20:28Z"}, {"author": "Eric Rescorla", "text": "OK theoretically my mic will work now
", "time": "2022-03-22T09:20:38Z"}, {"author": "Sean Turner", "text": ":)
", "time": "2022-03-22T09:21:26Z"}, {"author": "Eric Rescorla", "text": "My current plan is to just shove it into GPT-3 and then type \"QUIC version negotiation\" as the prompt
", "time": "2022-03-22T09:21:39Z"}, {"author": "Martin Thomson", "text": "the structure of the doc is much improved
", "time": "2022-03-22T09:22:55Z"}, {"author": "Martin Thomson", "text": "I
", "time": "2022-03-22T09:22:56Z"}, {"author": "Martin Thomson", "text": "I will need to re-review
", "time": "2022-03-22T09:23:04Z"}, {"author": "Christian Huitema", "text": "Where is the ietf-draft tuning for GPT-3?
", "time": "2022-03-22T09:23:27Z"}, {"author": "Ted Hardie", "text": "This seems to be the right answer.
", "time": "2022-03-22T09:25:24Z"}, {"author": "Martin Thomson", "text": "anything that is compatible++ with QUICv1 should be able to use the same ALPN; for that, it needs to be VN compatible and feature compatible
", "time": "2022-03-22T09:25:27Z"}, {"author": "Martin Thomson", "text": "if the new version misses on either count, then we have a potential problem
", "time": "2022-03-22T09:25:56Z"}, {"author": "Christian Huitema", "text": "+1 Martin.
", "time": "2022-03-22T09:26:09Z"}, {"author": "Christian Huitema", "text": "The ties between ALPN and VN should be as loose as possible.
", "time": "2022-03-22T09:26:33Z"}, {"author": "Martin Thomson", "text": "this was the point I was going to make
", "time": "2022-03-22T09:26:53Z"}, {"author": "Christian Huitema", "text": "Yes, Mike is right
", "time": "2022-03-22T09:27:02Z"}, {"author": "Martin Thomson", "text": "we need to define what it means to share an ALPN across versions
", "time": "2022-03-22T09:27:12Z"}, {"author": "Matt Joras", "text": "+1. Practically this is a good way to use ALPN + version. We have used the same ALPN with consecutive QUIC versions to great effect.
", "time": "2022-03-22T09:27:25Z"}, {"author": "Ted Hardie", "text": "If Martin's text above ended up in the VN draft, I think that would be the right core statement.
", "time": "2022-03-22T09:27:33Z"}, {"author": "Eric Kinnear", "text": "Seems reasonable to have VN say \"here's what you sign up for if you want to share\" and then v2 says \"great, we want that\"
", "time": "2022-03-22T09:27:52Z"}, {"author": "Martin Thomson", "text": "the problem with VN incompatible sharing an ALPN is that you add latency
", "time": "2022-03-22T09:28:22Z"}, {"author": "Christian Huitema", "text": "Kind of practical. Otherwise, we get to have a list of ALPN in each client hello to match the proposed VN, and then why not have that in the TPs?
", "time": "2022-03-22T09:28:36Z"}, {"author": "Martin Thomson", "text": "the problem with feature incompatible sharing an ALPN is that you might not be able to operate the protocol
", "time": "2022-03-22T09:28:40Z"}, {"author": "Christian Huitema", "text": "... and vice versa. If you can operate the protocol then it works...
", "time": "2022-03-22T09:29:32Z"}, {"author": "Christian Huitema", "text": "Love optimistic statements like DoQ has shipped...
", "time": "2022-03-22T09:30:08Z"}, {"author": "Martin Thomson", "text": "for features, you want \u2287
", "time": "2022-03-22T09:30:20Z"}, {"author": "Alan Frindell", "text": "Do application layer protocols that use quic need a way to specify what they require from a quic version? I thought H3 kind of did that.
", "time": "2022-03-22T09:30:22Z"}, {"author": "Lucas Pardue", "text": "cutting the queue...
", "time": "2022-03-22T09:30:52Z"}, {"author": "jhoyla", "text": "@David Schinazi_web_725 \ud83d\udd25\ud83d\udd25\ud83d\udd25
", "time": "2022-03-22T09:31:08Z"}, {"author": "Martin Thomson", "text": "with Alt-Svc, we did the best that we could with the information we had at hand
", "time": "2022-03-22T09:31:14Z"}, {"author": "Jonathan Lennox", "text": "If a new quic version adds a feature, and then an app wants to use that new feature if quic supports it, does that need a new alpn?
", "time": "2022-03-22T09:31:14Z"}, {"author": "Martin Thomson", "text": "unfortunately, that was not very good
", "time": "2022-03-22T09:31:23Z"}, {"author": "Martin Thomson", "text": "features used in original version \u2287 features used in other version
", "time": "2022-03-22T09:31:55Z"}, {"author": "Christian Huitema", "text": "Many features can be negotiated via TP negotiation. How do you tie ALPN negotiation to *that*?
", "time": "2022-03-22T09:32:01Z"}, {"author": "Mike Bishop", "text": "@Jonathan, I would say only if the feature is mandatory.
", "time": "2022-03-22T09:32:09Z"}, {"author": "Luca Niccolini", "text": "for HTTP at least, can't SETTINGS be used instead of a new ALPN per version?
", "time": "2022-03-22T09:33:20Z"}, {"author": "Lucas Pardue", "text": "how do you read the settings? :-)
", "time": "2022-03-22T09:33:44Z"}, {"author": "Christian Huitema", "text": "Datagram is not negotiated by version!
", "time": "2022-03-22T09:34:14Z"}, {"author": "Mike Bishop", "text": "It works if you lose features you don't use. A version of QUIC that didn't have server-initiated bidi streams, for example.
", "time": "2022-03-22T09:34:39Z"}, {"author": "Luca Niccolini", "text": "@lucasp unless the H3 framing itself has changed I can read settings. If H3 framing is different then yeah, I'd need a new ALPN
", "time": "2022-03-22T09:35:08Z"}, {"author": "Mike Bishop", "text": "Invariants have a notion of application protocol selection.
", "time": "2022-03-22T09:35:22Z"}, {"author": "Lucas Pardue", "text": "you need to know that the settings arrive on a unidirectional stream. If a QUIC version removes unidirectional streams, you can't do that
", "time": "2022-03-22T09:35:56Z"}, {"author": "David Schinazi", "text": "@Mike where is that in RFC 8999?
", "time": "2022-03-22T09:36:31Z"}, {"author": "Mirja K\u00fchlewind", "text": "Maybe it's actually about the question if API changes (in an incompatible way)
", "time": "2022-03-22T09:37:36Z"}, {"author": "Luca Niccolini", "text": "@lucasp yeah, got it. Alan summarized it for me with \"you need a new alpn when a current h3 parser couldn't correctly parse or understand the wire image\". I get it now
", "time": "2022-03-22T09:38:41Z"}, {"author": "Mike Bishop", "text": "@David, you're correct. I was remembering that we required protocol agreement as a property of the handshake (and ALPN as the mechanism TLS uses), but 8999 is basically an exterior view.
", "time": "2022-03-22T09:40:55Z"}, {"author": "David Schinazi", "text": "I still don't think we can move v2 forward when it doesn't meet the goals we set out for it: v2 exists to grease the version field - if we only use it with compatible VN then v2 doesn't grease the version field
", "time": "2022-03-22T09:42:03Z"}, {"author": "Martin Thomson", "text": "the block cipher doesn't have the 12 iterations issue
", "time": "2022-03-22T09:42:35Z"}, {"author": "Martin Thomson", "text": "David: how do you reckon regarding the version field? My implementation will use a new version number in a range of scenarios.
", "time": "2022-03-22T09:43:46Z"}, {"author": "Mike Bishop", "text": "RFC 9000 Section 7 still has some of that abstraction that QUIC has requirements of the handshake which QUIC v1 meets with TLS.
", "time": "2022-03-22T09:43:53Z"}, {"author": "Matt Joras", "text": "David: I think it depends on how you interpret the goal. If the goal is to get a different version number in the \"wild\" then we don't need an incompatible version.
", "time": "2022-03-22T09:43:57Z"}, {"author": "David Schinazi", "text": "In my view the goal is to make sure that middleboxes don't fall over when clients send a different version
", "time": "2022-03-22T09:44:39Z"}, {"author": "Martin Thomson", "text": "sequence number encryption was post-hoc validated by Bellare et. al.
", "time": "2022-03-22T09:45:17Z"}, {"author": "Martin Thomson", "text": "the problem here is that FPE is really, really hard to do well
", "time": "2022-03-22T09:45:59Z"}, {"author": "Matt Joras", "text": "David: why does it matter if the version used is compatible with v1? I would say the existing v2 + VN + the current ALPN situation does that fine. Especially given things like ECH.
", "time": "2022-03-22T09:46:33Z"}, {"author": "Martin Thomson", "text": "my understanding is that FFX is not the current gold standard for FPE
", "time": "2022-03-22T09:46:51Z"}, {"author": "Eric Rescorla", "text": "Me too.
", "time": "2022-03-22T09:47:06Z"}, {"author": "Eric Rescorla", "text": "But this is more like a variable-length block cipher than FPE
", "time": "2022-03-22T09:47:18Z"}, {"author": "Eric Rescorla", "text": "Actually, no, I guess FFX is that
", "time": "2022-03-22T09:47:37Z"}, {"author": "Eric Rescorla", "text": "And then has an FPE layer on top
", "time": "2022-03-22T09:47:44Z"}, {"author": "Martin Thomson", "text": "can we add a tweak?
", "time": "2022-03-22T09:48:21Z"}, {"author": "Martin Thomson", "text": "a per-deployment tweak might help
", "time": "2022-03-22T09:48:42Z"}, {"author": "David Schinazi", "text": "@Matt my issue is not with compatibility, it's with the fact that browsers can't send a v2 initial because there's no way to express h3 over QUICv2 in Alt-Svc
", "time": "2022-03-22T09:48:47Z"}, {"author": "Martin Thomson", "text": "David, we send a v2 Initial in some cases
", "time": "2022-03-22T09:49:32Z"}, {"author": "Eric Rescorla", "text": "@David: well, they can, as long as they are willing to accept an extra VN RT, right?
", "time": "2022-03-22T09:49:40Z"}, {"author": "Martin Thomson", "text": "we take the VN RTT in that case
", "time": "2022-03-22T09:49:51Z"}, {"author": "Eric Rescorla", "text": "Indeed, that's the only way you'll ever exercise incompatible VN :)
", "time": "2022-03-22T09:49:53Z"}, {"author": "David Schinazi", "text": "Browsers are not willing to accept extra rount trips
", "time": "2022-03-22T09:49:56Z"}, {"author": "Eric Rescorla", "text": "Well, I don't see how you can have it both ways (1) grease incompatible VN and (2) no RTs
", "time": "2022-03-22T09:50:14Z"}, {"author": "Martin Thomson", "text": "I'm willing to try to be more aggressive and suffer an RT on an error
", "time": "2022-03-22T09:50:23Z"}, {"author": "Matt Joras", "text": "Ah, okay, I misunderstood.
FWIW practically I am not so worried about the version field on the wire. We have routinely been messing with middleboxes with non-v1 versions for \"a while\" and will continue to do that.
", "time": "2022-03-22T09:50:28Z"}, {"author": "David Schinazi", "text": "I'm not trying to grease incompatible VN, I'm trying to send v2 initials and have those work
", "time": "2022-03-22T09:50:40Z"}, {"author": "Eric Rescorla", "text": "OK, I misunderstood your comments above them.
", "time": "2022-03-22T09:50:53Z"}, {"author": "Eric Rescorla", "text": "This is, in fact, why I wanted compatible VN in the initial spec.
", "time": "2022-03-22T09:51:11Z"}, {"author": "Martin Thomson", "text": "but that problem is addressed by the AltSvc/SVCB extension, right?
", "time": "2022-03-22T09:51:14Z"}, {"author": "David Schinazi", "text": "Sorry if I wasn't clear, haven't had enough coffee
", "time": "2022-03-22T09:51:14Z"}, {"author": "David Schinazi", "text": "@MT yeah that's why I'd like to see that extension mature before we ship this
", "time": "2022-03-22T09:51:34Z"}, {"author": "Martin Thomson", "text": "I don't think that we need to wait on that.
", "time": "2022-03-22T09:51:58Z"}, {"author": "Mike Bishop", "text": "Does that scenario even need multi-path? You can just keep the cellular path validated in stock QUIC, can't you?
", "time": "2022-03-22T09:53:17Z"}, {"author": "Martin Thomson", "text": "I would like to see a design for the backup path thing before signing a deal.
", "time": "2022-03-22T09:53:34Z"}, {"author": "Martin Thomson", "text": "that is, if I'm going to buy this, what does it cost?
", "time": "2022-03-22T09:53:44Z"}, {"author": "Eric Kinnear", "text": "Mike: Yes that should work today, but once you do multipath you remove some of the parts that make that work
", "time": "2022-03-22T09:54:34Z"}, {"author": "Eric Kinnear", "text": "(Specifically the part where the receiver tells the sender what path to use)
", "time": "2022-03-22T09:55:09Z"}, {"author": "Martin Thomson", "text": "how do you signal that a path is in this state? the only thing I can think of here that would reliably work for a path-related signal is PATH_RESPONSE
", "time": "2022-03-22T09:56:13Z"}, {"author": "Martin Thomson", "text": "or, is this something that works best as an extension?
", "time": "2022-03-22T09:57:01Z"}, {"author": "Eric Kinnear", "text": "Seems reasonable as an extension but also kinda seems like table stakes for enabling multipath QUIC: don't regress what stock QUIC can do
", "time": "2022-03-22T09:58:02Z"}, {"author": "Christian Huitema", "text": "Suppose you move from cellular to Wi-Fi: you want cellular back to standby. Not sure this is easy with Path Response.
", "time": "2022-03-22T09:58:04Z"}, {"author": "Nicolas Kuhn", "text": "I think this should be compared with the connection migration in QUIC in the draft
", "time": "2022-03-22T09:59:22Z"}, {"author": "Nicolas Kuhn", "text": "if this is included
", "time": "2022-03-22T09:59:31Z"}, {"author": "Ted Hardie", "text": "I really think a simple approach here is not likely to be very satisfactory; trying to map even the different states you'd get out of OpenRoaming when connecting to a new network would take more space. So I'd want to see some more thought on this.
", "time": "2022-03-22T09:59:52Z"}, {"author": "Christian Huitema", "text": "+1 Mike
", "time": "2022-03-22T10:01:42Z"}, {"author": "Hang Shi", "text": "What is the additional use case for server to open new paths?
", "time": "2022-03-22T10:01:45Z"}, {"author": "Jana Iyengar", "text": "agree with mike
", "time": "2022-03-22T10:01:59Z"}, {"author": "Tommy Pauly", "text": "I think we could punt on this to future work?
", "time": "2022-03-22T10:02:08Z"}, {"author": "Martin Thomson", "text": "how does this manage glare?
", "time": "2022-03-22T10:02:39Z"}, {"author": "Martin Thomson", "text": "if you have ICE, what would you do? build a new candidate pair and then what? this seems to cover that. but I don't think that this works with ICE at all
", "time": "2022-03-22T10:04:35Z"}, {"author": "Martin Thomson", "text": "ICE manages path migration for you, which means that your path identity is bound to the concepts in ICE, not IPs and ports
", "time": "2022-03-22T10:05:00Z"}, {"author": "Tommy Pauly", "text": "+1 to eric
", "time": "2022-03-22T10:05:58Z"}, {"author": "Hang Shi", "text": "+1 to eric
", "time": "2022-03-22T10:06:22Z"}, {"author": "Jana Iyengar", "text": "good call out eric -- especially on the ability for hijackers
", "time": "2022-03-22T10:06:37Z"}, {"author": "Eric Kinnear", "text": "Would be worth going through some of the minutes (esp. from Zurich IIRC and a few of the prior meetings) to dig up a few of the things we punted on. Server Preferred Address was explicitly super narrowly scoped to thread the needle on some of those
", "time": "2022-03-22T10:08:55Z"}, {"author": "Jonathan Lennox", "text": "I think if you have \"please connect to this address\" and you have a way of handling glare, you have everything you need to integrate ICE functionality directly into QUIC (saving you the RTs of ICE). I think that this should be a separate extension though.
", "time": "2022-03-22T10:10:00Z"}, {"author": "Mike Bishop", "text": "We made mobility client-only for simplicity, and SPA was a bid to get a little bit of server address mobility.
", "time": "2022-03-22T10:10:43Z"}, {"author": "Hang Shi", "text": "+1 to Christian. If we want to deviate from single path QUIC, we need to define the usecase clearly.
", "time": "2022-03-22T10:11:03Z"}, {"author": "Tommy Pauly", "text": "Yeah let's keep this simple for this document
", "time": "2022-03-22T10:11:35Z"}, {"author": "Jana Iyengar", "text": "I don't think this is a small change.
", "time": "2022-03-22T10:13:15Z"}, {"author": "Eric Kinnear", "text": "+1 to a separate extension, it might be just a paragraph to delete but we pointed at that paragraph an awful lot when issues came up. (And, to be clear, I think the intent was to eventually delete that paragraph, but let's do it with actual focus on making it work, not as an afterthought.)
", "time": "2022-03-22T10:13:22Z"}, {"author": "Christian Huitema", "text": "Also, keep it simple!
", "time": "2022-03-22T10:16:12Z"}, {"author": "Jana Iyengar", "text": "Section 9.3, RFC 9000: \"An endpoint MAY send data to an unvalidated peer address, but it MUST
protect against potential attacks as described in Sections 9.3.1 and
9.3.2. An endpoint MAY skip validation of a peer address if that
address has been seen recently. In particular, if an endpoint
returns to a previously validated path after detecting some form of
spurious migration, skipping address validation and restoring loss
detection and congestion state can reduce the performance impact of
the attack.\"
", "time": "2022-03-22T10:16:37Z"}, {"author": "Jana Iyengar", "text": "^^ that was for the previous issue -- you can send data before validation.
", "time": "2022-03-22T10:17:59Z"}, {"author": "Eric Kinnear", "text": "+1 to Jana, you can get going (even if not full-speed, although you probably need to ramp up anyways for CC) in parallel with validation
", "time": "2022-03-22T10:18:56Z"}, {"author": "Eric Kinnear", "text": "Is there any downside to having separate ACK frames in the same packet, one for each path?
", "time": "2022-03-22T10:19:37Z"}, {"author": "Ted Hardie", "text": "Rephrasing Eric: if we upgrade the SHOULD to MUST, does this issue go away?
", "time": "2022-03-22T10:20:47Z"}, {"author": "Vidhi Goel", "text": "I strongly feel against the recommendation for the ECN solutions described
", "time": "2022-03-22T10:21:09Z"}, {"author": "Vidhi Goel", "text": "Disabling ECN makes you lose all the benefits of L4S
", "time": "2022-03-22T10:22:07Z"}, {"author": "Martin Thomson", "text": "vidhi, perhaps you should send an email to the list
", "time": "2022-03-22T10:22:15Z"}, {"author": "Vidhi Goel", "text": "Will do
", "time": "2022-03-22T10:22:24Z"}, {"author": "Martin Thomson", "text": "it seems to me that the recommendation for ECN is very much aligned with this notion of multiple PN spaces
", "time": "2022-03-22T10:22:33Z"}, {"author": "Matt Joras", "text": "Vidhi: or on github, which I think is preferred: https://github.com/quicwg/multipath/issues/87
", "time": "2022-03-22T10:22:39Z"}, {"author": "Matt Joras", "text": "(proposed PR: https://github.com/quicwg/multipath/pull/97 )
", "time": "2022-03-22T10:23:11Z"}, {"author": "Martin Thomson", "text": "no mention here of key schedule changes
", "time": "2022-03-22T10:23:24Z"}, {"author": "Martin Thomson", "text": "are we maintaining per-path usage counters on the ciphers?
", "time": "2022-03-22T10:23:37Z"}, {"author": "Jana Iyengar", "text": "it's really a generalized datastructure for loss recovery with multiple PN spaces, isn't it?
", "time": "2022-03-22T10:23:43Z"}, {"author": "Martin Thomson", "text": "(in the multiple PN space option)
", "time": "2022-03-22T10:23:47Z"}, {"author": "Eric Kinnear", "text": "Does recovery actually need multiple PN spaces to be efficient though? Packet X being lost is the same regardless of the number it had, but perhaps there's a common implementation that doesn't lend itself to that?
", "time": "2022-03-22T10:25:54Z"}, {"author": "Jana Iyengar", "text": "the problem eric is with doing packet-threshold loss recovery, which uses acks of \"subsequent packets\" to suggest loss... this gets complicated quickly with single sequence space
", "time": "2022-03-22T10:27:54Z"}, {"author": "Hang Shi", "text": "Yes, to implement the packet-threshold loss recovery with single pn space, you basically need to create virtual pn space for each path
", "time": "2022-03-22T10:29:54Z"}, {"author": "Eric Kinnear", "text": "Ahh thanks, my recollection from implementing that way back when is that each packet was pretty independent, but there were a few spots where we did math using PNs rather than count of packets and packet threshold would have been one of those
", "time": "2022-03-22T10:31:30Z"}, {"author": "Matt Joras", "text": "yes, it is a very convenient property of QUIC PNs, which makes the loss recovery algorithm so simple as to be forgettable :)
", "time": "2022-03-22T10:33:01Z"}, {"author": "Hang Shi", "text": "I like the unified proposal. It is much easier to port single path QUIC to multipath QUIC with multiple pn space w/o NULL SCID. If an implementation want to use NULL SCID for multipath, it need to deal with the complexity.
", "time": "2022-03-22T10:33:41Z"}, {"author": "Eric Kinnear", "text": "Would any implementations that currently use 0-length packet numbers have an issue with _not_ doing that in order to have MPQUIC?
", "time": "2022-03-22T10:34:55Z"}, {"author": "Jana Iyengar", "text": "Multiple sequence spaces is explicit. I would argue strongly for multiple spaces ... the implementation complexity argument was one that we made earlier for keeping scope tight for RFC9000. In the world where we are in fact defining MP, the arguments against using separate explicit sequence spaces aren't strong enough, and are likely to cause pain down the road.
", "time": "2022-03-22T10:34:57Z"}, {"author": "Christian Huitema", "text": "@jana our thinking evolved. We pretty much agree on multiple PN spaces if long CID are there. The only remaining issue is wehther to also negotiate multipath with zero-length CID, and how to support that if we do.
", "time": "2022-03-22T10:36:29Z"}, {"author": "Jana Iyengar", "text": "@christian -- ah, thanks for clarifying. In that case, I like the unified proposal
", "time": "2022-03-22T10:37:40Z"}, {"author": "Martin Thomson", "text": "isn't there a change here? I understand that CDDL is ordered, but JSON stuff might not have been
", "time": "2022-03-22T10:37:45Z"}, {"author": "Lucas Pardue", "text": "I think that depends on the chosen serialization?
", "time": "2022-03-22T10:38:19Z"}, {"author": "Christian Huitema", "text": "We are going to need a qlogv2022 interop!
", "time": "2022-03-22T10:38:50Z"}, {"author": "Lucas Pardue", "text": "+1 to metadata in CDDL
", "time": "2022-03-22T10:41:45Z"}, {"author": "Sean Turner", "text": "CDDL: helps with cross-area review ;)
", "time": "2022-03-22T10:42:25Z"}, {"author": "Martin Thomson", "text": "CDDL: XML Schema for those who never had to live through the XML age
", "time": "2022-03-22T10:43:34Z"}, {"author": "Sean Turner", "text": ":)
", "time": "2022-03-22T10:43:56Z"}, {"author": "Martin Thomson", "text": "basically, anyone for whom the mention of \"Unique Particle Attribution\" doesn't result in a reaction
", "time": "2022-03-22T10:44:55Z"}, {"author": "Alan Frindell", "text": "I commented on the issue, I can help you with QPACK
", "time": "2022-03-22T10:46:01Z"}, {"author": "Lucas Pardue", "text": "We have QUIC and HTTP/3 stickers at the chairs desk at the front to of the room. At the end of session, please come and collect some for yourself, colleages and friends
", "time": "2022-03-22T10:50:40Z"}, {"author": "Christian Huitema", "text": "Do remote attendees get a GIF of the stickers?
", "time": "2022-03-22T10:51:13Z"}, {"author": "Lucas Pardue", "text": "NFT
", "time": "2022-03-22T10:51:19Z"}, {"author": "Christian Huitema", "text": "Eric K should know better. There are really no field that cannot be used for fingerprinting and reidentification...
", "time": "2022-03-22T10:52:03Z"}, {"author": "Christian Huitema", "text": "QLOG is mostly used for debugging. And for debugging, you want to look at the whole connection, all the events, etc. That's necessarily going to be privacy sensistive
", "time": "2022-03-22T10:53:14Z"}, {"author": "Craig Taylor", "text": "...so needs notes on handling/retention
", "time": "2022-03-22T10:53:52Z"}, {"author": "David Schinazi", "text": "We can't hear you Nicolas
", "time": "2022-03-22T10:53:57Z"}, {"author": "Christian Huitema", "text": "Maybe Gorry should present!
", "time": "2022-03-22T10:53:58Z"}, {"author": "Eric Rescorla", "text": "Indeed
", "time": "2022-03-22T10:54:07Z"}, {"author": "Nicolas Kuhn", "text": "Try to fix my mic
", "time": "2022-03-22T10:54:11Z"}, {"author": "Nicolas Kuhn", "text": "sorry about that
", "time": "2022-03-22T10:54:16Z"}, {"author": "Martin Thomson", "text": "please don't use \"transport parameters\" like that
", "time": "2022-03-22T10:55:13Z"}, {"author": "Eric Kinnear", "text": "Christian: Sure, as Robin mentioned implementations will always need to have some other controls around what happens with _any_ content from qlog. Even for debugging, I'd argue there's utility in an additional manual and explicit opt-in for \"all the events\"
", "time": "2022-03-22T10:55:16Z"}, {"author": "Martin Thomson", "text": "how can you learn the RTT when you are doing 0-RTT?
", "time": "2022-03-22T10:57:37Z"}, {"author": "Christian Huitema", "text": "you remain conservative until you have learned the RTT
", "time": "2022-03-22T10:58:01Z"}, {"author": "Nicolas Kuhn", "text": "one approach is to send a standard IW and measure the RTT with this.
", "time": "2022-03-22T10:58:21Z"}, {"author": "Hang Shi", "text": "Do we need to do this for each new congestion control algorithm?
", "time": "2022-03-22T10:58:44Z"}, {"author": "Martin Thomson", "text": "malicious clients will be malicious, with or without your nice advice
", "time": "2022-03-22T10:59:25Z"}, {"author": "Nicolas Kuhn", "text": "it depends on how the slow start is done. there are implementation guidelines for bbr and cubic
", "time": "2022-03-22T10:59:39Z"}, {"author": "Christian Huitema", "text": "the advice is to the server...
", "time": "2022-03-22T10:59:45Z"}, {"author": "Martin Thomson", "text": "BDPFRAME: no
", "time": "2022-03-22T10:59:59Z"}, {"author": "Martin Thomson", "text": "careful resumption: maybe
", "time": "2022-03-22T11:00:08Z"}, {"author": "Mike Bishop", "text": "Why does the client need to see it? Embedding it in the token seems sufficient, no?
", "time": "2022-03-22T11:00:33Z"}, {"author": "Martin Thomson", "text": "Mike: exactly
", "time": "2022-03-22T11:00:47Z"}, {"author": "Nicolas Kuhn", "text": "the client may want to reject the extension
", "time": "2022-03-22T11:00:53Z"}, {"author": "Christian Huitema", "text": "I kind of agree with Martin on priorities. We can deploy with server remembering the data, and then invest in the new frame later if there is demand for it.
", "time": "2022-03-22T11:01:08Z"}, {"author": "Mike Bishop", "text": "Not the client's business. It's the server's information for itself.
", "time": "2022-03-22T11:01:08Z"}, {"author": "Robin Marx", "text": "Bye all!
", "time": "2022-03-22T11:01:35Z"}, {"author": "Mirja K\u00fchlewind", "text": "Thanks! bye!
", "time": "2022-03-22T11:01:42Z"}, {"author": "Sam Hurst", "text": "Thanks for the great session!
", "time": "2022-03-22T11:01:48Z"}]