Internet Draft Internet Engineering Task Force Praveen Bhaniramka INTERNET DRAFT Wei Sun Raj Jain File: draft-bhani-mpls-te-anal-00.txt March, 1999 Expires: September, 1999 Quality of Service using Traffic Engineering over MPLS: An Analysis Status of this Memo This document is an Internet-Draft. 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 any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). NOTE This document is not to be taken as a finished product. Some of the sections are rough and are included in order to obtain comments from the community that will benefit future iterations of this document. This is simply a step in the ongoing conversation about this document. Finally, all the authors of this draft do not necessarily agree with and/or advocate all the mechanisms outlined in this document. 1. Abstract We compare the service received by TCP and UDP flows when they share either a link or an MPLS traffic trunk. Since traffic trunks allow non shortest path links also to be used, the total network throughput goes up with proper traffic engineering. If UDP and TCP flows are mixed in a trunk, TCP flows receive reduced service as the UDP flows increase their rates. Also, we found that in order to benefit from traffic engineering, MPLS trunks should be implemented end-to-end (first router to last router). If some part of the network is MPLS-unaware, the benefits are reduced or eliminated. Bhani & Sun & Jain [Page 1] draft-bhani-mpls-te-anal-00.txt - 2 - March, 1999 2. Introduction This draft presents an analysis of performance of TCP and UDP flows using MPLS traffic trunks. According to Li and Rekhter [1] and also in MPLS traffic engineering requirements documents [2], a traffic trunk is an aggregation of traffic flows of the same class which are placed inside a Label Switched Path (LSP). Traffic trunks are routable objects like virtual circuits in ATM and Frame Relay networks. These trunks can be established either statically or dynamically between any two nodes in an MPLS domain. A trunk can carry any aggregate of micro-flows, where each micro-flow consists of packets belonging to a single TCP or UDP flow. In general, trunks are expected to carry several such micro-flows of different transport types. However, as shown in this analysis, mixing different transport types can cause performance problems such as starvation and unfairness for certain traffic. In this draft, we analyze the performance impact of mixing TCP and UDP traffic. The two transports have very different congestion response. TCP has congestion control and so it reduces its traffic in response to packet loss. UDP has no congestion control and does not respond to losses. While it is possible to design UDP applications that are sensitive to congestion losses, very few such applications exist. 3. Network Topology: We used network simulator version 2 (ns-2) [3] for our analysis with new modules for label switching and trunk queueing. In the simulations, the network topology shown in Figure 1 was used. It consists of six routers and six end-systems. There are 3 flows. Source S1 sends UDP traffic to destination D1. Sources S2 and S3 send TCP traffic to destination D2 and D3, respectively. The UDP source sends traffic at a given rate. The TCP sources are "infinite ftp" sources and send packets whenever its congestion window allows. The two TCP flows are different only in their packet sizes. The first TCP flow (TCP1) between S2 and D2 uses an MSS of 512 bytes. The second flow (TCP2) between S3 and D3 uses an MSS of 1024 bytes. Thus, the two flows are almost identical except for the packet sizes. There exist two parallel paths between routers R2 and R5, one of a high bandwidth (45 Mbps) and another of comparatively low bandwidth (15 Mpbs). Bhani & Sun & Jain [Page 2] draft-bhani-mpls-te-anal-00.txt - 3 - March, 1999 S1 --R3-- D1 \ / \ / \ / \ / \ / \ / S2----R1-----R2 R5------R6----D2 / \ / \ / \ / \ / \ / \ S3 --R4-- D3 Figure 1: Network Topology 4. Simulation Results We analyzed four different scenarios with different intermixing of TCP and UDP flows. These scenarios and the analysis results are as follows. Case 1: No Trunks The first case we analyzed is current IP with best effort shortest path routing without any trunks. All data in this case follows the high-speed path R2-R3-R5 and the alternative path R2-R4-R5 is unused. We vary the UDP rate and measure the throughput of the three flows. The results are shown in Table 1. Table 1: Results using normal IP routing ------------------------------------------------------------ UDP Source rate (Mbps) | Throughput (Mbps) ------------------------------------------------------------ | UDP TCP1 TCP2 ------------------------------------------------------------ 16.8 | 15.90 2.66 18.56 18.7 | 17.80 2.76 16.52 21.0 | 19.86 2.15 16.43 24.0 | 22.63 1.99 14.59 28.0 | 26.19 1.35 12.48 ------------------------------------------------------------ Notice that as the UDP flow increases its rate, the throughputs of both TCP flows decrease. That is, the congestion-sensitive traffic suffers at the hands of congestion-insensitive traffic. Notice also that the two TCP flows that are different only in their packet sizes get very different throughput. The flow with smaller packet size gets very small throughput. This is a known behaviour of TCP Bhani & Sun & Jain [Page 3] draft-bhani-mpls-te-anal-00.txt - 4 - March, 1999 congestion mechanism [3]. Case 2: Two Trunks with TCP and UDP mixed on one Trunk In this case we have configured two trunks over the network in the following way. The first trunk carries UDP and TCP1 and follows the label switched path (LSP) R1-R2-R4-R5-R6 (high bandwidth path). The second trunk carries TCP2 and follows the path R1-R2-R3-R5-R6 (low bandwidth path). We vary the UDP source rate and observe the throughput for the various flows. The result are shown in Table 2. Table 2: Results using two trunks, with TCP and UDP mixed on one Trunk ------------------------------------------------------------ UDP Source rate (Mbps) | Throughput (Mbps) ------------------------------------------------------------ | UDP TCP1 TCP2 ------------------------------------------------------------ 16.8 | 16.49 18.91 12.97 18.7 | 18.32 17.46 12.98 21.0 | 20.61 16.17 12.94 24.0 | 23.52 15.00 12.33 28.0 | 27.45 4.54 12.97 ------------------------------------------------------------ Notice that there is a significant improvement in the throughput of the flows. This is because the low bandwidth link which was not being utilised till now is also being used. Hence, TCP2 which is directed on a separate trunk and follows the low bandwidth link is unaffected by the increase in the UDP source rate and hence shows an almost constant throughput. But, we also observe that as the UDP source rate increases, the throughtput of the TCP1 flow mixed with it on the same trunk suffers. This is because the TCP flow cuts down its rate in response to network congestion. Thus, we can say that use of separate trunks definitely improves the network performance but, is not sufficient to provide the quality of service which might be desirable for some applications. Thus, in order to guarantee the quality of service to a given flow, we need to isolate the various flows in different trunks so that even if a given flow increases its source rate, other flows are unaffected by this. Case 3: Three Trunks with isolated TCP and UDP flows In this case, we use three isolated trunks, one each for the UDP and TCP flows, respectively. This is done using separate queues for all the different trunks at the routers R1 and R2. By doing this, we essentially separate the UDP flow from the TCP flows and thus get the results shown Bhani & Sun & Jain [Page 4] draft-bhani-mpls-te-anal-00.txt - 5 - March, 1999 in Table 3. Table 3: Results using a separate trunk for each flow ------------------------------------------------------------ UDP Source rate (Mbps) | Throughput (Mbps) ------------------------------------------------------------ | UDP TCP1 TCP2 ------------------------------------------------------------ 16.8 | 15.64 21.27 12.10 18.7 | 16.33 21.21 12.09 21.0 | 17.34 21.08 12.08 24.0 | 18.13 21.02 12.22 28.0 | 19.06 21.23 12.06 ------------------------------------------------------------ Here we see that the increase in the UDP source rate does not affect either of the TCP sources and both are able to get a fairly constant throughput. Thus, by isolating the various flows, we can guarantee a given quality of service to sources which are responsive to congestion control also. Although this is achieved at the overhead of maintaining separate queues for each of the trunks at each of the routers. Case 4: Non-end-to-end Trunks In this case we analyse a scenario where the trunks are not end to end. Specifically, the trunks are being initialized onlt at R2. In this case, the flows interfere with each other for part of the path since R1 does not distinguish between the various flows. The results are shown in Table 4. Table 4: Results using Non-end-to-end trunks ------------------------------------------------------------ UDP Source rate (Mbps) | Throughput (Mbps) ------------------------------------------------------------ | UDP TCP1 TCP2 ------------------------------------------------------------ 16.8 | 16.33 18.28 11.88 18.7 | 18.27 17.41 13.03 21.0 | 20.60 4.87 13.09 24.0 | 18.27 4.86 13.12 28.0 | 26.89 10.90 11.11 ------------------------------------------------------------ Bhani & Sun & Jain [Page 5] draft-bhani-mpls-te-anal-00.txt - 6 - March, 1999 The above results show that the network really cannot guarantee anything in such a case. This happens because at R1 the flows are treated identically and during periods of congestion the TCP sources reduce their source rates and this leads to very poor throughput for the TCP sources even though they are treated distinctly at R2. Thus, in order that this kind of a scheme be successful, the flows should be separated as soon as they share a common link in the network. 5. Summary The above simulations clearly indicate the effectiveness of traffic trunks in providing different qualities of service and the related issues. We can infer that the use of traffic trunks would be effective only if they are end-to-end and should be able to isolate congestion insensitive traffic from congestion sensitive traffic. 6. References [1] Li, T., Rekhter, Y. "A Provider Architecture for Differentialted Services and Traffic Engineering (PASTE)". RFC 2430. October 1998. [2] Awduche, D.O., Malcolm, J., O'DEll, M., McManus, J. "Requirements for Traffic Engineering Over MPLS". draft-ietf-mpls-traffic-eng-00.txt. [3] UCB, LBNL, VINT Network Simulator - ns http://www-mash.cs.berkeley.edu/ns/ns.html [4] Rosen, E.C., Vishwanathan, A., Callon, R. "Multiprotocol Label Switching Architecture". draft-ietf-mpls-arch-02.txt. 7. Contact Addresses Praveen Bhaniramka, Wei Sun and Raj Jain Department of Computer and Information Science The Ohio State University 2015 Neil Ave, DL395 Columbus, OH 43210 Phone: +1 614-292-3989 Email: bhaniram@cis.ohio-state.edu Email: wsun@cis.ohio-state.edu Email: jain@cis.ohio-state.edu Bhani & Sun & Jain [Page 6]