udt.sdk.2.3.tar.gz_TCP NAT_UDP 传输_udp 可靠传输_udt_传输 udp

Internet Engineering Task Force Yunhong Gu Internet Draft Robert L. Grossman Document: draft-gg-udt-01.txt University of Illinois at Chicago Expires: February 2005 August 2004 UDT: A Transport Protocol for Data Intensive Applications Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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." 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 document proposes a new UDP based Data Transfer protocol, also known as UDT. UDT can be used in high bandwidth-delay product (BDP) networks to utilize the abundant network resource efficiently and fairly. It is expected to be used in distributed data intensive applications over high-speed wide area networks, such as scientific computing on computational grids. The current most widely used TCP version (TCP NewReno/SACK) does not work well in such environments due to its slow discovery and recovery to the available bandwidth as the network BDP increases. In addition, it exhibits "unfairness" when concurrent TCP flows have different round trip time (RTT). UDT is an application layer solution by introducing new congestion control and reliability control. The protocol if defined upon UDP. The congestion control combines both rate-based and window-based methods and uses bandwidth estimation techniques to dynamically configure the control parameters. Gu, Grossman Expires - February 2005 [Page 1] UDT August 2004 Conventions used in this document 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 RFC 2119. Table of Contents 1. Introduction...................................................2 2. Target Use Scenarios and Design Goals..........................3 3. Protocol Specification.........................................4 3.1 Overview...................................................4 3.2 Packet Structures..........................................4 3.3 Timing.....................................................6 3.4 The Sender's Algorithm.....................................7 3.5 The Receiver's Algorithm...................................8 3.6 Rate Control Algorithm....................................11 3.7 Flow Control Algorithm....................................12 3.8 Connection Setup and shutdown.............................12 3.9 Loss Information Compression Scheme.......................13 4. Efficiency and Fairness Characters............................14 Security Considerations..........................................14 Normative References.............................................15 Informative References...........................................15 Acknowledgments..................................................15 Author's Addresses...............................................16 1. Introduction As the network bandwidth-delay product (BDP) increases, conventional TCP implementations become inefficient. This is because its AIMD (additive increase multiplicative decrease) algorithm reduces the TCP congestion window drastically but fails to recover it to the available bandwidth quickly. Theoretical flow level analysis has shown that TCP becomes more vulnerable to packet loss as the BDP increases higher [LM97]. Additionally, the unfairness of RTT bias inherent in TCP congestion control also becomes more serious in distributed data intensive applications. Concurrent TCP flows with different RTT will tend to unfairly share the available bandwidth. Although small BDP networks will share bandwidth relatively fairly using conventional TCP implementations, networks with large BDP tend to suffer severe unfairness issues under conventional TCP. This RTT bias severely limits the effectiveness of distributed computations based on high- speed wide-area networks as, for example, Grid-based computations in Gu, Grossman Expires - February 2005 [Page 2] UDT August 2004 an Internet2-based context. As of today, improvements on the standard TCP still fails to satisfy the efficiency and fairness (especially the RTT bias problem) objectives in high BDP environments. Such TCP modifications as presented in RFC 1423 (high-performance extensions), RFC 2018 (SACK), RFC 2582 (New Reno), RFC 2883 (D-SACK), and RFC 2988 (RTO calculation) do improve the efficiency more or less, but the fundamental problem of the TCP AIMD algorithm is unsolved. HS TCP (RFC 3649) achieved high utilization of bandwidth in high BDP networks by radically changing the TCP congestion control algorithm, but the fairness problem still remains. Considering the background above, new transport protocol is needed to support the high performance bulk data transfer in high BDP networks. We propose a new application level transport protocol, named UDT, or UDP based Data Transfer Protocol, together with a new congestion control algorithm. This document presents the two orthogonal parts of the UDT protocol and the UDT congestion control algorithm. The application level protocol, layering over UDP, can use other congestion control algorithms; whereas the algorithm defined in this document can be implemented in other protocols, such as TCP. An example implementation of the protocol can be found at [UDT]. Detailed performance analysis of the congestion control algorithm can be found in [GHG04]. 2. Target Use Scenarios and Design Goals UDT is expected to be used in the situations where a small number of bulk sources share abundant bandwidth. Typical use scenario is the computational grids [FKT01] built on wide area optical networks. A few institutes run their data intensive distributed applications on the networks, such as remote access to scientific instruments, distributed data mining, and high-resolution media streams. The main objectives of UDT are efficiency, fairness, and stability. Single, or small number of, UDT flows should utilize all the available bandwidth provided by the high-speed links, even if the bandwidth changes drastically. Meanwhile, all concurrent flows must share the bandwidth fairly, independent of the different bottleneck bandwidth, start time, or RTT. Stability requires that the packet sending rate should always converge to the available bandwidth very quickly, and congestion collapse must be avoided. UDT is NOT used to replace TCP in the Internet where the bottleneck Gu, Grossman Expires - February 2005