rfc2760.txt

RFC 的详细文档！

   performance of FACK with Rate-Halving was shown to be much closer to



Allman, et al.               Informational                     [Page 15]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   the theoretical maximum for TCP than either TCP Reno or the SACK-
   based extensions to fast recovery outlined in section 3.3.2.1
   [MSMO97].

3.3.2.2.3 Implementation Issues

   In order to use FACK, the sender's TCP stack must be modified.  In
   addition, the receiver must be able to generate SACK options to
   obtain the full benefit of using FACK.  The FACK algorithm is safe
   for shared networks and is allowed by RFC 2581 [APS99].

3.3.2.2.4 Topology Considerations

   FACK is expected to improve performance in all environments outlined
   in section 2.  Since it is better able to sustain its self-clock than
   TCP Reno, it may be considerably more attractive over long delay
   paths.

3.3.2.2.5 Possible Interaction and Relationships with Other Research

   Both SACK based loss recovery algorithms described above (the fast
   recovery enhancement and the FACK algorithm) are similar in that they
   attempt to effectively repair multiple lost segments from a window of
   data.  Which of the SACK-based loss recovery algorithms to use is
   still an open research question.  In addition, these algorithms are
   similar to the non-SACK NewReno algorithm described in section 3.3.1,
   in that they attempt to recover from multiple lost segments without
   reverting to using the retransmission timer.  As has been shown, the
   above SACK based algorithms are more robust than the NewReno
   algorithm.  However, the SACK algorithm requires a cooperating TCP
   receiver, which the NewReno algorithm does not.  A reasonable TCP
   implementation might include both a SACK-based and a NewReno-based
   loss recovery algorithm such that the sender can use the most
   appropriate loss recovery algorithm based on whether or not the
   receiver supports SACKs.  Finally, both SACK-based and non-SACK-based
   versions of fast recovery have been shown to transmit a large burst
   of data upon leaving loss recovery, in some cases [Hay97].
   Therefore, the algorithms may benefit from some burst suppression
   algorithm.

3.3.3 Explicit Congestion Notification

3.3.3.1 Mitigation Description

   Explicit congestion notification (ECN) allows routers to inform TCP
   senders about imminent congestion without dropping segments.  Two
   major forms of ECN have been studied.  A router employing backward
   ECN (BECN), transmits messages directly to the data originator



Allman, et al.               Informational                     [Page 16]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   informing it of congestion.  IP routers can accomplish this with an
   ICMP Source Quench message.  The arrival of a BECN signal may or may
   not mean that a TCP data segment has been dropped, but it is a clear
   indication that the TCP sender should reduce its sending rate (i.e.,
   the value of cwnd).  The second major form of congestion notification
   is forward ECN (FECN).  FECN routers mark data segments with a
   special tag when congestion is imminent, but forward the data
   segment.  The data receiver then echos the congestion information
   back to the sender in the ACK packet.  A description of a FECN
   mechanism for TCP/IP is given in [RF99].

   As described in [RF99], senders transmit segments with an "ECN-
   Capable Transport" bit set in the IP header of each packet.  If a
   router employing an active queueing strategy, such as Random Early
   Detection (RED) [FJ93,BCC+98], would otherwise drop this segment, an
   "Congestion Experienced" bit in the IP header is set instead.  Upon
   reception, the information is echoed back to TCP senders using a bit
   in the TCP header.  The TCP sender adjusts the congestion window just
   as it would if a segment was dropped.

   The implementation of ECN as specified in [RF99] requires the
   deployment of active queue management mechanisms in the affected
   routers.  This allows the routers to signal congestion by sending TCP
   a small number of "congestion signals" (segment drops or ECN
   messages), rather than discarding a large number of segments, as can
   happen when TCP overwhelms a drop-tail router queue.

   Since satellite networks generally have higher bit-error rates than
   terrestrial networks, determining whether a segment was lost due to
   congestion or corruption may allow TCP to achieve better performance
   in high BER environments than currently possible (due to TCP's
   assumption that all loss is due to congestion).  While not a solution
   to this problem, adding an ECN mechanism to TCP may be a part of a
   mechanism that will help achieve this goal.  See section 3.3.4 for a
   more detailed discussion of differentiating between corruption and
   congestion based losses.

3.3.3.2 Research

   [Flo94] shows that ECN is effective in reducing the segment loss rate
   which yields better performance especially for short and interactive
   TCP connections.  Furthermore, [Flo94] also shows that ECN avoids
   some unnecessary, and costly TCP retransmission timeouts.  Finally,
   [Flo94] also considers some of the advantages and disadvantages of
   various forms of explicit congestion notification.






Allman, et al.               Informational                     [Page 17]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


3.3.3.3 Implementation Issues

   Deployment of ECN requires changes to the TCP implementation on both
   sender and receiver.  Additionally, deployment of ECN requires
   deployment of some active queue management infrastructure in routers.
   RED is assumed in most ECN discussions, because RED is already
   identifying segments to drop, even before its buffer space is
   exhausted.  ECN simply allows the delivery of "marked" segments while
   still notifying the end nodes that congestion is occurring along the
   path.  ECN is safe (from a congestion control perspective) for shared
   networks, as it maintains the same TCP congestion control principles
   as are used when congestion is detected via segment drops.

3.3.3.4 Topology Considerations

   It is expected that none of the environments outlined in section 2
   will present a bias towards or against ECN traffic.

3.3.3.5 Possible Interaction and Relationships with Other Research

   Note that some form of active queueing is necessary to use ECN (e.g.,
   RED queueing).

3.3.4 Detecting Corruption Loss

   Differentiating between congestion (loss of segments due to router
   buffer overflow or imminent buffer overflow) and corruption (loss of
   segments due to damaged bits) is a difficult problem for TCP.  This
   differentiation is particularly important because the action that TCP
   should take in the two cases is entirely different.  In the case of
   corruption, TCP should merely retransmit the damaged segment as soon
   as its loss is detected; there is no need for TCP to adjust its
   congestion window.  On the other hand, as has been widely discussed
   above, when the TCP sender detects congestion, it should immediately
   reduce its congestion window to avoid making the congestion worse.

   TCP's defined behavior, as motivated by [Jac88,Jac90] and defined in
   [Bra89,Ste97,APS99], is to assume that all loss is due to congestion
   and to trigger the congestion control algorithms, as defined in
   [Ste97,APS99].  The loss may be detected using the fast retransmit
   algorithm, or in the worst case is detected by the expiration of
   TCP's retransmission timer.

   TCP's assumption that loss is due to congestion rather than
   corruption is a conservative mechanism that prevents congestion
   collapse [Jac88,FF98].  Over satellite networks, however, as in many
   wireless environments, loss due to corruption is more common than on
   terrestrial networks.  One common partial solution to this problem is



Allman, et al.               Informational                     [Page 18]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   to add Forward Error Correction (FEC) to the data that's sent over
   the satellite/wireless link.  A more complete discussion of the
   benefits of FEC can be found in [AGS99].  However, given that FEC
   does not always work or cannot be universally applied, other
   mechanisms have been studied to attempt to make TCP able to
   differentiate between congestion-based and corruption-based loss.

   TCP segments that have been corrupted are most often dropped by
   intervening routers when link-level checksum mechanisms detect that
   an incoming frame has errors.  Occasionally, a TCP segment containing
   an error may survive without detection until it arrives at the TCP
   receiving host, at which point it will almost always either fail the
   IP header checksum or the TCP checksum and be discarded as in the
   link-level error case.  Unfortunately, in either of these cases, it's
   not generally safe for the node detecting the corruption to return
   information about the corrupt packet to the TCP sender because the
   sending address itself might have been corrupted.

3.3.4.1 Mitigation Description

   Because the probability of link errors on a satellite link is
   relatively greater than on a hardwired link, it is particularly
   important that the TCP sender retransmit these lost segments without
   reducing its congestion window.  Because corrupt segments do not
   indicate congestion, there is no need for the TCP sender to enter a
   congestion avoidance phase, which may waste available bandwidth.
   Simulations performed in [SF98] show a performance improvement when
   TCP can properly differentiate between between corruption and
   congestion of wireless links.

   Perhaps the greatest research challenge in detecting corruption is
   getting TCP (a transport-layer protocol) to receive appropriate
   information from either the network layer (IP) or the link layer.
   Much of the work done to date has involved link-layer mechanisms that
   retransmit damaged segments.  The challenge seems to be to get these
   mechanisms to make repairs in such a way that TCP understands what
   happened and can respond appropriately.

3.3.4.2 Research

   Research into corruption detection to date has focused primarily on
   making the link level detect errors and then perform link-level
   retransmissions.  This work is summarized in [BKVP97,BPSK96].  One of
   the problems with this promising technique is that it causes an
   effective reordering of the segments from the TCP receiver's point of
   view.  As a simple example, if segments A B C D are sent across a
   noisy link and segment B is corrupted, segments C and D may have
   already crossed the link before B can be retransmitted at the link



Allman, et al.               Informational                     [Page 19]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   level, causing them to arrive at the TCP receiver in the order A C D
   B.  This segment reordering would cause the TCP receiver to generate
   duplicate ACKs upon the arrival of segments C and D.  If the
   reordering was bad enough, the sender would trigger the fast
   retransmit algorithm in the TCP sender, in response to the duplicate
   ACKs.  Research presented in [MV98] proposes the idea of suppressing
   or delaying the duplicate ACKs in the reverse direction to counteract
   this behavior.  Alternatively, proposals that make TCP more robust in
   the face of re-ordered segment arrivals [Flo99] may reduce the side
   effects of the re-ordering caused by link-layer retransmissions.

   A more high-level approach, outlined in the [DMT96], uses a new
   "corruption experienced" ICMP error message generated by routers that
   detect corruption.  These messages are sent in the forward direction,
   toward the packet's destination, rather than in the reverse direction
   as is done with ICMP Source Quench messages.  Sending the error
   messages in the forward direction allows this feedback to work over
   asymmetric paths.  As noted above, generating an error message in
   response to a damaged packet is problematic because the source and
   destination addresses may not be valid.  The mechanism outlined in
   [DMT96] gets around this problem by having the routers maintain a
   small cache of recent packet destinations; when the router
   experiences an error rate above some threshold, it sends an ICMP
   corruption-experienced message to all of the destinations in its
   cache.  Each TCP receiver then must return this information to its
   respective TCP sender (through a TCP option).  Upon receiving an ACK
   with this "corruption-experienced" option, the TCP sender assumes
   that packet loss is due to corruption rather than congestion for two
   round trip times (RTT) or until it receives additional link state
   information (such as "link down", source quench, or additional
   "corruption experienced" messages).  Note that in shared networks,
   ignoring segment loss for 2 RTTs may aggravate congestion by making
   TCP unresponsive.

3.3.4.3 Implementation Issues

   All of the techniques discussed above require changes to at least the
   TCP sending and receiving stacks, as well as intermediate routers.
   Due to the concerns over possibly ignoring congestion signals (i.e.,
   segment drops), the above algorithm is not recommended for use in
   shared networks.

3.3.4.4 Topology Considerations

   It is expected that corruption detection, in general would be
   beneficial in all environments outlined in section 2.  It would be