Regarding UDP-Lite deprecation and removal

* Regarding UDP-Lite deprecation and removal
@ 2024-03-17  0:34 Lynne
  2024-03-18 10:36 ` Paolo Abeni
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Lynne @ 2024-03-17  0:34 UTC (permalink / raw)
  To: Netdev; +Cc: Kuniyu, Willemdebruijn Kernel

Hello,

UDP-Lite was scheduled to be removed in 2025 in commit
be28c14ac8bbe1ff due to a lack of real-world users, and
a long-outstanding security bug being left undiscovered.

I would like to open a discussion to perhaps either avoid this,
or delay it, conditionally.

To give some context, UDP-Lite was designed as an even-more
unreliable protocol, with limited CRC coverage, to enable
very low latency multimedia transmissions. Due to roundtrip
times often being longer than a single frame's duration, it
simply becomes impractical to retransmit corrupt packets.

Instead of simply not showing a frame, it is preferable to
allow corruption within the packet, due to video decoders
themselves being resilient to bitflips, as any differences
within the frame will, at worst, fade away over a number
of frames due to prediction.

UDP-Lite was slow to reach adoption, mainly due to
broadcasting companies still using SDI internally, rather
than IP, and popular applications's own protocols,
like Flash (that one) using TCP (RTMP) or HTTP (HLS/DASH)
instead. MPEG-TS over UDP was preferred for point-to-point
broadcasts over the internet, partially due to potential issues
with incompatible gateways.

An additional limitation of MPEG-TS was its large vulnerability
to bitflips, with it only supporting 188-byte packets, and most
of it being packet headers full of optional branches affecting
demuxing, where a single bitflip could result in missing more
than a single frame due to corrupted state.

For the majority of consumer broadcasts, UDP itself
has only somewhat recently started getting traction, due
to WebRTC becoming a standard.

Due to the limitations of video transmission becoming
more and more visible, as the whole streaming ecosystem
and standards keeps improving, eventually, I think, it is bound
that a use-case will arise for UDP-Lite.

I am an FFmpeg developer and, alongside assistance from developers
from other organizations, VideoLAN and Xiph, we are working on a new
transmission protocol for multimedia, called AVTransport.
The specification can be viewed here: https://cyanreg.github.io/avtransport/
UDP-Lite specific streaming details are on chapter 3.3.2

It was designed from the start to take advantage of UDP-Lite
at its minimum permitted CRC size. All its vital packet data
(such as type, length, timestamps) is protected by LDPC codes,
and not only collections of frames, but individual packets themselves
being able to have FEC, allowing for minimum latency transmission
even over wet unbalanced strings, and meeting the requirements
for long-term archival.

The protocol itself is still in a draft form, and its reference implementation
is only just starting to become functional.
UDP-Lite is already supported, and is tested. The specification actually
recommends using UDP-Lite over UDP, due to the protocol's robustness.

FFmpeg, has also supported UDP-Lite, for RTC or MPEG-TS, for a
very long time, and I cannot say with certainty that no one
is using this without letting us know. What I do know is that
someone cared enough for it to send a patch.

Other operating systems still maintain their UDP-Lite implementations,
and have made no deprecation plans yet.

At the very least, without UDP-Lite, someone may think of a new,
possibly proprietary way, once this problem is encountered.

Given all this, I would like to ask if it would be possible to maintain
UDP-Lite support, even if only partially. I would be fine with its CRC
coverage being fixed to its lowest value, or even doing reviews for
patches or bugs submitted to the LKML.

At the very least, there is already a way for users to retrieve raw,
uncorrected UDP packets (by settings rx-fcs and rx-all on network
interfaces, which most support). Perhaps some compromise could
be reached by giving users the responsibility to check CRC themselves?

Thanks,
Lynne

^ permalink raw reply	[flat|nested] 9+ messages in thread