Subject: 2.5G/3G text - comments on section 4

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 9 Aug 2001 17:56:10 +0100 (BST)

2.5G Internet Draft - Section 4.

*** This text is a large improvement, on reading through there are
*** a number of minor NiTs/clarifications which you may like to think
*** about, as shown below:

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. 

*** I don't understand why the handshaking packet size is so significant
*** to benefit from compression - this seems an interesting comment
*** - have I missed something? - are you thinking about the under-lying
*** overhead within the network - such as setting up compression context?

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

*** "safes" --> should be "saves"

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. 

*** It may be useful to refer also to SLOW here? [RFC3150]

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.

*** Yes. But, isn't this only "for short-lived connections" too?

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

*** Would it be better to say "significant packet reordering" rather
*** than just "packet re-ordering"?
*** (e.g. greater than DupACK Threshold) - small reordering is currently
*** observed on many Internet paths.

*** It may be helpful to add a phrase to explain how "duplication" on
*** the forward and return paths negatively impacts performance at the TCP
level.  
*** apart from simply taking capacity away from that available for useful
*** data transfers, what are the TCP issues?

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.         

*** Last para raised two points, - as you presented in PILC WG meeting,
*** that of initial RTO, and the SYN RTT measurement.