Re: [Moq] Charter adjustment

"On-path" frequently means "on the native routing/switching path", where the packets would flow such as through a switch, router, or firewall.  Switches, routers, and firewalls don't appear in the IP source or destination.  If packets are sent to a specific IP address (proxy, peer), it's being sent to a host (proxy, peer) which is not on that natural packet routing path.

-d

> On Jul 21, 2022, at 6:13 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> Hi Ali,
> 
> In-line.
> 
> 
> On Thu, Jul 21, 2022 at 10:58 AM Ali C. Begen <ali.begen@networked.media> wrote:
> Hi Ted,
> 
> On Thu, Jul 21, 2022 at 12:40 PM Ted Hardie <ted.ietf@gmail.com> wrote:
> Hi Ali,
> 
> On Thu, Jul 21, 2022 at 10:16 AM Ali C. Begen <ali.begen@networked.media> 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 <ted.ietf@gmail.com> 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
> > Moq@ietf.org
> > https://www.ietf.org/mailman/listinfo/moq
> 
> -- 
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq