Subject: Question/idea on retransmition Times.

From: "Kevin Cross" <[email-masked]>
Date: Mon, 07 Oct 2002 16:08:08 +1200 (NZST)

Hi all,
I have a question about retransmition timers.
The question is does each segment that is transmitted need a separate 
timer. 

The reason I ask this is what if the RTT changes between segments ie a 
burst of congestion which bumps up the RTT. Should the timers beyond the 
oldest segment (the timer that is closest to going off) be adjusted to the 
current RTT , technically speaking, or should they stay with the old 
retransmition timers.

I think the adjusting timers may help avoid unnecessary retransmitions but 
could delay traversing into the retransmition state, causing a slow 
retransmition response. On the other hand it may create quicker 
retransmitions if a packet is lost once coming off a heavily traffic 
period when the old RTT was very high.

So the implementation of this would mean that you only have one timer and 
a queued sequence of sent segments with time stamps. Once the first 
segment in the queue is acked the timer is cleared, the RTT calculated, 
then the current rtt is used to calculate the time and set the next 
retransmition timer. The time calculation would be along the lines of 
(current RTT) - (the time since the segment was transmitted). 

I do not know what the implications of this approach would be, can anyone 
postulate the implications?

Ps: RTT meaning Round trip time ( I'm sure you all know that ).

cheers,
An inquisitive developer.

Kevin Cross
-----------------------------------------------------------
--
Kevin Cross
Software Engineer
Allied Telesyn
-----------------------------------------------------------
--

---

From: Neil Spring <[email-masked]>
Date: Sun, 6 Oct 2002 23:11:26 -0700

> The question is does each segment that is transmitted need a separate

In the words of Mark Allman [1],

RFC 2988

> So the implementation of this would mean that you only
> have one timer and a queued sequence of sent segments with
> time stamps. Once the first segment in the queue is acked
> the timer is cleared, the RTT calculated, then the current
> rtt is used to calculate the time and set the next
> retransmition timer. The time calculation would be along
> the lines of (current RTT) - (the time since the segment
> was transmitted).

Your proposal is only a minor change from 2988, where the
timer is set to expire after RTO + now.  Note that in the
absence of SACK, the sender has no information about whether
the packet after the one that timed out was received, so it
would be premature to retransmit it without leving time for
the ack-of-retransmit.

-neil
[1] http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/2849.html