-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-xxx-tsvwg-udp-rfc5404-bis-00.xml
1776 lines (1441 loc) · 87.9 KB
/
draft-xxx-tsvwg-udp-rfc5404-bis-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<rfc category="bcp" ipr="trust200902" number="" seriesNo="145 (if approved)">
<front>
<title abbrev="Unicast UDP Usage Guidelines">Unicast UDP Usage
Guidelines</title>
<author fullname="Lars Eggert" initials="L." surname="Eggert">
<organization abbrev="Nokia">Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<code>00045</code>
<city>Nokia Group</city>
<country>Finland</country>
</postal>
<phone>+358 50 48 24461</phone>
<email>[email protected]</email>
<uri>http://people.nokia.net/~lars/</uri>
</address>
</author>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>Department of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>Scotland</country>
</postal>
<email>[email protected]</email>
<uri>http://www.erg.abdn.ac.uk/</uri>
</address>
</author>
<date day="01" month="May" year="2014" />
<area>Transport Area</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>UDP</keyword>
<keyword>guidelines</keyword>
<abstract>
<t>XXX If approved as a WG document, this draft will be a proposed
update to BCP 145 XXX</t>
<t>XXX If published, this document will replace RFC 5405, making RFC
5405 Historic XXX</t>
<t>The User Datagram Protocol (UDP) provides a minimal message-passing
transport that has no inherent congestion control mechanisms. Because
congestion control is critical to the stable operation of the Internet,
applications and upper-layer protocols that choose to use UDP as an
Internet transport must employ mechanisms to prevent congestion collapse
and to establish some degree of fairness with concurrent traffic.</t>
<t>This document provides guidelines on the use of UDP for the designers
of unicast applications, tunnels that use UDP and upper-layer protocols.
Congestion control guidelines are a primary focus, but the document also
provides guidance on other topics, including message sizes, reliability,
checksums, and middlebox traversal.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The User Datagram Protocol (UDP) <xref target="RFC0768"></xref>
provides a minimal, unreliable, best-effort, message-passing transport
to applications and upper-layer protocols (both simply called
"applications" in the remainder of this document). Compared to other
transport protocols, UDP and its UDP-Lite variant <xref
target="RFC3828"></xref> are unique in that they do not establish
end-to-end connections between communicating end systems. UDP
communication consequently does not incur connection establishment and
teardown overheads, and there is minimal associated end system state.
Because of these characteristics, UDP can offer a very efficient
communication transport to some applications.</t>
<t>A second unique characteristic of UDP is that it provides no inherent
congestion control mechanisms. On many platforms, applications can send
UDP datagrams at the line rate of the link interface, which is often
much greater than the available path capacity, and doing so contributes
to congestion along the path. <xref target="RFC2914"></xref> describes
the best current practice for congestion control in the Internet. It
identifies two major reasons why congestion control mechanisms are
critical for the stable operation of the Internet: <list style="numbers">
<t>The prevention of congestion collapse, i.e., a state where an
increase in network load results in a decrease in useful work done
by the network.</t>
<t>The establishment of a degree of fairness, i.e., allowing
multiple flows to share the capacity of a path reasonably
equitably.</t>
</list></t>
<t>Because UDP itself provides no congestion control mechanisms, it is
up to the applications that use UDP for Internet communication to employ
suitable mechanisms to prevent congestion collapse and establish a
degree of fairness. <xref target="RFC2309"></xref> discusses the dangers
of congestion-unresponsive flows and states that "all UDP-based
streaming applications should incorporate effective congestion avoidance
mechanisms". This is an important requirement, even for applications
that do not use UDP for streaming. In addition, congestion-controlled
transmission is of benefit to an application itself, because it can
reduce self-induced packet loss, minimize retransmissions, and hence
reduce delays. Congestion control is essential even at relatively slow
transmission rates. For example, an application that generates five
1500-byte UDP datagrams in one second can already exceed the capacity of
a 56 Kb/s path. For applications that can operate at higher, potentially
unbounded data rates, congestion control becomes vital to prevent
congestion collapse and establish some degree of fairness. <xref
target="udpguide"></xref> describes a number of simple guidelines for
the designers of such applications.</t>
<t>A UDP datagram is carried in a single IP packet and is hence limited
to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for IPv6.
The transmission of large IP packets usually requires IP fragmentation.
Fragmentation decreases communication reliability and efficiency and
should be avoided. IPv6 allows the option of transmitting large packets
("jumbograms") without fragmentation when all link layers along the path
support this <xref target="RFC2675"></xref>. Some of the guidelines in
<xref target="udpguide"></xref> describe how applications should
determine appropriate message sizes. Other sections of this document
provide guidance on reliability, checksums, and middlebox traversal.</t>
<t>This document provides guidelines and recommendations. Although most
unicast UDP applications are expected to follow these guidelines, there
do exist valid reasons why a specific application may decide not to
follow a given guideline. In such cases, it is RECOMMENDED that the
application designers document the rationale for their design choice in
the technical specification of their application or protocol.</t>
<t>This document provides guidelines to designers of applications that
use UDP for unicast transmission, which is the most common case.
Specialized classes of applications use UDP for IP multicast <xref
target="RFC1112"></xref>, broadcast <xref target="RFC0919"></xref>, or
anycast <xref target="RFC1546"></xref> transmissions. The design of such
specialized applications requires expertise that goes beyond the simple,
unicast-specific guidelines given in this document. Multicast and
broadcast senders may transmit to multiple receivers across potentially
very heterogeneous paths at the same time, which significantly
complicates congestion control, flow control, and reliability
mechanisms. The IETF has defined a reliable multicast framework <xref
target="RFC3048"></xref> and several building blocks to aid the
designers of multicast applications, such as <xref
target="RFC3738"></xref> or <xref target="RFC4654"></xref>. Anycast
senders must be aware that successive messages sent to the same anycast
IP address may be delivered to different anycast nodes, i.e., arrive at
different locations in the topology. It is not intended that the
guidelines in this document apply to multicast, broadcast, or anycast
applications that use UDP.</t>
<t><xref target="RFC5405"></xref> was scoped to provide guidelines for
unicast applications only, this document therefore updates this to also
provide guidelines for UDP flows use IP multicast or use a UDP tunnel to
support IP multicast flows. There are currently two models of multicast
delivery: the Any-Source Multicast (ASM) model as defined in [RFC1112]
and the Source-Specific Multicast (SSM) model as defined in [RFC4607].
ASM group members will receive all data sent to the group by any source,
while SSM constrains the distribution tree to only one single source.
Many congestion-controlled transport protocols are often not applicable
to multicast distribution services, or simply won't scale well to very
large multicast trees since they require bi-directional communication
and adapt the data-rate to accommodate the network conditions to a
single receiver. Multicast distribution trees can often fan out to
massive numbers of receivers limiting the scalability of an in-band
return channel to control the data-rate, and the one-to-many nature of
multicast distribution trees prevent adapting the data-rate to
individual receiver requirements. For this reason, TCP-compatible
aggregate flow for Internet multicast data, either native or tunneled,
is the responsibility of the application.</t>
<t>Finally, although this document specifically refers to unicast
applications that use UDP, the spirit of some of its guidelines also
applies to other message-passing applications and protocols
(specifically on the topics of congestion control, message sizes, and
reliability). Examples include signaling or control applications that
choose to run directly over IP by registering their own IP protocol
number with IANA. This document may provide useful background reading to
the designers of such applications and protocols.</t>
</section>
<section anchor="term" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="udpguide" title="UDP Usage Guidelines">
<t>Internet paths can have widely varying characteristics, including
transmission delays, available bandwidths, congestion levels, reordering
probabilities, supported message sizes, or loss rates. Furthermore, the
same Internet path can have very different conditions over time.
Consequently, applications that may be used on the Internet MUST NOT
make assumptions about specific path characteristics. They MUST instead
use mechanisms that let them operate safely under very different path
conditions. Typically, this requires conservatively probing the current
conditions of the Internet path they communicate over to establish a
transmission behavior that it can sustain and that is reasonably fair to
other traffic sharing the path.</t>
<t>These mechanisms are difficult to implement correctly. For most
applications, the use of one of the existing IETF transport protocols is
the simplest method of acquiring the required mechanisms. Consequently,
the RECOMMENDED alternative to the UDP usage described in the remainder
of this section is the use of an IETF transport protocol such as TCP
<xref target="RFC0793"></xref>, Stream Control Transmission Protocol
(SCTP) <xref target="RFC4960"></xref>, and SCTP Partial Reliability
Extension (SCTP-PR) <xref target="RFC3758"></xref>, or Datagram
Congestion Control Protocol (DCCP) <xref target="RFC4340"></xref> with
its different congestion control types <xref
target="RFC4341"></xref><xref target="RFC4342"></xref><xref
target="CCID4"></xref>.</t>
<t>If used correctly, these more fully-featured transport protocols are
not as "heavyweight" as often claimed. For example, the TCP algorithms
have been continuously improved over decades, and have reached a level
of efficiency and correctness that custom application-layer mechanisms
will struggle to easily duplicate. In addition, many TCP implementations
allow connections to be tuned by an application to its purposes. For
example, TCP's "Nagle" algorithm <xref target="RFC0896"></xref> can be
disabled, improving communication latency at the expense of more
frequent -- but still congestion-controlled -- packet transmissions.
Another example is the TCP SYN cookie mechanism <xref
target="RFC4987"></xref>, which is available on many platforms. TCP with
SYN cookies does not require a server to maintain per-connection state
until the connection is established. TCP also requires the end that
closes a connection to maintain the TIME-WAIT state that prevents
delayed segments from one connection instance from interfering with a
later one. Applications that are aware of and designed for this behavior
can shift maintenance of the TIME-WAIT state to conserve resources by
controlling which end closes a TCP connection <xref
target="FABER"></xref>. Finally, TCP's built-in capacity-probing and
awareness of the maximum transmission unit supported by the path (PMTU)
results in efficient data transmission that quickly compensates for the
initial connection setup delay, in the case of transfers that exchange
more than a few segments.</t>
<section anchor="ccguide" title="Congestion Control Guidelines">
<t>If an application or upper-layer protocol chooses not to use a
congestion-controlled transport protocol, it SHOULD control the rate
at which it sends UDP datagrams to a destination host, in order to
fulfill the requirements of <xref target="RFC2914"></xref>. It is
important to stress that an application SHOULD perform congestion
control over all UDP traffic it sends to a destination, independently
from how it generates this traffic. For example, an application that
forks multiple worker processes or otherwise uses multiple sockets to
generate UDP datagrams SHOULD perform congestion control over the
aggregate traffic.</t>
<t>Several approaches to perform congestion control are discussed in
the remainder of this section. Not all approaches discussed below are
appropriate for all UDP-transmitting applications. <xref
target="btguide"></xref> discusses congestion control options for
applications that perform bulk transfers over UDP. Such applications
can employ schemes that sample the path over several subsequent RTTs
during which data is exchanged, in order to determine a sending rate
that the path at its current load can support. Other applications only
exchange a few UDP datagrams with a destination. <xref
target="ldrguide"></xref> discusses congestion control options for
such "low data-volume" applications. Because they typically do not
transmit enough data to iteratively sample the path to determine a
safe sending rate, they need to employ different kinds of congestion
control mechanisms. <xref target="tunguide"></xref> discusses
congestion control considerations when UDP is used as a tunneling
protocol.</t>
<t>It is important to note that congestion control should not be
viewed as an add-on to a finished application. Many of the mechanisms
discussed in the guidelines below require application support to
operate correctly. Application designers need to consider congestion
control throughout the design of their application, similar to how
they consider security aspects throughout the design process.</t>
<t>In the past, the IETF has also investigated integrated congestion
control mechanisms that act on the traffic aggregate between two
hosts, i.e., a framework such as the Congestion Manager <xref
target="RFC3124"></xref>, where active sessions may share current
congestion information in a way that is independent of the transport
protocol. Such mechanisms have currently failed to see deployment, but
would otherwise simplify the design of congestion control mechanisms
for UDP sessions, so that they fulfill the requirements in <xref
target="RFC2914"></xref>.</t>
<section anchor="btguide" title="Bulk Transfer Applications">
<t>Applications that perform bulk transmission of data to a peer
over UDP, i.e., applications that exchange more than a small number
of UDP datagrams per RTT, SHOULD implement TCP-Friendly Rate Control
(TFRC) <xref target="RFC5348"></xref>, window-based, TCP-like
congestion control, or otherwise ensure that the application
complies with the congestion control principles.</t>
<t>TFRC has been designed to provide both congestion control and
fairness in a way that is compatible with the IETF's other transport
protocols. If an application implements TFRC, it need not follow the
remaining guidelines in <xref target="btguide"></xref>, because TFRC
already addresses them, but SHOULD still follow the remaining
guidelines in the subsequent subsections of <xref
target="udpguide"></xref>.</t>
<t>Bulk transfer applications that choose not to implement TFRC or
TCP-like windowing SHOULD implement a congestion control scheme that
results in bandwidth use that competes fairly with TCP within an
order of magnitude. Section 2 of <xref target="RFC3551"></xref>
suggests that applications SHOULD monitor the packet loss rate to
ensure that it is within acceptable parameters. Packet loss is
considered acceptable if a TCP flow across the same network path
under the same network conditions would achieve an average
throughput, measured on a reasonable timescale, that is not less
than that of the UDP flow. The comparison to TCP cannot be specified
exactly, but is intended as an "order-of-magnitude" comparison in
timescale and throughput.</t>
<t>Finally, some bulk transfer applications may choose not to
implement any congestion control mechanism and instead rely on
transmitting across reserved path capacity. This might be an
acceptable choice for a subset of restricted networking
environments, but is by no means a safe practice for operation in
the Internet. When the UDP traffic of such applications leaks out on
unprovisioned Internet paths, it can significantly degrade the
performance of other traffic sharing the path and even result in
congestion collapse. Applications that support an uncontrolled or
unadaptive transmission behavior SHOULD NOT do so by default and
SHOULD instead require users to explicitly enable this mode of
operation.</t>
</section>
<section anchor="ldrguide" title="Low Data-Volume Applications">
<t>When applications that at any time exchange only a small number
of UDP datagrams with a destination implement TFRC or one of the
other congestion control schemes in <xref target="btguide"></xref>,
the network sees little benefit, because those mechanisms perform
congestion control in a way that is only effective for longer
transmissions.</t>
<t>Applications that at any time exchange only a small number of UDP
datagrams with a destination SHOULD still control their transmission
behavior by not sending on average more than one UDP datagram per
round-trip time (RTT) to a destination. Similar to the
recommendation in <xref target="RFC1536"></xref>, an application
SHOULD maintain an estimate of the RTT for any destination with
which it communicates. Applications SHOULD implement the algorithm
specified in <xref target="RFC2988"></xref> to compute a smoothed
RTT (SRTT) estimate. They SHOULD also detect packet loss and
exponentially back-off their retransmission timer when a loss event
occurs. When implementing this scheme, applications need to choose a
sensible initial value for the RTT. This value SHOULD generally be
as conservative as possible for the given application. TCP uses an
initial value of 3 seconds <xref target="RFC2988"></xref>, which is
also RECOMMENDED as an initial value for UDP applications. SIP <xref
target="RFC3261"></xref> and GIST <xref target="GIST"></xref> use an
initial value of 500 ms, and initial timeouts that are shorter than
this are likely problematic in many cases. It is also important to
note that the initial timeout is not the maximum possible timeout --
the RECOMMENDED algorithm in <xref target="RFC2988"></xref> yields
timeout values after a series of losses that are much longer than
the initial value.</t>
<t>Some applications cannot maintain a reliable RTT estimate for a
destination. The first case is that of applications that exchange
too few UDP datagrams with a peer to establish a statistically
accurate RTT estimate. Such applications MAY use a predetermined
transmission interval that is exponentially backed-off when packets
are lost. TCP uses an initial value of 3 seconds <xref
target="RFC2988"></xref>, which is also RECOMMENDED as an initial
value for UDP applications. SIP <xref target="RFC3261"></xref> and
GIST <xref target="GIST"></xref> use an interval of 500 ms, and
shorter values are likely problematic in many cases. As in the
previous case, note that the initial timeout is not the maximum
possible timeout.</t>
<t>A second class of applications cannot maintain an RTT estimate
for a destination, because the destination does not send return
traffic. Such applications SHOULD NOT send more than one UDP
datagram every 3 seconds, and SHOULD use an even less aggressive
rate when possible. The 3-second interval was chosen based on TCP's
retransmission timeout when the RTT is unknown <xref
target="RFC2988"></xref>, and shorter values are likely problematic
in many cases. Note that the sending rate in this case must be more
conservative than in the two previous cases, because the lack of
return traffic prevents the detection of packet loss, i.e.,
congestion events, and the application therefore cannot perform
exponential back-off to reduce load.</t>
<t>Applications that communicate bidirectionally SHOULD employ
congestion control for both directions of the communication. For
example, for a client-server, request-response-style application,
clients SHOULD congestion-control their request transmission to a
server, and the server SHOULD congestion-control its responses to
the clients. Congestion in the forward and reverse direction is
uncorrelated, and an application SHOULD either independently detect
and respond to congestion along both directions, or limit new and
retransmitted requests based on acknowledged responses across the
entire round-trip path.</t>
</section>
<section anchor="tunguide" title="UDP Tunnels">
<t>One increasingly popular use of UDP is as a tunneling protocol,
where a tunnel endpoint encapsulates the packets of another protocol
inside UDP datagrams and transmits them to another tunnel endpoint,
which decapsulates the UDP datagrams and forwards the original
packets contained in the payload. Tunnels establish virtual links
that appear to directly connect locations that are distant in the
physical Internet topology and can be used to create virtual
(private) networks. Using UDP as a tunneling protocol is attractive
when the payload protocol is not supported by middleboxes that may
exist along the path, because many middleboxes support transmission
using UDP.</t>
<t>Well-implemented tunnels are generally invisible to the endpoints
that happen to transmit over a path that includes tunneled links. On
the other hand, to the routers along the path of a UDP tunnel, i.e.,
the routers between the two tunnel endpoints, the traffic that a UDP
tunnel generates is a regular UDP flow, and the encapsulator and
decapsulator appear as regular UDP-sending and -receiving
applications. Because other flows can share the path with one or
more UDP tunnels, congestion control needs to be considered.</t>
<t>Two factors determine whether a UDP tunnel needs to employ
specific congestion control mechanisms -- first, whether the payload
traffic is IP-based; second, whether the tunneling scheme generates
UDP traffic at a volume that corresponds to the volume of payload
traffic carried within the tunnel.</t>
<t>IP-based traffic is generally assumed to be
congestion-controlled, i.e., it is assumed that the transport
protocols generating IP-based traffic at the sender already employ
mechanisms that are sufficient to address congestion on the path.
Consequently, a tunnel carrying IP-based traffic should already
interact appropriately with other traffic sharing the path, and
specific congestion control mechanisms for the tunnel are not
necessary.</t>
<t>However, if the IP traffic in the tunnel is known to not be
congestion-controlled, additional measures are RECOMMENDED in order
to limit the impact of the tunneled traffic on other traffic sharing
the path.</t>
<t>The following guidelines define these possible cases in more
detail:</t>
<t><list style="numbers">
<t>A tunnel generates UDP traffic at a volume that corresponds
to the volume of payload traffic, and the payload traffic is
IP-based and congestion-controlled.<vspace blankLines="1" />This
is arguably the most common case for Internet tunnels. In this
case, the UDP tunnel SHOULD NOT employ its own congestion
control mechanism, because congestion losses of tunneled traffic
will already trigger an appropriate congestion response at the
original senders of the tunneled traffic.<vspace
blankLines="1" />Note that this guideline is built on the
assumption that most IP-based communication is
congestion-controlled. If a UDP tunnel is used for IP-based
traffic that is known to not be congestion-controlled, the next
set of guidelines applies.</t>
<t>A tunnel generates UDP traffic at a volume that corresponds
to the volume of payload traffic, and the payload traffic is not
known to be IP-based, or is known to be IP-based but not
congestion-controlled.<vspace blankLines="1" />This can be the
case, for example, when some link-layer protocols are
encapsulated within UDP (but not all link-layer protocols; some
are congestion-controlled). Because it is not known that
congestion losses of tunneled non-IP traffic will trigger an
appropriate congestion response at the senders, the UDP tunnel
SHOULD employ an appropriate congestion control mechanism.
Because tunnels are usually bulk-transfer applications as far as
the intermediate routers are concerned, the guidelines in <xref
target="btguide"></xref> apply.</t>
<t>A tunnel generates UDP traffic at a volume that does not
correspond to the volume of payload traffic, independent of
whether the payload traffic is IP-based or
congestion-controlled.<vspace blankLines="1" />Examples of this
class include UDP tunnels that send at a constant rate, increase
their transmission rates under loss, for example, due to
increasing redundancy when Forward Error Correction is used, or
are otherwise constrained in their transmission behavior. These
specialized uses of UDP for tunneling go beyond the scope of the
general guidelines given in this document. The implementer of
such specialized tunnels SHOULD carefully consider congestion
control in the design of their tunneling mechanism.</t>
</list></t>
<t>Designing a tunneling mechanism requires significantly more
expertise than needed for many other UDP applications, because
tunnels virtualize lower-layer components of the Internet, and the
virtualized components need to correctly interact with the
infrastructure at that layer. This document only touches upon the
congestion control considerations for implementing UDP tunnels; a
discussion of other required tunneling behavior is out of scope.</t>
<t>Most UDP tunnels that carrying IP multicast use a tunnel
encapsulation with a unicast destination address. These must have
the same requirements as a tunnel carrying unicast data. There are
deployment cases and solutions where the outer header of a UDP
tunnel contains a multicast destination address, such as <xref
target="RFC6513"></xref>. These cases are primarily deployed in
conrtrolled networks with bandwidth reservation, operating within a
single administrative domain, or between two domains where a
bi-laterally agreed upon path and bandwidth is in place and so
congestion control is not an issue, but use of circuit breaker
techniques may still apply.</t>
</section>
</section>
<section title="Multicast Usage of UDP">
<t>Multicast data transmission usually employs the UDP transport
protocol, although it may be used with other transport protocols (e.g.
UDP-Lite).</t>
<t>There are currently two models of multicast delivery: the
Any-Source Multicast (ASM) model as defined in <xref
target="RFC1112"></xref> and the Source-Specific Multicast (SSM) model
as defined in <xref target="RFC4607"></xref>. ASM group members will
receive all data sent to the group by any source, while SSM constrains
the distribution tree to only one single source.</t>
<t>Most congestion-controlled transport protocols are often not
applicable to multicast distribution services, or simply will not
scale well to large multicast trees since they require bi-directional
communication and adapt the data-rate to accommodate the network
conditions to a single receiver. Multicast distribution trees may fan
out to massive numbers of receivers limiting the scalability of an
in-band return channel to control the data-rate, and the one-to-many
nature of multicast distribution trees prevent adapting the data-rate
to individual receiver requirements. For this reason, multicast
congestion control, either native or tunneled, is the responsibility
of the application controlling the source and receiver of a multicast
flow.</t>
<section title="Bulk Transfer Multicast Applications">
<t>XXX New section under devlopment XXX</t>
<t>Applications that perform bulk transmission of data over a
multicast distribution tree, i.e., applications that exchange more
than a small number of UDP datagrams per maximum receiver RTT,
SHOULD implement a method for congestion control. The currently
recommended IETF methods are: Asynchronous Layered Coding (ALC)
[RFC5775], TCP-Friendly Multicast Congestion Control (TFMCC)
[RFC4654], Wave and Equation Based Rate Control (WEBRC) [RFC3738],
NACK-Oriented Reliable Multicast (NORM) transport protocol
[RFC5740], File Delivery over Unidirectional Transport (FLUTE)
[RFC6726], Real Time Protocol/Control Protocol (RTP/RTCP),
[RFC3550].</t>
<t>It may implement another congestion control scheme following the
guidelines of [RFC2887] and utilizing the framework of [RFC3048].
Bulk transfer applications that choose not to implement [RFC4654],
[RFC5775], [RFC3738], [RFC5740], [RFC6726], or [RFC3550] SHOULD
implement a congestion control scheme that results in bandwidth use
that competes fairly with TCP within an order of magnitude. Section
2 of [RFC3551] states that applications SHOULD monitor the packet
loss rate to ensure that this is within acceptable parameters.
Packet loss is considered acceptable if a TCP flow across the same
network path under the same network conditions would achieve an
average throughput, measured on a reasonable timescale, that is not
less than that of the UDP flow. The comparison to TCP cannot be
specified exactly, but is intended as an "order-of-magnitude"
comparison in timescale and throughput. Finally, some bulk transfer
applications may choose not to implement any congestion control
mechanism and instead rely on transmitting across reserved path
capacity. This might be an acceptable choice for a subset of
restricted networking environments, but is by no means a safe
practice for operation in the Internet. When the multicast traffic
of such applications leaks out on unprovisioned Internet paths, it
can significantly degrade the performance of other traffic sharing
the path and even result in congestion collapse. Applications that
support an uncontrolled or unadaptive transmission behavior SHOULD
NOT do so by default and SHOULD instead require users to explicitly
enable this mode of operation.</t>
</section>
<section title="Low Data-Volume Multicast Applications">
<t>All of the recommendations in section XXX of [THIS DRAFT] are
also applicable to multicast applications.</t>
</section>
</section>
<section anchor="msguide" title="Message Size Guidelines">
<t>IP fragmentation lowers the efficiency and reliability of Internet
communication. The loss of a single fragment results in the loss of an
entire fragmented packet, because even if all other fragments are
received correctly, the original packet cannot be reassembled and
delivered. This fundamental issue with fragmentation exists for both
IPv4 and IPv6. In addition, some network address translators (NATs)
and firewalls drop IP fragments. The network address translation
performed by a NAT only operates on complete IP packets, and some
firewall policies also require inspection of complete IP packets. Even
with these being the case, some NATs and firewalls simply do not
implement the necessary reassembly functionality, and instead choose
to drop all fragments. Finally, <xref target="RFC4963"></xref>
documents other issues specific to IPv4 fragmentation.</t>
<t>Due to these issues, an application SHOULD NOT send UDP datagrams
that result in IP packets that exceed the MTU of the path to the
destination. Consequently, an application SHOULD either use the path
MTU information provided by the IP layer or implement path MTU
discovery itself <xref target="RFC1191"></xref><xref
target="RFC1981"></xref><xref target="RFC4821"></xref> to determine
whether the path to a destination will support its desired message
size without fragmentation.</t>
<t>Applications that do not follow this recommendation to do PMTU
discovery SHOULD still avoid sending UDP datagrams that would result
in IP packets that exceed the path MTU. Because the actual path MTU is
unknown, such applications SHOULD fall back to sending messages that
are shorter than the default effective MTU for sending (EMTU_S in
<xref target="RFC1122"></xref>). For IPv4, EMTU_S is the smaller of
576 bytes and the first-hop MTU <xref target="RFC1122"></xref>. For
IPv6, EMTU_S is 1280 bytes <xref target="RFC2460"></xref>. The
effective PMTU for a directly connected destination (with no routers
on the path) is the configured interface MTU, which could be less than
the maximum link payload size. Transmission of minimum-sized UDP
datagrams is inefficient over paths that support a larger PMTU, which
is a second reason to implement PMTU discovery.</t>
<t>To determine an appropriate UDP payload size, applications MUST
subtract the size of the IP header (which includes any IPv4 optional
headers or IPv6 extension headers) as well as the length of the UDP
header (8 bytes) from the PMTU size. This size, known as the MMS_S,
can be obtained from the TCP/IP stack <xref
target="RFC1122"></xref>.</t>
<t>Applications that do not send messages that exceed the effective
PMTU of IPv4 or IPv6 need not implement any of the above mechanisms.
Note that the presence of tunnels can cause an additional reduction of
the effective PMTU, so implementing PMTU discovery may be
beneficial.</t>
<t>Applications that fragment an application-layer message into
multiple UDP datagrams SHOULD perform this fragmentation so that each
datagram can be received independently, and be independently
retransmitted in the case where an application implements its own
reliability mechanisms.</t>
<t>XXX This section does not speak of requirements for PMTUD and
PLPMTUD (RFC4821) - important as people mention use with tunnels etc
XXX</t>
<section anchor="MPMTU" title="Message Size Multicast Guidelines">
<t>A multicast application SHOULD NOT send UDP datagrams that result
in IP packets that exceed the effective MTU as described in section
3 of <xref target="RFC6807"> </xref>. Consequently, an application
SHOULD either use the effective MTU information provided by the
Population Count Extensions to Protocol Independent Multicast <xref
target="RFC6807"></xref> or implement path MTU discovery itself (see
<xref target="msguide"></xref>) to determine whether the path to
each destination will support its desired message size without
fragmentation.</t>
</section>
</section>
<section anchor="reguide" title="Reliability Guidelines">
<t>Application designers are generally aware that UDP does not provide
any reliability, e.g., it does not retransmit any lost packets. Often,
this is a main reason to consider UDP as a transport. Applications
that do require reliable message delivery MUST implement an
appropriate mechanism themselves.</t>
<t>UDP also does not protect against datagram duplication, i.e., an
application may receive multiple copies of the same UDP datagram.
Application designers SHOULD verify that their application handles
datagram duplication gracefully, and may consequently need to
implement mechanisms to detect duplicates. Even if UDP datagram
reception triggers idempotent operations, applications may want to
suppress duplicate datagrams to reduce load.</t>
<t>In addition, the Internet can significantly delay some packets with
respect to others, e.g., due to routing transients, intermittent
connectivity, or mobility. This can cause reordering, where UDP
datagrams arrive at the receiver in an order different from the
transmission order. Applications that require ordered delivery MUST
reestablish datagram ordering themselves.</t>
<t>Finally, it is important to note that delay spikes can be very
large. This can cause reordered packets to arrive many seconds after
they were sent. <xref target="RFC0793"></xref> defines the maximum
delay a TCP segment should experience -- the Maximum Segment Lifetime
(MSL) -- as 2 minutes. No other RFC defines an MSL for other transport
protocols or IP itself. This document clarifies that the MSL value to
be used for UDP SHOULD be the same 2 minutes as for TCP. Applications
SHOULD be robust to the reception of delayed or duplicate packets that
are received within this 2-minute interval.</t>
<t>An application that requires reliable and ordered message delivery
SHOULD choose an IETF standard transport protocol that provides these
features. If this is not possible, it will need to implement a set of
appropriate mechanisms itself.</t>
</section>
<section anchor="chkguide" title="Checksum Guidelines">
<t>The UDP header includes an optional, 16-bit one's complement
checksum that provides an integrity check. This results in a
relatively weak protection in terms of coding theory <xref
target="RFC3819"></xref>, and application developers SHOULD implement
additional checks where data integrity is important, e.g., through a
Cyclic Redundancy Check (CRC) included with the data to verify the
integrity of an entire object/file sent over the UDP service.</t>
<t>The UDP checksum provides a statistical guarantee that the payload
was not corrupted in transit. It also allows the receiver to verify
that it was the intended destination of the packet, because it covers
the IP addresses, port numbers, and protocol number, and it verifies
that the packet is not truncated or padded, because it covers the size
field. It therefore protects an application against receiving
corrupted payload data in place of, or in addition to, the data that
was sent. More description of the set of checks performed using the
checksum field are provided in section 3.1 of <xref
target="RFC6396"></xref>. These checks are not strong from a coding or
cryptographic perspective, and are not designed to detect
physical-layer errors or malicious modification of the datagram <xref
target="RFC3819"></xref>. </t>
<t>Applications SHOULD enable UDP checksums, although <xref
target="RFC0768"></xref> permits the option to disable their use for
IPv4. Applications that choose to disable UDP checksums when
transmitting over IPv4 therefore MUST NOT make assumptions regarding
the correctness of received data and MUST behave correctly when a UDP
datagram is received that was originally sent to a different
destination or is otherwise corrupted. </t>
<t>The use of the UDP checksum was REQUIRED when applications transmit
UDP over IPv6 <xref target="RFC2460"></xref>. This requirement was
updated in <xref target="RFC6395"></xref>, but only for specific
protocols/applications that could implement the set of functions
defined in <xref target="RFC6396"></xref> .</t>
<section anchor="udplite" title="UDP-Lite">
<t>A special class of applications can derive benefit from having
partially-damaged payloads delivered, rather than discarded, when
using paths that include error-prone links. Such applications can
tolerate payload corruption and MAY choose to use the Lightweight
User Datagram Protocol (UDP-Lite) <xref target="RFC3828"></xref>
variant of UDP instead of basic UDP. Applications that choose to use
UDP-Lite instead of UDP should still follow the congestion control
and other guidelines described for use with UDP in <xref
target="udpguide"></xref>.</t>
<t>UDP-Lite changes the semantics of the UDP "payload length" field
to that of a "checksum coverage length" field. Otherwise, UDP-Lite
is semantically identical to UDP. The interface of UDP-Lite differs
from that of UDP by the addition of a single (socket) option that
communicates a checksum coverage length value: at the sender, this
specifies the intended checksum coverage, with the remaining
unprotected part of the payload called the "error-insensitive part".
By default, the UDP-Lite checksum coverage extends across the entire
datagram. If required, an application may dynamically modify this
length value, e.g., to offer greater protection to some messages.
UDP-Lite always verifies that a packet was delivered to the intended
destination, i.e., always verifies the header fields. Errors in the
insensitive part will not cause a UDP datagram to be discarded by
the destination. Applications using UDP-Lite therefore MUST NOT make
assumptions regarding the correctness of the data received in the
insensitive part of the UDP-Lite payload.</t>
<t>The sending application SHOULD select the minimum checksum
coverage to include all sensitive protocol headers. For example,
applications that use the Real-Time Protocol (RTP) <xref
target="RFC3550"></xref> will likely want to protect the RTP header
against corruption. Applications, where appropriate, MUST also
introduce their own appropriate validity checks for protocol
information carried in the insensitive part of the UDP-Lite payload
(e.g., internal CRCs).</t>
<t>The receiver must set a minimum coverage threshold for incoming
packets that is not smaller than the smallest coverage used by the
sender <xref target="RFC3828"></xref>. The receiver SHOULD select a
threshold that is sufficiently large to block packets with an
inappropriately short coverage field. This may be a fixed value, or
may be negotiated by an application. UDP-Lite does not provide
mechanisms to negotiate the checksum coverage between the sender and
receiver.</t>
<t>Applications may still experience packet loss, rather than
corruption, when using UDP-Lite. The enhancements offered by
UDP-Lite rely upon a link being able to intercept the UDP-Lite
header to correctly identify the partial coverage required. When
tunnels and/or encryption are used, this can result in UDP-Lite
datagrams being treated the same as UDP datagrams, i.e., result in
packet loss. Use of IP fragmentation can also prevent special
treatment for UDP-Lite datagrams, and this is another reason why
applications SHOULD avoid IP fragmentation (<xref
target="msguide"></xref>).</t>
<t>Current support for middlebox traversal using UDP-Lite is poor,
because UDP-Lite uses a different IPv4 protocol number or IPv6
network-layer Next Header value than that used for UDP; therefore,
few middleboxes are able to interpret UDP-Lite and take appropriate
actions when forwarding the packet. This makes UDP-Lite less suited
to protocols needing general Internet support, until such time as
UDP-Lite has achieved better support in middleboxes and
endpoints.</t>
</section>
</section>
<section anchor="natguide" title="Middlebox Traversal Guidelines">
<t>Network address translators (NATs) and firewalls are examples of
intermediary devices ("middleboxes") that can exist along an
end-to-end path. A middlebox typically performs a function that
requires it to maintain per-flow state. For connection-oriented
protocols, such as TCP, middleboxes snoop and parse the
connection-management traffic and create and destroy per-flow state
accordingly. For a connectionless protocol such as UDP, this approach
is not possible. Consequently, middleboxes may create per-flow state
when they see a packet that indicates a new flow, and destroy the
state after some period of time during which no packets belonging to
the same flow have arrived.</t>
<t>Depending on the specific function that the middlebox performs,
this behavior can introduce a time-dependency that restricts the kinds
of UDP traffic exchanges that will be successful across the middlebox.
For example, NATs and firewalls typically define the partial path on
one side of them to be interior to the domain they serve, whereas the
partial path on their other side is defined to be exterior to that
domain. Per-flow state is typically created when the first packet
crosses from the interior to the exterior, and while the state is
present, NATs and firewalls will forward return traffic. Return
traffic that arrives after the per-flow state has timed out is
dropped, as is other traffic that arrives from the exterior.</t>
<t>Many applications that use UDP for communication operate across
middleboxes without needing to employ additional mechanisms. One
example is the Domain Name System (DNS), which has a strict
request-response communication pattern that typically completes within
seconds.</t>
<t>Other applications may experience communication failures when
middleboxes destroy the per-flow state associated with an application
session during periods when the application does not exchange any UDP
traffic. Applications SHOULD be able to gracefully handle such
communication failures and implement mechanisms to re-establish
application-layer sessions and state.</t>
<t>For some applications, such as media transmissions, this
re-synchronization is highly undesirable, because it can cause
user-perceivable playback artifacts. Such specialized applications MAY
send periodic keep-alive messages to attempt to refresh middlebox
state. It is important to note that keep-alive messages are NOT
RECOMMENDED for general use -- they are unnecessary for many
applications and can consume significant amounts of system and network
resources.</t>
<t>An application that needs to employ keep-alives to deliver useful
service over UDP in the presence of middleboxes SHOULD NOT transmit
them more frequently than once every 15 seconds and SHOULD use longer
intervals when possible. No common timeout has been specified for
per-flow UDP state for arbitrary middleboxes. NATs require a state
timeout of 2 minutes or longer <xref target="RFC4787"></xref>.
However, empirical evidence suggests that a significant fraction of
currently deployed middleboxes unfortunately use shorter timeouts. The
timeout of 15 seconds originates with the Interactive Connectivity
Establishment (ICE) protocol <xref target="ICE"></xref>. When
applications are deployed in more controlled network environments, the
deployers SHOULD investigate whether the target environment allows
applications to use longer intervals, or whether it offers mechanisms
to explicitly control middlebox state timeout durations, for example,
using Middlebox Communications (MIDCOM) <xref
target="RFC3303"></xref>, Next Steps in Signaling (NSIS) <xref
target="NSLP"></xref>, or Universal Plug and Play (UPnP) <xref
target="UPnP"></xref>. It is RECOMMENDED that applications apply
slight random variations ("jitter") to the timing of keep-alive
transmissions, to reduce the potential for persistent synchronization
between keep-alive transmissions from different hosts.</t>
<t>Sending keep-alives is not a substitute for implementing robust
connection handling. Like all UDP datagrams, keep-alives can be
delayed or dropped, causing middlebox state to time out. In addition,
the congestion control guidelines in <xref target="ccguide"></xref>
cover all UDP transmissions by an application, including the
transmission of middlebox keep-alives. Congestion control may thus
lead to delays or temporary suspension of keep-alive transmission.</t>
<t>Keep-alive messages are NOT RECOMMENDED for general use. They are
unnecessary for many applications and may consume significant
resources. For example, on battery-powered devices, if an application
needs to maintain connectivity for long periods with little traffic,
the frequency at which keep-alives are sent can become the determining
factor that governs power consumption, depending on the underlying
network technology. Because many middleboxes are designed to require
keep-alives for TCP connections at a frequency that is much lower than
that needed for UDP, this difference alone can often be sufficient to
prefer TCP over UDP for these deployments. On the other hand, there is
anecdotal evidence that suggests that direct communication through
middleboxes, e.g., by using ICE <xref target="ICE"></xref>, does
succeed less often with TCP than with UDP. The tradeoffs between
different transport protocols -- especially when it comes to middlebox
traversal -- deserve careful analysis.</t>
</section>
<section anchor="progguide" title="Programming Guidelines">
<t>The de facto standard application programming interface (API) for
TCP/IP applications is the "sockets" interface <xref
target="POSIX"></xref>. Some platforms also offer applications the
ability to directly assemble and transmit IP packets through "raw
sockets" or similar facilities. This is a second, more cumbersome
method of using UDP. The guidelines in this document cover all such
methods through which an application may use UDP. Because the sockets
API is by far the most common method, the remainder of this section
discusses it in more detail.</t>
<t>Although the sockets API was developed for UNIX in the early 1980s,
a wide variety of non-UNIX operating systems also implement this. The
sockets API supports both IPv4 and IPv6 <xref
target="RFC3493"></xref>. The UDP sockets API differs from that for
TCP in several key ways. Because application programmers are typically
more familiar with the TCP sockets API, the remainder of this section
discusses these differences. <xref target="STEVENS"></xref> provides
usage examples of the UDP sockets API.</t>
<t>UDP datagrams may be directly sent and received, without any
connection setup. Using the sockets API, applications can receive
packets from more than one IP source address on a single UDP socket.
Some servers use this to exchange data with more than one remote host
through a single UDP socket at the same time. Many applications need
to ensure that they receive packets from a particular source address;
these applications MUST implement corresponding checks at the
application layer or explicitly request that the operating system
filter the received packets.</t>
<t>If a client/server application executes on a host with more than
one IP interface, the application SHOULD send any UDP responses with
an IP source address that matches the IP destination address of the
UDP datagram that carried the request (see <xref
target="RFC1122"></xref>, Section 4.1.3.5). Many middleboxes expect
this transmission behavior and drop replies that are sent from a
different IP address, as explained in <xref
target="natguide"></xref>.</t>
<t>A UDP receiver can receive a valid UDP datagram with a zero-length
payload. Note that this is different from a return value of zero from
a read() socket call, which for TCP indicates the end of the
connection.</t>
<t>Many operating systems also allow a UDP socket to be connected,
i.e., to bind a UDP socket to a specific pair of addresses and ports.
This is similar to the corresponding TCP sockets API functionality.
However, for UDP, this is only a local operation that serves to
simplify the local send/receive functions and to filter the traffic
for the specified addresses and ports. Binding a UDP socket does not
establish a connection -- UDP does not notify the remote end when a
local UDP socket is bound. Binding a socket also allows configuring
options that affect the UDP or IP layers, for example, use of the UDP
checksum or the IP Timestamp option. On some stacks, a bound socket
also allows an application to be notified when ICMP error messages are
received for its transmissions <xref target="RFC1122"></xref>.</t>
<t>UDP provides no flow-control. This is another reason why UDP-based
applications need to be robust in the presence of packet loss. This
loss can also occur within the sending host, when an application sends
data faster than the line rate of the outbound network interface. It
can also occur on the destination, where receive calls fail to return
all the data that was sent when the application issues them too
infrequently (i.e., such that the receive buffer overflows). Robust
flow control mechanisms are difficult to implement, which is why
applications that need this functionality SHOULD consider using a
full-featured transport protocol.</t>
<t>When an application closes a TCP, SCTP or DCCP socket, the
transport protocol on the receiving host is required to maintain
TIME-WAIT state. This prevents delayed packets from the closed
connection instance from being mistakenly associated with a later
connection instance that happens to reuse the same IP address and port
pairs. The UDP protocol does not implement such a mechanism.
Therefore, UDP-based applications need to be robust in this case. One
application may close a socket or terminate, followed in time by
another application receiving on the same port. This later application
may then receive packets intended for the first application that were
delayed in the network.</t>
<t>The Internet can provide service differentiation to applications