rfc2757.txt

<VC++网络游戏建摸与实现>源代码

      -  It is generally recognized that TCP does not perform well in
         the presence of significant levels of non-congestion loss.  TCP
         detractors argue that the wireless medium is one such case, and
         that it is hard enough to fix TCP. They argue that it is easier
         to start from scratch.

      -  TCP has too much header overhead.

      -  By the time the mechanisms are in place to fix it, TCP is very
         heavy, and ill-suited for use by lightweight, portable devices.

   and here are some in support of TCP:

      -  It is preferable to continue using the same protocol that the
         rest of the Internet uses for compatibility reasons. Any
         extensions specific to the wireless link may be negotiated.

      -  Legacy mechanisms may be reused (for example three-way
         handshake).

      -  Link-layer FEC and ARQ can reduce the BER such that any losses
         TCP does see are, in fact, caused by congestion (or a sustained
         interruption of link connectivity). Modern W-WAN technologies
         do this (CDPD, US-TDMA, CDMA, GSM), thus improving TCP
         throughput.

      -  Handoffs among different technologies are made possible by
         Mobile IP [RFC2002], but only if the same protocols, namely
         TCP/IP, are used throughout.

      -  Given TCP's wealth of research and experience, alternative
         protocols are relatively immature, and the full implications of
         their widespread deployment not clearly understood.

   Overall, we feel that the performance of TCP over long-thin networks
   can be improved significantly. Mechanisms to do so are discussed in
   the next sections.



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


4 Candidate Optimizations

   There is a large volume of work on the subject of optimizing TCP for
   operation over wireless media. Even though satellite networks
   generally fall in the LFN regime, our current LTN focus has much to
   benefit from it.  For example, the work of the TCP-over-Satellite
   working group of the IETF has been extremely helpful in preparing
   this section [AGS98, ADGGHOSSTT98].

4.1 TCP: Current Mechanisms

   A TCP sender adapts its use of bandwidth based on feedback from the
   receiver. The high latency characteristic of LTNs implies that TCP's
   adaptation is correspondingly slower than on networks with shorter
   delays.  Similarly, delayed ACKs exacerbate the perceived latency on
   the link. Given that TCP grows its congestion window in units of
   segments, small MTUs may slow adaptation even further.

4.1.1 Slow Start and Congestion Avoidance

   Slow Start and Congestion Avoidance [RFC2581] are essential the
   Internet's stability.  However there are two reasons why the wireless
   medium adversely affects them:

      -  Whenever TCP's retransmission timer expires, the sender assumes
         that the network is congested and invokes slow start. This is
         why it is important to minimize the losses caused by
         corruption, leaving only those caused by congestion (as
         expected by TCP).

      -  The sender increases its window based on the number of ACKs
         received. Their rate of arrival, of course, is dependent on the
         RTT (round-trip-time) between sender and receiver, which
         implies long ramp-up times in high latency links like LTNs. The
         dependency lasts until the pipe is filled.

      -  During slow start, the sender increases its window in units of
         segments. This is why it is important to use an appropriately
         large MTU which, in turn, requires requires link layers with
         low loss.

4.1.2 Fast Retransmit and Fast Recovery

   When a TCP sender receives several duplicate ACKs, fast retransmit
   [RFC2581] allows it to infer that a segment was lost.  The sender
   retransmits what it considers to be this lost segment without waiting
   for the full timeout, thus saving time.




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


   After a fast retransmit, a sender invokes the fast recovery [RFC2581]
   algorithm. Fast recovery allows the sender to transmit at half its
   previous rate (regulating the growth of its window based on
   congestion avoidance), rather than having to begin a slow start. This
   also saves time.

   In general, TCP can increase its window beyond the delay-bandwidth
   product. However, in LTN links the congestion window may remain
   rather small, less than four segments, for long periods of time due
   to any of the following reasons:

      1. Typical "file size" to be transferred over a connection is
         relatively small (Web requests, Web document objects, email
         messages, files, etc.) In particular, users of LTNs are not
         very willing to carry out large transfers as the response time
         is so long.

      2. If the link has high BER, the congestion window tends to stay
         small

      3. When an LTN is combined with a highly congested wireline
         Internet path, congestion losses on the Internet have the same
         effect as 2.

      4. Commonly, ISPs/operators configure only a small number of
         buffers (even as few as for 3 packets) per user in their dial-
         up routers

      5. Often small socket buffers are recommended with LTNs in order
         to prevent the RTO from inflating and to diminish the amount of
         packets with competing traffic.

   A small window effectively prevents the sender from taking advantage
   of Fast Retransmits. Moreover, efficient recovery from multiple
   losses within a single window requires adoption of new proposals
   (NewReno [RFC2582]). In addition, on slow paths with no packet
   reordering waiting for three duplicate ACKs to arrive postpones
   retransmission unnecessarily.

   Recommendation: Implement Fast Retransmit and Fast Recovery at this
   time. This is a widely-implemented optimization and is currently at
   Proposed Standard level. [AGS98] recommends implementation of Fast
   Retransmit/Fast Recovery in satellite environments.  NewReno
   [RFC2582] apparently does help a sender better handle partial ACKs
   and multiple losses in a single window, but at this point is not
   recommended due to its experimental nature.  Instead, SACK [RFC2018]
   is the preferred mechanism.




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


4.2 Connection Setup with T/TCP [RFC1397, RFC1644]

   TCP engages in a "three-way handshake" whenever a new connection is
   set up.  Data transfer is only possible after this phase has
   completed successfully.  T/TCP allows data to be exchanged in
   parallel with the connection set up, saving valuable time for short
   transactions on long-latency networks.

   Recommendation: T/TCP is not recommended, for these reasons:

   -  It is an Experimental RFC.

   -  It is not widely deployed, and it has to be deployed at both ends
      of a connection.

   -  Security concerns have been raised that T/TCP is more vulnerable
      to address-spoofing attacks than TCP itself.

   -  At least some of the benefits of T/TCP (eliminating three-way
      handshake on subsequent query-response transactions, for instance)
      are also available with persistent connections on HTTP/1.1, which
      is more widely deployed.

   [ADGGHOSSTT98] does not have a recommendation on T/TCP in satellite
   environments.

4.3 Slow Start Proposals

   Because slow start dominates the network response seen by interactive
   users at the beginning of a TCP connection, a number of proposals
   have been made to modify or eliminate slow start in long latency
   environments.

   Stability of the Internet is paramount, so these proposals must
   demonstrate that they will not adversely affect Internet congestion
   levels in significant ways.

4.3.1 Larger Initial Window

   Traditional slow start, with an initial window of one segment, is a
   time-consuming bandwidth adaptation procedure over LTNs. Studies on
   an initial window larger than one segment [RFC2414, AHO98] resulted
   in the TCP standard supporting a maximum value of 2 [RFC2581]. Higher
   values are still experimental in nature.







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


   In simulations with an increased initial window of three packets
   [RFC2415], this proposal does not contribute significantly to packet
   drop rates, and it has the added benefit of improving initial
   response times when the peer device delays acknowledgements during
   slow start (see next proposal).

   [RFC2416] addresses situations where the initial window exceeds the
   number of buffers available to TCP and indicates that this situation
   is no different from the case where the congestion window grows
   beyond the number of buffers available.

   [RFC2581] now allows an initial congestion window of two segments. A
   larger initial window, perhaps as many as four segments, might be
   allowed in the future in environments where this significantly
   improves performance (LFNs and LTNs).

   Recommendation: Implement this on devices now. The research on this
   optimization indicates that 3 segments is a safe initial setting, and
   is centering on choosing between 2, 3, and 4. For now, use 2
   (following RFC2581), which at least allows clients running query-
   response applications to get an initial ACK from unmodified servers
   without waiting for a typical delayed ACK timeout of 200
   milliseconds, and saves two round-trips. An initial window of 3
   [RFC2415] looks promising and may be adopted in the future pending
   further research and experience.

4.3.2 Growing the Window during Slow Start

   The sender increases its window based on the flow of ACKs coming back
   from the receiver. Particularly during slow start, this flow is very
   important.  A couple of the proposals that have been studied are (1)
   ACK counting and (2) ACK-every-segment.

4.3.2.1 ACK Counting

   The main idea behind ACK counting is:

      -  Make each ACK count to its fullest by growing the window based
         on the data being acknowledged (byte counting) instead of the
         number of ACKs (ACK counting). This has been shown to cause
         bursts which lead to congestion. [Allman98] shows that Limited
         Byte Counting (LBC), in which the window growth is limited to 2
         segments, does not lead to as much burstiness, and offers some
         performance gains.

   Recommendation: Unlimited byte counting is not recommended.  Van
   Jacobson cautions against byte counting [TCPSATMIN] because it leads
   to burstiness, and recommends ACK spacing [ACKSPACING] instead.



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


   ACK spacing requires ACKs to consistently pass through a single ACK-
   spacing router.  This requirement works well for W-WAN environments
   if the ACK-spacing router is also the intermediate node.

   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].