Subject: RE: LINK, 2.5g3g and CDMA2000

From: "Farid Khafizov" <[email-masked]>
Date: Tue, 8 Jan 2002 14:59:04 -0600

As a follow up on IETF-52 meeting discussions, we 
suggest adding the following text to 2.5g/3g ID:
 - a paragraph on VJC
 - a section on Bandwidth Oscillation

We also think that some info about CDMA2000 should be in the 
document. It could go into the same section where specifics of
UMTS are being discussed (Section 2), or be part of Bandwidth 
Oscillation section.

Please provide your feedback.
--Farid

-----------------------------------
1. Disabling Van Jacobson TCP/IP Header Compression

	Van Jacobson TCP/IP header compression (VJC) algorithm [35] is
negotiated between peer PPP layers. In CDMA2000 networks it could be
implemented between the Mobile Terminal Equipment, such as laptop computer,
and the Packet Data Serving Node. The algorithm was designed to increases
application layer throughput by reducing packetization overhead. In the
absence of TCP segment errors, for MTU=1000 Bytes, enabling VJC increases
throughput by about 4%. However, experiments have shown that in the presence
of TCP segment errors, VJC is not desirable because it does not allow TCP to
take advantage of Fast Retransmit Fast Recovery mechanism [n4]. VJC
algorithm transmits not the TCP/IP headers but only the changes in the
headers of consecutive segments. Therefore, a segment error causes the
transmitting and receiving TCP sequence numbers to go out of synch. When a
TCP segment is lost, none of the following segment will go through until RTO
expires. 

	It is recommended to disable VJC algorithm unless TCP segment errors
are very low.

2. Bandwidth Oscillation

	Limited RF spectrum along with high data rate requirement for
2.5G/3G wireless systems necessitate dynamic resource sharing among
concurrent data users. Various scheduling mechanisms can be deployed in
order to maximize resource utilization. Some of the limited resources in
CDMA based systems (e.g., UMTS, CDMA2000) are orthogonal codes and RF
transmit power. Shared channels in UMTS [N1] and supplemental channels in
CDMA2000 [N2], designed for high speed traffic, utilize relatively high RF
power and require higher portion of orthogonal code resources. Time division
sharing of these resources may result in TCP throughput degradation. Usually
these resources are allocated on per needed bases (bandwidth on demand) and
released when there is no data to send. There could, however, be situations
when resources are de-allocated while significant amount of data is still
waiting in the queue. If a number of users require large data file transfer
at the same time, the system (e.g., the scheduler) may have to repeatedly to
allocate and de-allocate resources from each user.

	In this section we refer to periodic allocation and de-allocation of
high-speed channel as Bandwidth Oscillation (BO). BO effects such as
spurious retransmission were identified elsewhere (e.g., [17]) as throughput
degradation factors. However, it is important to note that in case of some
3G wireless network configurations BO can be the single most important
factor in reducing throughput by as much as 30%-50%. In the next paragraph
we give an example of how BO effects TCP performance, and define notation
needed for further discussion. Although, the example is based on CDMA2000
system, the same considerations are applicable to many (wireless) systems
with time scheduling of high-speed data traffic. 

	CDMA2000 1x standard, IS-2000.2 [n2], provides means of transmitting
data over two type of traffic channels: Fundamental (FCH) and Supplemental
(SCH). Fundamental channel has a fixed low bandwidth (e.g., 9.6 kbps).
Bandwidth of SCH is a multiple of that and could be as high as 32 times of
FCH bandwidth. To simplify notation, we assume that FCH rate is fixed at 9.6
kbps, we denote (SCH+FCH)/FCH bandwidth ratio by O. Hence, O is proportional
to the SCH rate. FCH is always assigned before data transmission begins. SCH
is assigned on per needed basis. When SCH is being used we say that the call
is in burst. There are two type of SCH assignments: finite and infinite
[n3], which will be referred to as finite burst and infinite burst,
respectively. Infinite burst means that SCH can be used for transmitting
data until a release command is issued. Finite burst mode of operation
limits the SCH usage to one of fourteen finite time intervals [n3] before it
must be released. We denote the duration of SCH allocation by B. After SCH
is released, it can be acquired again after certain delay (D). 

	One of the ways of detecting congestion in TCP is RTO expiration.
RTO computation algorithm [32] was designed to follow closely round trip
time (RTT), but is known to work poorly when delay variance is high [11].
During high bandwidth (FCH+SCH) RTT is low and, if B is relatively long
(e.g., 5.12 seconds), RTO converges to RTT. When SCH is released, suddenly
RTT increases (proportionally to O) and low RTO expires forcing TCP into the
Slow Start state, while actually none of the TCP segments were lost. 

	            B            
	   |<--------------->|      |-----------------|      |
	   |                 |      |                 |      |
	   |   SCH+FCH       |   D  |                 |      |
	---|                 |<---->|                 |------|   
	                       FCH
	------------------------------------------------------
	Figure 1. Bandwidth oscillation. Full cycle time is B+D. SCH and FCH
are used for transmitting data for time B, then SCH is released and only FCH
carries data for time D.

	The best approach to avoiding adverse effects of BO, is, perhaps,
proper wireless sub-network design. Simulation results as well as lab
measurements suggest [N4] that when TCP parameters (and FCH rate) are fixed
the level of throughput degradation (and achievable throughput) is a
function of <O, B, D>. For some combinations degradation of throughput could
reach 55%. When B and/or D are low, the throughput degradation is less
severe. However, deploying some 2.5/3G wireless systems with low B and/or D
values could be impractical. Higher throughput is achieved when B is high,
while signaling delays impose limits on reducing D. Avoiding finite burst
mode of operation is also not practical because limited RF resources require
time-sharing of SCH resources (e.g., scheduling users). 

	Therefore, one has to consider other techniques that could reduce
spurious retransmissions due to bandwidth oscillation. One obvious method
was to adjust computed RTO value (or configure appropriately the minimum RTO
value) at sending TCP. This technique, however, can not be recommended as a
practical solution. 

	Experiments have shown that RTO algorithm implementation compliant
with RFC2988 (e.g., minimum RTO=1 sec and initial RTO=3 sec) reduce number
of spurious re-transmissions. Although RTO timer management specified in
RFC2988 is not mandatory, implementation of retransmission timer restart
when an ACK is received (section 5.3 of RFC2988) will further reduce (or
even eliminate) spurious retransmissions. However, secondary effects, such
as TCP segment loss, in combination with BO may not allow avoiding all
spurious re-transmissions.

	Analysis of RTO algorithm along with an alternative (Eifel)
algorithm are presented in [17]. Eifel algorithm requires timestamp option
and at least one RTO expiration before TCP "learns" that retransmission was
not necessary. Even in the absence of Eifel algorithm enabling timestamp
option reduces spurious re-transmissions due to BO. Other options that could
reduce spurious re-transmissions due to BO are increase CWND and reduce
delay ACK timer at Receiving TCP to < 100 ms (this technique may have side
effects in case bandwidth is limited in the opposite direction).

	[n1] "WCDMA for UMTS", edited by Harri Holma and Antti Toskala, John
Wiley & Sons, Ltd., 2000
	[n2] TIA/EIA/IS-2000.2-A, March, 2000, "Physical Layer Standard for
cdma2000 Spread Spectrum Systems", 
	[n3] TIA/EIA/IS-2000.5-A, "Upper Layer (Layer 3) Signaling Standard
for cdma2000 Spread Spectrum Systems", March, 2000
	[n4] F.Khafizov, M.Yavuz, "TCP over IS-2000", to appear in Proc. of
IEEE ICC 2002

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 9 Jan 2002 13:43:21 +0000 (GMT)

> Please provide your feedback.

I can't see the ROHC crowd being comfortable with this; I see
Carsten's got PPP/ROHC in last call.
http://www.normos.org/ietf/draft/draft-ietf-rohc-over-ppp-04.txt

Do similar comments apply to the increasing number of ROHC variants in
that ever-growing ROHC bubble? Some comments on ROHC work (and even
how expanding stateful compression relying on flow ordering beyond a
single link to a network path is just silly due to the failure modes
and expectations imposed on the network, where congestion can be a
fact of life) may well be appropriate.

On bandwidth oscillation (also really including extreme capacity
oscillations? I like the BO=undesirable connotations, though):

> proper wireless sub-network design.

here is a good place to reference Phil's link design draft.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 09 Jan 2002 14:42:23 +0000

> throughput by about 4%.

"enabling VJC increases throughput by about 4%" - but you can only quote
numbers for packets with a specific TCP segment size. MTU =/= segment size.

> However, experiments have shown that in the presence
> of TCP segment errors,

"errors" is a bad term - I suggest you say "packet loss", if you mean loss.

> VJC is not desirable because it does not allow TCP to
> take advantage of Fast Retransmit Fast Recovery mechanism [n4].

When the loss occurs on the link using VJC - loss of a TCP data segment
could occur elsewhere along the forward path, and then FR/FR would work.

> VJC
> headers of consecutive segments. Therefore, a segment error

"error" should be "loss a TCP segment on the VJC link"

> causes the

"go through" should be "will be forwarded by the link"

Suggest you refer to "draft-ietf-pilc-link-design"

> It is recommended to disable VJC algorithm unless TCP segment errors

I agree with Lloyd, it seems foolish at this stage not to also mention
ROHC for TCP, which is planning to address these issues directly.

Gorry Fairhurst