Filter use cases based on QUIC properties?

[martinduke]

IMO the current draft is an inventory of all the ways we use media over the internet. Certainly, it is technically possible to migrate all of these use cases to QUIC.

However, it is not at all clear to me that all of these use cases actually benefit from using QUIC. For example: taking a UDP based protocol that has its own congestion control and recovery, and porting it to QUIC/WebTransport datagrams, doesn't clearly leverage the purported benefits to QUIC.

Would it be worthwhile to downselect some of these cases for where we think QUIC is providing a genuine value add?

[ghost]

So we kind of covered this already back in IETF 113, and maybe even covered some of this in earlier versions of the document. Specifically I listed out in my presentation:

That's not to say we shouldn't describe these things in the document, but an important consideration is that the QUIC value add we describe is relative to the use cases and requirements we actually care about.

[SpencerDawkins]

I was hoping @fiestajetsam would point to the right place where we talked about this - and I think this slide was taken from a previous version of the draft (or, at least SOME draft!). Thank you, James.

I agree with @fiestajetsam about saying something in the document. What I think @martinduke was asking for (in at least a couple of private conversations) was something that lets him ask people who want to use MOQ with datagrams and handle almost all of the "transport-level" functionality (packet-level scheduling, loss detection and repair, congestion control, etc.) in their applications, "so, why do you want to use MOQ, if you're not going to use most of its functionality?" - Martin, do I have that right?

What that might look like, in the document, is a section that describes the benefits MOQ gets from QUIC (so, a more careful restatement of what we said at the non-WG-forming BOF), and then a statement, for each use case, saying which benefits that use case is leveraging.

Does that make sense?

[martinduke]

That is an accurate summary of my position, yes.

I am not absolutely against doing things over QUIC without really using QUIC, but in my view it's a lower priority and we should explicitly decide to do it.

On Fri, Feb 3, 2023 at 8:29 AM Spencer Dawkins @.***> wrote:

I was hoping @fiestajetsam https://github.com/fiestajetsam would point to the right place where we talked about this - and I think this slide was taken from a previous version of the draft (or, at least SOME draft!). Thank you, James.

I agree with @fiestajetsam https://github.com/fiestajetsam about saying something in the document. What I think @martinduke https://github.com/martinduke was asking for (in at least a couple of private conversations) was something that lets him ask people who want to use MOQ with datagrams and handle almost all of the "transport-level" functionality (packet-level scheduling, loss detection and repair, congestion control, etc.) in their applications, "so, why do you want to use MOQ, if you're not going to use most of its functionality?" - Martin, do I have that right?

What that might look like, in the document, is a section that describes the benefits MOQ gets from QUIC (so, a more careful restatement of what we said at the non-WG-forming BOF), and then a statement, for each use case, saying which benefits that use case is leveraging.

Does that make sense?

— Reply to this email directly, view it on GitHub https://github.com/fiestajetsam/draft-gruessing-moq-requirements/issues/85#issuecomment-1416106149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2EYELS6BDN3J4G2IN5YCTWVUW5JANCNFSM6AAAAAAUOIYFDA . You are receiving this because you were mentioned.Message ID: @.*** .com>

[SpencerDawkins]

Thanks, @martinduke - I'm just trying to figure how the functionalities in MOQ hang together (streams + datagrams, encapsulated in WebTransport + QUIC), and who needs the various combinations, and why. Not my job, I know, but if (as you said) some parts of what's in scope could be a lower priority, that might not be a bad thing.

@fiestajetsam - I am also looking at Section 3 of the Warp draft ("Motivation"), and seeing some overlaps with what you said in the non-WG-forming BOF, which is making me wonder whether it's reasonable to explain how each use case benefits from using MOQ (ignoring that this is a circular dependency). Do you and Martin have thoughts?

[SpencerDawkins]

@fiestajetsam and I note that Section 1.1 of the MOQ Transport Draft does contain helpful motivations, but are rather QUIC-centric, and while relevant, does not provide the motivations for implementing and deploying a MoQ system, that includes the application-level aspects of a MoQ system. That would also probably be a good thing to talk about in this draft.

[SpencerDawkins]

@fiestajetsam and I note that the material on "why QUIC" is distribution-centric. We'll take a step back and talk about both directions. Don't do "advantages of QUIC" for each use case, do it at a summary level. There is an overlap between interactive and live streaming use case, but there are also differences.

We are also noting that part of the advantages of MOQ are provided by the underlying QUIC specifications, but other advantages may be provided by the application itself. We will attempt to explain how an application can use QUIC facilities in order to provide those advantages.

[ghost]

I think we've covered this in the above linked PR, so closing this - please comment or re-open if we've overlooked something.