Internet Engineering Task Force Nabil Seddigh
Internet Draft Biswajit Nandy
Expires: December 1999 Peter Pieda
Nortel Networks
June 1999
draft-nsbnpp-diffserv-udptcpaf-00.txt
Study of TCP and UDP Interaction for the AF PHB
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provision s of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IE TF), its areas, and its working groups. Note that
other groups may also distribu te working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
anytime. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "
work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This informational draft presents results of a study on using
different drop precedence assignments to address fairness issues when
UDP and TCP traffic share the same Assured Forwarding (AF) PHB class.
In particular, five different possible combinations of drop
precedence assignment were explored with two different models of RED
parameter settings. We present results showing that the type of RED
model utilized can play a role in the nature of bandwidth sharing
between TCP and UDP flows. The results also show that with the
current four Class, three Drop Precedence AF specification, fairness
between TCP and UDP in an under-provisioned network cannot be
completely achieved by using separate drop precedence marking.
Certain drop precedence mapping schemes are beneficial to TCP while
others are beneficial for UDP. None are completely fair to both.
The pdf version of this document is available at:
http://www7.nortel.com:8080/CTL/
Seddigh, Nandy, Pieda [Page 1]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
1.0 Introduction
Recent studies of the Assured Forwarding PHB [5] showed that there
are a number of factors that affect fair bandwidth distribution for
aggregates with equal target rates [3] [4]. These factors cause
unfair distribution of excess bandwidth in an over-provisioned
network as well as unfair degradation in an under-provisioned or
over-subscribed network. One of the key factors identified is the
effect of unresponsive flows such as UDP when they share the same AF
class as TCP flows. In recent Diffserv IETF discussions on whether
the AF PHB required two or three drop precedences, it has
periodically been suggested that the TCP packets can be protected
from non-responsive UDP packets by assigning UDP to a different drop
precedence value than TCP. A preliminary study in this area was
reported by Goyal et al [6].
This work builds on the results presented in [6]. It studies the type
of bandwidth assurance that can be obtained in five different
scenarios where UDP & TCP packets are allocated to five different
drop precedence combinations.
To date, the discussion on solving the UDP/TCP fairness issue for the
AF PHB seems to have focused on penalizing the UDP flows. While there
is clearly a need to ensure that responsive TCP flows are protected
from non-responsive flows in the same class, we also recognize that
certain UDP flows will require the same fair treatment as TCP due to
multimedia requirements. Essentially, there is a need to ensure that
the drop precedence mapping scheme utilized should ensure fairness
for both TCP and UDP. In this case, we define fairness to mean that:
(a) In an over-provisioned network, UDP in-profile traffic
should be protected and TCP flows should obtain their
target bandwidths while competing for the excess bandwidth
(b) In an under-provisioned network, TCP and UDP flows should
experience proportional degradation of their
target bandwidth.
2.0 Experimental description and scope
The goal of the experiments is to explore five different combinations
of drop precedence mappings for TCP and UDP. The scenarios explored
only consider TCP flows with single target rates. There are no dual
rate targets. The experiments do not explore the possibility that
packets from a single policy aggregate may be marked into three
different drop precedences. Packets from a single policy aggregate
can be marked either in or out-of-profile (a maximum of two different
drop precedences) but depending on the particular mapping scheme
used, may be assigned any one of the three drop precedence markings
for that class.
Seddigh, Nandy, Pieda [Page 2]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
The study was carried out using VxWorks-based Diffserv Edge and Core
device prototypes developed at the Computing Technology Lab, Nortel
Networks.
The devices implement the AF PHB using the Multiple-RED (MRED)
algorithm. This document will use DP0 to specify the drop precedence
value with lowest drop probability and DP2 to specify the drop
precedence with highest drop probability. The MRED algorithm operates
as specified in the RIO scheme of [2]. The possibility of dropping
DP0 packets is dependent on the buffer occupancy of DP0 packets. The
possibility of dropping DP1 packets is dependent on the buffer
occupancy of DP0 and DP1 packets. The possibility of dropping DP2
packets is dependent on the buffer occupancy of DP0, DP1 and DP2
packets. The policer used is the TSW (Time Sliding Window) tagger
described in [2].
Table 1: Possible Scenarios for mapping TCP and UDP to
different drop precedences
Scenario Possibility
------------------------------------
| 1 | 2 | 3 | 4 | 5 |
-------------------------------------------------------
TCP 'in profile' | DP0 | DP0 | DP0 | DP0 | DP0 |
TCP 'out of profile' | DP1 | DP1 | DP1 | DP2 | DP1 |
UDP 'in profile' | DP0 | DP1 | DP1 | DP1 | DP2 |
UDP 'out of profile' | DP1 | DP1* | DP2 | DP2 | DP2* |
* No distinction is made between UDP 'IN' and 'OUT' of profile
packets
When considering the possibility of mapping TCP and UDP to different
drop precedences, we explored the matrix of options depicted in Table
1. The table shows for each scenario, which drop precedence the
UDP/TCP 'IN' and 'OUT' packets are mapped to. Thus for example,
scenario three is the case where TCP is mapped to DP2.
Scenario one is the baseline case that has been used in the various
studies that show fairness issues between UDP and TCP flows. The UDP
and TCP flows all have target rates and are mapped to the same drop
precedence in a single AF class.
Scenario two explores the possibility of mapping TCP in-profile
packets to DP0 marking, while mapping TCP out-of-profile and all UDP
packets to DP1. This is essentially a similar testcase as the one
performed by [6]. However, the difference is that we also use a
different RED model where the min-max thresholds do not overlap. As
the results show, this is an important factor.
In scenario three, TCP in-profile packets are mapped to DP0, TCP
out-of-profile packets are mapped to DP1, UDP in-profile packets are
mapped to DP1 and UDP out-of-profile packets are mapped to DP2. This
testcase differs from the previous one in that the UDP out-of-profile
traffic does not share the same drop precedence as the UDP in-profile
Seddigh, Nandy, Pieda [Page 3]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
traffic.
Scenario four is the same as scenario three except that TCP out-of-
profile packets are put in DP2. Thus, out-of-profile packets for both
TCP and UDP is put in DP2 while in-profile traffic is mapped to DP0
and DP1 respectively.
Scenario five completely isolates TCP and UDP traffic. TCP in-profile
traffic is mapped to DP0, TCP out- of-profile traffic is mapped to
DP1 and UDP traffic is mapped to DP2. This mapping is similar to one
performed in [6].
Experiments are performed for the above five scenarios with two
different models for the RED [1] parameter settings. Figure 1 depicts
the two types of models. In the first model, the min-max thresholds
are the same for DP0, DP1 and DP2 packets. Thus, the only factor
causing differentiation is maxp û the drop probability. In the second
model (figure b), the min-max thresholds for the different drop
precedence decisions don't overlap at all. This model allows a
greater opportunity for higher drop precedence (ie DP0) packets to
reach their end destinations than the other model. We call the first
model the 'overlap RED model' and the second model the 'non-overlap
RED model'. The RED parameter settings for the two models are
depicted in Table 2:
Table 2: RED parameter settings for experiments
Red Model
------------------------------------------------
| (a) || (B) |
-----------------------------------------------
| Minth | Maxth | Maxp || Minth | Maxth | Maxp |
------------------------------------------------------
DP0 | 10 | 40 | 0.02 || 40 | 55 | 0.02 |
DP1 | 10 | 40 | 0.05 || 25 | 40 | 0.05 |
DP2 | 10 | 40 | 0.1 || 10 | 25 | 0.01 |
The experimental network configuration is depicted in Figure 2. The
Netperf tool [7] was used to generate all the competing TCP traffic.
The UDPBLAST tool was used to generate all the UDP non-responsive
traffic. The competing TCP flows were all long lived. The link
between E1 and the core as well as between E2 and core was 10Mbps.
The link between core and E3 is the bottleneck link and has a
bandwidth of 5Mbps.
Seddigh, Nandy, Pieda [Page 4]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
Client C1 *===
>====|E1|====
Client C2 *===/ /===* Client C5
>====|Core|----|E3|====<
Client C3 *=== / ===* Client C6
>====|E2|====/
Client C4 *===/
Legend: E : Edge
== : 10 Mbps Link
-- : 5 Mbps Link
Figure 2 Experimental Network Setup
In the setup, a total of 24 TCP flows are generated from the sources
that enter the network via edge devices E1 and E2. The 24 flows are
divided amongst the source machines so that each machine sources 6
flows. A target rate is assigned for each group of 6 flows. UDP flows
are started from two of the source machines. All flows terminate in
the sink machines that connect to edge device E3. The UDP flows
source traffic at the rate of 1Mbps. The target bandwidth for each
UDP flow and TCP aggregate group is listed in the Figures of the
result section
3.0 Results
This section presents the results for each of the 5 scenarios
mentioned in the previous section. Each scenario has 2 results û one
for each RED model.
Figure 3: Experiment #1 (a)
---------------------------------------------
Test1 no overlap red model
---------------------------------------------
TCP Target Profile (Mbps)
----------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.66 0.75 0.81 0.89 0.94 0.91
C2-C5: TCP 0.70 0.73 0.79 0.93 1.0 1.01
C3-C6: TCP 0.67 0.73 0.81 0.94 0.97 0.96
C4-C6: TCP 0.89 0.82 0.87 0.96 1.05 1.10
C1-C5: UDP 0.99 0.95 0.82 0.60 0.48 0.48
C3-C6: UDP 0.99 0.95 0.83 0.61 0.49 0.48
Figure 3: Experiment #1 (b)
Seddigh, Nandy, Pieda [Page 5]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
---------------------------------------------
Test1 overlap red model
---------------------------------------------
TCP Target Profile (Mbps)
----------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.65 0.78 0.79 0.95 0.97 0.94
C2-C5: TCP 0.64 0.73 0.82 0.92 1.0 0.96
C3-C6: TCP 0.73 0.73 0.82 0.92 0.94 0.97
C4-C6: TCP 0.93 0.80 0.84 0.97 1.06 1.13
C1-C5: UDP 0.99 0.95 0.83 0.58 0.48 0.46
C3-C6: UDP 0.99 0.95 0.83 0.58 0.48 0.47
Figure 4: Experiment #2 (a)
---------------------------------------------
Test 2 No Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.69 0.81 0.87 1.02 1.18 1.22
C2-C5: TCP 0.78 0.79 0.88 0.99 1.14 1.21
C3-C6: TCP 0.77 0.78 0.88 1.0 1.16 1.24
C4-C6: TCP 0.89 0.90 0.96 1.06 1.19 1.25
C1-C5: UDP 0.90 0.82 0.66 0.43 0.13 0.015
C3-C6: UDP 0.90 0.82 0.67 0.43 0.13 0.015
Figure 4: Experiment #2 (b)
---------------------------------------------
Test 2 Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.75 0.75 0.89 1.01 1.14 1.13
C2-C5: TCP 0.78 0.82 0.88 0.98 1.13 1.14
C3-C6: TCP 0.77 0.77 0.89 1.04 1.10 1.14
C4-C6: TCP 0.83 0.94 0.93 1.05 1.15 1.27
C1-C5: UDP 0.90 0.83 0.67 0.42 0.20 0.14
C3-C6: UDP 0.90 0.83 0.68 0.43 0.20 0.14
Figure 5: Experiment #3 (a)
---------------------------------------------
Test 3 No Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.95 1.02 1.0 1.06 1.19 1.19
Seddigh, Nandy, Pieda [Page 6]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
C2-C5: TCP 0.97 0.94 1.02 1.09 1.15 1.27
C3-C6: TCP 0.95 0.96 1.04 1.06 1.16 1.22
C4-C6: TCP 1.18 1.14 1.09 1.13 1.20 1.26
C1-C5: UDP 0.44 0.44 0.39 0.3 0.12 0.004
C3-C6: UDP 0.45 0.43 0.39 0.29 0.12 0.004
Figure 5: Experiment #3 (b)
---------------------------------------------
Test 3 Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 1.02 0.96 1.03 1.06 1.18 1.21
C2-C5: TCP 1.02 1.04 1.0 1.09 1.15 1.22
C3-C6: TCP 0.87 1.0 1.03 1.09 1.16 1.22
C4-C6: TCP 1.13 1.08 1.09 1.10 1.21 1.29
C1-C5: UDP 0.44 0.43 0.39 0.30 0.11 0.0002
C3-C6: UDP 0.45 0.42 0.40 0.29 0.12 0.0005
Figure 6: Experiment #4 (a)
---------------------------------------------
Test 4 No Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.66 0.74 0.81 0.95 1.15 1.21
C2-C5: TCP 0.70 0.75 0.82 0.93 1.14 1.26
C3-C6: TCP 0.72 0.75 0.82 0.94 1.15 1.21
C4-C6: TCP 0.81 0.80 0.88 0.98 1.14 1.24
C1-C5: UDP 0.98 0.93 0.80 0.57 0.18 0.003
C3-C6: UDP 0.99 0.94 0.81 0.57 0.17 0.003
Figure 6: Experiment #4 (b)
---------------------------------------------
Test 4 Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.69 0.70 0.80 0.92 1.12 1.11
C2-C5: TCP 0.72 0.76 0.81 0.93 1.09 1.13
C3-C6: TCP 0.72 0.76 0.83 0.94 1.07 1.10
C4-C6: TCP 0.80 0.80 0.85 0.97 1.14 1.23
C1-C5: UDP 0.99 0.95 0.82 0.59 0.25 0.18
C3-C6: UDP 1.0 0.95 0.82 0.57 0.25 0.19
Figure 7: Experiment #5 (a)
---------------------------------------------
Test 5 No Overlap Red Model
Seddigh, Nandy, Pieda [Page 7]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 1.08 1.20 1.15 1.26 1.18 1.16
C2-C5: TCP 1.17 1.23 1.20 1.19 1.20 1.25
C3-C6: TCP 1.10 1.16 1.18 1.24 1.21 1.25
C4-C6: TCP 1.57 1.32 1.30 1.23 1.35 1.28
C1-C5: UDP 0.005 0.014 0.048 0.01 0.0008 0
C3-C6: UDP 0.005 0.015 0.048 0.01 0.0003 0
Figure 7: Experiment #5 (b)
---------------------------------------------
Test 5 Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 1.01 1.05 1.0 1.06 1.17 1.15
C2-C5: TCP 1.12 1.06 1.0 1.04 1.12 1.12
C3-C6: TCP 1.06 1.04 0.99 1.07 1.04 1.14
C4-C6: TCP 1.21 1.17 1.15 1.12 1.19 1.27
C1-C5: UDP 0.27 0.30 0.40 0.32 0.21 0.13
C3-C6: UDP 0.27 0.31 0.40 0.32 0.21 0.14
Figure 3 shows the results for experimentation with scenario one
described in section 2. This is the scenario where TCP and UDP
traffic are mapped to the same drop precedence. As the Figure shows,
TCP flows achieve their target rates in an over-provisioned network.
The UDP flows not only achieve their targets but get a share of the
bandwidth for their out-of-profile packets. However, as the network
approaches an under- provisioned state, the TCP flows suffer more
degradation than the UDP flows. UDP gains unfairly at the advantage
of TCP flows. This holds for both RED models.
The second experiment is essentially similar to the experiment
performed in [6]. The results of this experiment are presented in
Figure 4. As the network approaches an under-provisioned state, the
TCP flows suffer minimal degradation compared to UDP and approach
their specified traffic profile. We note that for RED model (b), the
results mimic what was reported in [6]. However, for RED model (a),
the results are different. In the overlapped RED model, UDP flows
achieve some measure of their bandwidth û though not much. However,
in the non-overlapped model, as the network approaches an under-
provisioned state, the UDP flows are severely punished and finally
starved. The TCP gain is at the expense of the UDP in-profile and
out-of-profile traffic.
Scenario 3 staggers the mapping of drop precedences. The experimental
results are depicted in Figure 5. From the Figure, we see that the
results obtained in this scenario are similar to those obtained for
the previous scenario. The only difference is that UDP traffic beyond
Seddigh, Nandy, Pieda [Page 8]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
its target profile is discarded even in an over-provisioned network.
This is because UDP out-of-profile is mapped to DP2. In an under-
provisioned situation, the DP1 and DP2 queue averages are close
enough to the maximum RED threshold that most of their packets are
discarded.
Scenario four is a slight variation of experiment three except that
TCP out-of-profile packets are mapped to DP2 instead of DP1. The
objective of this experiment was to protect UDP in-profile traffic by
putting TCP- out-of-profile traffic in DP2. The results are captured
in Figure 6. Moving the TCP out-of-profile packets to DP2 allowed UDP
to capture a greater share of the bandwidth in an over-provisioned
network. However, UDP is still starved in the under-provisioned case.
This is because in an under-provisioned network, the DP1 average
queue size is quite close to the maximum threshold and so all its
packets are dropped.
Scenario five is the case where TCP and UDP packets are totally
isolated. All the UDP traffic is mapped to DP2 while the TCP traffic
is mapped to DP0 and DP1 depending on whether or not it is in or out
of profile. The results in Figure 7 show that in the non-overlapped
RED model, UDP flows are completely starved. In the overlapped RED
model case, UDP receives some measure of the bandwidth but very
minimal. In either situation, the TCP flows are well protected from
UDP.
4.0 Experiments with De-coupled Drop Decision
Based on the results in the previous section, it appears as though
with the current RIO-based scheme, fairness issues between TCP and
UDP in a single AF class remain unsolved. We now consider slight
modifications to the RIO scheme [2] to determine if this will provide
a solution to the TCP/UDP interaction. In order to achieve fairness
it appears as though TCP and UDP packets must be isolated from each
other in terms of their drop precedence. However, as Figure 7 showed,
even this is not sufficient. In this scenario, UDP packets in DP2
receive unfairly degraded service because their drop probability is
dependent on the buffer occupancy of packets from DP1 and DP0. We
performed experiments where the drop decision for packets of each
drop precedence marking were dependent only on the buffer occupancy
of packets with their own marking. Thus, DP2 packet drop decision is
dependent on the buffer occupancy of DP2 packets. This is labelled as
the decoupled drop decision.
The tests that were performed utilized the same network setup as the
previous section. Scenarios 1, 2 and 5 were repeated with the de-
coupled drop decision algorithm. The results are reported in Table 3.
The table only shows results for the situation where the network
approaches an under-provisioned state. In these scenarios, each of
the TCP groups has a target profile of 1Mbps and each of the UDP
groups have a target profile of 0.5Mbps. The UDP flows source traffic
at the rate of 1Mbps.
Seddigh, Nandy, Pieda [Page 9]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
For scenarios 1 and 2, the results are beneficial for UDP. All the
UDP in-profile and out-of-profile traffic is protected at the expense
of TCP in-profile traffic. This is in contrast to experiment 2 of the
previous section. In that experiment, UDP achieved limited or no
bandwidth. Neither of these cases were fair.
Scenario 5 from the previous section was also repeated. In this case,
the UDP flows appear to receive their target bandwidths of 0.5Mbps.
However, on closer examination, this can be explained in the
following manner. The bandwidth of the UDP flows is governed by the
RED parameter settings and not their target profiles. Measurements on
queue size revealed a queue size of 70pkts. Of this, 15 of these
packets were DP2. Assuming an equal split between the UDP flows, each
UDP flow contributed 7 packets to the queue. The rate of UDP traffic
serviced is thus, (7/70)*5Mbps = 0.5Mbps. We found that if we
increased the maxth for DP2, the service rate would increase
accordingly irrespective of the actual traffic profile. Thus, it
seems that even decoupling drop decisions will not solve the UDP/TCP
fairness problem. It could be argued that the real test of isolation
and decoupling can only be done with 4 drop precedences where TCP in
and out of profile are mapped to DP0 and DP1 with UDP mapped to DP2
and DP3. This is an area that needs further experimentation.
Table 3: Results of test with Decoupled Drop Decision
Bandwidths(Mbps)
Test | |Mn Mx Mxp | TCP1 TCP2 TCP3 TCP4 UDP1 UDP2 |
----------|------------------------------------------------------|
Experiment|(i) | DP0 |10 40 0.02 | 0.69 0.55 0.72 0.91 1.02 1.03 |
one | | DP1 |10 40 0.05 | |
|----------------------|-------------------------------|
|(ii)| DP0 |20 40 0.02 | 0.65 0.78 0.77 0.69 1.02 1.02 |
| | DP1 |10 20 0.05 | |
----------|----------------------|-------------------------------|
Experiment|(i) | DP0 |10 30 0.02 | 0.66 0.77 0.52 0.88 1.05 1.05 |
two | | DP1 |10 25 0.05 | |
| | DP2 |10 20 0.1 | |
|----------------------|-------------------------------|
|(ii)| DP0 |10 45 0.02 | 0.74 0.77 0.74 0.87 0.91 0.91 |
| | DP1 |10 20 0.05 | |
| | DP2 |7 15 0.1 | |
----------|----------------------|-------------------------------|
Experiment| | DP0 |20 40 0.02 | 1.0 0.90 0.93 1.15 0.47 0.48 |
three | | DP1 |10 20 0.05 | |
| | DP2 |7 15 0.1 | |
-----------------------------------------------------------------|
TCP1: C1 - C5
TCP2: C2 - C5
TCP3: C3 - C6
TCP4: C4 - C6
UDP1: C1 - C5
UDP2: C3 - C6
Seddigh, Nandy, Pieda [Page 10]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
This work has considered a number of different combinations of drop
preference mapping with the goal of allowing TCP and UDP flows to
co-exist in a single AF class with neither traffic type experiencing
unfair degradation of bandwidth in an under-provisioned network. The
results show that such a goal is extremely difficult. An easier
approach to the problem is to put TCP and UDP traffic in separate AF
classes or queues. With such a scheme, both traffic types would
obtain their provisioned share of the bandwidth. UDP flows will be
restricted while still retaining their provisioned share of the
bandwidth. TCP flows will be protected from UDP.
5.0 Summary
The results in section 3.0 show that when UDP and TCP share the same
drop precedence assignment, in under-provisioned networks, UDP
suffers minimal degradation compared to the TCP flows. In experiments
2, 3, 4, and 5, the TCP profile is protected to some extent while the
UDP flows experience degradation and in some cases starvation. While
this is good for TCP, it is not good for those subscribers who wish
to have the same fairness attributes applicable to both TCP and UDP.
In summary, the results of this document show that:
1. Putting UDP 'IN' packets in DP1 or DP2 restricts the impact of
non-responsive flows on TCP when they compete for available
bandwidth in the same AF class in an under-provisioned network.
2. However, depending on the RED model used, UDP traffic with
identical profile as TCP could be starved or severely degraded.
This may not be acceptable to a subscriber who would like the
two traffic types to be treated equally.
3. Regardless of whether an AF class has two or three drop
precedences, the above two conclusions hold true. Three drop
precedences per AF class are not required to mitigate the
effects of UDP on TCP traffic. This is the same observation as [6].
4. A better solution that allows UDP and TCP to coexist fairly is
to put them in separate queues. Such a scheme will not only
address the fairness issues but will also restrict the delay
that UDP packets experience in the queue thus making AF
more amenable for real-time services.
6.0 References
[1] Floyd, S., and Jacobson, V., ôRandom Early Detection gateways for
Congestion Avoidance ô,IEEE/ACM Transactions on Networking, V.1
N.4, August 1993, p. 397-413.
[2] Clark D. and Fang W., ôExplicit Allocation of Best Effort Packet
Seddigh, Nandy, Pieda [Page 11]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-00.txt June 1999
Delivery Serviceö, http://diffserv.lcs.mit.edu/exp-alloc-ddc-wf.ps
1998
[3] Ibanez J, Nichols K., ôPreliminary Simulation Evaluation of
an Assured Serviceö, Internet Draft,
draft-ibanez-diffserv-assured-eval-00.txt>, August 1998
[4] Seddigh N, Nandy B, and Pieda P, "Bandwidth Assurance Issues
for TCP flows in a Differentiated Services Network",
submitted for publication, March 1999
http://www7.nortel.com:8080/CTL/
[5] Heinanen J., Baker F., Weiss W., and Wroclawski J.,
ôAssured Forwarding PHB Groupö, Internet Draft, RFC 2597, June 1999.
[6] Goyal M, Misra P, and Jain R, "Effect of Number of Drop
Precedences in Assured Forwarding", Internet Draft,
<draft-goyal-dpstdy-diffserv-00.txt>, March 1999
[7] http://www.netperf.org/netperf/NetperfPage.html
7.0 Author Addresses
Nabil Seddigh
Nortel Networks
3500 Carling Ave
Ottawa, ON, K2H 8E9
Canada
Email: nseddigh@nortelnetworks.com
Biswajit Nandy
Nortel Networks
3500 Carling Ave
Ottawa, ON, K2H 8E9
Canada
Email: bnandy@nortelnetworks.com
Peter Pieda
Nortel Networks
3500 Carling Ave
Ottawa, ON, K2H 8E9
Canada
Email: ppieda@nortelnetworks.com
Seddigh, Nandy, Pieda [Page 12]