📄 rfc2757.txt
字号:
Network Working Group G. MontenegroRequest for Comments: 2757 Sun Microsystems, Inc.Category: Informational S. Dawkins Nortel Networks M. Kojo University of Helsinki V. Magret Alcatel N. Vaidya Texas A&M University January 2000 Long Thin NetworksStatus of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.Abstract In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind. We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.Montenegro, et al. Informational [Page 1] RFC 2757 Long Thin Networks January 2000Table of Contents 1 Introduction ................................................. 3 1.1 Network Architecture .................................... 5 1.2 Assumptions about the Radio Link ........................ 6 2 Should it be IP or Not? ..................................... 7 2.1 Underlying Network Error Characteristics ................ 7 2.2 Non-IP Alternatives ..................................... 8 2.2.1 WAP ................................................ 8 2.2.2 Deploying Non-IP Alternatives ...................... 9 2.3 IP-based Considerations ................................. 9 2.3.1 Choosing the MTU [Stevens94, RFC1144] .............. 9 2.3.2 Path MTU Discovery [RFC1191] ....................... 10 2.3.3 Non-TCP Proposals .................................. 10 3 The Case for TCP ............................................. 11 4 Candidate Optimizations ...................................... 12 4.1 TCP: Current Mechanisms ................................. 12 4.1.1 Slow Start and Congestion Avoidance ................ 12 4.1.2 Fast Retransmit and Fast Recovery .................. 12 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] .......... 14 4.3 Slow Start Proposals .................................... 14 4.3.1 Larger Initial Window .............................. 14 4.3.2 Growing the Window during Slow Start ............... 15 4.3.2.1 ACK Counting .................................. 15 4.3.2.2 ACK-every-segment ............................. 16 4.3.3 Terminating Slow Start ............................. 17 4.3.4 Generating ACKs during Slow Start .................. 17 4.4 ACK Spacing ............................................. 17 4.5 Delayed Duplicate Acknowlegements ....................... 18 4.6 Selective Acknowledgements [RFC2018] .................... 18 4.7 Detecting Corruption Loss ............................... 19 4.7.1 Without Explicit Notification ...................... 19 4.7.2 With Explicit Notifications ........................ 20 4.8 Active Queue Management ................................. 21 4.9 Scheduling Algorithms ................................... 21 4.10 Split TCP and Performance-Enhancing Proxies (PEPs) ..... 22 4.10.1 Split TCP Approaches .............................. 23 4.10.2 Application Level Proxies ......................... 26 4.10.3 Snoop and its Derivatives ......................... 27 4.10.4 PEPs to handle Periods of Disconnection ........... 29 4.11 Header Compression Alternatives ........................ 30 4.12 Payload Compression .................................... 31 4.13 TCP Control Block Interdependence [Touch97] ............ 32 5 Summary of Recommended Optimizations ......................... 33 6 Conclusion ................................................... 35 7 Acknowledgements ............................................. 35 8 Security Considerations ...................................... 35Montenegro, et al. Informational [Page 2] RFC 2757 Long Thin Networks January 2000 9 References ................................................... 36 Authors' Addresses ............................................. 44 Full Copyright Statement ....................................... 461 Introduction Optimized wireless networking is one of the major hurdles that Mobile Computing must solve if it is to enable ubiquitous access to networking resources. However, current data networking protocols have been optimized primarily for wired networks. Wireless environments have very different characteristics in terms of latency, jitter, and error rate as compared to wired networks. Accordingly, traditional protocols are ill-suited to this medium. Mobile Wireless networks can be grouped in W-LANs (for example, 802.11 compliant networks) and W-WANs (for example, CDPD [CDPD], Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few). W-WANs present the most serious challenge, given that the length of the wireless link (expressed as the delay*bandwidth product) is typically 4 to 5 times as long as that of its W-LAN counterparts. For example, for an 802.11 network, assuming the delay (round-trip time) is about 3 ms. and the bandwidth is 1.5 Mbps, the delay*bandwidth product is 4500 bits. For a W-WAN such as Ricochet, a typical round-trip time may be around 500 ms. (the best is about 230 ms.), and the sustained bandwidth is about 24 Kbps. This yields a delay*bandwidth product roughly equal to 1.5 KB. In the near future, 3rd Generation wireless services will offer 384Kbps and more. Assuming a 200 ms round-trip, the delay*bandwidth product in this case is 76.8 Kbits (9.6 KB). This value is larger than the default 8KB buffer space used by many TCP implementations. This means that, whereas for W-LANs the default buffer space is enough, future W-WANs will operate inefficiently (that is, they will not be able to fill the pipe) unless they override the default value. A 3rd Generation wireless service offering 2 Mbps with 200-millisecond latency requires a 50 KB buffer. Most importantly, latency across a link adversely affects throughput. For example, [MSMO97] derives an upper bound on TCP throughput. Indeed, the resultant expression is inversely related to the round-trip time. The long latencies also push the limits (and commonly transgress them) for what is acceptable to users of interactive applications. As a quick glance to our list of references will reveal, there is a wealth of proposals that attempt to solve the wireless networking problem. In this document, we survey the different solutions available or under investigation, and issue the corresponding recommendations.Montenegro, et al. Informational [Page 3] RFC 2757 Long Thin Networks January 2000 There is a large body of work on the subject of improving TCP performance over satellite links. The documents under development by the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are very relevant. In both cases, it is essential to start by improving the characteristics of the medium by using forward error correction (FEC) at the link layer to reduce the BER (bit error rate) from values as high as 10-3 to 10-6 or better. This makes the BER manageable. Once in this realm, retransmission schemes like ARQ (automatic repeat request) may be used to bring it down even further. Notice that sometimes it may be desirable to forego ARQ because of the additional delay it implies. In particular, time sensitive traffic (video, audio) must be delivered within a certain time limit beyond which the data is obsolete. Exhaustive retransmissions in this case merely succeed in wasting time in order to deliver data that will be discarded once it arrives at its destination. This indicates the desirability of augmenting the protocol stack implementation on devices such that the upper protocol layers can inform the link and MAC layer when to avoid such costly retransmission schemes. Networks that include satellite links are examples of "long fat networks" (LFNs or "elephants"). They are "long" networks because their round-trip time is quite high (for example, 0.5 sec and higher for geosynchronous satellites). Not all satellite links fall within the LFN regime. In particular, round-trip times in a low-earth orbiting (LEO) satellite network may be as little as a few milliseconds (and never extend beyond 160 to 200 ms). W-WANs share the "L" with LFNs. However, satellite networks are also "fat" in the sense that they may have high bandwidth. Satellite networks may often have a delay*bandwidth product above 64 KBytes, in which case they pose additional problems to TCP [TCPHP]. W-WANs do not generally exhibit this behavior. Accordingly, this document only deals with links that are "long thin pipes", and the networks that contain them: "long thin networks". We call these "LTNs". This document does not give an overview of the API used to access the underlying transport. We believe this is an orthogonal issue, even though some of the proposals below have been put forth assuming a given interface. It is possible, for example, to support the traditional socket semantics without fully relying on TCP/IP transport [MOWGLI]. Our focus is on the on-the-wire protocols. We try to include the most relevant ones and briefly (given that we provide the references needed for further study) mention their most salient points.Montenegro, et al. Informational [Page 4] RFC 2757 Long Thin Networks January 20001.1 Network Architecture One significant difference between LFNs and LTNs is that we assume the W-WAN link is the last hop to the end user. This allows us to assume that a single intermediate node sees all packets transferred between the wireless mobile device and the rest of the Internet. This is only one of the topologies considered by the TCP Satellite community. Given our focus on mobile wireless applications, we only consider a very specific architecture that includes: - a wireless mobile device, connected via - a wireless link (which may, in fact comprise several hops at the link layer), to - an intermediate node (sometimes referred to as a base station) connected via - a wireline link, which in turn interfaces with - the landline Internet and millions of legacy servers and web sites. Specifically, we are not as concerned with paths that include two wireless segments separated by a wired one. This may occur, for example, if one mobile device connects across its immediate wireless segment via an intermediate node to the Internet, and then via a second wireless segment to another mobile device. Quite often, mobile devices connect to a legacy server on the wired Internet. Typically, the endpoints of the wireless segment are the intermediate node and the mobile device. However, the latter may be a wireless router to a mobile network. This is also important and has applications in, for example, disaster recovery. Our target architecture has implications which concern the deployability of candidate solutions. In particular, an important requirement is that we cannot alter the networking stack on the legacy servers. It would be preferable to only change the networking stack at the intermediate node, although changing it at the mobile devices is certainly an option and perhaps a necessity. We envision mobile devices that can use the wireless medium very efficiently, but overcome some of its traditional constraints. That is, full mobility implies that the devices have the flexibility and agility to use whichever happens to be the best network connectionMontenegro, et al. Informational [Page 5] RFC 2757 Long Thin Networks January 2000 available at any given point in time or space. Accordingly, devices could switch from a wired office LAN and hand over their ongoing⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -