Taps Working Group J. You Internet-Draft Huawei Intended status: Standards Track June 2, 2015 Expires: December 4, 2015 3RED Model for TAPS draft-you-taps-3red-model-00 Abstract This document defines a 3RED model to describe transport service features. Applications can make use of the 3RED model to request transport services from the TAPS by sending a request which contains the explicit 3RED requirement parameters. The purpose of this document is to enable applications to make use of various transport services without customization or re-implementation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 4, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents You Expires December 4, 2015 [Page 1] Internet-Draft 3RED Model June 2015 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 3RED Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Efficiency . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Differentiation . . . . . . . . . . . . . . . . . . . . . 8 4. 3RED Implementation . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Application programmers face difficulty when they use the transport services provided by the transport protocols other than TCP or UDP, such as SCTP, DCCP, WebSockets, MPTCP, UDP-Lite, etc. The goal of the TAPS working group is to help application and network stack programmers by describing an (abstract) interface for applications to make use of transport services. This document is to define a 3RED model to describe transport service features. Applications can make use of the 3RED model to request transport services from the TAPS by sending a request which contains the explicit 3RED requirement parameters. The purpose of this document is to enable applications to make use of various transport services without customization or re-implementation. 2. Terminology This section contains definitions of terms used in this document. 3RED: Rate, Response, Reliability, Efficiency and Differentiation BDP: Bandwidth-Delay Product You Expires December 4, 2015 [Page 2] Internet-Draft 3RED Model June 2015 DCCP: Datagram Congestion Control Protocol MPTCP: Multipath TCP RTO: Retransmission Timeout RTT: Round-Trip Time SCTP: Stream Control Transmission Protocol TCP: Transmission Control Protocol UDP: User Datagram Protocol UDP-Lite: Lightweight User Datagram Protocol 3. 3RED Model +------------+ | | | APPs | | | +-----+------+ | | 3RED|Model | | +-----v------+ | | | TAPS | | | +-----^------+ | | | | | +-----v------+ | Transport | | Protocols | | | +------------+ Figure 1: 3RED Model The APP extracts or derives the service requirement parameters (i.e. 3RED model) of the requested service, and then requests transport You Expires December 4, 2015 [Page 3] Internet-Draft 3RED Model June 2015 services from the TAPS by sending a request which contains the explicit 3RED requirement parameters. The usage of 3RED model is depicted in Figure 1. 3.1. Rate Rate, also known as bandwidth utilization rate, is the percentage of the access bandwidth (in bit/s) that goes to the actually achieved throughput when transmitting enough data. For example, TCP Reno throughput is measured as: Throughput <= min ( BW, WindowSize/RTT, MSS/(RTT*sqrt(p)) ) BW: maximum bandwidth WindowSize: congestion window size RTT: round trip time MSS: maximum segment size (fixed for each Internet path, typically 1460Bytes) p: packet loss probability For basic 4K streaming, it requires TCP throughput no less than 45Mbps. Assuming 100M network with RTT=50ms; p=0.01%; MSS=1460Bytes; WindowSize=256KBytes. Then, TCP Throughput <= min ( 100, 40.96, 23.36 ) <= 23.36Mbps As we can see TCP responds to loss of packets and RTT, this results in poor throughput. TCP is inefficiency in high bandwidth-delay product (BDP) networks. It has an inherent throughput bottleneck that becomes obvious and severe with increased packet loss and latency. Table 1 shows the throughput and bandwidth utilization rate of different congestion algorithms under different packet loss conditions on a 100Mbps link with RTT=100ms when downloading a file. The simulation topology is shown in Figure 2. You Expires December 4, 2015 [Page 4] Internet-Draft 3RED Model June 2015 +---------+ 100M +---------+ +---------+ | Sender +---------+ Switch | +---------+ Receiver| +---------+ +-----+---+ | +---------+ |100M | | | | | | +---+-----+ +-------+ Network | | Emulator| +---------+ Figure 2: Simulation Topology Table 1: Throughput and Rate +--------+-----------------+-----------------+-----------------+ | | p=0.1% | p=0.01% | p=0.005% | +--------+----------+------+----------+------+----------+------+ | |Throughput|Rate |Throughput|Rate |Throughput|Rate | +--------+----------+------+----------+------+----------+------+ |Cubic |641 KB/s |5.26% |3.14 MB/s |26.38%|4.93 MB/s |41.41%| +--------+----------+------+----------+------+----------+------+ |Westwood|1.19 MB/s |10.00%|3.97 MB/s |33.25%|5.41 MB/s |45.44%| +--------+----------+------+----------+------+----------+------+ |Veno |637 KB/s |5.23% |1.99 MB/s |16.72%|2.80 MB/s |23.52%| +--------+----------+------+----------+------+----------+------+ |Illinois|3.12 MB/s |26.21%|10.2 MB/s |85.68%|9.82 MB/s |82.49%| +--------+----------+------+----------+------+----------+------+ So Rate can be graded into 5 levels, as shown in Table 2. Table 2: Rate Rate Level Utilization Rate ----------------------------------- 5 80%-100% 4 60%-80% 3 40%-60% 2 20%-40% 1 0%-20% 3.2. Response Response (i.e. response time) is the time elapsed between the emission of the first bit of a data and the accumulated data that is able to make a service usable. For web browsing, the response time is the time elapsed between the emission of the first bit of a web page and the reception of the last bit of that web page. For example, with an initial window of 3 You Expires December 4, 2015 [Page 5] Internet-Draft 3RED Model June 2015 segments (IW3), a transfer of 25 segments of web page will require 5 round trips to complete. While with the larger initial window (e.g. IW=10 [RFC6928]), it will require only 2 round trips. An increase of the initial window from 3 segments to 10 segments improves the response latency. For 4K streaming video, the response time is the time elapsed between the emission of the first bit of a data and the accumulated data that is ready to play 4K video. For most non real time applications, such as web browsing, email, FTP, a response time of 2-5 seconds is suggested. For most real time applications, such as video conferencing, videophony, VoIP, a response time of less than 150ms is suggested [QoS-Requirements]. Table 3 shows the average response time of different congestion algorithms when downloading files with different size on a 100Mbps link with IW=10, meanwhile assuming a packet loss occurs during the first RTT. The simulation topology is the same as shown in Figure 2. Table 3: Response Time +--------+-----------+-----------+-----------+-----------+-----------+ | |Object Size|Object Size|Object Size|Object Size|Object Size| | |10K Bytes |40K Bytes |100K Bytes |256K Bytes |3.75M Bytes| +--------+-----------+-----------+-----------+-----------+-----------+ |Cubic | 3RTT | 4RTT | 8RTT | 16RTT | 85RTT | +--------+-----------+-----------+-----------+-----------+-----------+ |Westwood| 3RTT | 5RTT | 10RTT | 18RTT | 110RTT | +--------+-----------+-----------+-----------+-----------+-----------+ |Veno | 3RTT | 4RTT | 8RTT | 13RTT | 98RTT | +--------+-----------+-----------+-----------+-----------+-----------+ |Illinois| 3RTT | 5RTT | 9RTT | 15RTT | 50RTT | +--------+-----------+-----------+-----------+-----------+-----------+ Response can be graded into 5 levels, as shown in Table 4. Table 4: Response Response Level Response Time ------------------------------------ 5 <10ms 4 10-100ms 3 100-400ms 2 400-5000ms 1 >5000ms You Expires December 4, 2015 [Page 6] Internet-Draft 3RED Model June 2015 3.3. Reliability Reliability is measured by a maximum application-level packet loss rate that is tolerable for the applications. For web-browsing using HTTP over TCP, the expected data loss of HTTP objects is zero since TCP is a reliable transfer protocol in which erroneous packets are sent again using a retransmission policy. For HDTV quality MPEG-2 video streams, the tolerable loss rate should be less than 0.0001%. For broadcast audio streams, a tolerable loss rate of no more than 0.1% is recommended. For VoIP, the tolerable loss rate should be less than 1% in the G.729 codec [QoS-Requirements]. When addressing the QoS needs of streaming video traffic, loss should be no more than 5%. So Reliability can be graded into 5 levels, as shown in Table 5. Table 5: Reliability Reliability Level Tolerable Loss Rate --------------------------------------------- 5 0% 4 0%-0.1% 3 0.1%-1% 2 1%-5% 1 >5% 3.4. Efficiency Efficiency, also known as bandwidth utilization efficiency, is the percentage of network bottleneck bandwidth (in bit/s) that goes to the actually achieved throughput when a number of competing connections traverse the same network bottleneck. [Performance-Evaluation] evaluates a set of TCP variants over a single bottleneck network. Table 6 shows the efficiency of different congestion algorithms under different packet loss conditions when downloading files using different number of flows. The simulation topology is shown in Figure 3, Access Bandwidth= 1Gbps, Bottleneck Bandwidth=100Mbps, RTT=100ms. You Expires December 4, 2015 [Page 7] Internet-Draft 3RED Model June 2015 +---------+ 1G +---------+ +---------+ | Sender +---------+ Switch | +---------+ Receiver| +---------+ +-----+---+ | +---------+ |100M | | | | | | +---+-----+ +-------+ Network | | Emulator| +---------+ Figure 3: Simulation Topology Table 6: Efficiency +--------+-----------------------+-----------------+-----------------+ | | p=0.1%: | p=0.01% | p=0.005% | | +------+-------+--------+--------+--------+--------+--------+ | |1 flow|5 flows|10 flows|1 flow |5 flows |1 flow |5 flows | +--------+------+-------+--------+--------+--------+--------+--------+ |Cubic |5% |23% |43% |25% |100% |43% |100% | +--------+------+-------+--------+--------+--------+--------+--------+ |Westwood|9% |67% |100% |33% |100% |40% |100% | +--------+------+-------+--------+--------+--------+--------+--------+ |Veno |5% |26% |53% |17% |85% |23% |100% | +--------+------+-------+--------+--------+--------+--------+--------+ |Illinois|26% |100% |100% |75% |100% |96% |100% | +--------+------+-------+--------+--------+--------+--------+--------+ Efficiency can be graded into 5 levels, as shown in Table 7. Table 7: Efficiency Efficiency Level Efficiency ------------------------------------ 5 90%-100% 4 60%-80% 3 30%-60% 2 10%-30% 1 0%-10% 3.5. Differentiation Differentiation means that a number of competing connections are provided with differential opportunity to transfer data when they sharing a single bottleneck link. To provide a numerical measure reflecting the differential share distribution across the various connections, the differentiation index for one specified connection is defined as: You Expires December 4, 2015 [Page 8] Internet-Draft 3RED Model June 2015 (maximum throughput from all competing connections - the throughput of the specified connection) --------------------------------------------------------------- maximum throughput from all competing connections For example, for three competing connections, their throughputs are 5Mbps, 4Mbps and 1Mbps respectively; then their differentiation indexes are 0, 20% and 80% respectively. Differentiation determines whether users or applications are receiving a differential share of network resources when network is congested. Application may specify differentiation to individual media, in order to facilitate appropriate priority handling; for example, when the congestion is experienced, it informs the downstream nodes to downgrade their data transmission rate to some degree and vice versa. Assuming beta is a constant multiplication decrease factor applied for window reduction at the time of loss in TCP Reno, the throughput is measured as: Throughput <= min ( BW, WindowSize/RTT, sqrt(1/beta-1/2)*MSS/(RTT*sqrt(p)) ) So through adjusting beta, the throughput could be controlled. Accordingly, the differentiation level could be implemented. Differentiation can be graded into 5 levels, as shown in Table 8. Table 8: Differentiation Differentiation Level Differentiation ---------------------------------------------- 5 0%-10% 4 10%-30% 3 30%-50% 2 50%-70% 1 >70% 4. 3RED Implementation 3RED (i.e. Rate, Response, Reliability, Efficiency and Differentiation) usually cannot be satisfied at the same time. For example, if Reliability would be preferred, then Rate and Response have to be downgraded. When several flows share a single bottleneck link, if Response would be preferred, then Efficiency may be sacrificed. The application could belong to end-user or service provider. For end-user, it may care more about Rate, Response and Reliability; You Expires December 4, 2015 [Page 9] Internet-Draft 3RED Model June 2015 however for service provider, it may care more about Efficiency and Differentiation. 5. IANA Considerations This document has no actions for IANA. 6. Security considerations This document does not introduce any new security considerations. 7. Acknowledgement TBD. 8. Normative References [Performance-Evaluation] Alrshah, M. and M. Othman, "Performance Evaluation of Parallel TCP, and its Impact on Bandwidth Utilization and Fairness in High-BDP Networks Based on Test-bed", 2013 IEEE 11th Malaysia International Conference on Communications, November 2013. [QoS-Requirements] Chen, R., Farley, T., and N. Ye, "QoS Requirements of Network Applications on the Internet", Information Knowledge Systems Management, January 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, April 2013. Author's Address Jianjie You Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: youjianjie@huawei.com You Expires December 4, 2015 [Page 10]