Nitin,
I checked the TCP code and it certainly DOES reset the retx timer on
every new ACK. This certainly helps in avoiding spurious timeouts. Is this
kind of implementation true for other TCP code implementations ?
Even for a TCP tick of 100 ms, the observed margin is about 300 ms under
no air link errors, and this spruces up quite a bit once there're some burst
errors (common in radio links) and retransmissions. With 500 ms TICK, its
even higher. All these are greater than our configured radio link RTT.
Best,
Sanjoy
-----Original Message-----
From: Nitin H Vaidya [SMTP:vaidya@cs.tamu.edu]
Sent: Thursday, February 11, 1999 2:51 PM
To: Sen, Sanjoy [RICH2:2S52:EXCH]
Cc: pilc@lerc.nasa.gov
Subject: RE: LL ARQ on LD links [was: PILC: prioritization]
Sanjoy:
>> 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.
By the way, I now remember Reiner's explanation, which
probably also explains your observations.
He noted that when TCP sender receives an ack for a timed
packet, the timeout is reset (to its original value)
to time the next unack'd packet. This results in a much
larger timeout interval for the the next packet, allowing
plenty of slack for retransmits.
- nitin
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST