Internet Engineering Task Force Nabil Seddigh
Internet Draft Biswajit Nandy
Expires: February 2000 Peter Pieda
Nortel Networks
September 1999
Study of TCP and UDP Interaction for the AF PHB
<draft-nsbnpp-diffserv-udptcpaf-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute 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, six 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, complete fairness
between TCP and UDP cannot be completely achieved using separate drop
precedence assignment. This is true for both under-provisioned
networks and over-provisioned networks. Certain drop precedence
mapping schemes are beneficial to TCP while others are beneficial for
UDP.
The pdf version of this document is available at:
http://www7.nortel.com:8080/CTL/draft-nsbnpp-diffserv-tcpudpaf-01.pdf
Seddigh, Nandy, Pieda [Page 1]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
1.0 Introduction
Recent studies [3] [4] 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. 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
with 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. Preliminary studies in this area have been reported by
Goyal [6] and Elloumi [7]. This work studies the type of bandwidth
assurance that can be obtained in six different scenarios where UDP &
TCP packets are allocated to six different drop precedence
combinations.
To date, the discussion on solving the UDP/TCP fairness issue for the
AF PHB appears 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, both UDP and TCP target rates
should be achieved with the in-profile traffic being protected
(b) In an over-provisioned network, UDP out-of-profile and TCP
out-of-profile packets should have a reasonable share of the
excess bandwidth. Neither TCP nor UDP should be denied access
to the excess bandwidth.
(c) In an under-provisioned network, TCP and UDP flows should
experience degradation in proportion to their target bandwidth
2.0 Experimental description and scope
The goal of the experiments is to explore six different combinations
of drop precedence mappings for TCP and UDP within a single AF class.
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
Seddigh, Nandy, Pieda [Page 2]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
drop precedence markings for that class.
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)
scheme. 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 scheme operates in
accordance with the RIO algorithm described by Clark and Fang in [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 | 6 |
-----------------------------------------------------------------
TCP 'in profile' | DP0 | DP0 | DP0 | DP0 | DP0 | DP0 |
TCP 'out of profile' | DP1 | DP1 | DP1 | DP2 | DP1 | DP1 |
UDP 'in profile' | DP0 | DP1 | DP1 | DP1 | DP2 | DP0 |
UDP 'out of profile' | DP1 | DP1* | DP2 | 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. For each scenario, the table captures the drop precedence that
UDP/TCP 'IN' and 'OUT' packets are mapped to.
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
Seddigh, Nandy, Pieda [Page 3]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
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
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].
In Scenario six, both TCP and UDP in-profile packets are mapped to
DP0. However, TCP out-of-profile packets are mapped to DP1 while UDP
out-of-profile packets are mapped to DP2.
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 |
Experiments are performed for the above six 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.
The experimental network configuration is depicted in Figure 2. The
Netperf tool [8] 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-01.txt February 2000
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 six scenarios
mentioned in the previous section. Each scenario has 2 resultsû one
for each RED model.
Figure 3: Scenario #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
Seddigh, Nandy, Pieda [Page 5]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
Figure 3: Scenario #1 (b)
---------------------------------------------
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 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. The results for the RED model (a)
appear to be slightly different from that of RED model (b). In
overlapped RED model (RED model b), UDP flows achieve some measure of
their bandwidth though not much. However, in the non-overlapped
model (RED model a), 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.
Figure 4: Scenario #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
Seddigh, Nandy, Pieda [Page 6]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
Figure 4: Scenario #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
Scenario three 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 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.
Figure 5: Scenario #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
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
Seddigh, Nandy, Pieda [Page 7]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
Figure 5: Scenario #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
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.
Figure 6: Scenario #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: Scenario #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
Seddigh, Nandy, Pieda [Page 8]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
In scenario six, TCP and UDP in-profile packets share the same drop
preference while their out-of-profile packets are mapped to different
drop preferences. The results are captured in Figure 8. In the over-
provisioned case, both TCP and UDP achieve their target bandwidth. In
the overlapped RED model, the UDP flows achieve a share of the excess
bandwidth while the non-overlapped RED model doesn't allow the UDP
flows to pick up any of the excess bandwidth. In an under-provisioned
network, the TCP flows suffer maximal degradation from their target
bandwidth, while the UDP flows experience little degradation.
Figure 7: Scenario #5 (a)
---------------------------------------------
Test 5 No Overlap Red Model
---------------------------------------------
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: Scenario #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 8: Scenario #6 (a)
---------------------------------------------
Test 6 No 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.94 0.94 0.96 0.97 1.01
C2-C5: TCP 0.88 0.98 0.96 0.96 0.95 0.93
C3-C6: TCP 0.90 0.90 1.0 0.98 1.04 0.90
C4-C6: TCP 1.07 1.07 1.02 1.02 1.05 1.18
C1-C5: UDP 0.51 0.51 0.51 0.50 0.47 0.47
C3-C6: UDP 0.53 0.51 0.50 0.51 0.47 0.46
Seddigh, Nandy, Pieda [Page 9]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
Figure 8: Scenario #6 (b)
---------------------------------------------
Test 6 Overlap Red Model
---------------------------------------------
TCP Target Profile (Mbps)
---------------------------------
0.25 0.50 0.75 1.0 1.25 1.50
---------------------------------------------
C1-C5: TCP 0.77 0.85 0.87 0.92 0.86 0.99
C2-C5: TCP 0.77 0.84 0.89 0.89 0.94 0.77
C3-C6: TCP 0.83 0.80 0.86 0.93 0.96 0.90
C4-C6: TCP 0.98 0.88 0.88 0.94 1.01 1.13
C1-C5: UDP 0.78 0.77 0.72 0.63 0.59 0.58
C3-C6: UDP 0.79 0.77 0.71 0.63 0.58 0.57
4.0 Discussion of Results
Table 3 summarizes the results of the six experiments and puts them
in the context of the objectives of this study. From the table, we
observe that the three objectives of section one translate into six
criteria (two each for TCP and UDP) by which one can evaluate any
drop precedence mapping scheme. One relevant observation from the
table is that none of the scenarios achieves all three objectives for
both TCP and UDP. At most, four out of six criteria are achieved.
Table 3: Summary of Test Results from Six Scenarios
-------------------------------------------------------------------
Tests | Over-Provisioned Scenario | Under-Provisioned |
-------------------------------------------------------------------
| | Gets share of | Achieves Fair |
| Achieves Target | Excess BW | Degradation of Target |
| | | Rate |
-------------------------------------------------------------
| TCP | UDP | TCP | UDP | TCP | UDP |
-------------------------------------------------------------------
1 | Y | Y | * | Y | * | Y |
-------------------------------------------------------------------
2 | Y | Y | * | Y | Y | * |
-------------------------------------------------------------------
3 | Y | * | Y | * | Y | * |
-------------------------------------------------------------------
4 | Y | Y | * | Y | Y | * |
-------------------------------------------------------------------
5 | Y | * | Y | * | Y | * |
-------------------------------------------------------------------
6 | Y | Y | Y | *** | * | Y |
-------------------------------------------------------------------
Y: Yes
*: No
***: Depending on the RED model used, UDP either gets some or
none of the excess bandwidth.
Seddigh, Nandy, Pieda [Page 10]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
The results show that in an over-provisioned network, if TCP is
mapped to DP0, it mostly achieves its target rate irrespective of the
drop preference to which UDP in-profile packets are mapped. UDP
achieves its target rate if its in-profile packets are protected by
mapping them to DP0 (cases 3 and 5 being the exception). However, the
manner in which excess bandwidth is shared remains dependent on the
drop preference assigned to UDP out-of-profile packets none of the
scenarios are fair to both UDP and TCP. In an under-provisioned
network, mapping TCP in-profile to DP0 and UDP in-profile to either
DP1 or DP2 causes TCP to suffer lesser degradation from its target
bandwidth than UDP. Mapping both UDP and TCP in-profile to DP0
results in unfairness to TCP as it experiences severe degradation
from its target bandwidth as opposed to UDP.
5.0 Experiments with Decoupled 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 4.
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.
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
Seddigh, Nandy, Pieda [Page 11]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
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 4: 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
6.0 Summary
In summary, the results of this work are:
1. UDP and TCP interaction issues cannot be resolved completely
using drop preference mapping:
Seddigh, Nandy, Pieda [Page 12]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
- In an over-provisioned network, UDP and TCP traffic achieve
their target rates if the in-profile traffic is protected.
- In an over-provisioned network, the share of excess bandwidth
is dependent on the mapping of out-of-profile packets.
- In an under-provisioned network, if TCP and UDP share the same
AF class, fair degradation for both traffic types cannot be
achieved by different drop precedence assignments.
2. The choice of RED model impacts the way in which TCP and UDP
traffic interact. Some form of guideline would be useful.
3. A better solution that allows UDP and TCP to coexist fairly is
to put them in separate queues or AF classes. Such a scheme
will not only address the fairness issues but will also restrict
the delay and jitter that UDP packets experience in the queue.
This should make AF more amenable for real-time services.
7.0 References
[1] Floyd S, and Jacobson V, "Random Early Detection gateways for
Congetion Avoidance", IEEE/ACM Transactions on Networking,
V.1.N.4, August 1993, pp 397-413
[2] Clark D and Fang W, "Explicit Allocation of Best Effort Packet
Delivery Service", ACM Transactions on Networking, August 1998
[3] Ibanez J and 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",
to be presented at GLOBECOM 99, Rio De Janeiro, December 1999
[5] Heinanen J., Baker F., Weiss W., and Wroclawski J.,
Assured Forwarding PHB Group, Internet Draft, RFC 2597, June 1999
[6] Goyal M, Durresi A and Jain R, "Effect of Number of Drop
Precedences in Assured Forwarding", Internet Draft,
<draft-goyal-dpstdy-diffserv-02.txt>, June 1999
[7] Elloumi O, De Cnodder S, and Pauwels K, "Usefulness of Three
Drop Precedences in Assured Forwarding Service", Internet Draft,
<draft-elloumi-diffserv-threevstwo-00.txt>, July 1999
[8] http://www.netperf.org/netperf/NetperfPage.html
7.0 Author Addresses
Seddigh, Nandy, Pieda [Page 13]
INTERNET DRAFT draft-nsbnpp-diffserv-udptcpaf-01.txt February 2000
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 14]