Subject: large RTT variation caused by bandwidth oscillation

From: Aaron Falk <[email-masked]>
Date: Wed, 05 Dec 2001 13:07:44 -0500

So, here's something interesting.  In draft-ietf-pilc-link-design-07.txt we
say the following:

>    The goal is to compute a RTO that is small enough to detect and
>    recover from packet losses while minimizing unnecessary ("spurious")
>    retransmissions when packets are unexpectedly delayed but not lost.
>    Although these goals conflict, the algorithm works well when the
>    delay variance along the Internet path is low, or the packet loss
>    rate is low.
> 
>    If the path delay variance is high, TCP sets a RTO that is much
>    larger than the mean of the measured delays. But if the packet loss
>    rate is low, the large RTO is of little consequence, as timeouts
>    occur only rarely.  Conversely, if the path delay variance is low,
>    then TCP recovers quickly from lost packets; again, the algorithm
>    works well.
> 
>    But when delay variance and the packet loss rate are both high, these
>    algorithms perform poorly, especially when the mean delay is also
>    high.

But Farid, et al, point out in draft-khafizov-pilc-cdma2000-00.txt:

>     For some (default) network configurations, bandwidth oscillation
>     proved to be the single most significant factor in reducing
>     throughput. CDMA2000 1x standard, IS-2000.2 [10], 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 or 14.4 kbps). Bandwidth of SCH is a multiple
>     of that and could be as high as 32 times of FCH bandwidth. To
>     simplify notation we denote (SCH+FCH)/FCH bandwidth ratio by O. 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 [11], 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 [11] 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 [12] was designed to follow closely round
>     trip time (RTT), but is known to work poorly when delay variance is
>     high [13]. 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
>        |<--------------->|      |-----------------|      |-------------
>        |                 |      |                 |      |
>        |                 |  D   |                 |      |         SCH
>     ---|                 |<---->|                 |------|          +
>                                                      FCH           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.

At first, I thought that we might want to modify the statement in LINK
because CDMA2000 shows a case where you can get RTOs even though there is
no packet loss at all.  

But then I started thinking about how often this might happen.  The period
of SCH+FCH bandwidth needs to be fairly long (several seconds according to
the authors) to have RTO converge the current RTT.  Then you shift down to
narrowband and get a spurious RTO since your store-and-forward delay has
increased.  But at this point your window can afford to be smaller since
your BDP is smaller.  It takes less time to open a smaller window in CA.
So, perhaps this isn't a problem after all.  

Any thoughts?

--aaron

---

From: Anurag Kumar <[email-masked]>
Date: Thu, 6 Dec 2001 11:00:01 +0530 (IST)

On this point, our paper on TCP performance over a link with time
varying capacity in IEEE Trans on Networking August 2001 may be
of some interest.

Anurag Kumar