Re: [Moq] Upcoming Working Group Forming BoF

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Ali, (with a question for Luke, below),

On Sat, Jul 16, 2022 at 6:58 AM Ali C. Begen <[e-mail]>
wrote:

> Hi Spencer
>
> My quick responses are inline.
>

Thanks for these.

I'd encourage the BOF chairs to spin off questions that seem to need
discussing before the BOF into their own threads, but I want to let them
moderate this discussion, given that we don't have a lot of time before the
BOF itself, and I really don't want to distract from that.

A couple of things inline, below.


> > On Jul 15, 2022, at 10:22 PM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
> >
> > Hi, Alan,
> >
> > On Fri, Jul 15, 2022 at 11:03 AM Alan Frindell <afrind=
> [e-mail]> wrote:
> > Hi MoQ, we have a WG-forming BoF scheduled for 7/27 at 10 AM Eastern.
> We’d like to drive some of the charter discussion on list in advance of the
> meeting.
> >
> >
> >
> > Please have a look at the latest draft charter here:
> https://github.com/moq-wg/moq-charter/blob/main/charter.md.  GitHub
> issues are appreciated, but please use the mailing list as the primary
> discussion venue.
> >
> >
> > Thanks for inviting pre-meeting charter discussion.
> >
> > I'm asking questions here, and if the answer to any of these questions
> is "we don't need to know that before the BOF", that's a fine answer.
> >
> > If you and Ted think any of these questions are worth talking about
> before the BOF, could I ask you to start new threads appropriately?
> >
> > Is there any connection between MOQ and RTP-over-QUIC work in AVTCORE? I
> note that AVTCORE just adopted a draft in this space (at
> https://mailarchive.ietf.org/arch/msg/avt/zFIiDapDs8t58T0j9bCwbEb8T4o/).
>
> I thought about this for some time and concluded that MOQ would not need
> RTP encapsulation in most (if any at all) of its use cases. There are
> reasons to send RTP over QUIC but they don’t seem to be any of the reasons
> for MOQ. So, these can progress indepedent of each other.
>

This is an excellent answer.

I have talked to a fair number of people who weren't sure whether "RTP over
QUIC" was a subset of, or in any way related to, "Media over QUIC".

It's fair to point out that the only feedback on the AVTCORE mailing list
that wasn't positive for adoption of RTP over QUIC was

As you know the moq (media over Quic) group will have a BoF in IETF 114.
I think moq wishes to develop quic version(s)  with which probably we won't
need anything like RTP over Quic.
Because of that, isn't this call a bit early? Maybe we should wait for the
results of moq BOF?


If it's clear to most people that "Media over QUIC".and "RTP over QUIC"
don't overlap, that's great.


> > I like the idea of the architecture proposed in QUICR, but I haven't
> seen a lot of discussion of that architecture (did I miss it?), and "the
> MOQ architecture" is mentioned in the charter and in the milestones. Does
> this mean we are chartering to include THAT architecture, or to include AN
> architecture?
>
> My reading of the draft charter is to include an architecture. QUICR is
> simply one candidate. I saw Luke’s objection on the moq architecture being
> in the charter, but I think it should be part of it. The priorities within
> the charter can always be adjusted per needs.
>

This is definitely worth its own thread, if other people have thoughts.

Luke, would you still have an objection if a "MOQ architecture" was an
example used in the protocol specifications? Perhaps the way the "SIP
trapezoid" was used in
https://datatracker.ietf.org/doc/html/rfc3261#section-4?


> > One of the ideas I like about the charter is that if relays are used,
> they are "first class elements", and caching is mentioned as one of the
> functions that relays can perform. Are there others worthy of mention?
> Perhaps transcoding?
>
> Caching/replication/etc. capabilities should be part of the charter for
> any serious protocol considering to be scalable. More active capabilities
> involving any media processing like transcoding can also be considered if
> needed provided that people understand the complexities attached to it.
>

The charter language here

Media will be encrypted, possibly end-to-end encrypted for certain
usecases. The keying mechanisms for media confidentiality is however
outside the scope of this working group. Even when media is end-to-end
encrypted, the relays can access metadata needed for caching (such as
timestamp), making media forwarding decisions (such as drop or delay under
congestion) and so on.


seems tilted toward saying "if you can improve performance by using
metadata, that's great". If that's the way people are reading it, leaving
transcoding and other media-twiddling outside of the realm of MOQ, so that
media is always MOQ-endpoint-to-MOQ-endpoint-encrypted, that might be good
to say, if only because it might head off a discussion about use cases that
aren't end-to-end encrypted, that may not be helpful in moving towards a
chartered working group.


> > Are there any constraints about coexistence with non-MOQ QUIC streams or
> datagrams in a single QUIC connection?
>
> Not that I am aware of.
>

If other people see it that way, it seems worth saying. It also makes me
feel better about not mentioning "media-friendly congestion control" in the
charter.


> > Are there any constraints on the architecture or protocols to allow
> location of producers or consumers?
>
> I did not grok the question. But things like location privacy of either
> side should be kept in mind.
>

I'm sorry this wasn't clear. I was looking at the charter language.

This working group will not define signaling mechanisms for discovery of
relay or media producers or consumers.


My question was whether there was anything we needed to keep in mind that
would allow MOQ endpoints to either find each other or find an appropriate
relay.

Thanks for the opportunity to clarify.

Best,

Spencer

-acbegen
>
> >
> > Best,
> >
> > Spencer
> > --
> > Moq mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/moq
>
>