Subject: [tcpm] Variable "recover" in F-RTO

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 05 Mar 2009 11:37:33 +0100

Dear all,

I have an understanding problem with aforementioned variable "recover"
in the current version (http://www.tools.ietf.org/html/draft-ietf-tcpm-rfc4138bis-04 
)
of the F-RTO Algorithm.

Section 2.1 The Algorithm (F-RTO, Reno/NewReno Case)

Step 2): When the first ACK after RTO rexmit arrives at the TCP Sender,
we store the highest sequence number transmitted so far in the variable
"recover".

then

Step 2a) Check if the ACK from Step 2) is a DUPACK OR the ACK covers
"recover" but not more than "recover"...

Why is the check like this? IMHO we can only get an ACK that cover  
exactly "recover"
(Lost Retransmission - SIGCOM Paper Section 4.2) or an ACK that cover  
less than
"recover", but we cannot get ACK that cover more than "recover".

Alex

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 24 Mar 2009 07:21:51 -0700

Hi Alex,

Sorry that it took this long to reply.

The condition 'but not more than "recover"' is there just to cover  
the case of invalid ACKs arriving for some strange reason, and in  
such case revert to normal TCP operation, to be on a safe side. In a  
well-behaving environment one should not receive such an ACK.

- Pasi

On Mar 5, 2009, at 2:37, ext Alexander Zimmermann wrote:

> in the current version (http://www.tools.ietf.org/html/draft-ietf- 
> tcpm-rfc4138bis-04)
> of the F-RTO Algorithm.
>
> (Lost Retransmission - SIGCOM Paper Section 4.2) or an ACK that  
> cover less than