[{"author": "Alan Frindell", "text": "I can jabber scribe<br/>", "time": "2022-03-24T13:37:35Z"}, {"author": "Alan Frindell", "text": "dang it lucas<br/>", "time": "2022-03-24T13:37:43Z"}, {"author": "lpardue", "text": "you can be note taker alan<br/>", "time": "2022-03-24T13:37:53Z"}, {"author": "Alan Frindell", "text": "that is not my forte<br/>", "time": "2022-03-24T13:38:00Z"}, {"author": "David Schinazi", "text": "Meetecho I see that I can pass slide control to folks (which is great thanks) but I can't figure out how to take it back to myself, is that possible?<br/>", "time": "2022-03-24T13:40:12Z"}, {"author": "Martin Thomson", "text": "you aren't going to get anything better from us on dates, sorry<br/>", "time": "2022-03-24T13:40:24Z"}, {"author": "Meetecho", "text": "David: at the moment this isn't possible<br/>", "time": "2022-03-24T13:40:43Z"}, {"author": "Martin Thomson", "text": "the right arrow key works<br/>", "time": "2022-03-24T13:40:57Z"}, {"author": "David Schinazi", "text": "MT do you want that said at the mic?<br/>", "time": "2022-03-24T13:40:59Z"}, {"author": "David Schinazi", "text": "(Mozilla's position not the right arrow)<br/>", "time": "2022-03-24T13:41:10Z"}, {"author": "David Schinazi", "text": "Thanks Meetecho<br/>", "time": "2022-03-24T13:41:14Z"}, {"author": "Martin Thomson", "text": "I just wanted that on the record<br/>", "time": "2022-03-24T13:41:15Z"}, {"author": "David Schinazi", "text": "Thanks MT<br/>", "time": "2022-03-24T13:41:25Z"}, {"author": "Martin Thomson", "text": "I think that we just got writable streams finalized, so we're in a reasonable shape, but a small team with shifting priorities makes it hard to commit to a date<br/>", "time": "2022-03-24T13:41:48Z"}, {"author": "Alan Frindell", "text": "is there a mechanism in the api for setting egress priority?<br/>", "time": "2022-03-24T13:43:36Z"}, {"author": "Martin Thomson", "text": "I think that we might want to talk about the priority thing some<br/>", "time": "2022-03-24T13:43:43Z"}, {"author": "Eric Kinnear", "text": "Can we just inherit HTTP priorities since we put all of this over HTTP?<br/>", "time": "2022-03-24T13:43:48Z"}, {"author": "Alan Frindell", "text": "HTTP prioritizes request streams<br/>", "time": "2022-03-24T13:44:00Z"}, {"author": "Eric Kinnear", "text": "Ah fair<br/>", "time": "2022-03-24T13:44:13Z"}, {"author": "Martin Thomson", "text": "I'm not sure about what divergence is allowed by W3C process<br/>", "time": "2022-03-24T13:45:49Z"}, {"author": "lpardue", "text": "I wrote an I-D to accomodate HTTP datagram priority signalling. If people hate it that's fine but I've not seen any other reasonable suggestion<br/>", "time": "2022-03-24T13:47:39Z"}, {"author": "Alan Frindell", "text": "mt: it shows you are still sending audio?<br/>", "time": "2022-03-24T13:48:02Z"}, {"author": "Eric Kinnear", "text": "(There are two notes.ietf.org docs titled the same, one linked from the agenda in datatracker, one was made before switching to that one)<br/>", "time": "2022-03-24T13:48:18Z"}, {"author": "lpardue", "text": "incremental and 8 levels of urgency, sounds great ;)<br/>", "time": "2022-03-24T13:49:36Z"}, {"author": "Mike Bishop", "text": "@Alan, Meetecho recommended in a previous session people with Australia-scale latency mute rather than disconnecting audio due to the cutover time.<br/>", "time": "2022-03-24T13:49:39Z"}, {"author": "Alan Frindell", "text": "fair point about sequential/incremental.<br/>", "time": "2022-03-24T13:49:42Z"}, {"author": "Martin Thomson", "text": "8 or 4 levels would be fine<br/>", "time": "2022-03-24T13:50:04Z"}, {"author": "Alan Frindell", "text": "gotcha<br/>", "time": "2022-03-24T13:50:07Z"}, {"author": "Alan Frindell", "text": "I agree that signaling priority to the peer can be punted to applications over WT, but we still need an API to control browser side egress priority, right?<br/>", "time": "2022-03-24T13:51:40Z"}, {"author": "Martin Thomson", "text": "I was using a local mute (of which I have at least three) to manage my audio during discussion; I will continue doing that to avoid the multi-second lag<br/>", "time": "2022-03-24T13:51:55Z"}, {"author": "Alan Frindell", "text": "(y)<br/>", "time": "2022-03-24T13:52:11Z"}, {"author": "Martin Thomson", "text": "yes, we need a browser API for setting a priority value<br/>", "time": "2022-03-24T13:52:14Z"}, {"author": "Jonathan Lennox", "text": "Where \"we\" means W3C in this context, yes?<br/>", "time": "2022-03-24T13:52:28Z"}, {"author": "Martin Thomson", "text": "indeed<br/>", "time": "2022-03-24T13:52:36Z"}, {"author": "Hang Shi", "text": "Brower API for setting the priority would be useful. Application need some way to control the scheduling of multiple streams/datagrams.<br/>", "time": "2022-03-24T13:53:43Z"}, {"author": "Martin Thomson", "text": "our implementation has 5 levels, just to be perverse<br/>", "time": "2022-03-24T13:53:59Z"}, {"author": "lpardue", "text": "reminder, if you'd like me to relay anything to the microphone, please prepend a message here with MIC:<br/>", "time": "2022-03-24T13:54:20Z"}, {"author": "Alan Frindell", "text": "I like having goaway semantics&nbsp;&nbsp;on sessions<br/>", "time": "2022-03-24T13:54:32Z"}, {"author": "Alan Frindell", "text": "Sue<br/>", "time": "2022-03-24T13:54:48Z"}, {"author": "Alan Frindell", "text": "ure<br/>", "time": "2022-03-24T13:54:52Z"}, {"author": "lpardue", "text": "who is sue?<br/>", "time": "2022-03-24T13:54:59Z"}, {"author": "Martin Thomson", "text": "it turned out that we needed 5 to ensure that we can interleave with control frames, but one of those is a little scary<br/>", "time": "2022-03-24T13:55:39Z"}, {"author": "Martin Thomson", "text": "that is, 5 priority levels<br/>", "time": "2022-03-24T13:55:49Z"}, {"author": "Martin Thomson", "text": "I agree with Alan<br/>", "time": "2022-03-24T13:56:52Z"}, {"author": "Eric Kinnear", "text": "Seems workable, +1<br/>", "time": "2022-03-24T13:57:29Z"}, {"author": "Alan Frindell", "text": "I have a special calendar where I mark the days that Martin agrees with me<br/>", "time": "2022-03-24T13:57:31Z"}, {"author": "David Schinazi", "text": "Ooh I need one of those<br/>", "time": "2022-03-24T13:57:48Z"}, {"author": "Mike Bishop", "text": "My initial reaction was negative, but you might need to open new WebTrans streams to finish serving a \"request,\" so I can see the rationale for having GOAWAY not apply here.<br/>", "time": "2022-03-24T13:58:22Z"}, {"author": "David Schinazi", "text": "It might not be visible on meetecho but Alan is intently staring at the ceiling right now<br/>", "time": "2022-03-24T13:58:41Z"}, {"author": "Martin Thomson", "text": "Mike: that's exactly my reasoning also<br/>", "time": "2022-03-24T13:58:49Z"}, {"author": "Martin Thomson", "text": "Mike: you might want to exercise the \"WT_GTFO\" frame at the same time as GOAWAY if that makes sense.<br/>", "time": "2022-03-24T13:59:21Z"}, {"author": "Alan Frindell", "text": "i think to be consistent with what I just said at the mic, then closing CONNECT stream should kill everrything<br/>", "time": "2022-03-24T13:59:29Z"}, {"author": "David Schinazi", "text": "WTF_GTFO<br/>", "time": "2022-03-24T13:59:55Z"}, {"author": "David Schinazi", "text": "would be a better frame name<br/>", "time": "2022-03-24T14:00:10Z"}, {"author": "Martin Thomson", "text": "Closing CONNECT as an implicit WT_GTFO seems right, though the HTTP/2 version will be somewhat more immediate and final<br/>", "time": "2022-03-24T14:00:15Z"}, {"author": "Alan Frindell", "text": "is half-close specified in the doc now?<br/>", "time": "2022-03-24T14:00:27Z"}, {"author": "Alan Frindell", "text": "eg: there is no half-close<br/>", "time": "2022-03-24T14:01:00Z"}, {"author": "Eric Kinnear", "text": "Right, you may want to kick a single WT session and all of its streams<br/>", "time": "2022-03-24T14:01:26Z"}, {"author": "Martin Thomson", "text": "there is a half-close for streams, which means interesting things for this, because the termination cannot be synchronous<br/>", "time": "2022-03-24T14:03:19Z"}, {"author": "Alan Frindell", "text": "in h3 yes<br/>", "time": "2022-03-24T14:03:46Z"}, {"author": "Martin Thomson", "text": "yes, magnus, there are races<br/>", "time": "2022-03-24T14:03:49Z"}, {"author": "Martin Thomson", "text": "the answer is \"don't do that then\"<br/>", "time": "2022-03-24T14:03:59Z"}, {"author": "David Schinazi", "text": "Lucas can I ask you to close the door of the room please?<br/>", "time": "2022-03-24T14:05:17Z"}, {"author": "lpardue", "text": "yes<br/>", "time": "2022-03-24T14:05:58Z"}, {"author": "David Schinazi", "text": "(there's something halfway between a vacuum and a hair dryer outside)<br/>", "time": "2022-03-24T14:06:30Z"}, {"author": "David Schinazi", "text": "Thanks Lucas<br/>", "time": "2022-03-24T14:06:32Z"}, {"author": "Mike Bishop", "text": "Now that permission to ask has been obtained, David will now ask Lucas to close the door.&nbsp;&nbsp;;-)<br/>", "time": "2022-03-24T14:06:34Z"}, {"author": "lpardue", "text": "yes<br/>", "time": "2022-03-24T14:06:46Z"}, {"author": "Luke Curley", "text": "aww I just woke up and missed the priority discussion<br/>", "time": "2022-03-24T14:09:05Z"}, {"author": "Martin Thomson", "text": "Luke: how many priority levels do you want?<br/>", "time": "2022-03-24T14:09:23Z"}, {"author": "Alan Frindell", "text": "I don't think you missed that much - is there a point you wanted to make?<br/>", "time": "2022-03-24T14:09:28Z"}, {"author": "Martin Thomson", "text": "4, 8, or ?<br/>", "time": "2022-03-24T14:09:30Z"}, {"author": "Magnus Westerlund", "text": "@martin: I do need to read the draft. As long as it clear enough that this is what will happen. I was thinking about this due to some interesting corner case found when working on DTLS/SCTP where we work hard to maintain the SCTP convention that a non aborted session will have have delivered the data is sent reliable even if shutdown is called direclty. So its a question of clarity on the semantics.<br/>", "time": "2022-03-24T14:09:43Z"}, {"author": "Alan Frindell", "text": "and do you want the signaling built into WT or each application<br/>", "time": "2022-03-24T14:09:51Z"}, {"author": "Victor Vasiliev", "text": "The proposal I was going to write had four billions squared levels of priorities<br/>", "time": "2022-03-24T14:10:00Z"}, {"author": "Martin Thomson", "text": "magnus, yeah, this is a very reasonable thing to have in mind, but if we don't have that SCTP guarantee, then it's a bit easier<br/>", "time": "2022-03-24T14:10:20Z"}, {"author": "Luke Curley", "text": "Warp works by prioritizing new &gt; old<br/>", "time": "2022-03-24T14:10:27Z"}, {"author": "Alan Frindell", "text": "Maybe HTTP/3 stream should read QUIC stream on this slide<br/>", "time": "2022-03-24T14:10:37Z"}, {"author": "Luke Curley", "text": "my current implementation just uses a uint64 for priority so it's super easy<br/>", "time": "2022-03-24T14:10:46Z"}, {"author": "Luke Curley", "text": "basically stream id == priority<br/>", "time": "2022-03-24T14:11:05Z"}, {"author": "Magnus Westerlund", "text": "MT: Sure, as long as the properties of the provided transport is clearly documented. <br/>", "time": "2022-03-24T14:11:06Z"}, {"author": "Martin Thomson", "text": "Luke: that is opposite to what HTTP will do generally, so enabling that might be tricky; good input<br/>", "time": "2022-03-24T14:11:14Z"}, {"author": "Martin Thomson", "text": "Magnus, yeah, I'm not sure if we are very clear just yet<br/>", "time": "2022-03-24T14:11:27Z"}, {"author": "Luke Curley", "text": "yeah, HTTP typically prioritizes older streams/requests first<br/>", "time": "2022-03-24T14:11:48Z"}, {"author": "Alan Frindell", "text": "Is that in the draft?&nbsp;&nbsp;I thought it was ambiguous<br/>", "time": "2022-03-24T14:12:06Z"}, {"author": "Martin Thomson", "text": "Alan: I think that the priorities draft says that you order responses by how they arrived<br/>", "time": "2022-03-24T14:12:36Z"}, {"author": "Martin Thomson", "text": "(by stream ID)<br/>", "time": "2022-03-24T14:12:41Z"}, {"author": "Alan Frindell", "text": "push notwithstanding<br/>", "time": "2022-03-24T14:12:52Z"}, {"author": "Martin Thomson", "text": "push is \u00af_(\u30c4)_/\u00af, as always<br/>", "time": "2022-03-24T14:13:14Z"}, {"author": "Alan Frindell", "text": "i'll go back and read it, I thought it was up to the implementation and loose guidance to do it that way<br/>", "time": "2022-03-24T14:14:00Z"}, {"author": "Martin Thomson", "text": "SETTINGS_WT_MAX_SESSIONS is pretty neat<br/>", "time": "2022-03-24T14:14:05Z"}, {"author": "Luke Curley", "text": "I'm not sure if there's explicit text, but browsers will request resources in the order they depend on them<br/>", "time": "2022-03-24T14:14:07Z"}, {"author": "Martin Thomson", "text": "Alan: yes, priority is always \"loose guidance\"<br/>", "time": "2022-03-24T14:14:17Z"}, {"author": "Luke Curley", "text": "so it's generally safer to serve requests in order<br/>", "time": "2022-03-24T14:14:27Z"}, {"author": "lpardue", "text": "priorities says the request order is an input into the scheduling. No strict requirement on FIFO or LIFO. Just a nudge that FIFO works better for the web<br/>", "time": "2022-03-24T14:14:51Z"}, {"author": "Alan Frindell", "text": "right<br/>", "time": "2022-03-24T14:15:02Z"}, {"author": "Luke Curley", "text": "yeah, and Warp wants LIFO not FIFO<br/>", "time": "2022-03-24T14:15:29Z"}, {"author": "lpardue", "text": "with pooling in H3, you might even want a different approach for webtransport streams and normal request streams<br/>", "time": "2022-03-24T14:15:40Z"}, {"author": "lpardue", "text": "in quiche, we walk a stream iterator. The first version of that did LIFO by accident. To fix it we just reversed the iterator<br/>", "time": "2022-03-24T14:16:18Z"}, {"author": "Luke Curley", "text": "Warp also has a control stream with priority = maxint64<br/>", "time": "2022-03-24T14:16:31Z"}, {"author": "Mike Bishop", "text": "Though note that H3 doesn't allow you to change that value after the connection is established.<br/>", "time": "2022-03-24T14:16:33Z"}, {"author": "Luke Curley", "text": "so media won't delay control messages<br/>", "time": "2022-03-24T14:16:50Z"}, {"author": "Martin Thomson", "text": "would it be a MAX_STREAMS capsule or something else?<br/>", "time": "2022-03-24T14:16:55Z"}, {"author": "Alan Frindell", "text": "yeah he said capsuile<br/>", "time": "2022-03-24T14:17:03Z"}, {"author": "Jonathan Lennox", "text": "For a MOQ scenario I can certainly imagine wanting to say \"this frame is now stale, de-prioritize it\"<br/>", "time": "2022-03-24T14:17:19Z"}, {"author": "Alan Frindell", "text": "note i think for h2 it already had those<br/>", "time": "2022-03-24T14:17:28Z"}, {"author": "Martin Thomson", "text": "I guess that you need to have it be an absolute number, because you can't make it a MAX_WT_STREAM_ID<br/>", "time": "2022-03-24T14:17:29Z"}, {"author": "Jonathan Lennox", "text": "That makes the API a lot more complicated tho<br/>", "time": "2022-03-24T14:17:34Z"}, {"author": "Will Law", "text": "WT_MAX_DATA does not include datagram bytes?<br/>", "time": "2022-03-24T14:18:17Z"}, {"author": "lpardue", "text": "no flow control on datagrams<br/>", "time": "2022-03-24T14:18:32Z"}, {"author": "Martin Thomson", "text": "jonathan, it's a constraint, but it doesn't necessarily mean that the API is worse; using it is harder though<br/>", "time": "2022-03-24T14:18:35Z"}, {"author": "Alan Frindell", "text": "correct<br/>", "time": "2022-03-24T14:18:37Z"}, {"author": "David Schinazi", "text": "Datagram bytes can't really be flow controlled because they're not retransmitted so you can't keep both endpoints in sync<br/>", "time": "2022-03-24T14:18:48Z"}, {"author": "lpardue", "text": "layers are a myth<br/>", "time": "2022-03-24T14:19:26Z"}, {"author": "Martin Thomson", "text": "Marten is right; this is really tricky<br/>", "time": "2022-03-24T14:19:31Z"}, {"author": "Martin Thomson", "text": "I can see a limit on streams as feasible<br/>", "time": "2022-03-24T14:19:46Z"}, {"author": "Alan Frindell", "text": "my intuition is the same as Davids<br/>", "time": "2022-03-24T14:20:15Z"}, {"author": "Jan-Ivar Bruaroey", "text": "more streams != more data<br/>", "time": "2022-03-24T14:24:04Z"}, {"author": "Jan-Ivar Bruaroey", "text": "E.g. when sending N bytes, it seems entirely up to the application to use between 1 and N streams<br/>", "time": "2022-03-24T14:24:38Z"}, {"author": "Martin Thomson", "text": "enforcing MAX_WT_STREAMS might be a little tricky to work out<br/>", "time": "2022-03-24T14:26:50Z"}, {"author": "Martin Thomson", "text": "and for the problem where a session eats all the data (which is easy to arrange, by the way), that's something we can address with timeouts and the like in the extreme; we'll need to think about what we can do<br/>", "time": "2022-03-24T14:27:43Z"}, {"author": "Alan Frindell", "text": "i think it's worth spending some more time exploring, not sure it's possible<br/>", "time": "2022-03-24T14:28:25Z"}, {"author": "Martin Thomson", "text": "+1 to David's suggestion<br/>", "time": "2022-03-24T14:28:33Z"}, {"author": "Martin Thomson", "text": "do we *have* to solve it?&nbsp;&nbsp;no.<br/>", "time": "2022-03-24T14:29:33Z"}, {"author": "Eric Kinnear", "text": "Let's do this without MAX_DATA for now, and we can revisit as we get the rest of it working (or not)<br/>", "time": "2022-03-24T14:30:10Z"}, {"author": "lpardue", "text": "no worry, we have&nbsp;&nbsp;infinite time to fix our past mistakes<br/>", "time": "2022-03-24T14:30:26Z"}, {"author": "Martin Thomson", "text": "yeah, I suspect Alan's prediction will come true...&nbsp;&nbsp;I'm just not interested in grappling with it<br/>", "time": "2022-03-24T14:30:35Z"}, {"author": "Martin Thomson", "text": "implementation-level strategies for managing resource sharing with pooling might still be possible, without standardization of any mechanisms<br/>", "time": "2022-03-24T14:31:00Z"}, {"author": "lpardue", "text": "what frames *are* flow controlled? DATA and ..<br/>", "time": "2022-03-24T14:32:16Z"}, {"author": "Alan Frindell", "text": "hopefully i'm just not the one doing the debugging, because future Alan will be angry with past Alan<br/>", "time": "2022-03-24T14:32:21Z"}, {"author": "Martin Thomson", "text": "WT_MAX_STREAMS<br/>", "time": "2022-03-24T14:32:25Z"}, {"author": "Martin Thomson", "text": "anything that opens a stream can't be sent, but a lot of the housekeeping stuff is possible<br/>", "time": "2022-03-24T14:32:51Z"}, {"author": "Martin Thomson", "text": "Alan: that's a constant, you're just tweaking the magnitude<br/>", "time": "2022-03-24T14:33:14Z"}, {"author": "Martin Thomson", "text": "s/constant/given<br/>", "time": "2022-03-24T14:33:23Z"}, {"author": "Alan Frindell", "text": "a given that I'll be upset with myself?&nbsp;&nbsp;or that I'm doing the debugging<br/>", "time": "2022-03-24T14:33:55Z"}, {"author": "Martin Thomson", "text": "plenty of reasons to be angry at my previous self, I can't imagine anyone else is different<br/>", "time": "2022-03-24T14:34:27Z"}, {"author": "Alan Frindell", "text": "be gentle with yourself martin.&nbsp;&nbsp;We're all doing our best<br/>", "time": "2022-03-24T14:35:21Z"}, {"author": "Martin Thomson", "text": "do any of the other frames have lengths?<br/>", "time": "2022-03-24T14:35:23Z"}, {"author": "Martin Thomson", "text": "Alan: yeah, it's 1:35am and the fourth day in a row, hard to see past that :|<br/>", "time": "2022-03-24T14:35:48Z"}, {"author": "Alan Frindell", "text": "so these would be like datagram capsules, where intermediaries can convert to native concepts where supported<br/>", "time": "2022-03-24T14:38:06Z"}, {"author": "Victor Vasiliev", "text": "Does H2 draft currently define CLOSE_WEBTRANSPORT_SESSION?<br/>", "time": "2022-03-24T14:41:42Z"}, {"author": "Martin Thomson", "text": "Victor: not yet<br/>", "time": "2022-03-24T14:42:58Z"}, {"author": "Martin Thomson", "text": "it's an open issue<br/>", "time": "2022-03-24T14:43:01Z"}, {"author": "Eric Kinnear", "text": "Yeah, need to write some text, but can make it look like whatever we do for H3<br/>", "time": "2022-03-24T14:43:35Z"}, {"author": "Martin Thomson", "text": "WT_CONNECTION_CLOSE might be the shape that takes :p<br/>", "time": "2022-03-24T14:43:47Z"}, {"author": "lpardue", "text": "isn't that the defnition of an HTTP intermediary? :)<br/>", "time": "2022-03-24T14:44:45Z"}, {"author": "Martin Thomson", "text": "David is doing a good job of framing my thinking.&nbsp;&nbsp;I think that this comes back to ekr's comments in the design team: if you have an intermediary, it needs to intermediate WebTransport...<br/>", "time": "2022-03-24T14:45:04Z"}, {"author": "Martin Thomson", "text": "it's not a generic intermediatry<br/>", "time": "2022-03-24T14:45:17Z"}, {"author": "lpardue", "text": "that problem exists for H2 to H2 intermediation<br/>", "time": "2022-03-24T14:46:35Z"}, {"author": "Eric Kinnear", "text": "And we're not keeping everything in the stream for H3<br/>", "time": "2022-03-24T14:48:09Z"}, {"author": "Martin Thomson", "text": "one model I had for this that works is where you only opportunistically lift things out of the stream<br/>", "time": "2022-03-24T14:49:17Z"}, {"author": "Mike Bishop", "text": "@Martin, I like that model a lot.&nbsp;&nbsp;Everything *can* be a capsule, but particular protocols might define a \"better\" way to carry that particular capsule type.<br/>", "time": "2022-03-24T14:50:17Z"}, {"author": "Martin Thomson", "text": "the performance guarantees are ... not great<br/>", "time": "2022-03-24T14:51:10Z"}, {"author": "Eric Kinnear", "text": "(Which, to be fair, is really agreeing with Martin here)<br/>", "time": "2022-03-24T14:52:18Z"}, {"author": "Eric Kinnear", "text": ":) <br/>", "time": "2022-03-24T14:52:24Z"}, {"author": "Martin Thomson", "text": "I forgot, we added lengths<br/>", "time": "2022-03-24T14:52:49Z"}, {"author": "lpardue", "text": "QUIC SMASH<br/>", "time": "2022-03-24T14:53:21Z"}, {"author": "Alan Frindell", "text": "When it was LTV is was a little nicer for QUIC parser re-use :P<br/>", "time": "2022-03-24T14:53:37Z"}, {"author": "Eric Kinnear", "text": "Heh, that ship has sailed I think<br/>", "time": "2022-03-24T14:53:49Z"}, {"author": "Alan Frindell", "text": "even if you have h3 on both sides of a webtransport proxy, you can still have the stream mismatch problem.<br/>", "time": "2022-03-24T14:54:52Z"}, {"author": "lpardue", "text": "exactly<br/>", "time": "2022-03-24T14:55:07Z"}, {"author": "Martin Thomson", "text": "and that was incoherent, sorry<br/>", "time": "2022-03-24T14:55:07Z"}, {"author": "Martin Thomson", "text": "so, so, tired<br/>", "time": "2022-03-24T14:55:13Z"}, {"author": "Eric Kinnear", "text": "Victor: Any thoughts? How are capsules feeling in H3?<br/>", "time": "2022-03-24T14:57:18Z"}, {"author": "Martin Thomson", "text": "we talked about this idea of a baseline protocol before and rejected it.&nbsp;&nbsp;i don't remember why<br/>", "time": "2022-03-24T14:57:48Z"}, {"author": "Martin Thomson", "text": "I'd be happy to join a call<br/>", "time": "2022-03-24T14:58:11Z"}, {"author": "Eric Kinnear", "text": "Same re: remembering why<br/>", "time": "2022-03-24T14:58:49Z"}, {"author": "Eric Kinnear", "text": "+1, thanks Martin<br/>", "time": "2022-03-24T14:59:01Z"}, {"author": "Alan Frindell", "text": "kinda sounds like a design team<br/>", "time": "2022-03-24T14:59:02Z"}, {"author": "Victor Vasiliev", "text": "Capsules have been convenient in h3<br/>", "time": "2022-03-24T14:59:04Z"}, {"author": "Eric Kinnear", "text": "Design team sounds good<br/>", "time": "2022-03-24T14:59:20Z"}, {"author": "Martin Thomson", "text": "I think we rejected a baseline protocol because we wouldn't be able to guarantee performance properties of various pieces<br/>", "time": "2022-03-24T14:59:44Z"}, {"author": "Eric Kinnear", "text": "(Which it sounds like is a problem either way, so far)<br/>", "time": "2022-03-24T15:00:04Z"}, {"author": "Martin Thomson", "text": "right, but requireUnreliable might not produce a guarantee as much as originally thought<br/>", "time": "2022-03-24T15:00:50Z"}, {"author": "Martin Thomson", "text": "wow, that queue filled fast<br/>", "time": "2022-03-24T15:01:50Z"}, {"author": "Eric Kinnear", "text": "Would that be a \"sending strategy\" sort of thing to add to HTTP priorities land?<br/>", "time": "2022-03-24T15:02:03Z"}, {"author": "Martin Thomson", "text": "Alan's suggestion is what I was going to say also: you might not even need to have that signal sent<br/>", "time": "2022-03-24T15:03:04Z"}, {"author": "lpardue", "text": "as MT used to tell me when I was young, don't conflate per-request(stream) signalling with prioritization<br/>", "time": "2022-03-24T15:03:25Z"}, {"author": "Martin Thomson", "text": "Eric: the challenge is that we need to be able to tell the *browser* what to do, and I suspect that that is Luke's challenge here<br/>", "time": "2022-03-24T15:03:40Z"}, {"author": "Eric Kinnear", "text": "So far every time we've looked at sending strategies it's been something that we didn't really need the client to signal since it was already obvious to the server anyways<br/>", "time": "2022-03-24T15:03:56Z"}, {"author": "Eric Kinnear", "text": "Yeah, makes sense :) <br/>", "time": "2022-03-24T15:04:07Z"}, {"author": "Victor Vasiliev", "text": "<a href=\"https://github.com/w3c/webtransport/issues/62\" rel=\"nofollow\">https://github.com/w3c/webtransport/issues/62</a><br/>", "time": "2022-03-24T15:06:24Z"}, {"author": "Luke Curley", "text": "yeah, I think prioritization can be signaled at the application level<br/>", "time": "2022-03-24T15:07:20Z"}, {"author": "Luke Curley", "text": "but it could be at the transport too<br/>", "time": "2022-03-24T15:07:48Z"}, {"author": "Martin Thomson", "text": "yeah, I don't think that we're doing transport-level priority signaling<br/>", "time": "2022-03-24T15:08:19Z"}, {"author": "Martin Thomson", "text": "we tried that once.&nbsp;&nbsp;it kinda didn't work out as well as we had hoped<br/>", "time": "2022-03-24T15:08:34Z"}, {"author": "Martin Thomson", "text": "+1 to lucas here<br/>", "time": "2022-03-24T15:09:58Z"}, {"author": "Martin Thomson", "text": "I'm just concerned that we might need rules about priority tweaks at the browser end<br/>", "time": "2022-03-24T15:10:27Z"}, {"author": "Martin Thomson", "text": "thankfully, we don't need to design the prioritization scheme :)<br/>", "time": "2022-03-24T15:11:30Z"}, {"author": "lpardue", "text": "I agree on the browser side and that's one area I am less certain how to address. MT if we say little now, does it prevent future browserland-innovation <br/>", "time": "2022-03-24T15:11:35Z"}, {"author": "Martin Thomson", "text": "lucas: probably not so much<br/>", "time": "2022-03-24T15:12:00Z"}, {"author": "Martin Thomson", "text": "one thing web sites can do is just hold application data back so that they never engage browser-level prioritization; at a cost of not always keeping the stack saturated (which might be suboptimal)<br/>", "time": "2022-03-24T15:12:42Z"}, {"author": "lpardue", "text": "reminder, Cloudflare support discretionary priority boundaries in a single resource for H2. It's set upfront, it's dynamic but not interactive<br/>", "time": "2022-03-24T15:15:55Z"}, {"author": "lpardue", "text": "congestion control control and priority optimization = C3PO<br/>", "time": "2022-03-24T15:18:38Z"}, {"author": "Alan Frindell", "text": "lucas: does that mean you the server will serve the resource at different priorities as its served?<br/>", "time": "2022-03-24T15:18:53Z"}, {"author": "Luke Curley", "text": "+1 to GCC in QUIC<br/>", "time": "2022-03-24T15:19:45Z"}, {"author": "lpardue", "text": "alan: yes, see cf-priority-change header towards the bottom of <a href=\"https://blog.cloudflare.com/parallel-streaming-of-progressive-images/\" rel=\"nofollow\">https://blog.cloudflare.com/parallel-streaming-of-progressive-images/</a><br/>", "time": "2022-03-24T15:20:03Z"}, {"author": "Alan Frindell", "text": "ok yeah, figured it was a progressive jpeg thing, thanks<br/>", "time": "2022-03-24T15:20:24Z"}, {"author": "lpardue", "text": "the notion of a \"priority change<br/>", "time": "2022-03-24T15:20:36Z"}, {"author": "Will Law", "text": "@lpardue - Remote Reliability Datagram Delay = R2D2<br/>", "time": "2022-03-24T15:20:46Z"}, {"author": "lpardue", "text": "\" could be more standardized to work in other domians, like temporal<br/>", "time": "2022-03-24T15:20:56Z"}, {"author": "Victor Vasiliev", "text": "We did have a version of GoogCC in QUIC at some point<br/>", "time": "2022-03-24T15:21:00Z"}, {"author": "lpardue", "text": "lol Will<br/>", "time": "2022-03-24T15:21:15Z"}, {"author": "Stefan Holmer", "text": "I think when it comes to RTC the congestion control problem is pretty far from solved, and I believe most applications still iterate a lot on this. So being able to have more possibilities to experiment and improve over time would be highly useful<br/>", "time": "2022-03-24T15:21:25Z"}, {"author": "Luke Curley", "text": "@victor doesn't GCC depend on a RTT estimate per packet?<br/>", "time": "2022-03-24T15:21:37Z"}, {"author": "Francesca Palombini", "text": "thank you to the chairs as well!<br/>", "time": "2022-03-24T15:21:45Z"}, {"author": "Luke Curley", "text": "are QUIC ACKS adequate?<br/>", "time": "2022-03-24T15:22:00Z"}, {"author": "Stefan Holmer", "text": "quic acks with receive timestamps are enough<br/>", "time": "2022-03-24T15:22:13Z"}, {"author": "Jonathan Lennox", "text": "Yeah, this is why receive timestamps were suggested I think<br/>", "time": "2022-03-24T15:22:25Z"}, {"author": "Victor Vasiliev", "text": "We have an extension for timestamps<br/>", "time": "2022-03-24T15:22:29Z"}, {"author": "Luke Curley", "text": "I think it depends on the ACK batch size<br/>", "time": "2022-03-24T15:22:42Z"}]