[{"author": "Christian Huitema", "text": "

Good evening everybody!

", "time": "2024-03-18T03:04:51Z"}, {"author": "Luke Curley", "text": "

the newborn is crying atm

", "time": "2024-03-18T03:06:24Z"}, {"author": "Luke Curley", "text": "

feels bad

", "time": "2024-03-18T03:06:46Z"}, {"author": "Ali Begen", "text": "

good luck, Luke

", "time": "2024-03-18T03:07:06Z"}, {"author": "Spencer Dawkins", "text": "

Luke, I spent my afternoon at a first birthday party for a friend's daughter. It gets better. Please tell the newborn that. :wink:

", "time": "2024-03-18T03:08:39Z"}, {"author": "Zaheduzzaman Sarker", "text": "

notified to fix the mic

", "time": "2024-03-18T03:10:08Z"}, {"author": "Christian Huitema", "text": "

Last is the one just before current in the picture, but it may be way before if something prevented complete reception of the groups in between.

", "time": "2024-03-18T03:12:38Z"}, {"author": "Victor Vasiliev", "text": "

We may solve some form of this with \"NACK objects\"

", "time": "2024-03-18T03:23:18Z"}, {"author": "Chris Lemmons", "text": "

Youngest IETF attendee's opinions are always welcome. :)

", "time": "2024-03-18T03:24:18Z"}, {"author": "Luke Curley", "text": "

yeah, I'd like GROUP_DROPPED in both FETCH/SUBSCRIBE

", "time": "2024-03-18T03:24:36Z"}, {"author": "Luke Curley", "text": "

or similar

", "time": "2024-03-18T03:24:42Z"}, {"author": "Kirill Pugin", "text": "

Dropped where?

", "time": "2024-03-18T03:25:01Z"}, {"author": "Luke Curley", "text": "

or RELIABLE_RESET_STREAM after the object header...

", "time": "2024-03-18T03:25:02Z"}, {"author": "Ted Hardie", "text": "

Note that this means a simple design with a single group for the track cannot meet that requirement.

", "time": "2024-03-18T03:25:10Z"}, {"author": "Suhas Nandakumar", "text": "

what dp you mean by Group dropped?

", "time": "2024-03-18T03:25:16Z"}, {"author": "Peter Thatcher", "text": "

I like that idea of something like that
\n if it comes all the way from the publisher. But should it be \"you will not get X\" or should it be \"you should have gotten A-Z. If you didn't something is missing\"? Or do we just assume there are no gaps in object IDs and group IDs?

", "time": "2024-03-18T03:25:56Z"}, {"author": "Luke Curley", "text": "

@kirill publisher decides, could be due to a TTL expiring due to massive congestion

", "time": "2024-03-18T03:26:13Z"}, {"author": "Luke Curley", "text": "

relay would propagate, potentially retry in the future if it's 404 vs 409

", "time": "2024-03-18T03:26:37Z"}, {"author": "Suhas Nandakumar", "text": "

Groups are not sequential always .. Using it for gap detection is error prone ..

", "time": "2024-03-18T03:26:39Z"}, {"author": "Jonathan Lennox", "text": "

If that's any kind of bandwidth limitation upstream of the relay there will be things you don't get.

", "time": "2024-03-18T03:26:48Z"}, {"author": "Luke Curley", "text": "

yeah, assume a mobile phone only has RAM for a few seconds of buffer, SOMETHING will be permanently dropped

", "time": "2024-03-18T03:27:14Z"}, {"author": "Kirill Pugin", "text": "

Knowing that something has never been sent by publisher and not going to be is useful, agree

", "time": "2024-03-18T03:27:25Z"}, {"author": "Martin Duke", "text": "

I like this but I am going to have to change so much code

", "time": "2024-03-18T03:27:51Z"}, {"author": "Luke Curley", "text": "

yeah, right now groups only have two states: Unknown or Received

", "time": "2024-03-18T03:27:52Z"}, {"author": "Suhas Nandakumar", "text": "

things can be dropped in transit too

", "time": "2024-03-18T03:27:53Z"}, {"author": "Luke Curley", "text": "

I'd like to add a Missing/Dropped state

", "time": "2024-03-18T03:28:22Z"}, {"author": "Jonathan Lennox", "text": "

But you want to make sure you don't use up a whole lot of bandwidth saying you've dropped things to save bandwidth.

", "time": "2024-03-18T03:28:25Z"}, {"author": "Suhas Nandakumar", "text": "

in original quicr, we used marker groups t indicate if there was an intentional drop

", "time": "2024-03-18T03:28:26Z"}, {"author": "Jonathan Lennox", "text": "

Audio objects could be similar in size to the drop message.

", "time": "2024-03-18T03:28:58Z"}, {"author": "Ali Begen", "text": "

Why not use a masking field like we do in some RTP payload headers?

", "time": "2024-03-18T03:29:36Z"}, {"author": "Luke Curley", "text": "

@jonathan something like NACK with ranges if you really want to optimize

", "time": "2024-03-18T03:29:38Z"}, {"author": "Alan Frindell", "text": "

Maybe Victor's idea from the interim is a nice optimization here - SUBSCRIBE_AND_FETCH, where you get a FETCH up to the live head and subscribe starting from there?

", "time": "2024-03-18T03:30:24Z"}, {"author": "Peter Thatcher", "text": "

If they are sent in a reliable stream, QUIC can do a pretty good job of piggy backing the bits other streams if there are any.

", "time": "2024-03-18T03:30:43Z"}, {"author": "Peter Thatcher", "text": "

But the reliability is only hop-by-hop. If the relay gets an \"object NACK\" form the publisher, what does it forward? I guess it could indicate where it was dropped, by the publisher or by the relay.

", "time": "2024-03-18T03:31:49Z"}, {"author": "Ted Hardie", "text": "

Please remember to say your name when you reach the mic

", "time": "2024-03-18T03:32:19Z"}, {"author": "Victor Vasiliev", "text": "

I believe the main value of \"object NACK\" is that it is fully propagated downstream

", "time": "2024-03-18T03:32:44Z"}, {"author": "Christian Huitema", "text": "

PEEK

", "time": "2024-03-18T03:33:49Z"}, {"author": "Ted Hardie", "text": "

Note as well that we may have media that is not inherently serial (like the 3d media where the adjacent blocks are the likely targets of next selectioins). So we should check our design against that style of media to make sure it still works. I think those end up being Fetch-heavy but still work.

", "time": "2024-03-18T03:35:19Z"}, {"author": "Christian Huitema", "text": "

I mean, what Martin describe is something like the classic \"peek\": get dta but not change the state. So \"peek\" would return the ID of the current, last, etc.

", "time": "2024-03-18T03:35:41Z"}, {"author": "Peter Thatcher", "text": "

It's tricky making sure something can be propagated downstream reliably. What if the relay dies and a subscriber connects to a new relay? Will it be able to know what it missed during the failover?

", "time": "2024-03-18T03:35:47Z"}, {"author": "Peter Thatcher", "text": "

A subcribe is not just a range filter. It also expresses the desire that the relay also subscribe upstream.

", "time": "2024-03-18T03:39:02Z"}, {"author": "Mike English", "text": "

I'm fine with a world where fetch+subscribe end up being a single verb on the wire. I think describing them as conceptually separate just makes it easier to describe expected behavior of all the different permutations.

", "time": "2024-03-18T03:39:11Z"}, {"author": "Jana Iyengar", "text": "

@Luke -- is your Subscribe semantically similar to our Fetch (in the proposal today)?

", "time": "2024-03-18T03:39:16Z"}, {"author": "Luke Curley", "text": "

@jana pretty much, except without the race conditions involved with fetch can only serve old stuff, and subscribe can only serve new stuff

", "time": "2024-03-18T03:40:01Z"}, {"author": "Luke Curley", "text": "

the main victim of FETCH is the HLS/DASH use-case

", "time": "2024-03-18T03:41:01Z"}, {"author": "Jana Iyengar", "text": "

Could you do what you want to do with the following:

\n
    \n
  1. Subscribe (get the current group number)
    2. \n
  2. Fetch from group 0 to current
    3. \n
  3. Prioritize as you want
    4. \n
", "time": "2024-03-18T03:41:22Z"}, {"author": "Ted Hardie", "text": "

@Luke I don't think anyone is suggesting FETCH replaces SUBSCRIBE

", "time": "2024-03-18T03:41:29Z"}, {"author": "Luke Curley", "text": "

@ted SUBSCRIBE can't do relative offsets with this proposal

", "time": "2024-03-18T03:42:09Z"}, {"author": "Luke Curley", "text": "

so if I want to start a few groups back, like HLS/DASH, then I have to use FETCH first

", "time": "2024-03-18T03:42:25Z"}, {"author": "Suhas Nandakumar", "text": "

@luke there is last for that ..

", "time": "2024-03-18T03:42:30Z"}, {"author": "Kirill Pugin", "text": "

@Jana, while I am fetching from 0 to current, current changes, how do I continue?

", "time": "2024-03-18T03:42:34Z"}, {"author": "Luke Curley", "text": "

and I somehow need to advertise the absolute group IDs to the player prior to playback

", "time": "2024-03-18T03:42:50Z"}, {"author": "Luke Curley", "text": "

@suhas only serving the latest group means a random jitter buffer between 0.1s and 2s

", "time": "2024-03-18T03:43:10Z"}, {"author": "Ted Hardie", "text": "

@Luke, okay, I see the point now. I thought you were worried that you'd have to repeat the fetch many times to get the data.

", "time": "2024-03-18T03:43:11Z"}, {"author": "Suhas Nandakumar", "text": "

@luke i meant last , not the latest .. from a streaming app, that would be 5-8 seconds

", "time": "2024-03-18T03:43:48Z"}, {"author": "Kirill Pugin", "text": "

So I asked what current is - it's 100, I fetched 0 - 100 how do I continue? do I subscibe? or do I fetch 101 and keep fetching?

", "time": "2024-03-18T03:44:02Z"}, {"author": "Jana Iyengar", "text": "

@Kirill: I'll clarify:

\n
    \n
  1. Subscribe (get the current group number, say 15), start to receive group 15 and forward
    2. \n
  2. Fetch from group 0:15
    3. \n
  3. Prioritize as you want, so that you can decide what groups you want to receive urgently
    4. \n
", "time": "2024-03-18T03:44:04Z"}, {"author": "Kirill Pugin", "text": "

3) who does priotization?

", "time": "2024-03-18T03:44:33Z"}, {"author": "Suhas Nandakumar", "text": "

+1 to Jana, that was my understanding on what is presented

", "time": "2024-03-18T03:44:40Z"}, {"author": "Suhas Nandakumar", "text": "

on 3) , priortization needs to be discussed in detail ..

", "time": "2024-03-18T03:45:07Z"}, {"author": "Jana Iyengar", "text": "

The client can/probably should, but I don't think we've solved this yet.

", "time": "2024-03-18T03:45:08Z"}, {"author": "Luke Curley", "text": "

@suhas okay a better word is probably \"prev\"

", "time": "2024-03-18T03:45:22Z"}, {"author": "Kirill Pugin", "text": "

ok, that makes sense assuming that we can figure out prioritization

", "time": "2024-03-18T03:45:31Z"}, {"author": "Jana Iyengar", "text": "

yup, and we HAVE to figure out prioritization, otherwise we're in trouble

", "time": "2024-03-18T03:45:49Z"}, {"author": "Suhas Nandakumar", "text": "

yes .. we need to figure out for anything sensible regardless of fetch/subscribe

", "time": "2024-03-18T03:46:05Z"}, {"author": "Victor Vasiliev", "text": "

I'm not entirely sure there is a huge difference between \"give me a group in the past\" and \"give me N groups in past\"

", "time": "2024-03-18T03:46:05Z"}, {"author": "Suhas Nandakumar", "text": "

@victor .. the challenge is relative offsets leads to lot of edge cases

", "time": "2024-03-18T03:46:35Z"}, {"author": "Jana Iyengar", "text": "

@victor, the edges are a bit hairy.

", "time": "2024-03-18T03:46:43Z"}, {"author": "Peter Thatcher", "text": "

What if the groups are very large? It seems like we're assuming they are small.

", "time": "2024-03-18T03:46:50Z"}, {"author": "Victor Vasiliev", "text": "

Are they? I think that's only the case in current draft cause we allow object-relative ones

", "time": "2024-03-18T03:47:44Z"}, {"author": "Peter Thatcher", "text": "

Even just \"last\" or \"current\" might be really big

", "time": "2024-03-18T03:47:46Z"}, {"author": "Suhas Nandakumar", "text": "

@peter .. in that case the application might not want to last as starting point if it is live edge case

", "time": "2024-03-18T03:48:08Z"}, {"author": "Suhas Nandakumar", "text": "

ALso the idea of \"now\" looks nice

", "time": "2024-03-18T03:48:26Z"}, {"author": "Jana Iyengar", "text": "

I thought about that @peter... I don't think there's an assumption here about that.

\n
    \n
  1. The relay SHOULD cache two groups. I expect one of the cases it can't if the group size is too large
    2. \n
  2. There is an expectation that the client and the content server know what they're doing... as in, the client should know what the sizes are to make sensible requests
    3. \n
", "time": "2024-03-18T03:48:27Z"}, {"author": "Peter Thatcher", "text": "

I think publisher TTL solves this, so I'm happy with Cullen's answer

", "time": "2024-03-18T03:50:35Z"}, {"author": "Peter Thatcher", "text": "

If feels like a follow-up should be the \"NACK object\" question

", "time": "2024-03-18T03:51:21Z"}, {"author": "Alan Frindell", "text": "

I'd like to see the PR. I'm concerned about interaction with forwarding preference, and the bit about how to know the largest object in an old group, etc.

", "time": "2024-03-18T03:53:10Z"}, {"author": "Ali Begen", "text": "

is it me or is this mic getting softer and softer?

", "time": "2024-03-18T03:54:07Z"}, {"author": "Luke Curley", "text": "

how do you prioritize FETCH vs SUBSCRIBE?

", "time": "2024-03-18T03:55:13Z"}, {"author": "Luke Curley", "text": "

etc

", "time": "2024-03-18T03:55:15Z"}, {"author": "altanai", "text": "

@Ali Begen Agree with you .. m continuously working on the volume up and down buttons

", "time": "2024-03-18T03:56:00Z"}, {"author": "Victor Vasiliev", "text": "

I think FETCH vs SUBSCRIBE is same as one track vs another -- you set priorities per track or a fetch request

", "time": "2024-03-18T03:56:19Z"}, {"author": "Luke Curley", "text": "

@victor imo FETCH is meant to deliver in ascending group order, while SUBSCRIBE is based on send_order

", "time": "2024-03-18T03:57:13Z"}, {"author": "Luke Curley", "text": "

but we also need a way of performing HLS/DASH style head-of-line blocking via SUBSCRIBE

", "time": "2024-03-18T03:57:25Z"}, {"author": "Victor Vasiliev", "text": "

FETCH can be useful in both asc and desc order

", "time": "2024-03-18T03:57:42Z"}, {"author": "Kirill Pugin", "text": "

in theory if player doesn't need to start playback asap, SUBSCRIBE would be sufficient for most cases

", "time": "2024-03-18T03:58:38Z"}, {"author": "Kirill Pugin", "text": "

for Live streaming usecases, FETCH is only needed to build buffer

", "time": "2024-03-18T03:59:32Z"}, {"author": "Suhas Nandakumar", "text": "

agree ..having a delivery preference for the order in fetch is not a bad idea ..

", "time": "2024-03-18T03:59:35Z"}, {"author": "Suhas Nandakumar", "text": "

@kiril , only if last is not sufficient enough for your playout buffer

", "time": "2024-03-18T04:00:06Z"}, {"author": "Luke Curley", "text": "

@kirill time to first frame is really important, we can't wait

", "time": "2024-03-18T04:00:08Z"}, {"author": "Kirill Pugin", "text": "

it pretty much always not enough ;)

", "time": "2024-03-18T04:00:25Z"}, {"author": "Kirill Pugin", "text": "

@luke, if only TTF matter than subscribe LAST solves that, right?

", "time": "2024-03-18T04:01:01Z"}, {"author": "Suhas Nandakumar", "text": "

@kiril what is your typical group size

", "time": "2024-03-18T04:01:24Z"}, {"author": "Kirill Pugin", "text": "

the problem is that if your bandwidth suck and you are not going to get next group in time

", "time": "2024-03-18T04:01:30Z"}, {"author": "Luke Curley", "text": "

SUBSCRIBE sends in send_order, which means you'll receive the live playhead before the actual start playhead

", "time": "2024-03-18T04:01:33Z"}, {"author": "Luke Curley", "text": "

we need head-of-line blocking for SUBSCRIBE for larger jitter buffers

", "time": "2024-03-18T04:01:50Z"}, {"author": "Luke Curley", "text": "

and I don't want to do that with a piecewise FETCH for each group like HLS/DASH

", "time": "2024-03-18T04:02:22Z"}, {"author": "Kirill Pugin", "text": "

@luke, hm... right...

", "time": "2024-03-18T04:02:23Z"}, {"author": "Luke Curley", "text": "

I filed a proposal to add order=ASC|DESC to SUBSCRIBE

", "time": "2024-03-18T04:02:40Z"}, {"author": "Luke Curley", "text": "

which is half-way to FETCH

", "time": "2024-03-18T04:02:51Z"}, {"author": "Luke Curley", "text": "

#411

", "time": "2024-03-18T04:03:09Z"}, {"author": "Kirill Pugin", "text": "

@Suhas, remind me what we consider group? GOP?

", "time": "2024-03-18T04:03:31Z"}, {"author": "Suhas Nandakumar", "text": "

for video , yes it is GOP

", "time": "2024-03-18T04:03:48Z"}, {"author": "Kirill Pugin", "text": "

1-5s

", "time": "2024-03-18T04:03:56Z"}, {"author": "Peter Thatcher", "text": "

Could be a lot more than 1-5s

", "time": "2024-03-18T04:04:07Z"}, {"author": "Kirill Pugin", "text": "

1s buffer may not be enough

", "time": "2024-03-18T04:04:10Z"}, {"author": "Alan Frindell", "text": "

The FETCH proposal from today said you might not get things in any particular order, right?

", "time": "2024-03-18T04:04:12Z"}, {"author": "Luke Curley", "text": "

yeah so SUBSCRIBE last will add startup latency, since current will be delivered first

", "time": "2024-03-18T04:04:21Z"}, {"author": "Cullen Jennings", "text": "

It seems like ASC / DESC is largely what gets sent next which is the prioritization conversation. I can easily imagine us wanting to add info to sub or fetch that helped the relay decide what to send next

", "time": "2024-03-18T04:04:34Z"}, {"author": "Suhas Nandakumar", "text": "

@luke .. that's not my read ot it

", "time": "2024-03-18T04:04:39Z"}, {"author": "Kirill Pugin", "text": "

@Peter, in practice for Live streaming, that what we've been using, you can go higher but that become not practical and you not gaining anything

", "time": "2024-03-18T04:04:50Z"}, {"author": "Luke Curley", "text": "

@suhas if SUBSCRIBE follows send_order, yes it does

", "time": "2024-03-18T04:04:51Z"}, {"author": "Luke Curley", "text": "

unless you want to ignore the send order for the first group?

", "time": "2024-03-18T04:05:06Z"}, {"author": "Suhas Nandakumar", "text": "

again , subscribe last , means statr from current-1 and into future

", "time": "2024-03-18T04:05:28Z"}, {"author": "Peter Thatcher", "text": "

@Kirill If the app wants to have large groups, it should be up to the app. We shouldn't bake the assumption of small groups into MoQ.

", "time": "2024-03-18T04:05:42Z"}, {"author": "Suhas Nandakumar", "text": "

current - 1 as an example .. wtaever the last group

", "time": "2024-03-18T04:05:47Z"}, {"author": "Luke Curley", "text": "

@suhas yeah but current may have 1.9s of data, which will be delivered before last

", "time": "2024-03-18T04:05:48Z"}, {"author": "Luke Curley", "text": "

while the player waits for last before starting playback

", "time": "2024-03-18T04:06:08Z"}, {"author": "Kirill Pugin", "text": "

@Peter I was answering Suhas' qeustion about group size.

", "time": "2024-03-18T04:06:34Z"}, {"author": "Peter Thatcher", "text": "

@Kirill. Ah, sorry. I misunderstood.

", "time": "2024-03-18T04:07:03Z"}, {"author": "Kirill Pugin", "text": "

@Peter, np. But I am not sure if we not thinking about groups as somthing that is not big :D

", "time": "2024-03-18T04:08:04Z"}, {"author": "Kirill Pugin", "text": "

so your point is valid

", "time": "2024-03-18T04:08:16Z"}, {"author": "Jana Iyengar", "text": "

@luke: I'm missing it. Why will current be delivered first if the client says \"Subscribe Last\"?

", "time": "2024-03-18T04:09:49Z"}, {"author": "Luke Curley", "text": "

@jana SUBSCRIBE start=-1 will start delivering -1 (last) and 0 (current)

", "time": "2024-03-18T04:10:33Z"}, {"author": "Luke Curley", "text": "

and they will be transmitted according to their priority

", "time": "2024-03-18T04:10:45Z"}, {"author": "Jana Iyengar", "text": "

yes

", "time": "2024-03-18T04:10:52Z"}, {"author": "Luke Curley", "text": "

and for live, new will be higher priority

", "time": "2024-03-18T04:11:18Z"}, {"author": "Luke Curley", "text": "

so the incomplete current group is delivered first

", "time": "2024-03-18T04:11:32Z"}, {"author": "Luke Curley", "text": "

while the player waits for the previous group to start playback

", "time": "2024-03-18T04:11:42Z"}, {"author": "Luke Curley", "text": "

HLS/DASH work by requesting something like 4s back, but starting playback if the first 1s has been received

", "time": "2024-03-18T04:12:03Z"}, {"author": "Jana Iyengar", "text": "

So yeah, I think we need to clearly articulate what is prioritized with Subscribe.

", "time": "2024-03-18T04:12:08Z"}, {"author": "Luke Curley", "text": "

so if we deliver 3s-4s first, then 0-1s

", "time": "2024-03-18T04:12:17Z"}, {"author": "Luke Curley", "text": "

2-4s first, then 0-1s*

", "time": "2024-03-18T04:12:24Z"}, {"author": "Luke Curley", "text": "

then we just increase startup time

", "time": "2024-03-18T04:12:29Z"}, {"author": "Zafer G\u00fcrel", "text": "

@luke Is it not possible for the relay to set the priority of last higher than current one's as an exception?

", "time": "2024-03-18T04:13:06Z"}, {"author": "Luke Curley", "text": "

that's one solution, gross of course, and it's not clear how FETCH interacts

", "time": "2024-03-18T04:14:02Z"}, {"author": "Jana Iyengar", "text": "

It's not clear to me which should be prioritized though... if the new is higher priority for the application, does it make sense to Subscribe to Last? Is there a clear answer in your mind as to exactly what should be prioritized when the client subscribes (in the general sense) for anything other than Now?

", "time": "2024-03-18T04:14:02Z"}, {"author": "Zafer G\u00fcrel", "text": "

If there is an intention for the last, then isn't it a signal to get it earlier than the current one?

", "time": "2024-03-18T04:14:12Z"}, {"author": "Jana Iyengar", "text": "

But yeah -- I think the prio question is one that we can address. It's a matter of understanding exaclty what we want to express.

", "time": "2024-03-18T04:14:28Z"}, {"author": "Luke Curley", "text": "

@Jana in #411 I have a proposal for SUBSCRIBE order=ASC if you want head-of-line blocking

", "time": "2024-03-18T04:14:40Z"}, {"author": "Mike English", "text": "

Up till now we've considered priority as being defined by the original publisher

", "time": "2024-03-18T04:14:50Z"}, {"author": "Luke Curley", "text": "

but I want that to work for more than just -1 group

", "time": "2024-03-18T04:14:56Z"}, {"author": "Luke Curley", "text": "

yeah the subscriber needs the ability to specify the priority too for HLS/DASH style playback

", "time": "2024-03-18T04:15:17Z"}, {"author": "Zafer G\u00fcrel", "text": "

I think relays should also have a say in setting priorities for such cases.

", "time": "2024-03-18T04:15:34Z"}, {"author": "Luke Curley", "text": "

order=ASC if you want to buffer to avoid dropping, order=DESC if you want to skip to keep latency low

", "time": "2024-03-18T04:15:56Z"}, {"author": "Jana Iyengar", "text": "

having the client express priority makes sense to me. Luke, you proposal seems like a fine starting point

", "time": "2024-03-18T04:16:44Z"}, {"author": "Lucas Pardue", "text": "

the http model is to allow client and server signalling, and place the burden on the tranmitter (relay) to figure out how best to resolve that by combining those signals with information only it knows (like local network conditions)

", "time": "2024-03-18T04:17:04Z"}, {"author": "Suhas Nandakumar", "text": "

Sender has idea of what is important . we should be careful on anyone in the middle flipping it .. each recv may end up getting different thing on who decidees to change

", "time": "2024-03-18T04:17:21Z"}, {"author": "Kirill Pugin", "text": "

@luke, won't we need to change ASC to DESC as client had built buffer? :D

", "time": "2024-03-18T04:17:25Z"}, {"author": "Luke Curley", "text": "

@kirill not for HLS/DASH, they still do ASC to buffer instead of skip video

", "time": "2024-03-18T04:17:49Z"}, {"author": "Alan Frindell", "text": "

I think if moq allows sender and receiver priority signals, we may need more normative guidance for how relays merge them than HTTP does

", "time": "2024-03-18T04:18:02Z"}, {"author": "Jana Iyengar", "text": "

@Lucas -- I think we should really aspire to making this simpler.

", "time": "2024-03-18T04:18:13Z"}, {"author": "Suhas Nandakumar", "text": "

HLS --> MLS
\nDASH -> DASM

", "time": "2024-03-18T04:18:41Z"}, {"author": "Jana Iyengar", "text": "

But this is the prioritization conversation we should be having soon.

", "time": "2024-03-18T04:18:57Z"}, {"author": "Suhas Nandakumar", "text": "

+1 Jana

", "time": "2024-03-18T04:19:06Z"}, {"author": "Kirill Pugin", "text": "

@Luke, well, yeah, but they do it because they only have FETCH ;)

", "time": "2024-03-18T04:19:10Z"}, {"author": "Luke Curley", "text": "

yeah, and I think FETCH is secretly about prioritization, since the goal is to deliver in order without loss

", "time": "2024-03-18T04:19:23Z"}, {"author": "Lucas Pardue", "text": "

I won't advocate for more complexity than needed. But the simpler the language, the biiger the risk we just build artificial constraints that will be ignored in practice

", "time": "2024-03-18T04:19:34Z"}, {"author": "Kirill Pugin", "text": "

at the end of the day, I want build buffer and then do normal Subscribe-like delivery

", "time": "2024-03-18T04:19:50Z"}, {"author": "Mike English", "text": "

I've started looking into adding LOC support to my implementation, too. Leaning on WebCodecs for the registry of elemental stream formats is handy. :)

", "time": "2024-03-18T04:21:32Z"}, {"author": "Kirill Pugin", "text": "

FWIW, when we built RUSH it was basically LOC :D

", "time": "2024-03-18T04:22:14Z"}, {"author": "Lucas Pardue", "text": "

e.g. I'm going to ignore client that are sending BS priority signals that are trying to disrupt the operation of my relay

", "time": "2024-03-18T04:22:45Z"}, {"author": "Luke Curley", "text": "

yeah, I think the publisher could still choose the priority, but the subscriber could override it

", "time": "2024-03-18T04:23:14Z"}, {"author": "Luke Curley", "text": "

like order=DESC from broadcaster -> origin, but order=DESC from origin -> vod playback

", "time": "2024-03-18T04:23:41Z"}, {"author": "Mike English", "text": "

+1 to Streaming (or \"Media\" now?) Format and Container as separately defined things

", "time": "2024-03-18T04:23:47Z"}, {"author": "Suhas Nandakumar", "text": "

@luke by susbcribe do you mean end receiver or the relay ?

", "time": "2024-03-18T04:23:49Z"}, {"author": "Lucas Pardue", "text": "

that model works Luke

", "time": "2024-03-18T04:24:20Z"}, {"author": "Luke Curley", "text": "

@suhas both? I don't want to treat the last mile separately

", "time": "2024-03-18T04:24:27Z"}, {"author": "Luke Curley", "text": "

a relay could override the publisher preferences I guess

", "time": "2024-03-18T04:24:51Z"}, {"author": "Suhas Nandakumar", "text": "

how does the relay know to make that decision ?

", "time": "2024-03-18T04:25:00Z"}, {"author": "Victor Vasiliev", "text": "

I think there's no need to make a \"moq-on-disc\" loc-specific

", "time": "2024-03-18T04:25:03Z"}, {"author": "Luke Curley", "text": "

maybe we have a MoQT on disk format

", "time": "2024-03-18T04:25:24Z"}, {"author": "Victor Vasiliev", "text": "

We just need a file with a catalog, a way to annotate groups/objects, and an index at the end

", "time": "2024-03-18T04:25:32Z"}, {"author": "Lucas Pardue", "text": "

Suhas Nandakumar said:

\n
\n

how does the relay know to make that decision ?

\n
\n

spec guidance and operational experience

", "time": "2024-03-18T04:26:21Z"}, {"author": "Luke Curley", "text": "

if a relay has 5 viewers who want order=ASC and 0 who want order=DESC, the relay could choose to fetch ASC from upstream

", "time": "2024-03-18T04:27:12Z"}, {"author": "Luke Curley", "text": "

if it wants to ignore the publisher's preference for DESC and add extra complexity I guess

", "time": "2024-03-18T04:27:31Z"}, {"author": "Victor Vasiliev", "text": "

let's do less drafts

", "time": "2024-03-18T04:27:48Z"}, {"author": "Mike English", "text": "

WARP

", "time": "2024-03-18T04:27:53Z"}, {"author": "Christian Huitema", "text": "

In the prototype that I did last year, I had a \"number of object in previous group\" as a property of the first object in the next group. Plus a control message stating the number of \"last group, last object\".

", "time": "2024-03-18T04:34:25Z"}, {"author": "Alan Frindell", "text": "

I don't know if I'd make that an object property, but could see that metadata being present at the beginning of the next group stream.

", "time": "2024-03-18T04:37:10Z"}, {"author": "Martin Duke", "text": "

+1 to Luke. If we put it in the data plane it has bad data-plane reliability guarantees

", "time": "2024-03-18T04:38:00Z"}, {"author": "Christian Huitema", "text": "

I agree with Luke

", "time": "2024-03-18T04:38:12Z"}, {"author": "Cullen Jennings", "text": "

I suspect 3 designs we could go down A) last object has flag B) an extra object at the end of group that is a tombstone C) info in next group that says what the end of prev group is

", "time": "2024-03-18T04:38:17Z"}, {"author": "Christian Huitema", "text": "

The flag is a nice way to optimize the golden path. Although if we have a \"stream per group\" model, the FIN of stream also provides a signal.

", "time": "2024-03-18T04:39:39Z"}, {"author": "Luke Curley", "text": "

I like the FIN of the stream to signal the end of a group on success, but we still need a message to signal the end on failure

", "time": "2024-03-18T04:40:17Z"}, {"author": "Luke Curley", "text": "

(unless we encode the group/object ID into RESET_STREAM...)

", "time": "2024-03-18T04:40:30Z"}, {"author": "Suhas Nandakumar", "text": "

We need these explicit messages, no doubt . we can make it reliable on data path

", "time": "2024-03-18T04:40:46Z"}, {"author": "altanai", "text": "

+1 for use-case wise prioritization by @Mo Zanaty

", "time": "2024-03-18T04:42:14Z"}, {"author": "Christian Huitema", "text": "

Also, think of the audio stream, one object per group, 50 objects per second. Signalling that on the control path would be very expensive.

", "time": "2024-03-18T04:42:31Z"}, {"author": "Luke Curley", "text": "

and I do want to add that adding priority to SUBSCRIBE aligns with HTTP/3 priorities

", "time": "2024-03-18T04:46:43Z"}, {"author": "Luke Curley", "text": "

+1 prioritization is absolutely required for MoQ

", "time": "2024-03-18T04:50:07Z"}, {"author": "Lucas Pardue", "text": "

I disagree it didn't matter as much for HTTP/3

", "time": "2024-03-18T04:50:25Z"}, {"author": "Lucas Pardue", "text": "

you can absoultely tank the performance of web pages with bad scheduling, to the point of unacceptability

", "time": "2024-03-18T04:50:44Z"}, {"author": "Luke Curley", "text": "

@lucas let me clarify, for real-time use-cases

", "time": "2024-03-18T04:50:45Z"}, {"author": "Luke Curley", "text": "

if you're trying to build a WebRTC alternative

", "time": "2024-03-18T04:50:54Z"}, {"author": "Lucas Pardue", "text": "

I think we were alway agreed luke, I was pushing back on Jana's microphone point :D

", "time": "2024-03-18T04:52:09Z"}, {"author": "Cullen Jennings", "text": "

Section 4.1.1 and 4.1.2 are pretty specific proposal

", "time": "2024-03-18T04:52:24Z"}, {"author": "Luke Curley", "text": "

ah okay

", "time": "2024-03-18T04:52:51Z"}, {"author": "Suhas Nandakumar", "text": "

+1 . it came after lots of discussions .. we need to see why they don't work or what needs fixing

", "time": "2024-03-18T04:53:02Z"}, {"author": "Mike English", "text": "

Ali and Zafer have some data :)

", "time": "2024-03-18T04:54:09Z"}, {"author": "Suhas Nandakumar", "text": "

our implementation works today on priotities (like HTTP/3) and it works pretty well

", "time": "2024-03-18T04:54:42Z"}, {"author": "Mike English", "text": "

But I agree, it'd be nice to have a place to put subscriber side priority signals if we want to compare

", "time": "2024-03-18T04:55:05Z"}, {"author": "Luke Curley", "text": "

@suhas HTTP/3 priorities are decided by the subscriber, while send_order is decided by the publisher today

", "time": "2024-03-18T04:55:19Z"}, {"author": "Victor Vasiliev", "text": "

I don't think I personally would be able to gather any form of data before Vancouver

", "time": "2024-03-18T04:55:38Z"}, {"author": "Lucas Pardue", "text": "

HTTP/3 priorities are merged from client and server signals

", "time": "2024-03-18T04:57:39Z"}, {"author": "Lucas Pardue", "text": "

how to weight the merge can easily be tilted differently for MoQ

", "time": "2024-03-18T04:58:11Z"}, {"author": "Mike English", "text": "

+1 to having discussion. Like Alan, I'm unsure if we'll have much to look at before Vancouver

", "time": "2024-03-18T04:58:29Z"}, {"author": "Mike English", "text": "

Mostly because I don't know if I'll have time to gather the data I'd like to have in that timeframe with other priorities

", "time": "2024-03-18T04:59:22Z"}]