Principles
UDP Lite is a new standardized IP transport protocol (
RFC 3828) for
error-prone network environments. It offers to applications such as
streaming media to use the `good
parts' of a partially corrupted packet.
Usually, UDP datagrams are always
discarded when their
checksum (which is a simple one's complement bit sum) does not pass.
This means that the corruption of just one byte leads to the whole
packet being dropped. If the packet is large, (UDP packets
support sizes
up to 64kB),
this can have a clear impact on audio/video/game quality.
UDP Lite makes it possible to
reuse useful information in such cases by limiting the scope of the
checksum length.
Availability and applications
Linux: UDP Lite has been a part of the Linux kernel since version 2.6.20.
Several applications for testing are included in the tarball:
- a client-server
application in C to test the connectivity and features
- W. Richard Stevens' sock program
ported to UDP Lite (many more testing options)
- a patched version of the ttcp network
test program
- a patch for the Video LAN client for streaming MPEG, DVD, DVB ....
over UDP Lite
- UDP-Lite programs in Perl: two client / server applications
Download here the
latest tarball, including all
applications and instructions how to set these up. A
HOWTO is included in the
distribution.
FreeBSD: UDP Lite has been a part of the FreeBSD since April 2014.
Included in FreeBSD 10.1
Wireshark
Thanks to the work of Jaap Keuter, Wireshark (formerly known as Ethereal) can now decode UDP-Lite,
there is also a WiKi
with capture files. The following shows Ethereal in action, using the
following capture
file which traced the transfer of "hello world\n".
The protocol type shows as 0x88 (136 in decimal). The
following decodes the data
highlighted above. Our payload is 12 bytes including CR/LF (0xa), the
total is 20bytes.
Hex
Value
|
Meaning
|
Value
|
8000
|
Source port
|
32768 |
04d2
|
Destination port
|
1234 |
0008
|
Checksum coverage length
|
8 bytes (header only)
|
ca15
|
UDP Lite checksum
|
correct (see below)
|
6865
6c6c 6f20
|
payload data
|
hello + ' '
|
776f
726c 640a
|
payload
data
|
world
+ '\n'
|
The checksum coverage is set to the minimum here, 8 bytes, which
covers only the header. The actual checksum calculation uses the same algorithm as TCP
and UDP, i.e. the one's complement of all the octets plus a pre-fixed
pseudo header (see example below).
Detailed information
In the minimal case, the UDP checksum covers only the header (8 bytes),
in the other extreme the
checksum covers the entire packet -- in this case UDP Lite does exactly
the same as UDP. To achieve compatibility with the 8-byte UDP header
format (
RFC 768), the
Length field of the UDP header is re-interpreted
as `checksum coverage length'. The UDP length field is redundant:
it
can be retrieved from the IP payload length(s). For comparison, here is
the
original UDP
header:
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
And this is the UDP Lite header (
RFC 3828):
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
As can be seen, if
Checksum Coverage
=
Length, there is virtually
no
difference between UDP and UDP Lite.
If the checksum coverage field is 0, this means that the entire packet
is covered by the checksum field, otherwise the value is minimally 8.
Packets with a coverage length less than 8
must be
discarded, the same goes for packets whose coverage length exceeds the
packet length. A failure to do so in the latter case can result
in reading beyond the end of the packet buffer (i.e. illegal memory
access by the driver).
Checksum computation example
With regard to the above
figure, we here
show how the checksum is computed. Like IP, TCP, and UDP, UDP Lite uses
the 1's complement of the 1's complement sum of 16-bit integers. This
is slightly unusual, since most computers use 2's complement
representation of integers. Practically, the 1's complement sum of
16-bit integers can be achieved by summing these up as a 32-bit
integer, and then add the carry (i.e. the value obtained by and-ing
with 0xFFFF0000) to the lower two bytes. The process is described in
detail, and with algorithms, in
RFC 1071. Here we show
how it works for UDP Lite on the above trace.
The first set of 16-bit words is the pseudo header, which contains the
hex values for source/destination IP, total IP payload length, and
protocol type. The following table shows the values for the above trace.
Pseudo
Header Field
|
Value
|
Hex
Value |
Source IP
address
|
139.133.204.183
|
8B85 CCB7 |
Destination
IP address
|
139.133.204.176 |
8B85 CCB0 |
IANA
Protocol Type
|
136 (UDP Lite)
|
0088 |
IP Payload
length
|
20 bytes
|
0014 |
The sum of these words is
0002 B10D.
The UDP Lite packet from above in hex looks like this (header is marked
in bold).
8000 04D2 0008 0000
6865 6C6C 6F20 776F 726C 640A |
Note that the checksum field (last two octets of the header)
is set to zero. This is required for the checksum computation.
The third field, 0008, denotes the
checksum
coverage length. It is set to 8 in this example which means that
only the header is covered.
With regard to the
checksum,
we thus have to add
8000 +
04D2 + 0008 + 0000 = 84DA
To this we add the sum over the
pseudo-header:
0002
B10D + 84DA
= 0003 35E7
This is a 32-bit value, to obtain the 16-bit one's complement
sum, we add the (`end-around') carry:
0003
+ 35E7 = 35EA
We are almost done: it remains to create the
one's complement of this sum, by
subtracting it from FFFF:
FFFF
- 35EA = CA15
Compare with the above - this is the value showing up in the checksum
field of the UDP Lite header. This kind of arithmetic can very easily
be done using the
bc(1)
calculator, by setting `
obase=16;
ibase=16' at the beginning and only using capital letters for
the hex values. More checksum computation examples
can be found on
this page.
Literature
- RFC 3828 - UDP Lite protocol standard.
- RFC 5405 - Unicast UDP Usage Guidelines for Application Designers (BCP 145), section 3.4.1.
- Wireshark
WiKi with information and sample capture files
- Stanislaus, Fairhurst and Radzik:
Cross-Layer techniques for flexible transport protocols (UDP-Lite and
DCCP) over a satellite network. Proceedings of the International
Workshop on Satellite and Space Communications (IWSSC-05). [PDF]
- Hammer et al.: Corrupted Speech Data Considered Useful.
Proc. 1st ISCA Tutorial and Research Workshop on Auditory Quality of
Systems, Mont Cenis, Germany, April 2003. [PDF]
- Singh, Konrad, Joseph: Performance
Evaluation of UDP Lite for Cellular Video. Proc. 11th Int.
Workshop on Network and Operating Systems Support for Digital Audio and
Video, 2001. [PDF]
[ACM]
- Larzon, Degermark, Pink:
Efficient use of Wireless Bandwidth for Multimedia Applications.
IEEE MoMuC '99. [Citeseer]
- Larzon, Degermark, Pink: UDP
Lite for Real-Time Multimedia Applications. Proc. IEEE ICC-99.
[PDF] [PS]
- RFC 4019 - G.
Pelletier. RObust Header
Compression (ROHC) Profiles for UDP-Lite.