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 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, , June 1999 [7] Elloumi O, De Cnodder S, and Pauwels K, "Usefulness of Three Drop Precedences in Assured Forwarding Service", Internet Draft, , 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]