Use terminology correctly for Relays, Caches, Replication Points, and Media Translators

[SpencerDawkins]

From the MOQ charter:

The working group will define MoQ so that the media publication protocol can leverage coordinating relays, caches, or replication points wherever applicable to improve the delivery performance.

I'm working from these assumptions:

• If there's a MOQ entity between client and server, that entity includes relay functionality
• In addition, a MOQ entity between client and server can include a cache
• In addition, a MOQ entity between client and server can include functionality for media media replication
• In addition, a MOQ entity between client and server can include functionality for transcoding media

The first three assumptions are explicitly mentioned in the charter.

It would be helpful to provide some level of detail about what is expected for these entities.

[SpencerDawkins]

From #81 - Expectations for relay functionality.

At a minimum, we've had conversations about what level of granularity we expect relays to make forwarding decisions on, and how much we expect relays to understand about media, without introducing media-specific relay behaviour.

[SpencerDawkins]

@SpencerDawkins opinion - this isn't about drawing all the possible ways to combine these blocks - that would happen as part of discussion about deployment considerations (probably in other documents).

[fluffy]

I view Media Translators as a type of endpoint as they see some of all the media.

[SpencerDawkins]

@fluffy,

I view Media Translators as a type of endpoint as they see some of all the media.

I agree, if the Media Translator sees all of the media. If all Media Translators see all of the media (or, equally good, if we identify something that's sort of a Media Translator, that - I'm making this up as I go along - needs to see some, but not all, of the metadata that relays do not have access to, so it's more than a relay, but not exactly a Media Translator that needs to see everything), we can remove Media Translators from the list here, and consider that function as part of the systems engineering work that @hardie mentioned during the interim meeting yesterday.

[SpencerDawkins]

This issue was discussed at the MOQ interim meeting on 2023-01-31 - notes from that meeting are here - and again on 2023-02-01 - notes from that meeting are here - and are included here by reference.

Anyone working on a PR for this issue should take a look at the discussion notes.

[suhasHere]

@SpencerDawkins I can take a stab at the PR

[SpencerDawkins]

@suhasHere - thanks! You might want to keep an eye on discussion in the MOQ Entity design team about this, but if we can put something in the requirements draft that's enough to get us started on requirements, that would be helpful.

[SpencerDawkins]

What I would LIKE to do, is use the @suhasHere scenarios and architecture drafts (submitted before IETF 116), as a reference, rather than add anything in our document called "terminology" or "architecture".

Not "add definitions", but "use terminology correctly".

[SpencerDawkins]

This issue is important, but depends on an agreed minimal architecture for a MOQ system, and secondarily, depends on some consensus for terminology in some wiki somewhere, to ensure that we don't produce multiple drafts with different terminology and different assumptions about what MOP systems look like. These are both external dependencies that the MOQ working group has agreed matter in more than one formal meeting. How does MOQ make that happen?

[SpencerDawkins]

We plan to match the relevant terminology in these drafts:

• Media over QUIC Transport and
• Media Over QUIC Media and Security Architecture.

Ideally, these documents should also match each other, of course. 🙄