Re: [Moq] Upcoming Working Group Forming BoF

[Luke Curley <[e-mail]>]

Hey Spencer, the SIP analogy is great.

Warp, RUSH, SRT, RTP over QUIC, etc are replacements for RTMP and RTP
(media transport). However, QUICR seems like a replacement for SIP, as it's
a layer on top responsible for authorization, naming, discovery, proxying,
etc (orchestration layer?).

The media transport should definitely be a separate draft from the
orchestration layer. However, should they be in the same working group? I
don't know how that distinction is made.

Right now "the MOQ architecture" sentence seems to be the only reference to
something like QUICR. I think that either needs to be expanded (same WG),
deleted (different WG), or made more generic (punted).


On Sat, Jul 16, 2022, 11:27 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> 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
>>
>> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>