clap clap clap
", "time": "2022-11-07T13:07:28Z"}, {"author": "Richard Barnes", "text": "i hear MASQUE compliance is compulsory at this meeting
", "time": "2022-11-07T13:08:42Z"}, {"author": "Jonathan Lennox", "text": "While we're advertising things using QUIC (that it'd be good to have solid QUIC expertise for), AVTCore will be talking about RTP over QUIC tomorrow during session 1.
", "time": "2022-11-07T13:10:43Z"}, {"author": "Ted Hardie", "text": "Just to confirm my understanding: you can only use a single path at a time--this would not impact the QUICv1 path switching. Is that right?
", "time": "2022-11-07T13:17:57Z"}, {"author": "Christian Huitema", "text": "My experience with Single number space is that you can in fact make it work, but the receive needs complex acknowledgement heuristics, which is difficult to implement. With proper implementation, the performance are about 98 to 99% of multiple number space.
", "time": "2022-11-07T13:19:39Z"}, {"author": "Eric Kinnear", "text": "That would fit my feelings -- in theory, it was nice to be in SPNS land, but in practice it turns out that humans reason better about the tuple of (path, packet number)
", "time": "2022-11-07T13:20:48Z"}, {"author": "Christian Huitema", "text": "To answer Ted's question: if negotiating multipath, path migration has to be explicit rather than implicit.
", "time": "2022-11-07T13:22:20Z"}, {"author": "David Schinazi", "text": "+1 to Eric
", "time": "2022-11-07T13:22:39Z"}, {"author": "Christian Huitema", "text": "+1 what Mirja says.
", "time": "2022-11-07T13:23:10Z"}, {"author": "Ted Hardie", "text": "@Christian I am okay with that, but I think it is an important thing to highlight--it's easy to see the first mechanism as a first step toward multipath, so folks might expect that the later steps would maintain the same capability. Neogtiated multipath means \"use a tuple\" may be a surprise.
", "time": "2022-11-07T13:24:58Z"}, {"author": "David Schinazi", "text": "Simpler is better. Get read of everything we're not sure we need
", "time": "2022-11-07T13:25:45Z"}, {"author": "David Schinazi", "text": "rid*
", "time": "2022-11-07T13:25:49Z"}, {"author": "Tommy Pauly", "text": "Uhh that's a completely different thing than this draft
", "time": "2022-11-07T13:26:39Z"}, {"author": "David Schinazi", "text": "Thanks Eric, that explains it perfectly
", "time": "2022-11-07T13:27:42Z"}, {"author": "Martin Thomson", "text": "This is definitely possible, but it's a major shift in approach.
", "time": "2022-11-07T13:28:26Z"}, {"author": "Kazuho Oku", "text": "We already have path migration in QUIC v1, so I think we've already crossed the bridge (of having migration inside connection)?
", "time": "2022-11-07T13:28:55Z"}, {"author": "Martin Thomson", "text": "It might be easier to do though, provided that you can bond streams. You don't need to bond datagrams.
", "time": "2022-11-07T13:29:15Z"}, {"author": "Martin Thomson", "text": "@Kazuho Oku that is potentially something you could rationalize. The advantage with that approach is that the important stuff (CC, packet numbers, etc...) are all naturally independent.
", "time": "2022-11-07T13:30:52Z"}, {"author": "David Schinazi", "text": "It all comes down to which layer you want the complexity to live in. You can either deal with it in QUIC, or you can run TCP (shudder) over DATAGRAM frames
", "time": "2022-11-07T13:31:15Z"}, {"author": "Martin Thomson", "text": "The challenges are many: how do bond; how to manage different identities, how to manage state.
", "time": "2022-11-07T13:31:19Z"}, {"author": "David Schinazi", "text": "Or I hear that QUIC-in-QUIC is a thing
", "time": "2022-11-07T13:31:22Z"}, {"author": "Martin Thomson", "text": "Oh yeah, that would be a good design: two connections over which you send DATAGRAMs that carry packets for a different QUIC.
", "time": "2022-11-07T13:32:07Z"}, {"author": "David Schinazi", "text": "But yeah, the ship has sailed - the WG decided to work on the inside-QUIC version, we can always do the other version later if someone wants it
", "time": "2022-11-07T13:32:10Z"}, {"author": "Christian Huitema", "text": "Another challenge is that it is pretty hard to have multiple connections between two nodes without using explicit connection ID...
", "time": "2022-11-07T13:32:15Z"}, {"author": "Alan Frindell", "text": "It might be too early to say how moq might split a stream over multiple paths, as we're just starting to talk about how to map media onto streams.
", "time": "2022-11-07T13:36:10Z"}, {"author": "Marten Seemann", "text": "Transport parameters are declared, not negotiated, so I'm not sure if Mirja's text suggestion would work.
", "time": "2022-11-07T13:37:09Z"}, {"author": "Christian Huitema", "text": "Marten is right. The correct implementation is to say \"nodes MUST NOT propose support for multipath f they are using zero-length connection ID\"
", "time": "2022-11-07T13:39:04Z"}, {"author": "Lucas Pardue", "text": "+1
", "time": "2022-11-07T13:39:26Z"}, {"author": "Matt Joras", "text": "The solution for how to remove it will have to be iterated on, most likely
", "time": "2022-11-07T13:39:45Z"}, {"author": "Christian Huitema", "text": "Mirja and I differ on this. WE should specify less, not more. We don't know today what implementers will learn tomorrow.
", "time": "2022-11-07T13:42:16Z"}, {"author": "Kazuho Oku", "text": "For HTTP, we can rely on 0-RTT handshake, but for some application protocols it might make sense to send keep-alives (or do we want to implement resumption of inside application protocol)?
", "time": "2022-11-07T13:47:00Z"}, {"author": "Marten Seemann", "text": "It seems weird that we can 0-RTT-resume a connection, but impose a penalty for resuming a path.
", "time": "2022-11-07T13:47:20Z"}, {"author": "Martin Thomson", "text": "Heavy state protocols (some of the signaling protocols can be like this) do like to avoid teardown.
", "time": "2022-11-07T13:47:50Z"}, {"author": "Christian Huitema", "text": "Yunfei brought up the interesting scenario: use one path, keep a hot backup, and that requires keeping the backup alive.
", "time": "2022-11-07T13:49:21Z"}, {"author": "Jonathan Lennox", "text": "Does that also include sending enough data on the hot backup to keep its congestion window big?
", "time": "2022-11-07T13:50:10Z"}, {"author": "David Schinazi", "text": "Doesn't the congestion window stay big in the absence of traffic?
", "time": "2022-11-07T13:54:46Z"}, {"author": "Martin Thomson", "text": "Unfortunately, I don't think that Ian's suggestion to use the first CID seqno on the path works.
", "time": "2022-11-07T13:59:19Z"}, {"author": "Kazuho Oku", "text": "If we are to have only CID, does that mean that we have to send things like ACK_FREQUENCY frame on all the CIDs sharing one path?
", "time": "2022-11-07T13:59:25Z"}, {"author": "Martin Thomson", "text": "You need a shared understanding of what a \"path\" is in order to do that.
", "time": "2022-11-07T13:59:31Z"}, {"author": "Martin Thomson", "text": "What I think we want for path abandonment is \"you are sending to me with CID seqno X, please stop\" with an implied \"and stop sending on that path\"
", "time": "2022-11-07T14:00:13Z"}, {"author": "Martin Thomson", "text": "like STOP_SENDING, which asks the peer to send RESET_STREAM, you would say PLEASE_RETIRE_CID
", "time": "2022-11-07T14:00:43Z"}, {"author": "David Schinazi", "text": "@Meetecho slide issues
", "time": "2022-11-07T14:01:17Z"}, {"author": "Martin Thomson", "text": "chairs can request that the uploaded slides be refreshed, I believe
", "time": "2022-11-07T14:01:32Z"}, {"author": "Christian Huitema", "text": "+1 Martin. Treating Abandon as \"please abandon\" makes sense.
", "time": "2022-11-07T14:01:47Z"}, {"author": "David Schinazi", "text": "Varint all the things!
", "time": "2022-11-07T14:04:01Z"}, {"author": "Christian Huitema", "text": "Varint! Yes! Let's consider the reordering on a connection to the Moon!
", "time": "2022-11-07T14:05:09Z"}, {"author": "Jonathan Lennox", "text": "2^62 packets per RTT is further than the moon...
", "time": "2022-11-07T14:05:59Z"}, {"author": "Christian Huitema", "text": "Let's add weaselwords, \"the max number shall be compatible with IETF recommendations\" or something like that.
", "time": "2022-11-07T14:07:00Z"}, {"author": "Ted Hardie", "text": "Funny you should mention that: the host talk on Thursday at noon will be: \u201cProject Callisto: Extra-terrestrial collaboration with WebRTC and AV1.\"
", "time": "2022-11-07T14:07:12Z"}, {"author": "David Schinazi", "text": "Byte vs varint is really our favorite bikeshed in this WG
", "time": "2022-11-07T14:07:19Z"}, {"author": "Christian Huitema", "text": "Spinbitting the varint!
", "time": "2022-11-07T14:07:41Z"}, {"author": "Ted Hardie", "text": "The moon is in scope.
", "time": "2022-11-07T14:07:44Z"}, {"author": "Martin Thomson", "text": "There is nothing stopping an implementation with its own constraints from capping the value.
", "time": "2022-11-07T14:08:00Z"}, {"author": "Martin Thomson", "text": "If Linux can only count up to 255, then it can ACK at 255, even if the number is 2^57
", "time": "2022-11-07T14:08:27Z"}, {"author": "Martin Thomson", "text": "Please finish this draft; I implemented an older version and have been holding off on updates for AAAGES
", "time": "2022-11-07T14:09:32Z"}, {"author": "David Schinazi", "text": "Please set a deadline to motivate our editors
", "time": "2022-11-07T14:09:44Z"}, {"author": "Christian Huitema", "text": "+1 on updating implementations.
", "time": "2022-11-07T14:10:02Z"}, {"author": "Christian Huitema", "text": "Robin is close to saying \"privacy is hard, let's ignore it\"
", "time": "2022-11-07T14:11:46Z"}, {"author": "Lucas Pardue", "text": "Q: for ack frequency implementers, are you holding for 0 open issues or WGLC?
", "time": "2022-11-07T14:13:06Z"}, {"author": "Matt Joras", "text": "We already implemented it and have experimented with it (with a varint reordering threshold, lol)
", "time": "2022-11-07T14:13:24Z"}, {"author": "Daniel Gillmor", "text": "wow, april 1 comes early!
", "time": "2022-11-07T14:13:47Z"}, {"author": "Martin Thomson", "text": "am I alone in finding programming ligatures really hard to read?
", "time": "2022-11-07T14:14:32Z"}, {"author": "Christian Huitema", "text": "I am confused too. Code shall be fixed font, 80 chars per line. I did not learn how to do ligatures with punch cards.
", "time": "2022-11-07T14:17:16Z"}, {"author": "Ira McDonald", "text": "FYI - relative to CDDL difficulties - CDDL/2.0 plan in CBOR WG in session III tomorrow
", "time": "2022-11-07T14:17:17Z"}, {"author": "Martin Thomson", "text": "An event that might be useful is where the encoder might have inserted something in the table, but didn't because it couldn't write out the insertion instruction. It's related to HoLB, but is really for deadlock avoidance.
", "time": "2022-11-07T14:19:02Z"}, {"author": "Christian Huitema", "text": "Something something cultural references in slides. I don't watch TV...
", "time": "2022-11-07T14:19:27Z"}, {"author": "Jonathan Lennox", "text": "This is more did you watch TV 25 years ago, anyway
", "time": "2022-11-07T14:19:47Z"}, {"author": "Alan Frindell", "text": "The main thing you want to know is when headers are blocked on qpack.
", "time": "2022-11-07T14:19:53Z"}, {"author": "Lucas Pardue", "text": "yes that's a good example. Qlog can model things that aren't the wire protocol, that's one of its benefitr. What we want to figure out is what needs to be formally defined in the spec, or is just added as a custom event via the extensible nature of the schema
", "time": "2022-11-07T14:20:49Z"}, {"author": "Martin Thomson", "text": "The authors want more RFCs on their resumes
", "time": "2022-11-07T14:22:14Z"}, {"author": "Christian Huitema", "text": "Yeah! More RFC! Let's pack our publication records!
", "time": "2022-11-07T14:22:17Z"}, {"author": "Christian Huitema", "text": "That kind of stuff really calls for a Wiki
", "time": "2022-11-07T14:23:11Z"}, {"author": "Martin Thomson", "text": "This is silly.
", "time": "2022-11-07T14:23:23Z"}, {"author": "Martin Thomson", "text": "batch 'em up
", "time": "2022-11-07T14:23:31Z"}, {"author": "Christian Huitema", "text": "that. Batch of updates make for minor version updates of qlog.
", "time": "2022-11-07T14:23:58Z"}, {"author": "Valentin Go\u0219u", "text": "yearly RFC with qlog updates
", "time": "2022-11-07T14:24:03Z"}, {"author": "Christian Huitema", "text": "So, Wiki+yearly RFC
", "time": "2022-11-07T14:24:23Z"}, {"author": "Jonathan Lennox", "text": "Alternatively you could have a QLOG section in each QUIC extension.
", "time": "2022-11-07T14:24:31Z"}, {"author": "Martin Thomson", "text": "+1 Christian there.
", "time": "2022-11-07T14:24:42Z"}, {"author": "Martin Thomson", "text": "And yeah, you could have new extensions define their qlog bits.
", "time": "2022-11-07T14:24:59Z"}, {"author": "Lucas Pardue", "text": "we don't want to proliferate RFCs for the sake of it or resume boosting.
", "time": "2022-11-07T14:27:02Z"}, {"author": "Lucas Pardue", "text": "the feedback here is useful, thank you
", "time": "2022-11-07T14:27:26Z"}, {"author": "Randell Jesup", "text": "+1 to less RFC's / Jonathan Lennox
", "time": "2022-11-07T14:29:59Z"}, {"author": "Martin Thomson", "text": "Running AES-ECB in eBPF sounds totally reasonable to me.
", "time": "2022-11-07T14:35:40Z"}, {"author": "Lucas Pardue", "text": "topic for the eBPF bof!
", "time": "2022-11-07T14:36:03Z"}, {"author": "Martin Thomson", "text": "AES is a very common MPC target; if you can do it in MPC, doing it in the kernel is totally reasonable
", "time": "2022-11-07T14:36:18Z"}, {"author": "Alex Chernyakhovsky", "text": "I don't think eBPF will JIT an AES implementation to e.g., AES-NI. We'd probably want a special mechanism to expose platform acceleration primitives
", "time": "2022-11-07T14:39:06Z"}, {"author": "Matt Joras", "text": "it would likely be just an API exposed to eBPF programs as is already the case for other things
", "time": "2022-11-07T14:40:08Z"}, {"author": "Matt Joras", "text": "most functions aren't actually implemented as eBPF functions
", "time": "2022-11-07T14:40:21Z"}, {"author": "Alex Chernyakhovsky", "text": "Right but that's not what I interpreted @Martin Thomson to be saying, which was \"here's an AES implementation in eBPF instructions\". An aes_ecb function call would be great
", "time": "2022-11-07T14:41:04Z"}, {"author": "Martin Thomson", "text": "also, no one has EVER abused AES-ECB()
", "time": "2022-11-07T14:44:09Z"}, {"author": "Alex Chernyakhovsky", "text": ":) We might want to call it aes_encrypt to demonstrate it's the primitive if we were serious about this
", "time": "2022-11-07T14:45:01Z"}, {"author": "Martin Thomson", "text": "oh, that makes it sound far more useful than it really is
", "time": "2022-11-07T14:45:31Z"}, {"author": "Alex Chernyakhovsky", "text": "I may be over-indexing on the openssl api names because I'm used to them. Names are of course flexible
", "time": "2022-11-07T14:46:02Z"}, {"author": "Kazuho Oku", "text": "What Lucas says.
", "time": "2022-11-07T14:48:13Z"}, {"author": "Kazuho Oku", "text": "IIRC the reason we send PRIORITY_UPDATE frame on control stream is also this.
", "time": "2022-11-07T14:48:52Z"}, {"author": "Kazuho Oku", "text": "(maybe not re PRIORITY_UPDATE, but this is true for QPACK I think)
", "time": "2022-11-07T14:49:53Z"}, {"author": "Matt Joras", "text": "FWIW It wasn't Jana's idea to include app data, I suggested that on the list, though he may have adopted the idea afterward as I adopted it from Alan
", "time": "2022-11-07T14:51:37Z"}, {"author": "Matt Joras", "text": "I would really much prefer that to messing with the QUIC stream state machine
", "time": "2022-11-07T14:52:34Z"}, {"author": "Alan Frindell", "text": "QPACK's use of application level reset is slightly different -- it's to indicate when a RST_STREAM has been processed by the application at the receiver side.
", "time": "2022-11-07T14:52:37Z"}, {"author": "Kazuho Oku", "text": "I mean, the reason we do not send QPACK headers on request streams is because they might get reset?
", "time": "2022-11-07T14:55:02Z"}, {"author": "Alan Frindell", "text": "Also because they need to be ordered
", "time": "2022-11-07T14:55:29Z"}, {"author": "Marie-Jose Montpetit", "text": "Well it was the French and French Canadian mafia
", "time": "2022-11-07T14:57:20Z"}, {"author": "Alan Frindell", "text": "And I don't think you would want RELIABLE_RESET to handle delivery of QPACK data, because it could be in trailers after a large object body that you don't want to rxmit
", "time": "2022-11-07T14:57:33Z"}, {"author": "Kazuho Oku", "text": "Yeah we might have chosen to send indices explicitly, if we had reliable reset?
", "time": "2022-11-07T14:57:34Z"}, {"author": "David Schinazi", "text": "Oh sorry Matt right that was you
", "time": "2022-11-07T14:57:38Z"}, {"author": "Kazuho Oku", "text": "Yes, the trailer argument is a very good one, which also applies to Jana's suggestion of using FIN.
", "time": "2022-11-07T14:58:06Z"}, {"author": "David Schinazi", "text": "Christian we're hearing noises from you
", "time": "2022-11-07T14:58:10Z"}, {"author": "Ted Hardie", "text": "Please be careful putting words like \"patent free\" on a slide deck, especially for things like this. The lack of a disclosure is not a guarantee. There's a lot of IPR around fountain codes, and the relevant holders may simply not have seen this work.
", "time": "2022-11-07T14:59:29Z"}, {"author": "Marie-Jose Montpetit", "text": "Repetition coding is not efficient
", "time": "2022-11-07T14:59:42Z"}, {"author": "Marie-Jose Montpetit", "text": "And yes coding is a patent tripwire...
", "time": "2022-11-07T15:00:54Z"}, {"author": "Alex Chernyakhovsky", "text": "I was under the impression that FEC was much more effective on point-to-point links rather than end-to-end, since the loss patterns were dependent on the link characteristics. Why not do FEC at the link layer? (IIRC 100G ethernet does this)
", "time": "2022-11-07T15:02:06Z"}, {"author": "James Gruessing", "text": "Any FEC work in QUIC should be agile towards the coding that is used, and thus the coding scheme would need signalling and/or negotiation
", "time": "2022-11-07T15:02:50Z"}, {"author": "Christian Huitema", "text": "The noise were caused by some weirdness in Meteecho. I switched on the mike, but did not start speaking immediately. There was some kind of adaptation loop that kicked in, and the sound went bad.
", "time": "2022-11-07T15:02:51Z"}, {"author": "Christian Huitema", "text": "Dang, no remote chocolate
", "time": "2022-11-07T15:03:32Z"}]