Nitin,
We've done simulations for TCP over RLP (this is the semi-reliable ARQ
due to Phil) over CDMA IS-95, and the results sort of agrees with Reiner's
findings at low bit rate (< 14.4 Kbps). There're hardly any TCP timeouts due
to RLP retransmissions. The reason is, a significant queuing delay is
encountered by the TCP packets at the radio link layer (where they're split
into a number of RLP frames) due to the low air link bandwidth. This
inflates the RTT considerably, and if you add the delay variations
encountered by previous RLP retransmissions (however frequent they may be),
we've a RTO estimate which is at least about 1.5 times this (inflated) RTT.
This gives a more than sufficient margin to avoid spurious timeouts.
However, things might be different for higher bit-rate (e.g, in 3G)
where the air-link bit rate may go upto 2 Mbps, and we can expect to see
some spurious timeouts due to unexpected disconnections.
Thanks,
Sanjoy
-----Original Message-----
From: Nitin H Vaidya [SMTP:vaidya@cs.tamu.edu]
Sent: Thursday, February 11, 1999 8:50 AM
To: karn@qualcomm.com; vaidya@cs.tamu.edu
Cc: pilc@lerc.nasa.gov
Subject: RE: LL ARQ on LD links [was: PILC: prioritization]
>> From karn@homer.ka9q.ampr.org Thu Feb 11 01:36:10 1999
>>
>> >(i) Tweak wireless link layer so that the end-to-end RTT would
>> > not change despite retransmissions. Purely a link layer
>> > change.
>>
>> Hmm, making the RTT big all the time seems like you're going
from the
>> frying pan into the fire. It would be different if you put that
extra
>> time to good use (e.g., by coding and interleaving over that
span),
>> but you propose to just twiddle your thumbs until the allotted
time is
>> up. That doesn't sound like an advantage.
Yes, like I said earlier, I do see the obvious disadavantages
of this approach and the second approach below.
Would the above scheme be acceptable for bulk data though?
... one could choose to increase the RTT on a per-packet basis.
>> >(ii) Tweak RTO calculations so that the TCP sender would not
>> > timeout despite link-level retransmits. No changes to
>> > link layer. Purely a TCP change.
>>
>> Hmm.
>>
>> All of these TCP timing tweaks are really solving higher-order
>> problems, because stock TCP already adapts to changes in RTT.
>> Spurious retransmissions can only occur if there's a sudden,
>> unexpected increase in RTT when the mdev is small (which is
what makes
>> the increase unexpected). But if the measured RTT starts to
vary a
>> lot, then the mdev will increase and so will the retransmission
>> timeout and the spurious retransmissions will stop.
The question really is whether to rely on the mdev to inflate the
RTT sufficiently.
In any event, Reiner Ludwig pointed out that in the BSD stack,
the timeout is already inflated by one RTT. At the time, I thought
I understood what he meant. Now, I don't. If he is right, then
the above scheme is already implemented, perhaps unintentionally.
Reiner: Care to explain again why TCP sender did not timeout in
your experiments despite link level retransmits?
- nitin
>> If you're really worried about it, you might investigate ways
to have
>> TCP estimate higher order moments of the rtt distribution
beyond the
>> 0th (mean) and 1st (mdev, approximately sdev). Dunno if that
would
>> really help, but some simulations would tell.
>>
>> Phil
>>
>>
>>
>>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST