Are we asking the right questions?

[afrind]

There was discussion that the proposal as written assumes its premises, that it presumes the stated use cases are the right ones. You should ask those meta-questions first. It shouldn't be "Is there a protocol that meets these needs?" but rather "Are these the right needs we should be discussing?"

[SpencerDawkins]

I agree, and would go farther to say "are these the right needs we should be discussing, and do we have a reason to believe that existing protocols don't meet those needs?"

Again - if we can have that conversation on the MOQ list before IETF 113 meeting week starts, that would be awesome.

[afrind]

"are these the right needs we should be discussing, ...?"

This framing sounds like people don't believe Google/YouTube, Facebook/Meta and Amazon/Twitch when we lay out the challenges we've faced in the products and services we're trying to operate. We are here to talk about these needs. Other people might want to talk about different needs I guess?

Maybe we haven't done a great job of explaining our use cases, requirements and challenges on the list to this point? I feel like there was an attempt after the last IETF but the conversation didn't feel productive.

"and do we have a reason to believe that existing protocols don't meet those needs?"

This is one of the core questions I wanted the BoF to address -- is there something we don't understand about existing protocols that make them more suitable to our requirements than we perceive? Or could they be easily adapted to meet the requirements?

[SpencerDawkins]

This framing sounds like people don't believe Google/YouTube, Facebook/Meta and Amazon/Twitch when we lay out the challenges we've faced in the products and services we're trying to operate. We are here to talk about these needs. Other people might want to talk about different needs I guess?

I think you just hit bingo. We had a lot of discussion on the MOQ list about how many different protocols we thought we would end up with, unless we have one Swiss Army Protocol called MOQ that's supposed to handle any kind of media at any bitrate and any kind of latency requirements ... anyway, you see the problem.

I don't think people disbelieve you, but I do suspect that your challenges don't sound like their challenges, and they are worried that if they don't get their challenges on the plate, they aren't going to have a good "whatever over QUIC" story. Does that make sense?

One big goal that I have, that I don't think I'm writing down, is figuring out how many rooms we'll need to get everyone in the right room with the right people for what problem they're trying to solve, with nobody trying to solve a different problem in the same room. If we pull that off, we've already sort of won.

[afrind]

unless we have one Swiss Army Protocol called MOQ that's supposed to handle any kind of media at any bitrate and any kind of latency requirements

I think having a single 'media over QUIC' protocol to address everyone's needs may be a red herring, and is hindering progress. That's just the name of our mailing list to identify the broad area we are discussing. I like the use-case work you and James have done mapping the space, and perhaps reviewing that early in the agenda will help drive home the point that some kind of grand-unifying protocol is more of a nice to have.

My most important goal for the BoF though is to discuss in-depth the use-cases that RUSH and WARP were built to solve, and get community feedback and direction for where to take these next.

[SpencerDawkins]

@afrind - I agree about a MOQ protocol being a red herring, and I don't even like ACTUAL herring.

Not speaking for @fiestajetsam, but I also think the space-mapping discussion early on will be useful.

I definitely want to understand any differences between the RUSH and WARP use cases and the use cases we're describing (as quickly as we can type) in our use case/requirements draft. So I'm in on that goal, too.

[kixelated]

Yeah, one of the problems with MOQ is that it already assumes QUIC is the solution and we have to work backwards to find the problem. I would focus on the issues with RTMP and HLS/DASH, and why QUIC is uniquely positioned to address those issues.