Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2757

Long Thin Networks

Pages: 46
Informational
Part 2 of 2 – Pages 21 to 46
First   Prev   None

Top   ToC   RFC2757 - Page 21   prevText

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 queue management techniques have been proposed as enhancements to routers throughout the Internet [RED]. The primary motivation for deployment of these mechanisms is to prevent "congestion collapse" (a severe degradation in service) by controlling the average queue size at the routers. As the average queue length grows, Random Early Detection [RED] increases the possibility of dropping packets. The benefits are: - Reduce packet drops in routers. By dropping a few packets before severe congestion sets in, RED avoids dropping bursts of packets. In other words, the objective is to drop m packets early to prevent n drops later on, where m is less than n. - Provide lower delays. This follows from the smaller queue sizes, and is particularly important for interactive applications, for which the inherent delays of wireless links already push the user experience to the limits of the non- acceptable. - Avoid lock-outs. Lack of resources in a router (and the resultant packet drops) may, in effect, obliterate throughput on certain connections. Because of active queue management, it is more probable for an incoming packet to find available buffer space at the router. Active Queue Management has two components: (1) routers detect congestion before exhausting their resources, and (2) they provide some form of congestion indication. Dropping packets via RED is only one example of the latter. Another way to indicate congestion is to use ECN [ECN] as discussed above under "Detecting Corruption Loss: With Explicit Notifications." Recommendation: RED is currently being deployed in the Internet, and LTNs should follow suit. ECN deployment should complement RED's.

4.9 Scheduling Algorithms

Active queue management helps control the length of the queues. Additionally, a general solution requires replacing FIFO with other scheduling algorithms that improve:
Top   ToC   RFC2757 - Page 22
      1. Fairness (by policing how different packet streams utilize the
         available bandwidth), and

      2. Throughput (by improving the transmitter's radio channel
         utilization).

   For example, fairness is necessary for interactive applications (like
   telnet or web browsing) to coexist with bulk transfer sessions.
   Proposals here include:

      - Fair Queueing (FQ) [Demers90]

      - Class-based Queueing (CBQ) [Floyd95]

   Even if they are only implemented over the wireless link portion of
   the communication path, these proposals are attractive in wireless
   LTN environments, because new connections for interactive
   applications can have difficulty starting when a bulk TCP transfer
   has already stabilized using all available bandwidth.

   In our base architecture described above, the mobile device typically
   communicates directly with only one wireless peer at a given time:
   the intermediate node. In some W-WANs, it is possible to directly
   address other mobiles within the same cell.  Direct communication
   with each such wireless peer may traverse a spatially distinct path,
   each of which may exhibit statistically independent radio link
   characteristics. Channel State Dependent Packet Scheduling (CSDP)
   [BBKT96] tracks the state of the various radio links (as defined by
   the target devices), and gives preferential treatment to packets
   destined for radio links in a "good" state. This avoids attempting to
   transmit to (and expect acknowledgements from) a peer on a "bad"
   radio link, thus improving throughput.

   A further refinement of this idea suggests that both fairness and
   throughput can be improved by combining a wireless-enhanced CBQ with
   CSDP [FSS98].

   Recommendation: No recommendation at this time, pending further
   study.

4.10 Split TCP and Performance-Enhancing Proxies (PEPs)

Given the dramatic differences between the wired and the wireless links, a very common approach is to provide some impedance matching where the two different technologies meet: at the intermediate node.
Top   ToC   RFC2757 - Page 23
   The idea is to replace an end-to-end TCP connection with two clearly
   distinct connections: one across the wireless link, the other across
   its wireline counterpart. Each of the two resulting TCP sessions
   operates under very different networking characteristics, and may
   adopt the policies best suited to its particular medium.  For
   example, in a specific LTN topology it may be desirable to modify TCP
   Fast Retransmit to resend after the first duplicate ack and Fast
   Recovery to not shrink the congestion window if the LTN link has an
   extremely long RTT, is known to not reorder packets, and is not
   subject to congestion. Moreover, on a long-delay link or on a link
   with a relatively high bandwidth-delay product it may be desirable to
   "slow-start" with a relatively large initial window, even larger than
   four segments.  While these kinds of TCP modifications can be
   negotiated to be employed over the LTN link, they would not be
   deployed end-to-end over the global Internet. In LTN topologies where
   the underlying link characteristics are known, a various similar
   types of performance enhancements can be employed without endangering
   operations over the global Internet.

   In some proposals, in addition to a PEP mechanism at the intermediate
   node, custom protocols are used on the wireless link (for example,
   [WAP], [YB94] or [MOWGLI]).

   Even if the gains from using non-TCP protocols are moderate or
   better, the wealth of research on optimizing TCP for wireless, and
   compatibility with the Internet are compelling reasons to adopt TCP
   on the wireless link (enhanced as suggested in section 5 below).

4.10.1 Split TCP Approaches

Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP [YB94] which achieve performance improvements by abandoning end-to-end semantics. The Mowgli architecture [MOWGLI] proposes a split approach with support for various enhancements at all the protocol layers, not only at the transport layer. Mowgli provides an option to replace the TCP/IP core protocols on the LTN link with a custom protocol that is tuned for LTN links [KRLKA97]. In addition, the protocol provides various features that are useful with LTNs. For example, it provides priority-based multiplexing of concurrent connections together with shared flow control, thus offering link capacity to interactive applications in a timely manner even if there are bandwidth-intensive background transfers. Also with this option, Mowgli preserves the socket semantics on the mobile device so that legacy applications can be run unmodified.
Top   ToC   RFC2757 - Page 24
   Employing split TCP approaches have several benefits as well as
   drawbacks. Benefits related to split TCP approaches include the
   following:

   -  Splitting the end-to-end TCP connection into two parts is a
      straightforward way to shield the problems of the wireless link
      from the wireline Internet path, and vice versa. Thus, a split TCP
      approach enables applying local solutions to the local problems on
      the wireless link.  For example, it automatically solves the
      problem of distinguishing congestion related packet losses on the
      wireline Internet and packet losses due to transmission error on
      the wireless link as these occur on separate TCP connections.
      Even if both segments experience congestion, it may be of a
      different nature and may be treated as such.  Moreover, temporary
      disconnections of the wireless link can be effectively shielded
      from the wireline Internet.

   -  When one of the TCP connections crosses only a single hop wireless
      link or a very limited number of hops, some or all link
      characteristics for the wireless TCP path are known. For example,
      with a particular link we may know that the link provides reliable
      delivery of packets, packets are not delivered out of order, or
      the link is not subject to congestion. Having this information for
      the TCP path one could expect that defining the TCP mitigations to
      be employed becomes a significantly easier task. In addition,
      several mitigations that cannot be employed safely over the global
      Internet, can be successfully employed over the wireless link.

   -  Splitting one TCP connection into two separate ones allows much
      earlier deployment of various recent proposals to improve TCP
      performance over wireless links; only the TCP implementations of
      the mobile device and intermediate node need to be modified, thus
      allowing the vast number of Internet hosts to continue running the
      legacy TCP implementations unmodified. Any mitigations that would
      require modification of TCP in these wireline hosts may take far
      too long to become widely deployed.

   -  Allows exploitation of various application level enhancements
      which may give significant performance gains (see section 4.10.2).

   Drawbacks related to split TCP approaches include the following:

   -  One of the main criticisms against the split TCP approaches is
      that it breaks TCP end-to-end semantics. This has various
      drawbacks some of which are more severe than others. The most
      detrimental drawback is probably that splitting the TCP connection
      disables end-to-end usage of IP layer security mechanisms,
      precluding the application of IPSec to achieve end-to-end
Top   ToC   RFC2757 - Page 25
      security. Still, IPSec could be employed separately in each of the
      two parts, thus requiring the intermediate node to become a party
      to the security association between the mobile device and the
      remote host. This, however, is an undesirable or unacceptable
      alternative in most cases. Other security mechanisms above the
      transport layer, like TLS [RFC2246] or SOCKS [RFC1928], should be
      employed for end-to-end security.

   -  Another drawback of breaking end-to-end semantics is that crashes
      of the intermediate node become unrecoverable resulting in
      termination of the TCP connections. Whether this should be
      considered a severe problem depends on the expected frequency of
      such crashes.

   -  In many occasions claims have been stated that if TCP end-to-end
      semantics is broken, applications relying on TCP to provide
      reliable data delivery become more vulnerable. This, however, is
      an overstatement as a well-designed application should never fully
      rely on TCP in achieving end-to-end reliability at the application
      level. First, current APIs to TCP, such as the Berkeley socket
      interface, do not allow applications to know when an TCP
      acknowledgement for previously sent user data arrives at TCP
      sender.  Second, even if the application is informed of the TCP
      acknowledgements, the sending application cannot know whether the
      receiving application has received the data: it only knows that
      the data reached the TCP receive buffer at the receiving end.
      Finally, in order to achieve end-to-end reliability at the
      application level an application level acknowledgement is required
      to confirm that the receiver has taken the appropriate actions on
      the data it received.

   -  When a mobile device moves, it is subject to handovers by the
      serving base station. If the base station acts as the intermediate
      node for the split TCP connection, the state of both TCP endpoints
      on the previous intermediate node must be transferred to the new
      intermediate node to ensure continued operation over the split TCP
      connection. This requires extra work and causes overhead. However,
      in most of the W-WAN wireless networks, unlike in W-LANs, the W-
      WAN base station does not provide the mobile device with the
      connection point to the wireline Internet (such base stations may
      not even have an IP stack).  Instead, the W-WAN network takes care
      of the mobility and retains the connection point to the wireline
      Internet unchanged while the mobile device moves.  Thus, TCP state
      handover is not required in most W-WANs.

   -  The packets traversing through all the protocol layers up to
      transport layer and again down to the link layer result in extra
      overhead at the intermediate node. In case of LTNs with low
Top   ToC   RFC2757 - Page 26
      bandwidth, this extra overhead does not cause serious additional
      performance problems unlike with W-LANs that typically have much
      higher bandwidth.

   -  Split TCP proposals are not applicable to networks with asymmetric
      routing. Deploying a split TCP approach requires that traffic to
      and from the mobile device be routed through the intermediate
      node. With some networks, this cannot be accomplished, or it
      requires that the intermediate node is located several hops away
      from the wireless network edge which in turn is unpractical in
      many cases and may result in non-optimal routing.

   -  Split TCP, as the name implies, does not address problems related
      to UDP.

   It should noted that using split TCP does not necessarily exclude
   simultaneous usage of IP for end-to-end connectivity.  Correct usage
   of split TCP should be managed per application or per connection and
   should be under the end-user control so that the user can decide
   whether a particular TCP connection or application makes use of split
   TCP or whether it operates end-to-end directly over IP.

   Recommendation: Split TCP proposals that alter TCP semantics are not
   recommended. Deploying custom protocols on the wireless link, such as
   MOWGLI proposes is not recommended, because this note gives
   preference to (1) improving TCP instead of designing a custom
   protocol and (2) allowing end-to-end sessions at all times.

4.10.2 Application Level Proxies

Nowadays, application level proxies are widely used in the Internet. Such proxies include Web proxy caches, relay MTAs (Mail Transfer Agents), and secure transport proxies (e.g., SOCKS). In effect, employing an application level proxy results in a "split TCP connection" with the proxy as the intermediary. Hence, some of the problems present with wireless links, such as combining of a congested wide-area Internet path with a wireless LTN link, are automatically alleviated to some extent. The application protocols often employ plenty of (unnecessary) round trips, lots of headers and inefficient encoding. Even unnecessary data may get delivered over the wireless link in regular application protocol operation. In many cases a significant amount of this overhead can be reduced by simply running an application level proxy on the intermediate node. With LTN links, significant additional improvement can be achieved by introducing application level proxies with application-specific enhancements. Such a proxy may employ an enhanced version of the application protocol over the wireless link.
Top   ToC   RFC2757 - Page 27
   In an LTN environment enhancements at the application layer may
   provide much more notable performance improvements than any transport
   level enhancements.

   The Mowgli system provides full support for adding application level
   agent-proxy pairs between the client and the server, the agent on the
   mobile device and the proxy on the intermediate node. Such a pair may
   be either explicit or fully transparent to the applications, but it
   is, at all times, under the end-user control. Good examples of
   enhancements achieved with application-specific proxies include
   Mowgli WWW [LAKLR95], [LHKR96] and WebExpress [HL96], [CTCSM97].

   Recommendation: Usage of application level proxies is conditionally
   recommended: an application must be proxy enabled and the decision of
   employing a proxy for an application must be under the user control
   at all times.

4.10.3 Snoop and its Derivatives

Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme mixing link- layer reliability mechanisms with the split connection approach. It is an improvement over split TCP approaches in that end-to-end semantics are retained. SNOOP does two things: 1. Locally (on the wireless link) retransmit lost packets, instead of allowing TCP to do so end-to-end. 2. Suppress the duplicate acks on their way from the receiver back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter. Thus, the Snoop protocol is designed to avoid unnecessary fast retransmits by the TCP sender, when the wireless link layer retransmits a packet locally. Consider a system that does not use the Snoop agent. Consider a TCP sender S that sends packets to receiver R via an intermediate node IN. Assume that the sender sends packet A, B, C, D, E (in that order) which are forwarded by IN to the wireless receiver R. Assume that the intermediate node then retransmits B subsequently, because the first transmission of packet B is lost due to errors on the wireless link. In this case, receiver R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E triggers duplicate acknowledgements. When the TCP sender receives three duplicate acknowledgements, it triggers fast retransmit (which results in a retransmission, as well as reduction of congestion window). The fast retransmit occurs despite the link level retransmit on the wireless link, degrading throughput.
Top   ToC   RFC2757 - Page 28
   SNOOP [SNOOP] deals with this problem by dropping TCP dupacks
   appropriately (at the intermediate node). The Delayed Dupacks (see
   section 4.5) attempts to approximate Snoop without requiring
   modifications at the intermediate node.  Such schemes are needed only
   if the possibility of a fast retransmit due to wireless errors is
   non-negligible. In particular, if the wireless link uses a stop-and-
   go protocol (or otherwise delivers packets in-order), then these
   schemes are not very beneficial.  Also, if the bandwidth-delay
   product of the wireless link is smaller than four segments, the
   probability that the intermediate node will have an opportunity to
   send three new packets before a lost packet is retransmitted is
   small.  Since at least three dupacks are needed to trigger a fast
   retransmit, with a wireless bandwidth-delay product less than four
   packets, schemes such as Snoop and Delayed Dupacks would not be
   necessary (unless the link layer is not designed properly).
   Conversely, when the wireless bandwidth-delay product is large
   enough, Snoop can provide significant performance improvement
   (compared with standard TCP). For further discussion on these topics,
   please refer to [Vaidya99].

   The Delayed Dupacks scheme tends to provide performance benefit in
   environments where Snoop performs well. In general, performance
   improvement achieved by the Delayed Dupacks scheme is a function of
   packet loss rates due to congestion and transmission errors. When
   congestion-related losses occur, the Delayed Dupacks scheme
   unnecessarily delays retransmission.  Thus, in the presence of
   congestion losses, the Delayed Dupacks scheme cannot achieve the same
   performance improvement as Snoop.  However, simulation results
   [Vaidya99] indicate that the Delayed Dupacks can achieve a
   significant improvement in performance despite moderate congestion
   losses.

   WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end
   semantics.  In WTCP, the intermediate node uses a complex scheme to
   hide the time it spends recovering from local errors across the
   wireless link (this typically includes retransmissions due to error
   recovery, but may also include time spent dealing with congestion).
   The idea is for the sender to derive a smooth estimate of round-trip
   time.  In order to work effectively, it assumes that the TCP
   endpoints implement the Timestamps option in RFC 1323 [TCPHP].
   Unfortunately, support for RFC 1323 in TCP implementations is not yet
   widespread. Beyond this, WTCP requires changes only at the
   intermediate node.

   SNOOP and WTCP require the intermediate node to examine and operate
   on the traffic between the portable wireless device and the TCP
   server on the wired Internet. SNOOP and WTCP do not work if the IP
   traffic is encrypted, unless, of course, the intermediate node shares
Top   ToC   RFC2757 - Page 29
   the security association between the mobile device and its end-to-end
   peer.  They also require that both the data and the corresponding
   ACKs traverse the same intermediate node.  Furthermore, if the
   intermediate node retransmits packets at the transport layer across
   the wireless link, this may duplicate efforts by the link-layer.
   SNOOP has been described by its designers as a TCP-aware link-layer.
   This is the right approach:  the link and network layers can be much
   more aware of each other than traditional OSI layering suggests.

   Encryption of IP packets via IPSEC's ESP header (in either transport
   or tunnel mode) renders the TCP header and payload unintelligible to
   the intermediate node. This precludes SNOOP (and WTCP) from working,
   because it needs to examine the TCP headers in both directions.
   Possible solutions involve:

   -  making the SNOOP (or WTCP) intermediate node a party to the
      security association between the client and the server

   -  IPSEC tunneling mode, terminated at the SNOOPing intermediate node

   However, these techniques require that users trust intermediate
   nodes.  Users valuing both privacy and performance should use SSL or
   SOCKS for end-to-end security. These, however, are implemented above
   the transport layer, and are not as resistant to some security
   attacks (for example, those based on guessing TCP sequence numbers)
   as IPSEC.

   Recommendation: Implement SNOOP on intermediate nodes now.  Research
   results are encouraging, and it is an "invisible" optimization in
   that neither the client nor the server needs to change, only the
   intermediate node (for basic SNOOP without SACK). However, as
   discussed above there is little or no benefit from implementing SNOOP
   if:

      1. The wireless link provides reliable, in-order packet delivery,
         or,

      2. The bandwidth-delay product of the wireless link is smaller
         than four segments.

4.10.4 PEPs to handle Periods of Disconnection

Periods of disconnection are very common in wireless networks, either during handoff, due to lack of resources (dropped connections) or natural obstacles. During these periods, a TCP sender does not receive the expected acknowledgements. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all the related drawbacks. Re-transmitting packets is useless
Top   ToC   RFC2757 - Page 30
   since the connection is broken. [M-TCP] aims at enabling TCP to
   better handle handoffs and periods of disconnection, while preserving
   end-to-end semantics.  M-TCP adds an element: supervisor host (SH-
   TCP) at the edge of the wireless network.

   This intermediate node monitors the traffic coming from the sender to
   the mobile device. It does not break end-to-end semantics because the
   ACKs sent from the intermediate node to the sender are effectively
   the ones sent by the mobile node. The principle is to generally leave
   the last byte unacknowledged.  Hence, SH-TCP could shut down the
   sender's window by sending the ACK for the last byte with a window
   set to zero. Thus the sender will go to persist mode.

   The second optimization is done on both the intermediate node and the
   mobile host. On the latter, TCP is aware of the current state of the
   connection. In the event of a disconnection, it is capable of
   freezing all timers. Upon reconnection, the mobile sends a specially
   marked ACK with the number of the highest byte received.  The
   intermediate node assumes that the mobile is disconnected because it
   monitors the flow on the wireless link, so in the absence of
   acknowledgments from the mobile, it will inform SH-TCP, which will
   send the ACK closing the sender window as described in the previous
   paragraph. The intermediate node learns that the mobile is again
   connected when it receives a duplicate acknowledgment marked as
   reconnected.  At this point it sends a duplicate ACK to the sender
   and grows the window.  The sender exits persist mode and resumes
   transmitting at the same rate as before. It begins by retransmitting
   any data previously unacknowledged by the mobile node. Non
   overlapping or non soft handoffs are lightweight because the previous
   intermediate system  can shrink the window, and the new one modifies
   it as soon as it has received an indication from the mobile.

   Recommendation: M-TCP is not slated for adoption at this moment,
   because of the highly experimental nature of the proposal, and the
   uncertainty that TCP/IP implementations handle zero window updates
   correctly. Continue tracking developments in this space.

4.11 Header Compression Alternatives

Because Long Thin Networks are bandwidth-constrained, compressing every byte out of over-the-air segments is worth while. Mechanisms for TCP and IP header compression defined in [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] provide the following benefits: - Improve interactive response time - Allow using small packets for bulk data with good line efficiency
Top   ToC   RFC2757 - Page 31
      -  Allow using small packets for delay sensitive low data-rate
         traffic

      -  Decrease header overhead (for a common TCP segment size of 512
         the header overhead of IPv4/TCP within a Mobile IP tunnel can
         decrease from 11.7 to less than 1 per cent.

      -  Reduce packet loss rate over lossy links (because of the
         smaller cross-section of compressed packets).

   Van Jacobson (VJ) header compression [RFC1144] describes a Proposed
   Standard for TCP Header compression that is widely deployed.  It uses
   TCP timeouts to detect a loss of synchronization between the
   compressor and decompressor. [IPHC] includes an explicit request for
   transmission of uncompressed headers to allow resynchronization
   without waiting for a TCP timeout (and executing congestion avoidance
   procedures).

   Recommendation: Implement [IPHC], in particular as it relates to IP-
   in-IP [RFC2003] and Minimal Encapsulation [RFC2004] for Mobile IP, as
   well as TCP header compression  for lossy links and links that
   reorder packets. PPP capable devices should implement [IPHC-PPP].  VJ
   header compression may optionally be implemented as it is a widely
   deployed Proposed Standard.  However, it should only be enabled when
   operating over reliable LTNs, because even a single bit error most
   probably would result in a full TCP window being dropped, followed by
   a costly recovery via slow-start.

4.12 Payload Compression

Compression of IP payloads is also desirable. "IP Payload Compression Protocol (IPComp)" [IPPCP] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented. However, many IP payloads are already compressed (images, audio, video, "zipped" files being FTPed), or are already encrypted above the IP layer (SSL/TLS, etc.). These payloads will not "compress" further, limiting the benefit of this optimization. HTTP/1.1 already supports compression of the message body. For example, to use zlib compression the relevant directives are: "Content-Encoding: deflate" and "Accept-Encoding: deflate" [HTTP- PERF].
Top   ToC   RFC2757 - Page 32
   HTTP-NG is considering supporting compression of resources at the
   HTTP level, which would provide equivalent benefits for common
   compressible MIME types like text/html. This will reduce the need for
   IPComp. If IPComp is deployed more rapidly than HTTP-NG, IPComp
   compression of HTML and MIME headers would be beneficial.

   In general, application-level compression can often outperform
   IPComp, because of the opportunity to use compression dictionaries
   based on knowledge of the specific data being compressed.

   Recommendation: IPComp may optionally be implemented. Track HTTP-NG
   standardization and deployment for now. Implementing HTTP/1.1
   compression using zlib SHOULD is recommended.

4.13 TCP Control Block Interdependence [Touch97]

TCP maintains per-connection information such as connection state, current round-trip time, congestion control or maximum segment size. Sharing information between two consecutive connections or when creating a new connection while the first is still active to the same host may improve performance of the latter connection. The principle could easily be extended to sharing information amongst systems in a LAN not just within a given system. [Touch97] describes cache update for both cases. Users of W-WAN devices frequently request connections to the same servers or set of servers. For example, in order to read their email or to initiate connections to other servers, the devices may be configured to always use the same email server or WWW proxy. The main advantage of this proposal is that it relieves the application of the burden of optimizing the transport layer. In order to improve the performance of TCP connections, this mechanism only requires changes at the wireless device. In general, this scheme should improve the dynamism of connection setup without increasing the cost of the implementation. Recommendation: This mechanism is recommended, although HTTP/1.1 with its persistent connections may partially achieve the same effect without it. Other applications (even HTTP/1.0) may find it useful. Continue monitoring research on this. In particular, work on a "Congestion Manager" [CM] may generalize this concept of sharing information among protocols and applications with a view to making them more adaptable to network conditions.
Top   ToC   RFC2757 - Page 33

5 Summary of Recommended Optimizations

The table below summarizes our recommendations with regards to the main proposals mentioned above. The first column, "Stability of the Proposal," refers to the maturity of the mechanism in question. Some proposals are being pursued within the IETF in a somewhat open fashion. An IETF proposal is either an Internet Drafts (I-D) or a Request for Comments (RFC). The former is a preliminary version. There are several types of RFCs. A Draft Standards (DS) is standards track, and carries more weight than a Proposed Standard (PS), which may still undergo revisions. Informational or Experimental RFCs do not specify a standard. Other proposals are isolated efforts with little or no public review, and unknown chances of garnering industry backing. "Implemented at" indicates which participant in a TCP session must be modified to implement the proposal. Legacy servers typically cannot be modified, so this column indicates whether implementation happens at either or both of the two nodes under some control: mobile device and intermediate node. The symbols used are: WS (wireless sender, that is, the mobile device's TCP send operation must be modified), WR (wireless receiver, that is, the mobile device's TCP receive operation must be modified), WD (wireless device, that is, modifications at the mobile device are not specific to either TCP send or receive), IN (intermediate node) and NI (network infrastructure). These entities are to be understood within the context of Section 1.1 ("Network Architecture"). NA simply means "not applicable." The "Recommendation" column captures our suggestions. Some mechanisms are endorsed for immediate adoption, others need more evidence and research, and others are not recommended. Name Stability of Implemented Recommendation the Proposal at ==================== ============= =========== ================= Increased Initial RFC 2581 (PS) WS Yes Window (initial_window=2) Disable delayed ACKs NA WR When stable during slow start Byte counting NA WS No instead of ACK counting
Top   ToC   RFC2757 - Page 34
TCP Header             RFC 1144 (PS)    WD            Yes
compression for PPP                     IN            (see 4.11)

IP Payload             RFC 2393 (PS)    WD            Yes
Compression                             (simultaneously
(IPComp)                                needed on Server)

Header                 RFC 2507 (PS),   WD            Yes
Compression            RFC 2509 (PS)    IN            (For IPv4, TCP and
                                                      Mobile IP, PPP)

SNOOP plus SACK        In limited use   IN            Yes
                                        WD (for SACK)

Fast retransmit/fast   RFC 2581 (PS)    WD            Yes (should be
recovery                                              there already)

Transaction/TCP        RFC 1644         WD            No
                       (Experimental)   (simultaneously
                                        needed on Server)

Estimating Slow        NA               WS            No
Start Threshold
(ssthresh)

Delayed Duplicate      Not stable       WR            When stable
Acknowledgements                        IN (for
                                        notifications)

Class-based Queuing    NA               WD            When stable
on End Systems

Explicit Congestion    RFC 2481 (EXP)   WD            Yes

Notification                            NI

TCP Control Block      RFC 2140         WD            Yes
Interdependence        (Informational)                (Track research)


   Of all the optimizations in the table above, only SNOOP plus SACK and
   Delayed duplicate acknowledgements are currently being proposed only
   for wireless networks. The others are being considered even for non-
   wireless applications. Their more general applicability attracts more
   attention and analysis from the research community.

   Of the above mechanisms, only Header Compression (for IP and TCP) and
   "SNOOP plus SACK" cease to work in the presence of IPSec.
Top   ToC   RFC2757 - Page 35

6 Conclusion

In view of the unpredictable and problematic nature of long thin networks, arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks (LTNs).

7 Acknowledgements

The authors are deeply indebted to the IETF tcpsat and tcpimpl working groups. The following individuals have also provided valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark (Phone.com).

8 Security Considerations

The mechanisms discussed and recommended in this document have been proposed in previous publications. The security considerations outlined in the original discussions apply here as well. Several security issues are also discussed throughout this document. Additionally, we present below a non-exhaustive list of the most salient issues concerning our recommended mechanisms: - Larger Initial TCP Window Size No known security issues [RFC2414, RFC2581]. - Header Compression May be open to some denial of service attacks. But any attacker in a position to launch these attacks would have much stronger attacks at his disposal [IPHC, IPHC-RTP]. - Congestion Control, Fast Retransmit/Fast Recovery An attacker may force TCP connections to grind to a halt, or, more dangerously, behave more aggressively. The latter possibility may lead to congestion collapse, at least in some regions of the network [RFC2581]. - Explicit Congestion Notification It does not appear to increase the vulnerabilities in the network. On the contrary, it may reduce them by aiding in the identification of flows unresponsive to or non-compliant with TCP congestion control [ECN].
Top   ToC   RFC2757 - Page 36
   -  Sharing of Network Performance Information (TCP Control Block
      Sharing and Congestion Manager module)

      Some information should not be shared. For example, TCP sequence
      numbers are used to protect against spoofing attacks.  Even
      limiting the sharing to performance values leaves open the
      possibility of denial-of-service attacks [Touch97].

   -  Performance Enhancing Proxies

      These systems are men-in-the-middle from the point of view of
      their security vulnerabilities. Accordingly, they must be used
      with extreme care so as to prevent their being hijacked and
      misused.

   This last point is not to be underestimated: there is a general
   security concern whenever an intermediate node performs operations
   different from those carried out in an end-to-end basis. This is not
   specific to performance-enhancing proxies.  In particular, there may
   be a tendency to forego IPSEC-based privacy in order to allow, for
   example, a SNOOP module, header compression (TCP, UDP, RTP, etc), or
   HTTP proxies to work.

   Adding end-to-end security at higher layers (for example via RTP
   encryption, or via TLS encryption of the TCP payload) alleviates the
   problem. However, this still leaves protocol headers in the clear,
   and these may be exploited for traffic analysis and denial-of-service
   attacks.

9 References

[ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering", Work in Progress. [ADGGHOSSTT98] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Osterman, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", Work in Progress. [AGS98] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
Top   ToC   RFC2757 - Page 37
   [Allman98]     Mark Allman. On the Generation and Use of TCP
                  Acknowledgments. ACM Computer Communication Review,
                  28(5), October 1998.

   [AHO98]        Allman, M., Hayes, C., Ostermann, S., "An Evaluation
                  of TCP with Larger Initial Windows," Computer
                  Communication Review, 28(3), July 1998.

   [BBKT96]       Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi,
                  S., "Enhancing Throughput over Wireless LANs Using
                  Channel State Dependent Packet Scheduling," in Proc.
                  IEEE INFOCOM'96, pp. 1133-40, March 1996.

   [BBKVP96]      Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan,
                  D.K., "Improving Performance of TCP over Wireless
                  Networks," Technical Report 96-014, Texas A&M
                  University, 1996.

   [BPSK96]       Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz,
                  R., "A Comparison of Mechanisms for Improving TCP
                  Performance over Wireless Links," in ACM SIGCOMM,
                  Stanford, California, August 1996.

   [BPK99]        Balakrishnan, H., Padmanabhan, V., Katz, R., "The
                  effects of asymmetry on TCP performance," ACM Mobile
                  Networks and Applications (MONET), Vol. 4, No. 3,
                  1999, pp. 219-241.

   [BV97]         S. Biaz and N. H. Vaidya, "Distinguishing Congestion
                  Losses  from Wireless Transmission Losses: A Negative
                  Result," Seventh International Conference on Computer
                  Communications and Networks (IC3N), New Orleans,
                  October 1998.

   [BV98]         Biaz, S., Vaidya, N., "Sender-Based heuristics for
                  Distinguishing Congestion Losses from Wireless
                  Transmission Losses," Texas A&M University, Technical
                  Report 98-013, June 1998.

   [BV98a]        Biaz, S., Vaidya, N., "Discriminating Congestion
                  Losses from Wireless Losses using Inter-Arrival Times
                  at the Receiver," Texas A&M University, Technical
                  Report 98-014, June 1998.

   [BW97]         Brasche, G., Walke, B., "Concepts, Services, and
                  Protocols of the New GSM Phase 2+ general Packet Radio
                  Service," IEEE Communications Magazine, Vol. 35, No.
                  8, August 1997.
Top   ToC   RFC2757 - Page 38
   [CB96]         Cheshire, S., Baker, M., "Experiences with a Wireless
                  Network in MosquitoNet," IEEE Micro, February 1996.
                  Available online as:
                  http://rescomp.stanford.edu/~cheshire/papers
                  /wireless.ps.

   [CDMA]         Electronic Industry Alliance(EIA)/Telecommunications
                  Industry Association (TIA), IS-95: Mobile Station-Base
                  Station Compatibility Standard for Dual-Mode Wideband
                  Spread Spectrum Cellular System, 1993.

   [CDPD]         Wireless Data Forum, CDPD System Specification,
                  Release 1.1, 1995.

   [CM]           Hari Balakrishnan and Srinivasan Seshan, "The
                  Congestion Manager," Work in Progress.

   [CTCSM97]      Chang, H., Tait, C., Cohen, N., Shapiro, M.,
                  Mastrianni, S., Floyd, R., Housel, B., Lindquist, D.,
                  "Web Browsing in a Wireless Environment: Disconnected
                  and Asynchronous Operation in ARTour Web Express," in
                  Proc. MobiCom'97, Budapest, Hungary, September 1997.

   [Demers90]     Demers, A., Keshav, S., and Shenker, S., Analysis and
                  Simulation of a Fair Queueing Algorithm,
                  Internetworking: Research and Experience, Vol. 1,
                  1990, pp. 3-26.

   [ECN]          Ramakrishnan, K. and S. Floyd, "A Proposal to add
                  Explicit Congestion Notification (ECN) to IP", RFC
                  2481, January 1999.

   [Floyd95]      Floyd, S., and Jacobson, V., Link-sharing and Resource
                  Management Models for Packet Networks. IEEE/ACM
                  Transactions on Networking, Vol. 3 No. 4, pp. 365-386,
                  August 1995.

   [FSS98]        Fragouli, C., Sivaraman, V., Srivastava, M.,
                  "Controlled Multimedia Wireless Link Sharing via
                  Enhanced Class-Based Queueing with Channel-State-
                  Dependent Packet Scheduling," Proc. IEEE INFOCOM'98,
                  April 1998.

   [GPRS]         ETSI, "General Packet Radio Service (GPRS): Service
                  Description, Stage 2," GSM03.60, v.6.1.1 August 1998.
Top   ToC   RFC2757 - Page 39
   [GSM]          Rahnema, M., "Overview of the GSM system and protocol
                  architecture," IEEE Communications Magazine, vol. 31,
                  pp 92-100, April 1993.

   [HL96]         Hausel, B., Lindquist, D., "WebExpress: A System for
                  Optimizing Web Browsing in a Wireless Environment," in
                  Proc.  MobiCom'96, Rye, New York, USA, November 1996.

   [HTTP-PERF]    Henrik Frystyk Nielsen (W3C, MIT), Jim Gettys (W3C,
                  Digital), Anselm Baird-Smith (W3C, INRIA), Eric
                  Prud'hommeaux (W3C, MIT), Hon Lie (W3C, INRIA), Chris
                  Lilley (W3C, INRIA), "Network Performance Effects of
                  HTTP/1.1, CSS1, and PNG," ACM SIGCOMM '97, Cannes,
                  France, September 1997.  Available at:
                  http://www.w3.org/Protocols/HTTP/Performance
                  /Pipeline.html

   [IPPCP]        Shacham, A., Monsour, R., Pereira, R. and M. Thomas,
                  "IP Payload Compression Protocol (IPComp)", RFC 2393,
                  December 1998.

   [IPHC]         Degermark, M., Nordgren, B. and S. Pink, "IP Header
                  Compression", RFC 2507, February 1999.

   [IPHC-RTP]     Casner, S. and  V. Jacobson, "Compressing IP/UDP/RTP
                  Headers for Low-Speed Serial Links", RFC 2508,
                  February 1999.

   [IPHC-PPP]     Engan, M., Casner, S. and C. Bormann, "IP Header
                  Compression over PPP", RFC 2509, February 1999.

   [ITCP]         Bakre, A., Badrinath, B.R., "Handoff and Systems
                  Support for Indirect TCP/IP. In Proceedings of the
                  Second USENIX Symposium on Mobile and Location-
                  Independent Computing, Ann Arbor, Michigan, April 10-
                  11, 1995.

   [Jain89]       Jain, R., "A Delay-Based Approach for Congestion
                  Avoidance in Interconnected Heterogeneous Computer
                  Networks," Digital Equipment Corporation, Technical
                  Report DEC-TR-566, April 1989.

   [Karn93]       Karn, P., "The Qualcomm CDMA Digital Cellular System"
                  Proc. USENIX Mobile and Location-Independent Computing
                  Symposium, USENIX Association, August 1993.
Top   ToC   RFC2757 - Page 40
   [KRLKA97]      Kojo, M., Raatikainen, K., Liljeberg,  M., Kiiskinen,
                  J., Alanko, T., "An Efficient Transport Service for
                  Slow Wireless Telephone Links," in IEEE Journal on
                  Selected Areas of Communication, volume 15, number 7,
                  September 1997.

   [LAKLR95]      Liljeberg, M., Alanko, T., Kojo, M., Laamanen, H.,
                  Raatikainen, K., "Optimizing World-Wide Web for
                  Weakly-Connected Mobile Workstations: An Indirect
                  Approach," in Proc. 2nd Int.  Workshop on Services in
                  Distributed and Networked Environments, Whistler,
                  Canada, pp. 132-139, June 1995.

   [LHKR96]       Liljeberg, M., Helin, H., Kojo, M., Raatikainen, K.,
                  "Mowgli WWW Software: Improved Usability of WWW in
                  Mobile WAN Environments," in Proc.  IEEE Global
                  Internet 1996 Conference, London, UK, November 1996.

   [LS98]         Lettieri, P., Srivastava, M., "Adaptive Frame Length
                  Control for Improving Wireless Link Throughput, Range,
                  and Energy Efficiency," Proc.  IEEE INFOCOM'98, April
                  1998.

   [MNCP]         Piscitello, D., Phifer, L., Wang, Y., Hovey, R.,
                  "Mobile Network Computing Protocol (MNCP)", Work in
                  Progress.

   [MOWGLI]       Kojo, M., Raatikainen, K., Alanko, T., "Connecting
                  Mobile Workstations to the Internet over a Digital
                  Cellular Telephone Network," in Proc. Workshop on
                  Mobile and Wireless Information Systems (MOBIDATA),
                  Rutgers University, NJ, November 1994.  Available at:
                  http://www.cs.Helsinki.FI/research/mowgli/. Revised
                  version published in Mobile Computing, pp. 253-270,
                  Kluwer, 1996.

   [MSMO97]       Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The
                  Macroscopic Behavior of the TCP Congestion Avoidance
                  Algorithm," in Computer Communications Review, a
                  publication of ACM SIGCOMM, volume 27, number 3, July
                  1997.

   [MTCP]         Brown, K. Singh, S., "A Network Architecture for
                  Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388-
                  1396, March 1996.  Available at
                  ftp://ftp.ece.orst.edu/pub/singh/papers
                  /transport.ps.gz
Top   ToC   RFC2757 - Page 41
   [M-TCP]        Brown, K. Singh, S., "M-TCP: TCP for Mobile Cellular
                  Networks," ACM Computer Communications Review Vol.
                  27(5), 1997.  Available at
                  ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz

   [MV97]         Mehta, M., Vaidya, N., "Delayed Duplicate-
                  Acknowledgements:  A Proposal to Improve Performance
                  of TCP on Wireless Links," Texas A&M University,
                  December 24, 1997.  Available at
                  http://www.cs.tamu.edu/faculty/vaidya/mobile.html

   [NETBLT]       White, J., "NETBLT (Network Block Transfer Protocol)",
                  Work in Progress.

   [Paxson97]     V. Paxson, "End-to-End Internet Packet Dynamics,"
                  Proc. SIGCOMM '97.  Available at
                  ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z

   [RED]          Braden, B., Clark, D., Crowcroft, J., Davie, B.,
                  Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
                  Minshall, G., Partridge, C., Peterson, L.,
                  Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
                  Zhang, "Recommendations on Queue Management and
                  Congestion Avoidance in the Internet", RFC 2309, April
                  1998.

   [RLP]          ETSI, "Radio Link Protocol for Data and Telematic
                  Services on the Mobile Station - Base Station System
                  (MS-BSS) interface and the Base Station System -
                  Mobile Switching Center (BSS-MSC) interface," GSM
                  Specification 04.22, Version 3.7.0, February 1992.

   [RFC908]       Velten, D., Hinden, R. and J. Sax, "Reliable Data
                  Protocol", RFC 908, July 1984.

   [RFC1030]      Lambert, M., "On Testing the NETBLT Protocol over
                  Divers Networks", RFC 1030, November 1987.

   [RFC1122]      Braden, R., "Requirements for Internet Hosts --
                  Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1144]      Jacobson, V., "Compressing TCP/IP Headers for Low-
                  Speed Serial Links", RFC 1144, February 1990.

   [RFC1151]      Partridge, C., Hinden, R., "Version 2 of the Reliable
                  Data Protocol (RDP)", RFC 1151, April 1990.
Top   ToC   RFC2757 - Page 42
   [RFC1191]      Mogul, J. and S. Deering, "Path MTU Discovery", RFC
                  1191, November 1990.

   [RFC1397]      Braden, R., "Extending TCP for Transactions --
                  Concepts", RFC 1397, November 1992.

   [RFC1644]      Braden, R., "T/TCP -- TCP Extensions for Transactions
                  Functional Specification", RFC 1644, July 1994.

   [RFC1661]      Simpson, W., "The Point-To-Point Protocol (PPP)", STD
                  51, RFC 1661, July 1994.

   [RFC1928]      Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.
                  and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
                  March 1996.

   [RFC1986]      Polites, W., Wollman, W., Woo, D. and R. Langan,
                  "Experiments with a Simple File Transfer Protocol for
                  Radio Links using Enhanced Trivial File Transfer
                  Protocol (ETFTP)", RFC 1986, August 1996.

   [RFC2002]      Perkins, C., "IP Mobility Support", RFC 2002, October
                  1996.

   [RFC2003]      Perkins, C., "IP Encapsulation within IP", RFC 2003,
                  October 1996.

   [RFC2004]      Perkins, C., "Minimal Encapsulation within IP", RFC
                  2004, October 1996.

   [RFC2018]      Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow,
                  "TCP Selective Acknowledgment Options", RFC 2018,
                  October 1996.

   [RFC2188]      Banan, M., Taylor, M. and J. Cheng, "AT&T/Neda's
                  Efficient Short Remote Operations (ESRO) Protocol
                  Specification Version 1.2", RFC 2188, September 1997.

   [RFC2246]      Dierk, T. and E. Allen, "TLS Protocol Version 1", RFC
                  2246, January 1999.

   [RFC2414]      Allman, M., Floyd, S. and C. Partridge. "Increasing
                  TCP's Initial Window", RFC 2414, September 1998.

   [RFC2415]      Poduri, K.and K. Nichols, "Simulation Studies of
                  Increased Initial TCP Window Size", RFC 2415,
                  September 1998.
Top   ToC   RFC2757 - Page 43
   [RFC2416]      Shepard, T. and C. Partridge, "When TCP Starts Up With
                  Four Packets Into Only Three Buffers", RFC 2416,
                  September 1998.

   [RFC2581]      Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
                  Control", RFC 2581, April 1999.

   [RFC2582]      Floyd, S. and T. Henderson, "The NewReno Modification
                  to TCP's Fast Recovery Algorithm", RFC 2582, April
                  1999.

   [SNOOP]        Balakrishnan, H., Seshan, S., Amir, E., Katz, R.,
                  "Improving TCP/IP Performance over Wireless Networks,"
                  Proc. 1st ACM Conf. on Mobile Computing and Networking
                  (Mobicom), Berkeley, CA, November 1995.

   [Stevens94]    R. Stevens, "TCP/IP Illustrated, Volume 1," Addison-
                  Wesley, 1994 (section 2.10 for MTU size considerations
                  and section 11.3 for weak checksums).

   [TCPHP]        Jacobson, V., Braden, R. and D. Borman, "TCP
                  Extensions for High Performance", RFC 1323, May 1992.

   [TCPSATMIN]    TCPSAT Minutes, August, 1997. Available at:
                  http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-
                  minutes.txt.

   [Touch97]      Touch, T., "TCP Control Block Interdependence", RFC
                  2140, April 1997.

   [Vaidya99]     N. H. Vaidya, M. Mehta, C. Perkins, G. Montenegro,
                  "Delayed Duplicate Acknowledgements: A TCP-Unaware
                  Approach to Improve Performance of TCP over Wireless,"
                  Technical Report 99-003, Computer Science Dept., Texas
                  A&M University, February 1999.

   [VEGAS]        Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques
                  for Congestion Detection and Avoidance," SIGCOMM'94,
                  London, pp 24-35, October 1994.

   [VMTP]         Cheriton, D., "VMTP: Versatile Message Transaction
                  Protocol", RFC 1045, February 1988.

   [WAP]          Wireless Application Protocol Forum.
                  http://www.wapforum.org/
Top   ToC   RFC2757 - Page 44
   [WC91]         Wang, Z., Crowcroft, J., "A New Congestion Control
                  Scheme:  Slow Start and Search," ACM Computer
                  Communication Review, vol 21, pp 32-43, January 1991.

   [WTCP]         Ratnam, K., Matta, I., "WTCP: An Efficient
                  Transmission Control Protocol for Networks with
                  Wireless Links," Technical Report NU-CCS-97-11,
                  Northeastern University, July 1997. Available at:
                  http://www.ece.neu.edu/personal/karu/papers/WTCP-
                  NU.ps.gz

   [YB94]         Yavatkar, R., Bhagawat, N., "Improving End-to-End
                  Performance of TCP over Mobile Internetworks," Proc.
                  Workshop on Mobile Computing Systems and Applications,
                  IEEE Computer Society Press, Los Alamitos, California,
                  1994.

Authors' Addresses

Questions about this document may be directed at: Gabriel E. Montenegro Sun Labs Networking and Security Group Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303 Phone: +1-650-786-6288 Fax: +1-650-786-6445 EMail: gab@sun.com Spencer Dawkins Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805 Phone: +1-972-684-4827 Fax: +1-972-685-3292 EMail: sdawkins@nortel.com
Top   ToC   RFC2757 - Page 45
   Markku Kojo
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland

   Phone: +358-9-1914-4179
   Fax:   +358-9-1914-4441
   EMail: kojo@cs.helsinki.fi


   Vincent Magret
   Corporate Research Center
   Alcatel Network Systems, Inc
   1201 Campbell
   Mail stop 446-310
   Richardson Texas 75081 USA
   M/S 446-310

   Phone: +1-972-996-2625
   Fax:   +1-972-996-5902
   EMail: vincent.magret@aud.alcatel.com


   Nitin Vaidya
   Dept. of Computer Science
   Texas A&M University
   College Station, TX 77843-3112

   Phone: 979-845-0512
   Fax: 979-847-8578
   EMail: vaidya@cs.tamu.edu
Top   ToC   RFC2757 - Page 46
Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.