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, , 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]