📄 rfc2760.txt
字号:
Network Working Group M. Allman, Editor
Request for Comments: 2760 NASA Glenn Research Center/BBN Technologies
Category: Informational S. Dawkins
Nortel
D. Glover
J. Griner
D. Tran
NASA Glenn Research Center
T. Henderson
University of California at Berkeley
J. Heidemann
J. Touch
University of Southern California/ISI
H. Kruse
S. Ostermann
Ohio University
K. Scott
The MITRE Corporation
J. Semke
Pittsburgh Supercomputing Center
February 2000
Ongoing TCP Research Related to Satellites
Status 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
This document outlines possible TCP enhancements that may allow TCP
to better utilize the available bandwidth provided by networks
containing satellite links. The algorithms and mechanisms outlined
have not been judged to be mature enough to be recommended by the
IETF. The goal of this document is to educate researchers as to the
current work and progress being done in TCP research related to
satellite networks.
Allman, et al. Informational [Page 1]
RFC 2760 Ongoing TCP Research Related to Satellites February 2000
Table of Contents
1 Introduction. . . . . . . . . . . . . . . . . . . . 2
2 Satellite Architectures . . . . . . . . . . . . . . 3
2.1 Asymmetric Satellite Networks . . . . . . . . . . . 3
2.2 Satellite Link as Last Hop. . . . . . . . . . . . . 3
2.3 Hybrid Satellite Networks . . . . . . . . . . . 4
2.4 Point-to-Point Satellite Networks . . . . . . . . . 4
2.5 Multiple Satellite Hops . . . . . . . . . . . . . . 4
3 Mitigations . . . . . . . . . . . . . . . . . . . . 4
3.1 TCP For Transactions. . . . . . . . . . . . . . . . 4
3.2 Slow Start. . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Larger Initial Window . . . . . . . . . . . . . . . 6
3.2.2 Byte Counting . . . . . . . . . . . . . . . . . . . 7
3.2.3 Delayed ACKs After Slow Start . . . . . . . . . . . 9
3.2.4 Terminating Slow Start. . . . . . . . . . . . . . . 11
3.3 Loss Recovery . . . . . . . . . . . . . . . . . . . 12
3.3.1 Non-SACK Based Mechanisms . . . . . . . . . . . . . 12
3.3.2 SACK Based Mechanisms . . . . . . . . . . . . . . . 13
3.3.3 Explicit Congestion Notification. . . . . . . . . . 16
3.3.4 Detecting Corruption Loss . . . . . . . . . . . . . 18
3.4 Congestion Avoidance. . . . . . . . . . . . . . . . 21
3.5 Multiple Data Connections . . . . . . . . . . . . . 22
3.6 Pacing TCP Segments . . . . . . . . . . . . . . . . 24
3.7 TCP Header Compression. . . . . . . . . . . . . . . 26
3.8 Sharing TCP State Among Similar Connections . . . . 29
3.9 ACK Congestion Control. . . . . . . . . . . . . . . 32
3.10 ACK Filtering . . . . . . . . . . . . . . . . . . . 34
4 Conclusions . . . . . . . . . . . . . . . . . . . . 36
5 Security Considerations . . . . . . . . . . . . . . 36
6 Acknowledgments . . . . . . . . . . . . . . . . . . 37
7 References. . . . . . . . . . . . . . . . . . . . . 37
8 Authors' Addresses. . . . . . . . . . . . . . . . . 43
9 Full Copyright Statement. . . . . . . . . . . . . . 46
1 Introduction
This document outlines mechanisms that may help the Transmission
Control Protocol (TCP) [Pos81] better utilize the bandwidth provided
by long-delay satellite environments. These mechanisms may also help
in other environments or for other protocols. The proposals outlined
in this document are currently being studied throughout the research
community. Therefore, these mechanisms are not mature enough to be
recommended for wide-spread use by the IETF. However, some of these
mechanisms may be safely used today. It is hoped that this document
will stimulate further study into the described mechanisms. If, at
Allman, et al. Informational [Page 2]
RFC 2760 Ongoing TCP Research Related to Satellites February 2000
some point, the mechanisms discussed in this memo prove to be safe
and appropriate to be recommended for general use, the appropriate
IETF documents will be written.
It should be noted that non-TCP mechanisms that help performance over
satellite links do exist (e.g., application-level changes, queueing
disciplines, etc.). However, outlining these non-TCP mitigations is
beyond the scope of this document and therefore is left as future
work. Additionally, there are a number of mitigations to TCP's
performance problems that involve very active intervention by
gateways along the end-to-end path from the sender to the receiver.
Documenting the pros and cons of such solutions is also left as
future work.
2 Satellite Architectures
Specific characteristics of satellite links and the impact these
characteristics have on TCP are presented in RFC 2488 [AGS99]. This
section discusses several possible topologies where satellite links
may be integrated into the global Internet. The mitigation outlined
in section 3 will include a discussion of which environment the
mechanism is expected to benefit.
2.1 Asymmetric Satellite Networks
Some satellite networks exhibit a bandwidth asymmetry, a larger data
rate in one direction than the reverse direction, because of limits
on the transmission power and the antenna size at one end of the
link. Meanwhile, some other satellite systems are unidirectional and
use a non-satellite return path (such as a dialup modem link). The
nature of most TCP traffic is asymmetric with data flowing in one
direction and acknowledgments in opposite direction. However, the
term asymmetric in this document refers to different physical
capacities in the forward and return links. Asymmetry has been shown
to be a problem for TCP [BPK97,BPK98].
2.2 Satellite Link as Last Hop
Satellite links that provide service directly to end users, as
opposed to satellite links located in the middle of a network, may
allow for specialized design of protocols used over the last hop.
Some satellite providers use the satellite link as a shared high
speed downlink to users with a lower speed, non-shared terrestrial
link that is used as a return link for requests and acknowledgments.
Many times this creates an asymmetric network, as discussed above.
Allman, et al. Informational [Page 3]
RFC 2760 Ongoing TCP Research Related to Satellites February 2000
2.3 Hybrid Satellite Networks
In the more general case, satellite links may be located at any point
in the network topology. In this case, the satellite link acts as
just another link between two gateways. In this environment, a given
connection may be sent over terrestrial links (including terrestrial
wireless), as well as satellite links. On the other hand, a
connection could also travel over only the terrestrial network or
only over the satellite portion of the network.
2.4 Point-to-Point Satellite Networks
In point-to-point satellite networks, the only hop in the network is
over the satellite link. This pure satellite environment exhibits
only the problems associated with the satellite links, as outlined in
[AGS99]. Since this is a private network, some mitigations that are
not appropriate for shared networks can be considered.
2.5 Multiple Satellite Hops
In some situations, network traffic may traverse multiple satellite
hops between the source and the destination. Such an environment
aggravates the satellite characteristics described in [AGS99].
3 Mitigations
The following sections will discuss various techniques for mitigating
the problems TCP faces in the satellite environment. Each of the
following sections will be organized as follows: First, each
mitigation will be briefly outlined. Next, research work involving
the mechanism in question will be briefly discussed. Next the
implementation issues of the mechanism will be presented (including
whether or not the particular mechanism presents any dangers to
shared networks). Then a discussion of the mechanism's potential
with regard to the topologies outlined above is given. Finally, the
relationships and possible interactions with other TCP mechanisms are
outlined. The reader is expected to be familiar with the TCP
terminology used in [AGS99].
3.1 TCP For Transactions
3.1.1 Mitigation Description
TCP uses a three-way handshake to setup a connection between two
hosts [Pos81]. This connection setup requires 1-1.5 round-trip times
(RTTs), depending upon whether the data sender started the connection
actively or passively. This startup time can be eliminated by using
TCP extensions for transactions (T/TCP) [Bra94]. After the first
Allman, et al. Informational [Page 4]
RFC 2760 Ongoing TCP Research Related to Satellites February 2000
connection between a pair of hosts is established, T/TCP is able to
bypass the three-way handshake, allowing the data sender to begin
transmitting data in the first segment sent (along with the SYN).
This is especially helpful for short request/response traffic, as it
saves a potentially long setup phase when no useful data is being
transmitted.
3.1.2 Research
T/TCP is outlined and analyzed in [Bra92,Bra94].
3.1.3 Implementation Issues
T/TCP requires changes in the TCP stacks of both the data sender and
the data receiver. While T/TCP is safe to implement in shared
networks from a congestion control perspective, several security
implications of sending data in the first data segment have been
identified [ddKI99].
3.1.4 Topology Considerations
It is expected that T/TCP will be equally beneficial in all
environments outlined in section 2.
3.1.5 Possible Interaction and Relationships with Other Research
T/TCP allows data transfer to start more rapidly, much like using a
larger initial congestion window (see section 3.2.1), delayed ACKs
after slow start (section 3.2.3) or byte counting (section 3.2.2).
3.2 Slow Start
The slow start algorithm is used to gradually increase the size of
TCP's congestion window (cwnd) [Jac88,Ste97,APS99]. The algorithm is
an important safe-guard against transmitting an inappropriate amount
of data into the network when the connection starts up. However,
slow start can also waste available network capacity, especially in
long-delay networks [All97a,Hay97]. Slow start is particularly
inefficient for transfers that are short compared to the
delay*bandwidth product of the network (e.g., WWW transfers).
Delayed ACKs are another source of wasted capacity during the slow
start phase. RFC 1122 [Bra89] suggests data receivers refrain from
ACKing every incoming data segment. However, every second full-sized
segment should be ACKed. If a second full-sized segment does not
arrive within a given timeout, an ACK must be generated (this timeout
cannot exceed 500 ms). Since the data sender increases the size of
cwnd based on the number of arriving ACKs, reducing the number of
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -