Re: [tcpm] Re: draft-ietf-tcpm-rfc4138bis-00

" Ilpo Järvinen " <> Wed, 26 September 2007 13:53 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IaXK8-00052q-CX; Wed, 26 Sep 2007 09:53:08 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IaXK7-0004fV-Bv for; Wed, 26 Sep 2007 09:53:07 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1IaXK3-0007iN-IB for; Wed, 26 Sep 2007 09:53:04 -0400
Received: from ( []) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by with esmtp; Wed, 26 Sep 2007 16:52:45 +0300 id 000805EF.46FA642D.00004FC3
Received: by (Postfix, from userid 50795) id A6A69EAFEF; Wed, 26 Sep 2007 16:52:44 +0300 (EEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98768EAFEE; Wed, 26 Sep 2007 16:52:44 +0300 (EEST)
Date: Wed, 26 Sep 2007 16:52:43 +0300 (EEST)
From: "=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=" <>
To: Pasi Sarolahti <>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-rfc4138bis-00
In-Reply-To: <>
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_courier-20574-1190814783-0001-2"
Content-ID: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

...I shuffled it a bit.

On Tue, 25 Sep 2007, Pasi Sarolahti wrote:
> On Sep 11, 2007, at 19:15, ext Alfred HÎnes wrote:
> >Since I do not have detailed knowledge regarding the degree of
> >SACK support and actual use in the internet now, I admittedly
> >just had followed your arguments.
> >
> >But, if it turns ot that SACK will gain, or already has gained,
> >significant importance, it might indeed be reasonable to keep
> >the SACK variant of F-RTO in 4138bis.  To this end, it might be
> >useful to consider and evaluate the role of SACK for the evolution
> >of other aspects of TCP (and other transport protocols); if it
> >turns out, e.g., that SACK would be quite useful and important
> >for the expected predominant response algoritms for F-RTO anyway,
> >that should be taken as a firm indication that the SACK variant
> >of F-RTO should be left in the document.
> First, one note of clarification: a TCP that uses SACK can still use the basic
> version of F-RTO based on cumulative acknowledgements just fine. The SACK
> variant of F-RTO was intended to improve cases where duplicate ACKs (for
> reordering, for example) prevent detection of spurious RTO with the basic
> algorithm. To my understanding such cases are quite rare, so the additional
> benefit might not be too significant.

Also if there's a loss very close after the delayed packet, SACK version 
can first detect RTO as spurious and then TCP recovers after three 
dupacks. How likely that is, I don't know.

> Also, the SACK version of F-RTO has not been included in all 
> implementations that have the basic version
> (for example Linux distribution has had only the basic version).

...That's only partially valid because since 2.6.22 Linux has included 
both versions (though both off by default). Its SACK version includes 
features discussed in 4138's Appendix B. From 2.6.24 onward it will 
enable SACK version by default.

> I have started to hesitate with my opinion on the SACK variant. We proposed
> dropping out the SACK variant from the 4138bis draft, because it seemed that
> it has not been as thoroughly analyzed as the basic F-RTO.
> However, after I mentioned about dropping SACK in the Chicago presentation, it
> turned out in the hallway discussions that there are implementations of the
> SACK variant in real use. So if it seems that the consensus is for keeping the
> SACK variant in 4138bis, that's fine with me as well. I'd be happy to hear
> more comments on this!

Quite clearly using SACK blocks improves FRTO's accuracy in detection as 
they are rather strong indication what really arrived. However, it adds 
some challenges to aggressive response usage because then lying in SACK 
blocks should also be addressed in Security Considerations, especially as 
"because the sender will have an incorrect state, it cannot retransmit 
the segment that has never reached the receiver" does not hold like it 
does with SND.UNA. Yet, as long as FRTO is accompanied with a conservative 
response, I don't see how the receiver could have meaningful benefits from 
lying, whereas unnecessary retransmissions are more accurately mitigated.

tcpm mailing list