Next level of details on "configurable latency"

[SpencerDawkins]

We've had some conversations in Issue 72 about "configurable latency", but I'm not sure everyone means the same thing when they use that term. Possible meanings include

• At a minimum, allocated buffer sizes would influence end-to-end latency. What is configured?
• Do applications need to be notified that the configured latency being exceeded, in order to decide what to do next?
• Beyond (possibly) notifying the application that the configured latency is being exceeded, what else does the underlying media transport do? Does it drop queued media that has not been transmitted yet, or does the application control that? Does it make decisions about applying FEC on its own, or does the application control that?
• Is it meaningful to speak about "configurable latency", in an environment where relays and other intermediate devices can be nested?
• Is it meaningful to speak about "configurable latency", in an environment where relays and other intermediate devices can be nested, and may be parts of different operational domains?

Pushing down at least one level of detail seems helpful.

[SpencerDawkins]

This is related to the older issue #72 .

[fluffy]

Agree with several people in meeting to spoke to the point that the application would make the choices of how to use the protocol for different types of use cases ( 15 second super bowl vs webex call )

[acbegen]

If we will keep "configurable" we should rather say "configurable latency budget" - not latency. As the latency itself is mostly not configurable.

[SpencerDawkins]

If we will keep "configurable" we should rather say "configurable latency budget" - not latency. As the latency itself is mostly not configurable.

@acbegen - that's SUPER helpful. We should make that change throughout the document.

[SpencerDawkins]

This issue was discussed at the MOQ interim meeting on 2023-01-31 - notes from that meeting are here, and included here by reference.

Anyone working on a PR for this issue should take a look at the discussion notes.

[afrind]

Speaking as an individual, I think that a receiver should be able to make some tradeoffs about latency/liveness vs quality. This is tied to the size of the buffer - a long buffer will offer better quality but lower latency and vice versa. With head-of-line blocked protocols, the receiver can't do very much but show a spinner while the sender retransmits.

Communicating the receiver's preferences to the sender might be useful as the sender can factor that information into it's prioritization and drop decisions, and possibly what protocol mechanisms are used for transport.