>> 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