Re: [Moq] Charter adjustment

["Ali C. Begen" <[e-mail]>]

Hi Ted,

On Thu, Jul 21, 2022 at 12:40 PM Ted Hardie <[e-mail]> wrote:

> Hi Ali,
>
> On Thu, Jul 21, 2022 at 10:16 AM Ali C. Begen <[e-mail]>
> wrote:
>
>> Ted,
>>
>> My suggestion still stands as follows:
>>
>> The working group will define MoQ so that the media publication protocol
>> can leverage middleboxes such as relays, caches and replication points
>> wherever applicable to improve the delivery performance.
>>
>> Again, “on-path” is not needed IMO. Further, I still dont want to limit
>> ourselves to only relays.
>>
>>
> I think the point of "on-path" is to indicate that we're talking about the
> boxes through which some or all of the flow delivered to the recipient will
> pass.  It may not be the same set of boxes for the whole flow (depending on
> cache fill properties or client mobility).  We're not talking about, say,
> making the relevant DNS look-ups faster.  If you have a different phrase
> that captures that, I think we can discuss that, but I think for scope
> reasons that we need something there.
>

The simple counter example I have in mind is peers helping each other. In
that case, not every peer will be on each other's path. "On-path" limits us
to 1:1 delivery and I don't think we need this limitation. I don't think we
really need in there, omission is just fine :)


> The current text already says relays and caches, so your forumation adds
> "replication points"--can you say in more detail what you mean there and
> how it would differ from the other two?
>

Replication point is where you can get "multicast-like" replication at the
application layer. In case of push architectures, there is a need for
active replication in the network for 1:many delivery.


> For the same scope reason, I would not suggest having "leverage
> middleboxes" as a bare statement--there's too much disagreement on what
> that set might contain and what "leverage" might mean in practice (as the
> discussion about transcoding showed).  I think we're better off narrowing
> the set that we are aiming to include as design elements (even optional
> ones), while recognizing that there will be other boxes in play in some
> deployments no matter what we do.
>

That is my intent, too, to recording that there will be other boxes. The
text I proposed has caches/relays (as the low hanging fruit) and keeps the
door open for wider use cases. Not every one is understandably interested
in every use case, but those who are interested should be able to work on
them. Bottomline is I am in favor of a more flexible rather than
restrictive text.

-acbegen


>
> regards,
>
> Ted
>
>
>
>
>> -acbegen
>>
>> > On Jul 21, 2022, at 12:09 PM, Ted Hardie <[e-mail]> wrote:
>> >
>> > Folks seemed fairly happy with the idea of adjusting this text:
>> >
>> > "The MOQ architecture will allow for the use of optional relays as
>> first class elements of the design.  The media publication protocol can
>> leverage on-path relays/caches wherever applicable to improve the media
>> quality."
>> >
>> > to this text:
>> >
>> > "The working group will define MoQ so that the media publication
>> protocol can leverage on-path relays/caches wherever applicable to improve
>> the delivery performance."
>> >
>> > If anyone objects to this change, please say so on the list; otherwise,
>> I will adjust in the copy of the charter we review at the BoF (currently
>> https://github.com/moq-wg/moq-charter/pull/49).
>> >
>> > regards,
>> >
>> > Ted
>> > --
>> > Moq mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/moq
>>
>>