Subject: Re: Reminder: 2.5g3g wg last call ends Friday

From: William Gilliam <[email-masked]>
Date: Wed, 1 Aug 2001 11:32:20 -0700 (PDT)

As stated in previous messages, we are modifying the 2.5g3g draft
based upon the helpful comments received during Last Call.  Please
find below the updated Section 3.  (Remember that section 3.2 has
been removed, and a short applicability statement was added to
section 1.)

Thanks!

WG

3. TCP over 2.5G and 3G

3.1 Optimization Mechanisms

3.1.1 Large window size

   The traditional TCP specification limits the window size to 64 KB.
   If the end-to-end capacity is expected to be larger than 64 KB, the
   window scale option [6] can overcome that limitation. TCP over
   2.5G/3G should support appropriate window sizes based on the 
   Bandwidth Delay Product (BDP) of the end-to-end path. If the 
   estimated path BDP is larger than 64 KB, the window scale option
   may be used. 

3.1.2 Large initial window

   TCP controls its transmit rate using the congestion window
   mechanism. Traditionally, the initial value of the window is one
   segment. Because the delayed Ack mechanism is widely deployed, a TCP
   sender should have an increased initial congestion window of two
   segments[4]. This effectively cancels the delayed Ack by sending two
   segments at once in the first RTT of slow start, which helps avoid
   overhead in the initial phase of the connection. 

   Furthermore, the increased initial window mechanism [5] is also
   effective, especially for the transmission of small amounts of data,
   which is the behaviour commonly seen in such applications as 
   Internet-enabled mobile wireless devices. For large data transfers,
   on the other hand, the effect of this mechanism is negligible. 
   [7] describes evaluations of this mechanism by measurements. 

   An initial congestion window size of two segments is recommended in
   RFC2581[4]. RFC2414[5] also considers the use of an initial window
   size larger than two segments. Although use of the increased initial
   congestion window is currently experimental, the impact of its use to
   the majority of the Internet can be mitigated via deployment of the
   split architecture [36] in which TCP connections to the mobile node
   terminate at a specific gateway. The initial congestion window could
   then be set to more than 2 segments only for the connection between
   the gateway and the mobile node, thus allowing the performance
   benefits without using a larger initial congestion window on the
   Internet. Before employing such connection-splitting mechanisms,
   network designers should be aware of their possible implications. 
   See [36] for a discussion of those issues.

   Due to the fact that the delayed Ack mechanism is the standard, and
   that the increased initial window option is especially effective for
   the small data transfers that are common for mobile wireless devices,
   TCP over 2.5G/3G should use initial CWND (congestion window) = 2
   segments. It may use a CWND > 2 segments between a gateway and a
   mobile node. 

3.1.3 Limited Transmit

   RFC3042[30], Limited Transmit, extends Fast Retransmit/Fast Recovery
   for TCP connections with small congestion windows that are not
   likely to generate the three duplicate acknowledgements required to
   trigger Fast Retransmit. The mechanism calls for sending a new data
   segment in response to each of the first two duplicate acknowledgments
   that arrive at the sender. This mechanism is effective when the
   congestion window size is small or if a large number of segments in
   a window are lost. This may reduce the amount of retransmission due 
   to TCP round trip timeout. Similar to the discussion in Section 3.1.2,
   this mechanism is useful for small amounts of data to be transmitted. 
   TCP over 2.5G/3G implementations should implement Limited Transmit. 

3.1.4 Large MTU

   One of the link layer parameters is MTU (Maximum Transfer Unit). In
   TCP, the slow start mechanism tries to find an adequate rate for the
   network path. A larger MTU allows TCP to increase the congestion
   window faster [11], because the window is counted in units of
   segments. In links with high error rates, a smaller link PDU size 
   increases the chance of successful transmission. With layer two ARQ
   and transparent link layer fragmentation, the network layer can
   enjoy a larger MTU even in a relatively high BER (Bit Error Rate)
   condition. Without these features in the link, a smaller MTU is
   suggested. TCP over 2.5G/3G should allow freedom for designers to
   choose MTU values ranging from small values (such as 576 bytes) to
   a large value that is supported by the type of link in use (such as
   1500 bytes for IPv4 packets on Ethernet), although designers are
   generally encouraged to choose large values.

3.1.5 Path MTU discovery

   Path MTU discovery allows a sender to determine the maximum
   end-to-end transmission unit (without IP fragmentation) for a
   given routing path. RFC1191[21] and RFC1981[23] describe the MTU 
   discovery procedure for IPv4 and IPv6 respectively. This allows TCP
   senders to employ larger segment sizes (without causing IP layer
   fragmentation) instead of assuming the small default MTU.  TCP over
   2.5G/3G implementations should implement Path MTU Discovery. Path 
   MTU Discovery requires intermediate routers to support the
   generation of the necessary ICMP messages. RFC1993[22] provides
   recommendations that may be relevant for some router
   implementations. 

3.1.6 Selective Acknowledgments

   The selective acknowledgment option (SACK), RFC2018[8], is effective
   when multiple TCP segments are lost in a single TCP window [13] . In
   particular, if the end-to-end path has a large BDP and a certain
   packet loss rate, the probability of multiple segment losses in a 
   single window of data increases. In such cases, SACK provides
   reliability beyond traditional and Reno TCP [9]. TCP over 2.5G/3G
   should support SACK. 

3.1.7 Explicit Congestion Notification

   Explicit Congestion Notification, RFC2481[25], allows a TCP receiver
   to inform the sender of congestion in the network by setting the
   ECN-Echo flag upon receiving an IP packet marked with the CE bit. The
   TCP sender will then reduce its congestion window. Thus, the use of 
   ECN is believed to provide performance benefits [24]. TCP over 2.5G/3G
   may support ECN. RFC2481[25] also places requirements on intermediate
   routers (e.g. active queue management and setting of the CE bit in the
   IP header to indicate congestion). Therefore, the use of ECN is
   heavily dependent on the necessary support from the relevant routers. 

3.1.8 Recommendations

   Items                                   Qualifier
   ----------------------------------------------------------------
   Large window size
   based on end-to-end BDP
   Window scale option                      Window size>64KB
   [RFC1323]
   Large initial window (CWND = 2 segments)
   [RFC2581]
   Large initial window (CWND > 2 segments) Between a gateway and
   [RFC2414]                                mobile node
   Limited Transmit
   [RFC3042]
   Selective Acknowledgment option (SACK)
   [RFC2018]
   Path MTU discovery
   [RFC1191,RFC1981]M
   MTU larger than default IP MTU
   Explicit Congestion Notification(ECN)
   [RFC2481]

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 06 Aug 2001 05:17:58 +0200

Please, find below the updated Section 4. For the references check 
draft-ietf-pilc-2.5g3g-03.txt.

///Reiner

4. Open Issues

This section outlines additional mechanisms and parameter settings that may 
increase the end-to-end performance when running TCP across 2.5G/3G 
networks. Note, that apart from the discussion of the RTO's initial value, 
those mechanisms and parameter settings are not part of any standards track 
RFC at the timing of writing, and can therefore not be recommended in general.

Link layer mechanisms for increasing TCP performance include enhanced 
TCP/IP header compression schemes [ROHC/TCP], and active queue management 
[RFC2309]. Shortcomings of existing TCP/IP header compression schemes 
[RFC1144, RFC2507] are that headers of handshaking packets (SYNs and FINs), 
and TCP option fields (e.g., SACK or timestamps) are not compressed. In 
fact, the presence of timestamps effectively disables header compression 
based on RFC1144. Especially, if many short-lived TCP connections run 
across the link, the compression of the handshaking packets may greatly 
improve the overall header compression ratio. Implementing active queue 
management is attractive for a number of reasons as outlined in [RFC2309]. 
One important benefit for 2.5G/3G networks, is that it minimizes the amount 
of potentially stale data that may be queued in the network ("clicking from 
page to page" before the download of the previous page is complete). 
Avoiding the transmission of stale data across the 2.5G/3G radio link safes 
transmission (battery) power, and increases goodput (the ratio of useful 
data over total data transmitted). Another important benefit of active 
queue management for 2.5G/3G networks, is that it reduces the risk of a 
spurious timeout for the first data segment as outlined below.

Finding ways to avoid the round-trip times required for TCP's connection 
setup and disconnect is particularly attractive for 2.5G/3G networks since 
these networks are commonly characterized by high delays. This would be 
particularly beneficial for short-lived, transactional 
(request/response-style) TCP sessions that typically result from browsing 
the Web from a smart phone. However, existing solutions such as T/TCP [16] 
have not been adopted due to its security concerns.

A larger initial congestion window as proposed in RFC2414 [RFC2414] may 
greatly increase TCP performance when running across 2.5G/3G networks. 
Those networks often have large bandwidth delay products. Hence, TCP's 
performance is likely to be dominated by the slow start phase [RFC2581]. A 
larger initial congestion window effectively "speeds up" the slow start. At 
the time of writing RFC2414 has been proposed to become a standards track RFC.

Spurious timeouts, packet re-ordering, and packet duplication may reduce 
TCP's performance. Thus, making TCP more robust against those events is 
desirable. Solutions to this problem have been proposed [19], [29], 
[Blanton/Allman IDs], and standardization work within the IETF is ongoing 
at the time of writing. Those solutions include reversing congestion 
control state after such an event has been detected, and adapting the 
retransmission timer and duplicate acknowledgement threshold. The 
deployment of such solutions may be particularly beneficial when running 
TCP across wireless networks. This is since wireless access links may often 
be subject to handovers and resource preemption, or the mobile transmitter 
may traverse through a radio coverage hole. Such disrupting events may 
easily trigger a spurious timeout despite a conservative retransmission 
timer. Also, the mobility mechanisms of some wireless networks may cause 
packet duplication.

The algorithm for computing TCP's retransmission timer is specified in 
RFC2988 [37]. The initial setting of the retransmission timeout value (RTO) 
is specified as 3 seconds. This value might be too low when running TCP 
across 2.5G/3G networks. In addition to its high latencies, those networks 
may be run at bit rates of as low as about 10 kb/s which results in large 
transmission delays. In this case, the RTT for the first data segment may 
easily be beyond the initial retransmission timer setting of 3 seconds. 
This would then cause a spurious timeout for that segment. Hence, in such 
situations it may be advisable to set TCP's initial RTO to a value larger 
than 3 seconds. Furthermore, due to the potentially large transmissions 
delays, a TCP sender might choose to refrain from initializing its RTO from 
the RTT measured for the SYN, but instead take the RTT measured for the 
first data segment.