Distinguish between lossless and lossy media transport

[SpencerDawkins]

We already have use cases in each category

[kixelated]

I think every protocol can be lossy depending on the implementation. It's quite common to drop frames in RTMP when the TCP socket is full. It's also possible to skip/drop segments in HLS/DASH. The differentiating factor between protocols seems to be how aggressively they can respond to congestion.

[acbegen]

I think every protocol can be lossy depending on the implementation. It's quite common to drop frames in RTMP when the TCP socket is full. It's also possible to skip/drop segments in HLS/DASH. The differentiating factor between protocols seems to be how aggressively they can respond to congestion.

I think the difference is here who makes that choice. In your example, for DASH/HLS the client can opt for skipping some segments to catch up with live edge. To me, this is not a "lossy" transport. Or, the packager may fill the missing data in a segment if it detects the data won't arrive on time (a feature we added in DASH 4th edition). Maybe, this can be called "lossy" but not really since the "filled" segments are later on fixed as the data is recovered (for example in case you rewind and watch that portion again). If RTMP drops some frames and those are never recovered, that is a "lossy" transport. Or lost and unrecovered RTP packets indicate a lossy transport.

Bottom line is that I think we should be more granular than just lossy or losses. Recovery options and on-purpose skipping vs. enforced skipping, these need to be considered.

[SpencerDawkins]

@acbegen - this is a good point, but I think this is also about our definition of Media Transport Protocols in https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.html#name-media-transport-protoccol, and can be clarified there.

I'll think more about this, but that's where I'm starting.

[acbegen]

@acbegen - this is a good point, but I think this is also about our definition of Media Transport Protocols in https://fiestajetsam.github.io/draft-gruessing-moq-requirements/draft-gruessing-moq-requirements.html#name-media-transport-protoccol, and can be clarified there.

You mean section 6.6 maybe?

[SpencerDawkins]

@acbegen - my apologies for not being clear. I think you're right that this should be explained in 6.6 (which is still TODO), but should also be mentioned in 2.2, with forward pointers to 6.6 and wherever else seems right.

[SpencerDawkins]

I'm leaving this discussion for reference during work on requirements, now that MOQ has been chartered.

[SpencerDawkins]

@fiestajetsam and I have revisited this issue, and what we are thinking is

• we agree with @acbegen that "lossy" is relative - at a minimum, we would need to reframe this as reliability/retransmissibility, sender behaviors and receiver behaviors, etc.
• We need to clearly define what "lossy" and "lossless" mean in the MOQ environment, and how "lossy MOQ" is different from traditional lossy transport behavior (no loss detection, no reordering, no retransmission).
• We note that the WARP protocol uses QUIC streams, which will provide flow control, guaranteed delivery, etc. and resetting streams/opening new streams to avoid situations where the normal QUIC stream behavior is inconvenient.
• Are there MOQ use cases where the default QUIC stream behavior plus occasional recovery is not sufficient? If so, we will need to identify special requirements for those use cases, but we need to know what those use cases are, rather than define requirements out of thin air.
• We think we need to wait until IETF 118 timeframe before we can discuss these special MOQ use cases in a concrete form.