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
>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST