>> From sanjoy@nortelnetworks.com Thu Feb 11 14:20:06 1999
...
>> 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.
Larger RTT will give you a larger RTO, but not necessarily
a larger margin in RTO (i.e., RTO-RTT).
What is contributing to larger RTO-RTT is the variance.
I am somewhat uncomfortable that things seem to work
by chance - it would be nicer if things would work "provably".
If the RTO is large enough already, my suggestion would
not change the RTO at all - it will, however, inflate the
RTO when the RTO is not large enough due to happenstance.
Do you remember what the granularity of TCP timeout
in your simulations was?
I am curious if your results are valid for small RTO
granularity (i.e. timeout granularity smaller than wireless
link level RTT).
- nitin
>> 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