(original) (raw)
[{"author": "Lucas Pardue", "text": "
@fluffy: https://mailarchive.ietf.org/arch/msg/quic/QNXXJEDT9r32h1SUHay2G2jTukY/
", "time": "2024-03-19T07:32:09Z"}, {"author": "Jonathan Lennox", "text": "
I assume the mention of Google Meet on the previous slide is a remnant from the interim
", "time": "2024-03-19T07:32:33Z"}, {"author": "Ted Hardie", "text": "
Yeah, sorry, we'll clean that up.
", "time": "2024-03-19T07:34:38Z"}, {"author": "Kirill Pugin", "text": "
clarification question: Was it intentional for receiver to get all qualities? low def, mid def and high def?
", "time": "2024-03-19T07:44:09Z"}, {"author": "Alan Frindell", "text": "
When you say \"get scheduled\" - you mean the quic stack sent those before the losses were detected?
", "time": "2024-03-19T07:44:10Z"}, {"author": "Matt Joras", "text": "
Note that RFC 9000 already has language around the QUIC impl prioritizing retransmissions:
\n
\n
Endpoints SHOULD prioritize retransmission of data over sending new data, unless priorities specified by the application indicate otherwise;
\n
", "time": "2024-03-19T07:47:22Z"}, {"author": "Alan Frindell", "text": "
I'm curious about the details around when the reset decision is made
", "time": "2024-03-19T07:47:28Z"}, {"author": "Matt Joras", "text": "
https://www.rfc-editor.org/rfc/rfc9000.html#section-13.3-4
", "time": "2024-03-19T07:47:39Z"}, {"author": "Victor Vasiliev", "text": "
it's not a question
", "time": "2024-03-19T07:48:48Z"}, {"author": "Ian Swett", "text": "
Yes, but it's nice to have deployment experience to prove that, so thank you Suhas.
", "time": "2024-03-19T07:48:57Z"}, {"author": "Jana Iyengar", "text": "
Thanks, Matt -- I was going to copy that same language here. This is a bug in the stack, @suhas
", "time": "2024-03-19T07:49:32Z"}, {"author": "Ted Hardie", "text": "
Hi Victor, comment, then.
", "time": "2024-03-19T07:49:52Z"}, {"author": "Suhas Nandakumar", "text": "
thanks Ian .. we were able to learn more as we put it out to test .. It helps better understand the proposals.
", "time": "2024-03-19T07:50:08Z"}, {"author": "Will Law", "text": "
Are we allowed to go over today since this is the last scheduled meeting? We have a good audience, good material, it seems a squandered opportunity to not advance moq by taking advantage of that.
", "time": "2024-03-19T07:50:09Z"}, {"author": "Randell Jesup", "text": "
@suhas - was this an issue with which retransmits occur first, or whether retransmits are prioritized over new data (the item in the spec quote)?
", "time": "2024-03-19T07:51:18Z"}, {"author": "Victor Vasiliev", "text": "
@Suhas please leave a comment on https://github.com/w3c/webtransport/issues/523 before I actually write a PR and we end up putting something that does not work
", "time": "2024-03-19T07:51:25Z"}, {"author": "Christian Huitema", "text": "
The scheduling is done by Picoquic. There are multiple streams. When Picoquic can send, based on CC, it picks the next stream frame from the highest priority stream.
", "time": "2024-03-19T07:51:38Z"}, {"author": "Luke Curley", "text": "
do you prioritize retransmissions over new data?
", "time": "2024-03-19T07:52:40Z"}, {"author": "Suhas Nandakumar", "text": "
@victor.. will do
", "time": "2024-03-19T07:53:07Z"}, {"author": "Christian Huitema", "text": "
Retransmit is done at the same priority as the original stream. SO if we have seen packet losses on both a low def high priority stream and a high def low priority, the order will be: retransmit of high priority stream, then new data on high priority stream, then retransmit for low priority stream, then new data for low priority
", "time": "2024-03-19T07:53:27Z"}, {"author": "Luke Curley", "text": "
cool, yeah I think that is better but you do risk running out of flow control
", "time": "2024-03-19T07:54:06Z"}, {"author": "Ian Swett", "text": "
SUBSCRIBE/FETCH PR for those who are interested: https://github.com/moq-wg/moq-transport/pull/421
", "time": "2024-03-19T07:55:22Z"}, {"author": "Ian Swett", "text": "
Thanks Ali, one thought is that anytime the probe is smaller than the BDP, you're unlikely to observe the full bandwidth. That may be a cause of underestimation.
", "time": "2024-03-19T08:01:29Z"}, {"author": "Christian Huitema", "text": "
The priority scheduling is really a control problem. The sender is trying to send just what the network can carry, and to do that based on stream priorities. The sending rate is controlled by measurement of the capacity using the CC algorithm. By nature, this is a control loop with delay, because it takes some time for CC to detect the changes in network condition. So we have all the classic issue of control loop with delay. The first priority is to reduce the delay as much as we can, and then to do something efficient if the previous decisions were wrong.
", "time": "2024-03-19T08:02:00Z"}, {"author": "Ali Begen", "text": "
Yes indeed, Ian, but then we don't want to oversubscribe the channel, either so we are being really careful about the size
", "time": "2024-03-19T08:02:35Z"}, {"author": "Kirill Pugin", "text": "
bw, slides are not showing up on meetecho :/
", "time": "2024-03-19T08:04:21Z"}, {"author": "Alan Frindell", "text": "
I can see them on my client
", "time": "2024-03-19T08:04:38Z"}, {"author": "Ali Begen", "text": "
I can see them Kirill
", "time": "2024-03-19T08:04:39Z"}, {"author": "Suhas Nandakumar", "text": "
@kiril .. they did show up . but with a small delay
", "time": "2024-03-19T08:04:45Z"}, {"author": "Ted Hardie", "text": "
They are in day one, if you are looking for them in the datatracker.
", "time": "2024-03-19T08:04:55Z"}, {"author": "Kirill Pugin", "text": "
I don't see them and I even reconnected...
", "time": "2024-03-19T08:05:04Z"}, {"author": "Suhas Nandakumar", "text": "
@ali .. may be a PROBE message be more useful ? But i agree with Ian's concern on overshooting or undershooting and define a error flow as well ?
", "time": "2024-03-19T08:06:55Z"}, {"author": "Jana Iyengar", "text": "
Just a thought: The question of receiver or sender based CC is as old as the hills. The receiver is in the best place to observe receive_rate, which is ground truth as to what the receiver can get. That said, the sender is in the best place to know what it sent, which makes it the right side to know how to filter any measurements it makes of the network. On either side, you have to compensate for something. That said, the sender has to make decisions about what to send and when to send (consider pacing, for instance), so it has to have intelligence to figure that out. The client can help, but the sender is the one acting. This applies to any kind of congestion response, including scheduling and priorities.
", "time": "2024-03-19T08:08:00Z"}, {"author": "Jonathan Lennox", "text": "
Warp speed!
", "time": "2024-03-19T08:09:16Z"}, {"author": "Matt Joras", "text": "
@Jana Iyengar yeah there's a lot of nuance in the receiver side CCA situation. Especially when your receiver is e.g. a mobile phone where there's all sorts of funny things that can happen, e.g. with clocks, the batching of the radio, etc. etc.
\n
Our experience is that if you measure bandwidth at the sender/server, you end up with more accurate results than trying to do it on a mobile client.
", "time": "2024-03-19T08:10:30Z"}, {"author": "Kirill Pugin", "text": "
@Will, is timeline a separate track?
", "time": "2024-03-19T08:13:44Z"}, {"author": "Jonathan Lennox", "text": "
Suggestion: JSON streaming (RFC 7464)
", "time": "2024-03-19T08:14:34Z"}, {"author": "Kirill Pugin", "text": "
Do I need to receive timeline from the beginning of time or I can start getting it from subscribtion point?
", "time": "2024-03-19T08:14:38Z"}, {"author": "Luke Curley", "text": "
@kirill yeah, and it's optional to fetch
", "time": "2024-03-19T08:14:56Z"}, {"author": "Luke Curley", "text": "
really only needed for DVR
", "time": "2024-03-19T08:15:01Z"}, {"author": "Ali Begen", "text": "
@Jana, I guess you are going for a client-assisted sender-side ABR and I am cheering for the opposite: sender-assisted client-side ABR. Frankly, I see more advantages to the client-side ABR and all the testing we have done showed that.
", "time": "2024-03-19T08:15:18Z"}, {"author": "Kirill Pugin", "text": "
@Ali, fwiw, we've seen good results from Server based BW estimation
", "time": "2024-03-19T08:16:14Z"}, {"author": "Will Law", "text": "
@Kiril - yes. It may in fact be 2 tracks - one which always returns a complete update at each group, another which only issues delta updates. A player could subscribe to the complete track at the start (or when it needs to seek) and then unsubscribe from that and subscribe to the delta update variant.
", "time": "2024-03-19T08:16:16Z"}, {"author": "Ali Begen", "text": "
@matt, what you wrote above are just a few reasons to do client-side measurement (the receiving rate not the sender rate)
", "time": "2024-03-19T08:16:33Z"}, {"author": "Ali Begen", "text": "
that is what counts for the client
", "time": "2024-03-19T08:16:40Z"}, {"author": "Ali Begen", "text": "
@kirill, hence the ask for letting the client know what the sender knows.
", "time": "2024-03-19T08:17:31Z"}, {"author": "Ali Begen", "text": "
the client makes decisions based on many things not just the bw.
", "time": "2024-03-19T08:17:47Z"}, {"author": "Matt Joras", "text": "
Our experience is the opposite. Our VOD clients (including ULL) do measure bandwidth but the bandwidth measurements are much more problematic than when you shift that BWE to primarily derived from the server side.
", "time": "2024-03-19T08:17:57Z"}, {"author": "Jonathan Lennox", "text": "
GCM-SST!
", "time": "2024-03-19T08🔞04Z"}, {"author": "Matt Joras", "text": "
Kiril is speaking of the same fwiw.
", "time": "2024-03-19T08🔞13Z"}, {"author": "Ali Begen", "text": "
Sending rate is less relevant when you have the receiving rate.
", "time": "2024-03-19T08:19:29Z"}, {"author": "Ali Begen", "text": "
on top of that there are other factors that will affect the ABR beyond BW
", "time": "2024-03-19T08:19:54Z"}, {"author": "Matt Joras", "text": "
my point is that the receiving rate is difficult to measure and very noisy, so much so that it can cause pathologies when trying to tie it to a requested bitrate
\n
and yes of course ABR isn't just strictly related to BWE.
", "time": "2024-03-19T08:20:17Z"}, {"author": "Ali Begen", "text": "
so making decisions on the client-side rather than the server side makes more sense.- at least to me.
", "time": "2024-03-19T08:20:27Z"}, {"author": "Matt Joras", "text": "
I think having the client making the decisions is fine, it's how we do it. That said, I don't think that BWE is inherently better to do at the client and we have experience that suggests doing so is not as reliable as deriving those BWE from the sender (in this case a server host)
", "time": "2024-03-19T08:22:12Z"}, {"author": "Luke Curley", "text": "
it's the wrong data though, playback is blocked on the older group
", "time": "2024-03-19T08:23:44Z"}, {"author": "Ali Begen", "text": "
if the client is going to make the decisions (seems like an agreement), the discussion is now whether we should have a \"server-driven\" or \"server-assisted\" method :)
", "time": "2024-03-19T08:23:58Z"}, {"author": "Luke Curley", "text": "
I filed #419
", "time": "2024-03-19T08:25:13Z"}, {"author": "Luke Curley", "text": "
and attempted to describe how to use FETCH+SUBSCRIBE with this PR
", "time": "2024-03-19T08:25:27Z"}, {"author": "Jana Iyengar", "text": "
Where is MOQ moving to wit?
", "time": "2024-03-19T08:27:46Z"}, {"author": "Luke Curley", "text": "
thanks Ted, you've been amazing
", "time": "2024-03-19T08:28:12Z"}, {"author": "Ali Begen", "text": "
👏
", "time": "2024-03-19T08:28:36Z"}, {"author": "Will Law", "text": "
Obrigado Ted!
", "time": "2024-03-19T08:28:49Z"}, {"author": "Brian Trammell", "text": "
👏
", "time": "2024-03-19T08:28:49Z"}, {"author": "Mike English", "text": "
Thank you!
", "time": "2024-03-19T08:29:21Z"}]