A few comments, now that I've caught up on this discussion.
I don't doubt that the spurious retransmission problem you describe is
real. But it is not new or unique to CDMA2000. As Gorry remarked, it's
been seen since the primordial days when TCP ran over X.25 virtual
circuits. Not to mention demand-dialed PPP over ISDN or POTS modems.
And you don't need a connection-oriented link in your Internet path to
experience rapid, large changes in available bandwidth and RTT that
trigger spurious TCP retransmissions. All you need are intermittent
bursts from some competing traffic flows. Indeed, if you didn't have
competing traffic flows in your subnetwork, you wouldn't need to
allocate and deallocate your SCH channels in the first place. You
could just leave them up all the time!
TCP is supposed to adapt to RTT changes, but since it can't predict
the future it will never adapt perfectly. Perhaps there are some
further improvements to be had, but a *lot* of people have worked
literally for decades to improve TCP's timing and retransmission
algorithms. So I'm a little pessimistic that there's a whole lot we
can still do to improve TCP over your subnetwork without impairing
TCP's performance over the Internet as a whole, inserting PEPs that do
serious violence to the end-to-end model, or requiring ad-hoc manual
endpoint configurations based on the presence of a wireless link in
the path. None of these alternatives is very satisfying.
So aside from encouraging wider use of TCP timestamps, SACK, and the
latest tuning recommendations for initial cwnd, etc, I think the RTT
variation problem is best solved inside the subnetworks.
Also consider that the problem you describe is actually rather
artificial, at least in a CDMA-based network. Unlike TDMA-based
schemes like GSM and GPRS, opening a IS-95, IS-2000 or 1xEV "channel"
doesn't actually dedicate a scarce RF spectral resource to a user that
must go to waste when he has nothing to send. The CDMA user's terminal
simply stops transmitting, or it idles at a very low power level. This
reduces the interference on the channel and releases capacity that
somebody else can use. In that sense, a CDMA network only *appears* to
be connection oriented when it's really not.
The only resource that is truly dedicated to the CDMA user for the
duration of the connection is the RF modem at the base station. That's
just a little patch of silicon in a big array of ASICs, and silicon is
dirt cheap compared to RF spectrum. That argues for a liberal channel
assignment strategy that lets idle traffic channels stay up for
relatively long periods (in comparison to TDMA) before they're torn
down.
BTW, Solaris's TCP is infamous for spurious retransmissions, or at
least it was some years ago before Linux became my primary OS. How
many TCPs have you tried besides Solaris, and do all of them exhibit
the problem to the same or even a significant degree? How about a
recent BSD or Linux TCP with timestamps and SACK enabled?
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST