Network Working Group G. Montenegro
Request 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 Networks
STATUS OF this Memo
This document tracks the discussion of the Internet community to improve the agreement. See the official document (STD1) for details. This article can be arbitrarily distributed.
Copyright Notice
Copyright (c) The Internet Society (1999). All Rights Reserved.
Abstract
Due to the development of the remote narrowband network, there is still a lot of work to achieve optimized transmission. We will review the existing suggestions and its future development trends, and it is recommended to use the mechanisms based on this document in the implementation of the remote narrowband network.
Our goal is to ensure that the TCP protocol can be applied to all users, including users remote narrowband networks. We start this recommendation from the IETF based on the TCP (ie, Satellite TCP-TCPSAT) protocol based on Satellite Links.
We recognize that for remote narrowband networks, not every TCPSAT recommendation is required, but these recommendations still have a positive reference value.
Table of Contents
1 Introduction ......................... ............... ... .......................................................... 3
1.1 Network Architecture ............................................ ............ 5
1.2 Wireless Connection (Assumptions About the Radio Link) ...............................
2 Do it should not be considered an IP protocol (Should IT Be ip or not)? ................................ ............. 7
2.1 Potential Network Error Characteristics ...... ...... 7
Montenegro, et al. Informational [Page 1]
2.2 Non-IP Selection (non-ip alternatives) .................................. .... ........... .......... 82.2.1 WAP ......................... ....................………………………………………. 8
2.2.2 Configuring Non IP Selection (deploying non-ip alternatives) .......................................................................
2.3 Based on IP Consideration (ip-based considance) .......................................... .. 9
2.3.1 Select Maximum Transmission Unit (MTU Choosing The MTU) [Stevens94, RFC1144]. 9
2.3.2 MTU channel inventions [RFC1191] .............................................
2.3.3 Non-TCP Proposals ................................. 10
3 TCP protocol (The Case for TCP) ..................................... .....................
4 candidate optimizations ............................................................ ... 12
4.1 TCP: Current Mechanism (TCP: Current Mechanisms) .................................................
4.1.1 Slow start and congestion avoidance (Slow Start and Congestion Avoidance) ............ 12
4.1.2 Fast Solids and Fast Recovery .........................................
4.2 Based on T / TCP [RFC1397, RFC1644]
Connection setting (Connection setup with t / tcp) ......................................... 14
4.3 Slow Start Suggestions ..................................................... ...........................
4.3.1 Larger Initial Window ................................................. ...... 14
4.3.2 Growing The Window During Slow Start ... 15 during slow start
4.3.2.1 Ack counting ..................................... .............
4.3.2.2 Ack-every-segment ..................................................................... .......... 16
4.3.3 Terminating Slow Start ............................... ... .........................................................................................................................
4.4 Ack spacing ......................................... .................................
4.5 Delayed Duplicate Acknowlements .....................................
4.6 Selective Acknowledgements [RFC2018] .........................................
4.7 Detecting Corruption Loss .................................. .......... 19
4.7.1 Upset Explicit Notification ..................................... ............. ... .. 19
4.7.2 Explicit Notification (with explicit notification) ....................................... 20
4.8 Active Queue Management (Active Queue Management) ..................................... .….. twenty one
4.9 Timing Algorithms ...................................... .............. twenty one
4.10 Split TCP and Performance Enhancement Agent
(Split tcp and performance-enhancing proxies [PEPS]) .................. .. .... 22
4.10.1 Split TCP method (split tcp approaches) .................................... 23
4.10.2 Application Level Proxies ............................................ 26
4.10.3 Snoop and Its DeriVATIVes .............................. 27
4.10.4 Use performance enhancement agent processing disconnection phase
(PEPS to Handle Periods of Disconnection) .................................. 29
4.11 Title Compression Selection (Header Compression Alternatives) ...................................... 30
4.12 Payload Compression .................................................. 31
4.13 Internal dependencies of TCP Control Blocks (Touch97]). 325 Recommended Optimization Summation (Summary of Recommended Optimization) ......... ............ ......... 33
6 conclusion ................................................................... ........................ ......... 35
7 Thank you (Acknowledgements) .......................................................................... ........ 35
8 Safety considerations .......................................................... ... 35
Montenegro, et al. Informational [Page 2]
9 reference books (References) .................................. .................. ............... ............ 36
Author's address (authors' addresses) ............................................ .............................. 44
Full Copyright Statement .......................................... .... 46
1 Introduction
Mobile computing To support free access to network resources, the main obstacles to be resolved are optimization of wireless networks. However, the currently optimized data network protocol is mainly concentrated in the wired network. Compared with the wired network, the delay time, signal jitter and error rates in the wireless environment are very different, and therefore, traditional protocols are not suitable for this medium.
Mobile wireless networks can be attributed to broadband local area networks (ie W-Lans, for example, 802.11 compatible networks) and broadband WAN (ie W-WANS, for example, CDPD [CDPD], Ricochet, CDMA [CDMA], PHS, DOCOMO, GSM [GSM] Wait). Broadband Wide Area Network (W-Lans) The most serious problem is that its wireless connection time (ie delay time * bandwidth) is the same case of 4 to 5 times the broadband local area network (W-LAN). For example, for the 802.11 network, it is assumed that the delay (ie the round-trip time) is 3 milliseconds, and its bandwidth is 1.5 Mbps, then the delay * bandwidth is 4500 bits. For broadband WANs like RicoChet, a typical round-trip time may be 500 milliseconds (preferably approximately 230 milliseconds), and the continuous bandwidth is approximately 24kbps, so that the delay * is approximately equal to 1.5 KB. In the near future, the third-generation wireless service will provide 384kbps or higher bandwidth. It is assumed that the round trip time is 200ms. In this case, the delay * bandwidth should be 76.8kbits (ie, 9.6kb), and in the implementation of many TCP protocols, the default buffer space is only 8KB, which means unless alternative This default, otherwise, even if the default buffer space of W-Lans is large enough, the future W-WANS will not work with the greatest efficiency (that is, the pipeline will never be filled). If the third generation wireless service provides a bandwidth of 2 Mbps, the reaction time is within 200 milliseconds, and approximately 50 kb buffer is required. Most importantly, the reaction time of the link will affect the throughput. For example, in [MSMO97], the upper limit of the TCP protocol throughput is exported, which is inversely proportional to the trip time.
In addition, the reaction time has also limited the accessibility of the user's interactive application.
We can quickly scan a photo of the book, which can be found in solving wireless network issues, there are many value suggestions. In this article, we will examine these different solutions, whether they have been applying or in the research phase, and publish the corresponding recommendations.
Montenegro, et al. Informational [Page 3]
For the improvement of the TCP protocol performance, there is a large number of work to do, and the relationship is the most closely document development of the TCPSAT Workgroup of IETF [AGS98, ADGGHOSSTT98]. Regardless of which aspect, in order to improve the characteristics of the medium, the link layer is used to reduce the 'misserability' (BER, Bit Error Rate) in the link layer (FEC, FORWARD ERROR CORRECTION). It is even better from 10-3 to 10-6, even better, which makes BER more easily managed. In this field, information can be transferred to a further place by relay scenarios (such as ARQ, Automatic Repeat Request, Auto Request). Note that since ARQ generates additional delays, it will achieve more ideal effects in advance in advance. In special cases, for time-sensitive transmission (such as video, audio), the data must be overmolded within a certain time, more than this time range will be discarded. In this case, the time-consuming relay can only be wasted, and the data can only be discarded even if it is shipped to the destination. This indicates that the implementation of the equipment protocol stack is needed to allow the upper protocol to notify the link and the MAC layer in time to avoid this cost of trunk. Networks including satellite links are 'remote obesity network' (LFNS, long fixworks or elephants). They are "remote" network because their round-trip time is very large (for example, the earth synchronization is 0.5 seconds or more). Not all satellite links are LFN, especially some of the near-way orbiting, leo) networks may be in several milliseconds (more than 160 to 200 ms). Broadband Wide Area Network (W-WANS) has the "L" feature in the LFN, that is, remote. At the same time, the satellite network is also "fat" (FAT) because they have a high bandwidth. Under normal circumstances, the delay of the satellite network is above 64K bytes, which also brings additional trouble to TCP [TCPHP]. W-WANS usually does not show this behavior. Accordingly, this paper only processes the link associated with the 'remote narrow tape pipe' (Long Thin Pipes), and "long Thin Networks" containing their "remote narrowband network", we will refer to LTNS.
Although some of the recommendations below are presented under the premise that the interface has been given, this article does not intend to involve the API function of low-layer transmission. To support these traditional socket syntax, not completely dependent on TCP / IP transfer [MOWGLI], or it is possible.
Let's put your attention on the cable network. We will try to cover most of the relevant protocols and briefly discuss its significant feature (we also provide its origin to facilitate further research).
Montenegro, et al. Informational [Page 4]
1.1 Network Architecture
A significant difference between LFNs and LTNs is that we assume that W-WAN is the final way of connecting the end user. This allows us to make such an idea: a single intermediate node can see all the 'Packets (Packets) "passed between wireless mobile devices and Internet, of course, this topology is just a TCP Satellite Committee (Satellite Community) One of them. We will focus on mobile wireless applications, consider specially specified several systems, including the following:
- Provide a connected wireless mobile device;
- Wireless link (possibly in the link layer consisting of multi-level);
- The intermediate node passing through the connection (sometimes a base station);
- Wired linkage of the interface is provided in turn;
- INTERNET and millions of servers on earth and web sites.
In particular, we don't care about the channel issues in the case of a wired network segment. This situation is possible, for example, a mobile device is connected to the intermed edge of the Internet via its intermediary wireless network segment, and is connected to other mobile devices through the second wireless network segment. In fact, mobile devices often connect up traditional servers on the cable Internet network.
Typically, the end of the wireless network is either a mediation node or a mobile device. Among them, the latter may be a wireless router connected to a mobile network. Similarly, there are also important applications such as disaster recovery.
Our goal will imply that the alternative solutions involved are different in terms of scheduling capabilities. One of the important needs is that we cannot change the network stack on the traditional server. Although modification is also selected on mobile devices (and may be necessary), if you can modify the network stack at the intermediary node, it will be the perfect solution.
We can expect that mobile devices can use these wireless intermediaries very efficiently, but their own traditional lack of lack must be overcome. Perfect mobility means that the mobile device has a high degree of flexibility and adaptability, that is, no matter what happens, can always establish a connection to the best network with the best network in any specified time or region.
Montenegro, et al. Informational [Page 5]
