← Documents Documentation/networking/udplite.rst GitHub 원문 ↗

Linux 6.18.37 · Networking

The UDP-Lite protocol (RFC 3828)

UDP-Lite의 partial checksum coverage socket API, kernel normalization, fragmentation 계산과 runtime 통계를 설명합니다.

Source pathDocumentation/networking/udplite.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

udplite.rst:1-291

UDP-Lite는 packet 일부만 checksum해 noisy link의 multimedia payload가 부분 손상되더라도 codec에 전달할 수 있게 합니다. Sender는 coverage 길이를 정하고 receiver는 수락할 최소 coverage를 filter로 설정할 수 있습니다.

Kernel은 coverage가 8보다 작거나 packet보다 클 때 값을 보정하며 checksum 자체는 끌 수 없습니다. Send buffer와 MTU에 따른 packet 분할·IP fragmentation에서도 coverage byte 수를 fragment 경계에 맞춰 정확히 계산합니다.

UDP-Lite partial coverage
SOCK_DGRAM/IPPROTO_UDPLITEUDPLITE_SEND_CSCOVHeader + protected payload checksumNetwork damage 허용 영역UDPLITE_RECV_CSCOV filterCodec

Application 설정부터 receiver filter까지의 경로입니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 .. SPDX-License-Identifier: GPL-2.0
2
3 ================================
4 The UDP-Lite protocol (RFC 3828)
5 ================================
6
7
8 UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
9 is a variable-length checksum. This has advantages for transport of multimedia
10 (video, VoIP) over wireless networks, as partly damaged packets can still be
11 fed into the codec instead of being discarded due to a failed checksum test.
12
13 This file briefly describes the existing kernel support and the socket API.
14 For in-depth information, you can consult:
15
16 - The UDP-Lite Homepage:
17 http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
18
19 From here you can also download some example application source code.
20
21 - The UDP-Lite HOWTO on
22 http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
23
24 - The Wireshark UDP-Lite WiKi (with capture files):
25 https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
26
27 - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
28
29
30 1. Applications
31 ===============
32
33 Several applications have been ported successfully to UDP-Lite. Ethereal
34 (now called wireshark) has UDP-Litev4/v6 support by default.
35
36 Porting applications to UDP-Lite is straightforward: only socket level and
37 IPPROTO need to be changed; senders additionally set the checksum coverage
38 length (default = header length = 8). Details are in the next section.
39
40 2. Programming API
41 ==================
42
43 UDP-Lite provides a connectionless, unreliable datagram service and hence
44 uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
45 very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
46 socket(2) call so that the statement looks like::
47
48 s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
49
50 or, respectively,
51
52 ::
53
54 s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
55
56 With just the above change you are able to run UDP-Lite services or connect
57 to UDP-Lite servers. The kernel will assume that you are not interested in
58 using partial checksum coverage and so emulate UDP mode (full coverage).
59
60 To make use of the partial checksum coverage facilities requires setting a
61 single socket option, which takes an integer specifying the coverage length:
62
63 * Sender checksum coverage: UDPLITE_SEND_CSCOV
64
65 For example::
66
67 int val = 20;
68 setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
69
70 sets the checksum coverage length to 20 bytes (12b data + 8b header).
71 Of each packet only the first 20 bytes (plus the pseudo-header) will be
72 checksummed. This is useful for RTP applications which have a 12-byte
73 base header.
74
75
76 * Receiver checksum coverage: UDPLITE_RECV_CSCOV
77
78 This option is the receiver-side analogue. It is truly optional, i.e. not
79 required to enable traffic with partial checksum coverage. Its function is
80 that of a traffic filter: when enabled, it instructs the kernel to drop
81 all packets which have a coverage _less_ than this value. For example, if
82 RTP and UDP headers are to be protected, a receiver can enforce that only
83 packets with a minimum coverage of 20 are admitted::
84
85 int min = 20;
86 setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
87
88 The calls to getsockopt(2) are analogous. Being an extension and not a stand-
89 alone protocol, all socket options known from UDP can be used in exactly the
90 same manner as before, e.g. UDP_CORK or UDP_ENCAP.
91
92 A detailed discussion of UDP-Lite checksum coverage options is in section IV.
93
94 3. Header Files
95 ===============
96
97 The socket API requires support through header files in /usr/include:
98
99 * /usr/include/netinet/in.h
100 to define IPPROTO_UDPLITE
101
102 * /usr/include/netinet/udplite.h
103 for UDP-Lite header fields and protocol constants
104
105 For testing purposes, the following can serve as a ``mini`` header file::
106
107 #define IPPROTO_UDPLITE 136
108 #define SOL_UDPLITE 136
109 #define UDPLITE_SEND_CSCOV 10
110 #define UDPLITE_RECV_CSCOV 11
111
112 Ready-made header files for various distros are in the UDP-Lite tarball.
113
114 4. Kernel Behaviour with Regards to the Various Socket Options
115 ==============================================================
116
117
118 To enable debugging messages, the log level need to be set to 8, as most
119 messages use the KERN_DEBUG level (7).
120
121 1) Sender Socket Options
122
123 If the sender specifies a value of 0 as coverage length, the module
124 assumes full coverage, transmits a packet with coverage length of 0
125 and according checksum. If the sender specifies a coverage < 8 and
126 different from 0, the kernel assumes 8 as default value. Finally,
127 if the specified coverage length exceeds the packet length, the packet
128 length is used instead as coverage length.
129
130 2) Receiver Socket Options
131
132 The receiver specifies the minimum value of the coverage length it
133 is willing to accept. A value of 0 here indicates that the receiver
134 always wants the whole of the packet covered. In this case, all
135 partially covered packets are dropped and an error is logged.
136
137 It is not possible to specify illegal values (<0 and <8); in these
138 cases the default of 8 is assumed.
139
140 All packets arriving with a coverage value less than the specified
141 threshold are discarded, these events are also logged.
142
143 3) Disabling the Checksum Computation
144
145 On both sender and receiver, checksumming will always be performed
146 and cannot be disabled using SO_NO_CHECK. Thus::
147
148 setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... );
149
150 will always will be ignored, while the value of::
151
152 getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
153
154 is meaningless (as in TCP). Packets with a zero checksum field are
155 illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
156
157 4) Fragmentation
158
159 The checksum computation respects both buffersize and MTU. The size
160 of UDP-Lite packets is determined by the size of the send buffer. The
161 minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
162 in include/net/sock.h), the default value is configurable as
163 net.core.wmem_default or via setting the SO_SNDBUF socket(7)
164 option. The maximum upper bound for the send buffer is determined
165 by net.core.wmem_max.
166
167 Given a payload size larger than the send buffer size, UDP-Lite will
168 split the payload into several individual packets, filling up the
169 send buffer size in each case.
170
171 The precise value also depends on the interface MTU. The interface MTU,
172 in turn, may trigger IP fragmentation. In this case, the generated
173 UDP-Lite packet is split into several IP packets, of which only the
174 first one contains the L4 header.
175
176 The send buffer size has implications on the checksum coverage length.
177 Consider the following example::
178
179 Payload: 1536 bytes Send Buffer: 1024 bytes
180 MTU: 1500 bytes Coverage Length: 856 bytes
181
182 UDP-Lite will ship the 1536 bytes in two separate packets::
183
184 Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
185 Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes
186
187 The coverage packet covers the UDP-Lite header and 848 bytes of the
188 payload in the first packet, the second packet is fully covered. Note
189 that for the second packet, the coverage length exceeds the packet
190 length. The kernel always re-adjusts the coverage length to the packet
191 length in such cases.
192
193 As an example of what happens when one UDP-Lite packet is split into
194 several tiny fragments, consider the following example::
195
196 Payload: 1024 bytes Send buffer size: 1024 bytes
197 MTU: 300 bytes Coverage length: 575 bytes
198
199 +-+-----------+--------------+--------------+--------------+
200 |8| 272 | 280 | 280 | 280 |
201 +-+-----------+--------------+--------------+--------------+
202 280 560 840 1032
203 ^
204 *****checksum coverage*************
205
206 The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
207 header). According to the interface MTU, these are split into 4 IP
208 packets (280 byte IP payload + 20 byte IP header). The kernel module
209 sums the contents of the entire first two packets, plus 15 bytes of
210 the last packet before releasing the fragments to the IP module.
211
212 To see the analogous case for IPv6 fragmentation, consider a link
213 MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
214 coverage is less than 1232 bytes (MTU minus IPv6/fragment header
215 lengths), only the first fragment needs to be considered. When using
216 larger checksum coverage lengths, each eligible fragment needs to be
217 checksummed. Suppose we have a checksum coverage of 3062. The buffer
218 of 3356 bytes will be split into the following fragments::
219
220 Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data
221 Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data
222 Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data
223
224 The first two fragments have to be checksummed in full, of the last
225 fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
226
227 While it is important that such cases are dealt with correctly, they
228 are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
229 performance over wireless (or generally noisy) links and thus smaller
230 coverage lengths are likely to be expected.
231
232 5. UDP-Lite Runtime Statistics and their Meaning
233 ================================================
234
235 Exceptional and error conditions are logged to syslog at the KERN_DEBUG
236 level. Live statistics about UDP-Lite are available in /proc/net/snmp
237 and can (with newer versions of netstat) be viewed using::
238
239 netstat -svu
240
241 This displays UDP-Lite statistics variables, whose meaning is as follows.
242
243 ============ =====================================================
244 InDatagrams The total number of datagrams delivered to users.
245
246 NoPorts Number of packets received to an unknown port.
247 These cases are counted separately (not as InErrors).
248
249 InErrors Number of erroneous UDP-Lite packets. Errors include:
250
251 * internal socket queue receive errors
252 * packet too short (less than 8 bytes or stated
253 coverage length exceeds received length)
254 * xfrm4_policy_check() returned with error
255 * application has specified larger min. coverage
256 length than that of incoming packet
257 * checksum coverage violated
258 * bad checksum
259
260 OutDatagrams Total number of sent datagrams.
261 ============ =====================================================
262
263 These statistics derive from the UDP MIB (RFC 2013).
264
265 6. IPtables
266 ===========
267
268 There is packet match support for UDP-Lite as well as support for the LOG target.
269 If you copy and paste the following line into /etc/protocols::
270
271 udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
272
273 then::
274
275 iptables -A INPUT -p udplite -j LOG
276
277 will produce logging output to syslog. Dropping and rejecting packets also works.
278
279 7. Maintainer Address
280 =====================
281
282 The UDP-Lite patch was developed at
283
284 University of Aberdeen
285 Electronics Research Group
286 Department of Engineering
287 Fraser Noble Building
288 Aberdeen AB24 3UE; UK
289
290 The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
291 code was developed by William Stanislaus, <william@erg.abdn.ac.uk>.
292

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

UDP-Lite 개요와 참고 자료

1-29

UDP-Lite는 가변 길이 checksum을 특징으로 하는 IETF Standards-Track transport protocol입니다. Wireless network에서 multimedia(video, VoIP)를 전송할 때 일부가 손상된 packet을 checksum 실패로 버리지 않고 codec에 전달할 수 있다는 장점이 있습니다.

이 문서는 기존 kernel 지원과 socket API를 간략히 설명합니다. 자세한 자료로 UDP-Lite homepage와 HOWTO, capture file이 있는 Wireshark wiki, protocol specification인 RFC 3828을 안내하며 homepage에서는 example application source도 받을 수 있습니다.

.. SPDX-License-Identifier: GPL-2.0

================================
The UDP-Lite protocol (RFC 3828)
================================


  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
  is a variable-length checksum. This has advantages for transport of multimedia
  (video, VoIP) over wireless networks, as partly damaged packets can still be
  fed into the codec instead of being discarded due to a failed checksum test.

  This file briefly describes the existing kernel support and the socket API.
  For in-depth information, you can consult:

   - The UDP-Lite Homepage:
     http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/

     From here you can also download some example application source code.

   - The UDP-Lite HOWTO on
     http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt

   - The Wireshark UDP-Lite WiKi (with capture files):
     https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol

   - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt

Application porting

30-39

여러 application이 UDP-Lite로 성공적으로 port되었고, Ethereal의 후속인 Wireshark는 기본적으로 UDP-Litev4와 UDP-Litev6를 지원합니다.

Application porting은 간단합니다. Socket protocol level과 `IPPROTO`를 바꾸고, sender는 checksum coverage length도 설정합니다. 기본 coverage는 8-byte header 길이입니다.

1. Applications
===============

  Several applications have been ported successfully to UDP-Lite. Ethereal
  (now called wireshark) has UDP-Litev4/v6 support by default.

  Porting applications to UDP-Lite is straightforward: only socket level and
  IPPROTO need to be changed; senders additionally set the checksum coverage
  length (default = header length = 8). Details are in the next section.

Programming API와 checksum coverage

40-93

UDP-Lite는 UDP처럼 connectionless이고 신뢰성을 보장하지 않는 datagram service이므로 같은 `SOCK_DGRAM` socket type을 사용합니다. IPv4는 `socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE)`, IPv6는 `PF_INET6`로 만듭니다.

Protocol argument만 바꿔도 UDP-Lite service를 실행하거나 server에 연결할 수 있습니다. 별도 option이 없으면 kernel은 partial checksum coverage를 원하지 않는다고 보고 UDP처럼 packet 전체를 checksum합니다.

Partial coverage를 사용하려면 integer coverage length를 받는 socket option 하나를 설정합니다. Sender option `UDPLITE_SEND_CSCOV`에 20을 지정하면 8-byte UDP-Lite header와 12-byte data, 그리고 pseudo-header만 checksum합니다. 12-byte base header를 가진 RTP에 유용합니다.

Receiver option `UDPLITE_RECV_CSCOV`는 선택 사항이며 partial coverage traffic을 받기 위해 반드시 설정할 필요는 없습니다. 설정하면 traffic filter로 작동해 coverage가 지정한 최소값보다 작은 packet을 kernel이 drop합니다. RTP와 UDP header를 보호하려면 최소값 20을 요구할 수 있습니다.

`getsockopt()`도 같은 방식으로 사용합니다. UDP-Lite는 독립 protocol이 아니라 UDP extension이므로 `UDP_CORK`, `UDP_ENCAP`을 비롯한 UDP socket option을 그대로 사용할 수 있습니다.

UDP-Lite coverage option
Option방향값의 의미
UDPLITE_SEND_CSCOVSender각 packet에서 checksum할 byte 수
UDPLITE_RECV_CSCOVReceiver수락할 최소 coverage, 미달 packet drop

송신 범위와 수신 최소 허용 범위를 구분합니다.

2. Programming API
==================

  UDP-Lite provides a connectionless, unreliable datagram service and hence
  uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
  very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
  socket(2) call so that the statement looks like::

      s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);

  or, respectively,

  ::

      s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);

  With just the above change you are able to run UDP-Lite services or connect
  to UDP-Lite servers. The kernel will assume that you are not interested in
  using partial checksum coverage and so emulate UDP mode (full coverage).

  To make use of the partial checksum coverage facilities requires setting a
  single socket option, which takes an integer specifying the coverage length:

    * Sender checksum coverage: UDPLITE_SEND_CSCOV

      For example::

        int val = 20;
        setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));

      sets the checksum coverage length to 20 bytes (12b data + 8b header).
      Of each packet only the first 20 bytes (plus the pseudo-header) will be
      checksummed. This is useful for RTP applications which have a 12-byte
      base header.


    * Receiver checksum coverage: UDPLITE_RECV_CSCOV

      This option is the receiver-side analogue. It is truly optional, i.e. not
      required to enable traffic with partial checksum coverage. Its function is
      that of a traffic filter: when enabled, it instructs the kernel to drop
      all packets which have a coverage _less_ than this value. For example, if
      RTP and UDP headers are to be protected, a receiver can enforce that only
      packets with a minimum coverage of 20 are admitted::

        int min = 20;
        setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));

  The calls to getsockopt(2) are analogous. Being an extension and not a stand-
  alone protocol, all socket options known from UDP can be used in exactly the
  same manner as before, e.g. UDP_CORK or UDP_ENCAP.

  A detailed discussion of UDP-Lite checksum coverage options is in section IV.

Header file과 protocol constant

94-113

Socket API를 사용하려면 `/usr/include/netinet/in.h`가 `IPPROTO_UDPLITE`를 정의하고 `/usr/include/netinet/udplite.h`가 UDP-Lite header field와 protocol constant를 제공해야 합니다.

시험용 mini header에서는 `IPPROTO_UDPLITE`와 `SOL_UDPLITE`를 136, `UDPLITE_SEND_CSCOV`를 10, `UDPLITE_RECV_CSCOV`를 11로 정의할 수 있습니다. 여러 distribution용 완성 header는 UDP-Lite tarball에 있습니다.

UDP-Lite constant
SymbolValue
IPPROTO_UDPLITE136
SOL_UDPLITE136
UDPLITE_SEND_CSCOV10
UDPLITE_RECV_CSCOV11

문서의 시험용 mini header 값입니다.

3. Header Files
===============

  The socket API requires support through header files in /usr/include:

    * /usr/include/netinet/in.h
      to define IPPROTO_UDPLITE

    * /usr/include/netinet/udplite.h
      for UDP-Lite header fields and protocol constants

  For testing purposes, the following can serve as a ``mini`` header file::

    #define IPPROTO_UDPLITE       136
    #define SOL_UDPLITE           136
    #define UDPLITE_SEND_CSCOV     10
    #define UDPLITE_RECV_CSCOV     11

  Ready-made header files for various distros are in the UDP-Lite tarball.

Socket option에 대한 kernel 동작

114-161

Debug message 대부분이 `KERN_DEBUG` level 7을 사용하므로 확인하려면 log level을 8로 설정해야 합니다.

Sender가 coverage length 0을 지정하면 module은 full coverage로 해석하고 coverage field가 0인 packet과 해당 checksum을 전송합니다. 0이 아니면서 8보다 작으면 기본값 8을 사용하고, 지정 coverage가 packet length보다 크면 packet length로 줄입니다.

Receiver option은 허용할 최소 coverage를 지정합니다. 값 0은 packet 전체가 항상 checksum되기를 원한다는 뜻이므로 partial coverage packet을 모두 drop하고 error를 기록합니다.

음수나 0이 아닌 8 미만 같은 illegal value는 지정할 수 없으며 기본값 8을 사용합니다. 도착 packet의 coverage가 설정 threshold보다 작아도 packet을 버리고 event를 log합니다.

Sender와 receiver 모두 checksum 계산은 항상 수행하며 `SO_NO_CHECK`로 끌 수 없습니다. `setsockopt(... SO_NO_CHECK ...)`는 항상 무시되고 `getsockopt()` 값도 TCP와 마찬가지로 의미가 없습니다. Checksum field가 0인 packet은 RFC 3828 section 3.1에 따라 illegal이며 조용히 폐기됩니다.

Coverage normalization
입력SenderReceiver
0Full coverage, field 0Full coverage packet만 허용
0이 아닌 8 미만 또는 illegal8로 조정8로 조정
Packet length 초과Packet length로 조정해당 없음
Threshold 미달 packet해당 없음Drop 및 log

Sender와 receiver가 특수값을 해석하는 규칙입니다.

4. Kernel Behaviour with Regards to the Various Socket Options
==============================================================


  To enable debugging messages, the log level need to be set to 8, as most
  messages use the KERN_DEBUG level (7).

  1) Sender Socket Options

  If the sender specifies a value of 0 as coverage length, the module
  assumes full coverage, transmits a packet with coverage length of 0
  and according checksum.  If the sender specifies a coverage < 8 and
  different from 0, the kernel assumes 8 as default value.  Finally,
  if the specified coverage length exceeds the packet length, the packet
  length is used instead as coverage length.

  2) Receiver Socket Options

  The receiver specifies the minimum value of the coverage length it
  is willing to accept.  A value of 0 here indicates that the receiver
  always wants the whole of the packet covered. In this case, all
  partially covered packets are dropped and an error is logged.

  It is not possible to specify illegal values (<0 and <8); in these
  cases the default of 8 is assumed.

  All packets arriving with a coverage value less than the specified
  threshold are discarded, these events are also logged.

  3) Disabling the Checksum Computation

  On both sender and receiver, checksumming will always be performed
  and cannot be disabled using SO_NO_CHECK. Thus::

        setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );

  will always will be ignored, while the value of::

        getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);

  is meaningless (as in TCP). Packets with a zero checksum field are
  illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.

  4) Fragmentation

  The checksum computation respects both buffersize and MTU. The size
  of UDP-Lite packets is determined by the size of the send buffer. The
  minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF

Send buffer, MTU와 fragmentation

162-231

Checksum 계산은 send buffer size와 MTU를 모두 고려합니다. UDP-Lite packet size는 send buffer size가 결정합니다. 최소 send buffer는 `include/net/sock.h`의 `SOCK_MIN_SNDBUF`인 2048이고, 기본값은 `net.core.wmem_default` 또는 `SO_SNDBUF`로 설정하며 최대 상한은 `net.core.wmem_max`입니다.

Payload가 send buffer보다 크면 UDP-Lite는 buffer size만큼 채운 여러 개의 독립 packet으로 나눕니다. 정확한 결과는 interface MTU에도 좌우되며 MTU 때문에 IP fragmentation이 발생하면 첫 IP fragment에만 L4 header가 들어갑니다.

첫 예에서 payload 1536 bytes, send buffer 1024, MTU 1500, coverage 856이면 1024-byte payload packet과 512-byte payload packet 두 개를 보냅니다. 각 packet에는 8-byte UDP-Lite header와 20-byte IP header가 붙어 전체 1052와 540 bytes가 됩니다.

첫 packet에서는 UDP-Lite header와 payload 848 bytes가 checksum되고, 둘째 packet은 전체가 checksum됩니다. 둘째 packet은 coverage length가 packet length보다 크므로 kernel이 packet length에 맞춰 다시 조정합니다.

작은 fragment 예는 payload 1024, send buffer 1024, MTU 300, coverage 575입니다. Module은 8-byte header를 포함한 1032-byte UDP-Lite packet 하나를 만들고, MTU에 따라 IP payload 280 bytes와 IP header 20 bytes인 네 IP packet으로 나눕니다.

Checksum은 첫 두 fragment의 내용을 모두 더하고 세 번째 fragment의 앞 15 bytes까지 포함합니다. 이 계산을 마친 뒤 fragment를 IP module로 넘깁니다.

IPv4 tiny-fragment coverage
FragmentUDP-Lite data누적 offsetChecksum
18-byte header + 272-byte payload280전체
2280-byte payload560전체
3280-byte payload840앞 15 bytes
4280-byte payload1032미포함

원문의 ASCII diagram을 같은 크기와 coverage 경계로 구조화했습니다.

IPv6 예에서는 link MTU 1280과 write buffer 3356을 사용합니다. Coverage가 IPv6와 fragment header를 뺀 1232보다 작으면 첫 fragment만 보면 되지만, 더 크면 coverage에 걸치는 각 fragment를 checksum해야 합니다.

Coverage 3062이면 3356-byte buffer는 UDP-Lite data 1232 bytes를 담은 1280-byte fragment 두 개와 data 900 bytes를 담은 948-byte fragment 하나로 나뉩니다. 첫 두 fragment는 전부, 마지막 fragment는 `3062 - 2*1232 = 598` bytes만 checksum합니다.

이 corner case도 정확히 처리해야 하지만 UDP-Lite는 noisy wireless link의 multimedia 성능을 위해 설계되어 보통 더 짧은 coverage를 사용하므로 실제 발생은 드뭅니다.

  in include/net/sock.h), the default value is configurable as
  net.core.wmem_default or via setting the SO_SNDBUF socket(7)
  option. The maximum upper bound for the send buffer is determined
  by net.core.wmem_max.

  Given a payload size larger than the send buffer size, UDP-Lite will
  split the payload into several individual packets, filling up the
  send buffer size in each case.

  The precise value also depends on the interface MTU. The interface MTU,
  in turn, may trigger IP fragmentation. In this case, the generated
  UDP-Lite packet is split into several IP packets, of which only the
  first one contains the L4 header.

  The send buffer size has implications on the checksum coverage length.
  Consider the following example::

    Payload: 1536 bytes          Send Buffer:     1024 bytes
    MTU:     1500 bytes          Coverage Length:  856 bytes

  UDP-Lite will ship the 1536 bytes in two separate packets::

    Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
    Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes

  The coverage packet covers the UDP-Lite header and 848 bytes of the
  payload in the first packet, the second packet is fully covered. Note
  that for the second packet, the coverage length exceeds the packet
  length. The kernel always re-adjusts the coverage length to the packet
  length in such cases.

  As an example of what happens when one UDP-Lite packet is split into
  several tiny fragments, consider the following example::

    Payload: 1024 bytes            Send buffer size: 1024 bytes
    MTU:      300 bytes            Coverage length:   575 bytes

    +-+-----------+--------------+--------------+--------------+
    |8|    272    |      280     |     280      |     280      |
    +-+-----------+--------------+--------------+--------------+
                280            560            840           1032
                                        ^
    *****checksum coverage*************

  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
  header). According to the interface MTU, these are split into 4 IP
  packets (280 byte IP payload + 20 byte IP header). The kernel module
  sums the contents of the entire first two packets, plus 15 bytes of
  the last packet before releasing the fragments to the IP module.

  To see the analogous case for IPv6 fragmentation, consider a link
  MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
  coverage is less than 1232 bytes (MTU minus IPv6/fragment header
  lengths), only the first fragment needs to be considered. When using
  larger checksum coverage lengths, each eligible fragment needs to be
  checksummed. Suppose we have a checksum coverage of 3062. The buffer
  of 3356 bytes will be split into the following fragments::

    Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
    Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
    Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data

  The first two fragments have to be checksummed in full, of the last
  fragment only 598 (= 3062 - 2*1232) bytes are checksummed.

  While it is important that such cases are dealt with correctly, they
  are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
  performance over wireless (or generally noisy) links and thus smaller
  coverage lengths are likely to be expected.

Runtime statistic

232-264

예외와 오류는 `KERN_DEBUG` level로 syslog에 기록합니다. UDP-Lite live statistic은 `/proc/net/snmp`에서 제공하며 새 `netstat`에서는 `netstat -svu`로 볼 수 있습니다.

`InDatagrams`는 userspace에 전달한 datagram 총수, `NoPorts`는 알려지지 않은 port로 받은 packet 수입니다. `NoPorts`는 `InErrors`와 별도로 계산합니다.

`InErrors`는 잘못된 UDP-Lite packet 수입니다. Internal socket queue receive error, 8 bytes 미만의 짧은 packet, 선언 coverage가 수신 length를 초과한 packet, `xfrm4_policy_check()` error, application의 최소 coverage보다 작은 incoming packet, coverage 위반과 bad checksum을 포함합니다.

`OutDatagrams`는 보낸 datagram 총수입니다. 이 statistic은 RFC 2013의 UDP MIB에서 파생되었습니다.

UDP-Lite runtime statistic
Counter의미
InDatagramsUserspace에 전달한 datagram
NoPortsUnknown port로 받은 packet
InErrorsLength, policy, coverage, checksum 등의 error
OutDatagrams송신 datagram

`/proc/net/snmp`와 `netstat -svu`가 보여 주는 counter입니다.

5. UDP-Lite Runtime Statistics and their Meaning
================================================

  Exceptional and error conditions are logged to syslog at the KERN_DEBUG
  level.  Live statistics about UDP-Lite are available in /proc/net/snmp
  and can (with newer versions of netstat) be viewed using::

                            netstat -svu

  This displays UDP-Lite statistics variables, whose meaning is as follows.

   ============     =====================================================
   InDatagrams      The total number of datagrams delivered to users.

   NoPorts          Number of packets received to an unknown port.
                    These cases are counted separately (not as InErrors).

   InErrors         Number of erroneous UDP-Lite packets. Errors include:

                      * internal socket queue receive errors
                      * packet too short (less than 8 bytes or stated
                        coverage length exceeds received length)
                      * xfrm4_policy_check() returned with error
                      * application has specified larger min. coverage
                        length than that of incoming packet
                      * checksum coverage violated
                      * bad checksum

   OutDatagrams     Total number of sent datagrams.
   ============     =====================================================

   These statistics derive from the UDP MIB (RFC 2013).

iptables protocol match

265-278

iptables는 UDP-Lite packet match와 `LOG` target을 지원합니다. `/etc/protocols`에 `udplite 136 UDP-Lite # UDP-Lite [RFC 3828]`을 추가하면 `iptables -A INPUT -p udplite -j LOG`가 syslog에 기록을 남깁니다.

UDP-Lite packet을 drop하거나 reject하는 규칙도 정상적으로 동작합니다.

6. IPtables
===========

  There is packet match support for UDP-Lite as well as support for the LOG target.
  If you copy and paste the following line into /etc/protocols::

    udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]

  then::

              iptables -A INPUT -p udplite -j LOG

  will produce logging output to syslog. Dropping and rejecting packets also works.

개발 기관과 maintainer

279-291

UDP-Lite patch는 영국 Aberdeen의 University of Aberdeen, Electronics Research Group, Department of Engineering에서 개발되었습니다.

문서 기준 maintainer는 Gerrit Renker이며 초기 code는 William Stanislaus가 개발했습니다. 원문은 두 사람의 contact address를 보존합니다.

7. Maintainer Address
=====================

  The UDP-Lite patch was developed at

                    University of Aberdeen
                    Electronics Research Group
                    Department of Engineering
                    Fraser Noble Building
                    Aberdeen AB24 3UE; UK

  The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
  code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.