Subject: RE: draft-ietf-pilc-2.5g3g-04.txt (TCP performance over CDMA2000 1X networks)

From: "Farid Khafizov" <[email-masked]>
Date: Thu, 6 Dec 2001 04:30:15 -0600

Andrei, you asked a very good question.
Originally we observed RTO expiration due to "bandwidth oscillation" on
SunOS 5.8 (and 5.6) TCP which is not rfc2988 compliant (default
minRTO=400ms).
Later, however, we performed tests with minRTO set to 1 sec. It turns out
that even when MSS is 536 Bytes, RTO expires in almost every burst period.
(Burst period here means 5.12 sec of SCH+FCH followed by ~1sec of FCH).
Increasing minRTO to 2-3 seconds eliminates RTO expirations.
We think that SunOS does not implement rfc2988 recommended option (section
5.3) for re-transmission timer restart when ACK is received.
Based on our ns simulation results, we believe that if such recommendation
is followed then the spurious retransmissions could be reduced or avoided.

It is important to note that some implementations of 1x system may call for
no data transmission on FCH. We have seen such proposals.
In such cases it would be much harder to avoid RTO expiration when high rate
SCH is turned on and off periodically. 
Similar considerations are applicable to 1xEV-DO and other technologies that
require scheduling of RF resources. 
Therefore we regard "bandwidth oscillation" as a legitimate issue that needs
to be addressed by PILC WG not only in 2.5g/3g but also in LINK ID.

Regards,
--Farid

> -----Original Message-----
> From:	Andrei Gurtov [SMTP:[email-masked]]
> Sent:	Thursday, November 29, 2001 2:17 AM
> To:	Khafizov, Farid [RICH2:2N51:EXCH]; [email-masked]
> Cc:	Yavuz, Mehmet [RICH2:2N51:EXCH]
> Subject:	Re: draft-ietf-pilc-2.5g3g-04.txt (TCP performance over
> CDMA2000 1X          networks)
> 
> Hi Farid,
>  
>  Could you please describe which TCP and simulator  has been used in your
> experiments? Also what is the latency of the link with and without SCH?
>  
>  I would say that spurious RTOs are unlikely due to bandwidth oscillation
> if TCP uses default MSS of 536 Bytes and follows RFC2988 by implementing
> the minimum RTO of 1 sec. I assume that FCH can be used for transmission
> while SCH is being allocated. Then, in about half of the cases, the
> receiver has a delayed ACK outstanding and will send it out when the del.
> ack. timer experies. This ACK will restart the retransmit timer at the
> sender. In another half of the cases, the default MSS size is transmitted
> in less than half a second over 9.6 or 14.4 kbps link. That leaves another
> half a second to deliver an ACK which will restart the retransmit timer.
>  
> Andrei
>  
>  
> ----- Original Message ----- 
> 
> 	From: Farid Khafizov <mailto:[email-masked]> 
> 	To: [email-masked]' <mailto:[email-masked]'> 
> 	Cc: Mehmet Yavuz <mailto:[email-masked]> ; Farid Khafizov
> <mailto:[email-masked]> 
> 	Sent: Monday, November 19, 2001 8:14 PM
> 	Subject: Re: draft-ietf-pilc-2.5g3g-04.txt (TCP performance over
> CDMA2000 1X networks)
> 
> 
> 	We would like to bring our findings related to improving TCP
> performance over CDMA2000 1x  (a.k.a., 1XRTT) networks 
> 	to the attention of this forum. Our results are based on simulations
> and lab measurements for FTP sessions. 
> 
> 	We believe that our results are generally applicable to W-CDMA and,
> possibly, GPRS networks as well. 
> 	However, since we didn't simulate those networks, we can't claim
> that with absolute certainty. 
> 	Our hope is that the discussions on this email list will help to
> better identify 
> 	TCP performance improvement techniques which are applicable to all
> 3G wireless data networks. 
> 
> 	Our view on 3g wireless links is that three factors make them
> different from other links: 
> 	- 3g wireless links are links with Errors (rfc3155 covers that part)
> 
> 	- 3g wireless links experience (some) bandwidth asymmetry (asymmetry
> ID covers that part) 
> 	- 3g wireless links experience "bandwidth oscillation" (see below) 
> 
> 	In some cases bandwidth oscillation proved to be the most
> significant single factor 
> 	causing throughput degradation. (For more details please see the
> document). 
> 	We believe that effects of bandwidth oscillation will have to be
> addressed 
> 	in 3G wireless data ID because they will be present in any system
> which does 
> 	scheduling of RF resources. 
> 
> 	We put our observations/recommendations in a document which was
> submitted 
> 	to IETF last week and can be accessed at 
> 	<http://www.geocities.com/tsg_p/draft-khafizov-pilc-cdma2000-00.txt>
> 
> 	We apologize for some typos left in the document. 
> 
> --Farid 
>

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 6 Dec 2001 20:43:21 +0200 (EET)

Farid-

 I heartily agree that this problem should be studied closely and reflected
in 2.5g/3g and LINK documents. For 2.5g/3g my suggestion is to add it to
the paragraph of section 2 that also mentions other possible reasons of
delay spikes (link outages, handovers, priority blocking).  Avoiding
unnecessary retransmissions when delay spikes occur can be done by using a
more conservative RTO (e.g. setting a larger initial value, like you
suggest) and/or by implementing some response method to avoid unnecessary
retransmissions when detecting a spurious RTO.  There is some on-going work
on these.

  I'm not sure if current versions of SunOS still use BSD-derived TCP code
or they adopted the independent TCP implementation from earlier Solaris
versions. Solaris has reputation of having an aggressive retransmit timer.
For example, here is some text from Vern Paxson's dissertation (sec.
11.5.10)
___
Dawson et al. identified that Solaris uses a typically low
initial value of about 300 msec for its retransmission timeout (RTO). This
value, plus difficulties the timer has with adapting to higher RTTs, leads
to the broken retransmission behavior. For a connection with a longer RTT,
the TCP is guaranteed to retransmit its first packet, whether needed or
not. Such an unnecessary retransmission would be only a minor problem if
the timer then adapted to the RTT and raised the RTO, but it fails to do
so, leading to connections riddled with premature, unnecessary
retransmissions.
---

What could be the contribution to the LINK document? Since this method of
radio resource allocation seem to cause problems for TCPs, then the link
designers should avoid it or at least use the parameters that minimize the
delay spike and bandwidth oscillation? European 2.5g/3g systems
GPRS/UMTS seem to use a different way to allocate radio resources that
does not cause bandwidth oscillation. The delay caused by allocating the
radio resource can lead to increasing the RTT on partly-utilized link but
is not large enough to cause a spurious RTO.

Hope to see you next week in SLC.

-Andrei

-- 
Andrei

---

From: Aaron Falk <[email-masked]>
Date: Fri, 07 Dec 2001 11:27:24 -0500

Andrei-

I think your suggestions are good ones. 

> For 2.5g/3g my suggestion is to
> add it to the paragraph of section 2 that also mentions other possible
> reasons of delay spikes (link outages, handovers, priority blocking).

Yes.   IMO, we should find a way to make 2.5g3g representative of as large
a set of service provider links as reasonable. I'd like to see some draft
text on this.

> Avoiding unnecessary retransmissions when delay spikes occur can be done
> ... by implementing some response method to avoid unnecessary
> retransmissions when detecting a spurious RTO.  There is some on-going
> work on these.

Can you clafify or provide references?  Are you talking about using a
control channel or heuristics to notify stacks that link characteristics
have changed?  If so, this might be too large a topic to squeeze into
2.5g3g.  But it is still interesting.

> delay spike and bandwidth oscillation? 

There is a rather weak section on Bandwidth on Demand in LINK (I wrote it a
couple years and a couple employers ago).  This is really the issue it
should be dealing with.  Some proposed text to replace or enhance that
would be good as well. The current text is more descriptive regarding
mechanisms for managing BoD and only hints at interactions with TCP.  But,
again, this should be in summary form.  A seperate document might be good,
as we did for ASYM, if there's some meat here.

We'll have time on the agenda in SLC to discuss this further.

--aaron

---

From: Andrei Gurtov <[email-masked]>
Date: Sun, 9 Dec 2001 22:46:34 +0200 (EET)

Aaron-

> a set of service provider links as reasonable. I'd like to see some draft

In that case Farid would be the best source of this text?

> 2.5g3g.  But it is still interesting.

I mostly meant our joint work with Reiner. A technical report on some
fixes to the retransmit timer will be available shortly. Later, possibly
a draft based on this report and the draft that specifies Eifel response
to spurious timeouts.
> as we did for ASYM, if there's some meat here.

I think BoD text in LINK is quite informative. It's a nice idea to have a
separate document on this, if there are people interested in contributing.

-- 
Andrei