rfc2757.txt

RFC 的详细文档！

   Limited byte counting warrants further investigation before we can
   recommend this proposal, but it shows promise.

4.3.2.2 ACK-every-segment

   The main idea behind ACK-every-segment is:

      -  Keep a constant stream of ACKs coming back by turning off
         delayed ACKs [RFC1122] during slow start. ACK-every-segment
         must be limited to slow start, in order to avoid penalizing
         asymmetric-bandwidth configurations. For instance, a low
         bandwidth link carrying acknowledgements back to the sender,
         hinders the growth of the congestion window, even if the link
         toward the client has a greater bandwidth [BPK99].

   Even though simulations confirm its promise (it allows receivers to
   receive the second segment from unmodified senders without waiting
   for a typical delayed ACK timeout of 200 milliseconds), for this
   technique to be practical the receiver must acknowledge every segment
   only when the sender is in slow start.  Continuing to do so when the
   sender is in congestion avoidance may have adverse effects on the
   mobile device's battery consumption and on traffic in the network.

   This violates a SHOULD in [RFC2581]:  delayed acknowledgements SHOULD
   be used by a TCP receiver.

   "Disabling Delayed ACKs During Slow Start" is technically
   unimplementable, as the receiver has no way of knowing when the
   sender crosses ssthresh (the "slow start threshold") and begins using
   the congestion avoidance algorithm.  If receivers follow
   recommendations for increased initial windows, disabling delayed ACKs
   during an increased initial window would open the TCP window more
   rapidly without doubling ACK traffic in general.  However, this
   scheme might double ACK traffic if most connections remain in slow-
   start.

   Recommendation: ACK only the first segment on a new connection with
   no delay.









Montenegro, et al.           Informational                     [Page 16]

RFC 2757                   Long Thin Networks               January 2000


4.3.3 Terminating Slow Start

   New mechanisms [ADGGHOSSTT98] are being proposed to improve TCP's
   adaptive properties such that the available bandwidth is better
   utilized while reducing the possibility of congesting the network.
   This results in the closing of the congestion window to 1 segment
   (which precludes fast retransmit), and the subsequent slow start
   phase.

   Theoretically, an optimum value for slow-start threshold (ssthresh)
   allows connection bandwidth utilization to ramp up as aggressively as
   possible without "overshoot" (using so much bandwidth that packets
   are lost and congestion avoidance procedures are invoked).

   Recommendation: Estimating the slow start threshold is not
   recommended.  Although this would be helpful if we knew how to do it,
   rough consensus on the tcp-impl and tcp-sat mailing lists is that in
   non-trivial operational networks there is no reliable method to probe
   during TCP startup and estimate the bandwidth available.

4.3.4 Generating ACKs during Slow Start

   Mitigations that inject additional ACKs (whether "ACK-first-segment"
   or "ACK-every-segment-during-slow-start") beyond what today's
   conformant TCPs inject are only applicable during the slow-start
   phases of a connection. After an initial exchange, the connection
   usually completes slow-start, so TCPs only inject additional ACKs
   when (1) the connection is closed, and a new connection is opened, or
   (2) the TCPs handle idle connection restart correctly by performing
   slow start.

   Item (1) is typical when using HTTP/1.0, in which each request-
   response transaction requires a new connection.  Persistent
   connections in HTTP/1.1 help in maintaining a connection in
   congestion avoidance instead of constantly reverting to slow-start.
   Because of this, these optimizations which are only enabled during
   slow-start do not get as much of a chance to act. Item (2), of
   course, is independent of HTTP version.

4.4 ACK Spacing

   During slow start, the sender responds to the incoming ACK stream by
   transmitting N+1 segments for each ACK, where N is the number of new
   segments acknowledged by the incoming ACK.  This results in data
   being sent at twice the speed at which it can be processed by the
   network.  Accordingly, queues will form, and due to insufficient
   buffering at the bottleneck router, packets may get dropped before
   the link's capacity is full.



Montenegro, et al.           Informational                     [Page 17]

RFC 2757                   Long Thin Networks               January 2000


   Spacing out the ACKs effectively controls the rate at which the
   sender will transmit into the network, and may result in little or no
   queueing at the bottleneck router [ACKSPACING].  Furthermore, ack
   spacing reduces the size of the bursts.

   Recommendation: No recommendation at this time. Continue monitoring
   research in this area.

4.5 Delayed Duplicate Acknowlegements

   As was mentioned above, link-layer retransmissions may decrease the
   BER enough that congestion accounts for most of packet losses; still,
   nothing can be done about interruptions due to handoffs, moving
   beyond wireless coverage, etc. In this scenario, it is imperative to
   prevent interaction between link-layer retransmission and TCP
   retransmission as these layers duplicate each other's efforts. In
   such an environment it may make sense to delay TCP's efforts so as to
   give the link-layer a chance to recover. With this in mind, the
   Delayed Dupacks [MV97, Vaidya99] scheme selectively delays duplicate
   acknowledgements at the receiver.  It is preferable to allow a local
   mechanism to resolve a local problem, instead of invoking TCP's end-
   to-end mechanism and incurring the associated costs, both in terms of
   wasted bandwidth and in terms of its effect on TCP's window behavior.

   The Delayed Dupacks scheme can be used despite IP encryption since
   the intermediate node does not need to examine the TCP headers.

   Currently, it is not well understood how long the receiver should
   delay the duplicate acknowledgments. In particular, the impact of
   wireless medium access control (MAC) protocol on the choice of delay
   parameter needs to be studied. The MAC protocol may affect the
   ability to choose the appropriate delay (either statically or
   dynamically). In general, significant variabilities in link-level
   retransmission times can have an adverse impact on the performance of
   the Delayed Dupacks scheme. Furthermore, as discussed later in
   section 4.10.3, Delayed Dupacks and some other schemes (such as Snoop
   [SNOOP]) are only beneficial in certain types of network links.

   Recommendation: Delaying duplicate acknowledgements may be useful in
   specific network topologies, but a general recommendation requires
   further research and experience.

4.6 Selective Acknowledgements [RFC2018]

   SACK may not be useful in many LTNs, according to Section 1.1 of
   [TCPHP].  In particular, SACK is more useful in the LFN regime,
   especially if large windows are being used, because there is a




Montenegro, et al.           Informational                     [Page 18]

RFC 2757                   Long Thin Networks               January 2000


   considerable probability of multiple segment losses per window. In
   the LTN regime, TCP windows are much smaller, and burst errors must
   be much longer in duration in order to damage multiple segments.

   Accordingly, the complexity of SACK may not be justifiable, unless
   there is a high probability of burst errors and congestion on the
   wireless link. A desire for compatibility with TCP recommendations
   for non-LTN environments may dictate LTN support for SACK anyway.

   [AGS98] recommends use of SACK with Large TCP Windows in satellite
   environments, and notes that this implies support for PAWS
   (Protection Against Wrapped Sequence space) and RTTM (Round Trip Time
   Measurement) as well.

   Berkeley's SNOOP protocol research [SNOOP] indicates that SACK does
   improve throughput for SNOOP when multiple segments are lost per
   window [BPSK96]. SACK allows SNOOP to recover from multi-segment
   losses in one round-trip. In this case, the mobile device needs to
   implement some form of selective acknowledgements.  If SACK is not
   used, TCP may enter congestion avoidance as the time needed to
   retransmit the lost segments may be greater than the retransmission
   timer.

   Recommendation: Implement SACK now for compatibility with other TCPs
   and improved performance with SNOOP.

4.7 Detecting Corruption Loss

4.7.1 Without Explicit Notification

   In the absence of explicit notification from the network, some
   researchers have suggested statistical methods for congestion
   avoidance [Jain89, WC91, VEGAS]. A natural extension of these
   heuristics would enable a sender to distinguish between losses caused
   by congestion and other causes.  The research results on the
   reliability of sender-based heuristics is unfavorable [BV97, BV98].
   [BV98a] reports better results in constrained environments using
   packet inter-arrival times measured at the receiver, but highly-
   variable delay - of the type encountered in wireless environments
   during intercell handoff - confounds these heuristics.

   Recommendation: No recommendation at this time - continue to monitor
   research results.








Montenegro, et al.           Informational                     [Page 19]

RFC 2757                   Long Thin Networks               January 2000


4.7.2 With Explicit Notifications

   With explicit notification from the network it is possible to
   determine when a loss is due to congestion. Several proposals along
   these lines include:

      -  Explicit Loss Notification (ELN) [BPSK96]

      -  Explicit Bad State Notification (EBSN) [BBKVP96]

      -  Explicit Loss Notification to the Receiver (ELNR), and Explicit
         Delayed Dupack Activation Notification (EDDAN) (notifications
         to mobile receiver) [MV97]

      -  Explicit Congestion Notification (ECN) [ECN]

   Of these proposals, Explicit Congestion Notification (ECN) seems
   closest to deployment on the Internet, and will provide some benefit
   for TCP connections on long thin networks (as well as for all other
   TCP connections).

   Recommendation: No recommendation at this time. Schemes like ELNR and
   EDDAN [MV97], in which  the only systems that need to be modified are
   the intermediate node and the mobile device, are slated for adoption
   pending further research.  However, this solution has some
   limitations. Since the intermediate node must have access to the TCP
   headers, the IP payload must not be encrypted.

   ECN uses the TOS byte in the IP header to carry congestion
   information (ECN-capable and Congestion-encountered).  This byte is
   not encrypted in IPSEC, so ECN can be used on TCP connections that
   are encrypted using IPSEC.

   Recommendation: Implement ECN. In spite of this, mechanisms for
   explicit corruption notification are still relevant and should be
   tracked.

   Note: ECN provides useful information to avoid deteriorating further
   a bad situation, but has some limitations for wireless applications.
   Absence of packets marked with ECN should not be interpreted by ECN-
   capable TCP connections as a green light for aggressive
   retransmissions. On the contrary, during periods of extreme network
   congestion routers may drop packets marked with explicit notification
   because their buffers are exhausted - exactly the wrong time for a
   host to begin retransmitting aggressively.






Montenegro, et al.           Informational                     [Page 20]

RFC 2757                   Long Thin Networks               January 2000


4.8 Active Queue Management

   As has been pointed out above, TCP responds to congestion by closing
   down the window and invoking slow start. Long-delay networks take a
   particularly long time to recover from this condition. Accordingly,
   it is imperative to avoid congestion in LTNs. To remedy this, active