Nitin,
The minimum margin we observed from experiments is ~ .5RTT . The fact
that RTT is large (due to queuing delay) allows lot of slack for
retransmissions to happen without spurious timeouts.
Sanjoy
-----Original Message-----
From: Nitin H Vaidya [SMTP:vaidya@cs.tamu.edu]
Sent: Thursday, February 11, 1999 2:28 PM
To: Sen, Sanjoy [RICH2:2S52:EXCH]
Cc: pilc@lerc.nasa.gov
Subject: RE: LL ARQ on LD links [was: PILC: prioritization]
>> 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