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

Pasi Sarolahti <pasi.sarolahti@nokia.com> Mon, 01 October 2007 14:17 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcM5q-0004ht-Gd; Mon, 01 Oct 2007 10:17:54 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcM5p-0004eH-Pr for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 10:17:53 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcM5p-0004aw-D1 for tcpm@ietf.org; Mon, 01 Oct 2007 10:17:53 -0400
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcM5o-0004W2-Pm for tcpm@ietf.org; Mon, 01 Oct 2007 10:17:53 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l91EHg9D010915; Mon, 1 Oct 2007 17:17:50 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:16:36 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:16:36 +0300
Received: from [172.21.39.141] ([172.21.39.141]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:16:35 +0300
In-Reply-To: <Pine.LNX.4.64.0709261511080.5141@kivilampi-30.cs.helsinki.fi>
References: <200709111615.SAA24923@TR-Sys.de> <C3905EB6-9039-4EB2-8AE4-107101B9C444@nokia.com> <Pine.LNX.4.64.0709261511080.5141@kivilampi-30.cs.helsinki.fi>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <4018CF28-82C9-4089-AD77-A3EA0FACB137@nokia.com>
Content-Transfer-Encoding: quoted-printable
From: Pasi Sarolahti <pasi.sarolahti@nokia.com>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-rfc4138bis-00
Date: Mon, 1 Oct 2007 17:15:42 +0300
To: =?ISO-8859-1?Q?ext_Ilpo_J=E4rvinen?= <ilpo.jarvinen@helsinki.fi>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 01 Oct 2007 14:16:35.0340 (UTC) FILETIME=[AC7844C0:01C80435]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: =?ISO-8859-1?Q? ext_Alfred_H=CEnes ?= <ah@tr-sys.de>, tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

On Sep 26, 2007, at 16:52, ext Ilpo Järvinen wrote:

>> 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.

So I had outdated information. Thanks for keeping us updated!

Ok, we were too hasty in removing the SACK variant from the draft.  
The feedback so far, on and off the mailing list, seem to be in favor  
of keeping it. We'll add it back for the next version.

> 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.

This reminds me of another issue mentioned in the Chicago meeting  
that might deserve discussion: what should we say about the response  
in rfc4138bis? The current draft refers to the Eifel Response and to  
draft-allman-rto-backoff as possible response algorithms, but also  
says that if neither of these is implemented, the TCP sender should  
respond conservatively to spurious timeout, applying the TCP  
congestion control specification. I wonder if people prefer more  
definite words here about the response, or is it just enough to refer  
to the known choices, as we now have done. What you say above seems  
to indicate that at least with SACK we might want to prefer a  
conservative response.

- Pasi



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm