If we regard SCTP as "TCP++," then UDP-Lite is "UDP++"—or actually "UDP--"—because its only feature is the possibility to restrain or even disable the original UDP checksum (Larzon et al., 2004). The reason to do so is easily explained: there are video and audio codecs that can deal with bit errors (which can, for example, be caused by link noise in a wireless environment). However, even if only a single bit is wrong, the UDP checksum will fail, causing the receiver to drop the whole packet from the stack. The codec then ends up with a large number of bytes missing, as potentially useful data that actually made it to the receiver were discarded by the operating system.

The UDP-Lite header is very similar to the UDP header—just the "Length" field, which is redundant because the length of a datagram is contained in the IP header, was replaced with a field called "Checksum Coverage." It represents the number of bytes, counting from the beginning of the UDP-Lite header, that are covered by the checksum. Such partial coverage can be useful for certain codecs—the "adaptive multi-rate" and "adaptive multi-rate wideband" audio codecs, for example (Sjoberg, Westerlund, Lakaniemi, & Xie, 2002). In any case, it is mandatory to have the header checked because, without knowing that the header is correct, even the port numbers can be wrong and the whole communication flow becomes meaningless (it is actually possible to disable the checksum altogether in standard UDP, but this feature is rather useless).

Despite its simplicity and its seemingly obvious advantages, UDP-Lite caused a lot of discussions in the IETF. The main problem is the fact that UDP-Lite does not yield any benefits whatsoever unless a link layer technology actually hands over corrupt data. Since it is the first IETF development to have that requirement, link layer technologies were so far optimized for protocols that require data integrity. Typically, there is a strong checksum, and often, corrupt frames are retransmitted with a certain persistence and eventually dropped and not forwarded by the link layer (Fairhurst & Wood, 2002); this is, for example, the case with standard 802.11 wireless LAN systems.² UDP-Lite can be seen as being at odds with the notion "IP over everything," as it enables application programmers to write an application that works well in one environment (where there is a small loss ratio) and does not work at all in another. These issues are actually quite intricate; more details can be found in Welzl (2005). In any Page 134 case, from the perspective of a mobile multimedia application programmer, UDP-Lite is probably an attractive protocol, and after a couple of years of discussion, it has been published as a "Proposed Standard" RFC by the IETF. Since it was designed to be downward compatible with UDP, there is not much harm in using it even though the benefits can only be attained if an underlying link layer hands over corrupt data.