Reiner:
Thanks for the explanations.
>> From rludwig@huginn.cs.berkeley.edu Fri Jan 29 14:26:00 1999
>>
>> Thus, you are absolutely right when saying that this causes an extremely
>> conservative retransmission timer but not for the reason you give because
>> the RTT grows with the RTO and what you are really interested in is the
>> difference between the retransmission timer and the RTT. Now - at least in
>> BSD UNIX - it is important to understand that the retransmission timer is
>> _not_ the RTO (I brought that up before on this list). The reason for the
>> latter is that every ACK for new data re-starts the retransmission timer
>> with the RTO. As a consequence the retransmission timer is always off by
>> roughly one RTT. That's the main reason why the retransmission timer will
>> be _really_ conservative when you have an overbuffered bottleneck link.
Hmm ... good point, I had not thought of this one.
In this case, my other posting today on some wacky ideas to deal
with the timeout issue may be worth ignoring. If the retransmit
timeout occurs after an extra RTT, as you observe, there is no
need for any other mechanisms to inflate it (as I was trying
to argue for in my other e-mail).
>> To finally answer your question and your above concern: Yes, we also
>> measured with much smaller interface buffers (3, 4, and 5) but still didn't
>> "catch" any spurious timeouts. The main reason lies in the
>> hyper-sensitivity of RTO and the fact that the retransmission timer is
>> always off by ~ 1 RTT as explained above. Not so much the frequently quoted
>> coarse grained (500 ms) BSD timers although that certainly adds to it.
>>
>> In a soon to be finished paper we will give the corresponding analysis to
>> back this up.
OK. I look forward to it.
Cheerio.
- nitin
>>
>> >(By a similar argument, the impact of RLP link resets
>> >may become smaller at smaller window sizes, as
>> >compared to what you observe.)
>>
>> This is certainly very true. With much smaller interface buffers = much
>> smaller windows the impact of RLP link resets would by far not be that
>> devastating. But again, that's what you get when you take "standard"
>> equipment. And note that RLP link resets are A. super rare and B. can be
>> prevented with a simple AT command that bumps up the maximum number of
>> retransmissions before the RLP sender resets the link.
>>
>> What I would be really like to know is how big the interface buffer in the
>> PalmPilot or a W95 or WinCE box is. Venkat?
>>
>> ///Reiner
>>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST