Re: [Moq] Charter adjustment

[Ted Hardie <[e-mail]>]

Hi Ali,

In-line.


On Thu, Jul 21, 2022 at 10:58 AM Ali C. Begen <[e-mail]>
wrote:

> 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 :)
>

I don't think I understand what "peers helping each other" means that
doesn't result in their being a flow through the two of them to the
recipient.  It may be that you are reading "on-path" as if you assume a
single path for the lifetime of the media flow; I think cases where that's
not true are in scope (redirection from origin to relay being an obvious
case).

I think we have to be pretty careful here not to give ourselves the same
task as CDNI, at least in our first version of the charter; that's a big
additional scope.


>
>> 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.
>

Okay, I think that I see that as inherent in the current text, but I've
updated the pull request to add "replication points" to the text.

regards,

Ted


>
>
>> 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
>>>
>>>