Re: [Moq] Charter adjustment

[Ted Hardie <[e-mail]>]

While I appreciate all the additional thinking in this thread, I think I
still need to have a clear answer on what to do about the charter text
(sorry, BoF chair priorities).  We can:

Leave on-path in
Change on-path to something that does not have the same lower-layer
implications, but does retain the implication of a coordinated set through
whom the data flows
Remove it entirely.

Based on the discussion so far, my proposal is to adjust this to:

"The working group will define MoQ so that the media publication protocol
can leverage coordinating relays/caches wherever applicable to improve
the delivery
performance."

I think that addresses Ali's initial concern, removes my concern that we
will be signing up to unrelated work (like DNS query traffic), leaves the
CDNI problem space outside, and generally goes along with the discussion to
date.

Any thoughts before I update the PR?

regards,

Ted

On Fri, Jul 22, 2022 at 10:59 AM Maxim Sharabayko <
[e-mail]> wrote:

> HESP looks extremely interesting! Thank you Bernard for sharing!
>
>
>
> It seems to be a re-thinking of LL-HLS with low-latency in mind.
> One of the main outstanding points is low stream initialisation and
> channel switching time.
>
> Ian said: “This begs the question of "Why is MoQ better?"
>
>
>
> HESP is more a protocol to deliver (distribute) a content to an end-user,
> and does not cover ingest well enough.
>
> While MOQ “will develop simple low-latency media delivery solution for
> ingest and distribution.”
>
>
>
>
>
> -- Maxim
>
>
>
>
>
>
> Maxim Sharabayko
>
> Principal Research Engineer
>
> [image: Logo] <https://www.haivision.com/>
>
>
>
> *From: *Moq <[e-mail]> on behalf of Christian Huitema <
> [e-mail]>
> *Date: *Friday, 22. July 2022 at 08:05
> *To: *Bernard Aboba <[e-mail]>
> *Cc: *Ian Swett <ianswett=[e-mail]>, Suhas Nandakumar <
> [e-mail]>, Lucas Pardue <[e-mail]>, Mo
> Zanaty (mzanaty) <mzanaty=[e-mail]>, Ali C. Begen
> <ali.begen=[e-mail]>, Ted Hardie <
> [e-mail]>, MOQ Mailing List <[e-mail]>
> *Subject: *[EXTERNAL] Re: [Moq] Charter adjustment
>
> Thanks for the pointer to the HESP spec, Bernard. MoQ and HESP are very
> different approaches. I think that HESP strict adherence to HTTP implies
> risks of head-of-line blocking. Probably not an issue if low latency is
> defined as "under 400ms", but certainly important if we aim for "under
> 200ms" or "under 150ms".
>
> -- Christian Huitema
>
> On 7/21/2022 8:33 PM, Bernard Aboba wrote:
>
> https://datatracker.ietf.org/doc/draft-theo-hesp
>
>
>
> On Thu, Jul 21, 2022, 7:23 PM Christian Huitema <[e-mail]>
> wrote:
>
> On 7/21/2022 7:13 PM, Bernard Aboba wrote:
>
> 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?"
>
>
>
> If you want low latency, you need to support datagrams, and have some way
> to fragment long frames over series of datagrams. But then, if you require
> reassembly of fragmented frames at each step in the relaying chain, you can
> easily run into head-of-line blocking. That's something we can handle in
> MoQ. I don't know whether HESP does that -- the specs do not appear to be
> publicly available.
>
> -- Christian Huitema
>
>
>
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>