Re: [Moq] Charter adjustment

Ian said:

"HTTPS proxies have been around for a long time, and MoQ shares many of
those properties."

[BA] Indeed, there are proposals (such as HESP
<https://www.hespalliance.org/>) aimed at low-latency distribution that run
over HTTP/3 and support caching.

This begs the question of "Why is MoQ better?"

On Thu, Jul 21, 2022 at 4:39 PM Ian Swett <ianswett=
40google.com@dmarc.ietf.org> wrote:

>  I agree with Lucas.
>
> Ensuring uncoordinated middleboxes can improve MoQ content delivery seems
> like an impossible task, or at least out of scope for this working group.
> Ensuring coordinated middleboxes/CDNs can improve MoQ content delivery
> seems very much in scope.
>
> HTTPS proxies have been around for a long time, and MoQ shares many of
> those properties.
>
> Ian
>
> On Thu, Jul 21, 2022 at 6:40 PM Suhas Nandakumar <suhasietf@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Jul 21, 2022 at 3:34 PM Suhas Nandakumar <suhasietf@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Jul 21, 2022 at 3:08 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 21 Jul 2022, 10:16 Mo Zanaty (mzanaty), <mzanaty=
>>>> 40cisco.com@dmarc.ietf.org> wrote:
>>>>
>>>>> I agree with Ali and Dan that “on-path” has a specific meaning to many
>>>>> networking people which is not the meaning intended in the charter. I would
>>>>> contend that is a misnomer that must be removed.
>>>>>
>>>>> The discussion of middle boxes has been in the context of explicitly
>>>>> addressing them, not them happening to be on the network path to another
>>>>> endpoint and transparently mediating the packet flow addressed to that
>>>>> other endpoint. That is certainly a viable use case, but not one I’ve seen
>>>>> anyone mention, perhaps because QUIC encryption makes on-path mediation
>>>>> very difficult.
>>>>>
>>>>
>>>> QUIC makes uncoordinated middlebox behaviour difficult. Even detecting
>>>> QUIC traffic is tricky for such boxes. When there is coordination or
>>>> cooperation between endpoints and other components in the path, things are
>>>> a lot smoother.
>>>>
>>>> The prime example of this is QUIC load balancers that can make
>>>> decisions (routing/dispatching packets) based on the connection ID. The
>>>> generally works by the server picking IDs based on some scheme or algorithm
>>>> and sharing that with the load balancer.
>>>>
>>>> I think the MoQ charter needs to be clear about whether the middleboxen
>>>> are expected to work on: QUIC packets as opaque blobs, the frames within
>>>> QUIC packets once protection is removed by actors who have the session
>>>> keys, application data in streams, datagrams, or something else.
>>>>
>>>
>>> These are good points Lucas.
>>>
>>
>>
>>> Atleast from my reading of relays/caches in charter was that, its where
>>> the QUIC connection terminates (but not the MOQ) , akin to CDN , for
>>> example.
>>>
>>
>>
>>> PeerA    <-----QUIC----->  Relay <----QUIC---->  PeerB
>>> <---------------------------------- MOQ -------------------------->
>>>
>> Relays in the above contexts are special MOQ entities that perform
>> specific actions to enable MOQ protocol like
>>     - caching, forwarding/distributing, fragmentation where necessary,
>> reacting to congestion,
>>  These actions doesn't need access to raw media that is exchanged between
>> PeerA and PeerB for instance.
>>
>> Cheers
>>> Suhas
>>>
>>>
>>>> Cheers
>>>> Lucas
>>>>
>>> --
>> 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
>