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
On Thu, 6 Dec 2001, Farid Khafizov wrote:
> 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:gurtov@cs.helsinki.fi] > > Sent: Thursday, November 29, 2001 2:17 AM > > To: Khafizov, Farid [RICH2:2N51:EXCH]; pilc@grc.nasa.gov > > 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:faridk@nortelnetworks.com> > > To: 'pilc@grc.nasa.gov' <mailto:'pilc@grc.nasa.gov'> > > Cc: Mehmet Yavuz <mailto:myavuz@nortelnetworks.com> ; Farid Khafizov > > <mailto:faridk@nortelnetworks.com> > > 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 > > >
-- Andrei
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST