This site will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device.

UDP Lite WiKi


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

UDP-Lite is now 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.

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

  • 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.