Re: [tcpm] draft-ietf-tcpm-tcp-uto-02

Ted Faber <faber@ISI.EDU> Fri, 09 December 2005 00:19 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVyy-0000o6-HW; Thu, 08 Dec 2005 19:19:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVym-0000mc-6J for tcpm@megatron.ietf.org; Thu, 08 Dec 2005 19:19:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11028 for <tcpm@ietf.org>; Thu, 8 Dec 2005 19:18:11 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVyf-0003GJ-2B for tcpm@ietf.org; Thu, 08 Dec 2005 19:19:10 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8MS9r04908; Thu, 8 Dec 2005 14:28:09 -0800 (PST)
Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8MS8rZ069926; Thu, 8 Dec 2005 14:28:08 -0800 (PST) (envelope-from faber)
Date: Thu, 08 Dec 2005 14:28:08 -0800
From: Ted Faber <faber@ISI.EDU>
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02
Message-ID: <20051208222808.GB22920@hut.isi.edu>
References: <BF9BD734.4234%gorry@erg.abdn.ac.uk> <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost>
Mime-Version: 1.0
In-Reply-To: <6.2.0.14.0.20051202201002.048b5de8@localhost>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: gorry@erg.abdn.ac.uk, Lars Eggert <lars.eggert@netlab.nec.de>, tcpm@ietf.org, "mallman@icir.org" <mallman@icir.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>
Content-Type: multipart/mixed; boundary="===============1456122046=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Fri, Dec 02, 2005 at 08:37:16PM -0800, Fernando Gont wrote:
> At 06:13 a.m. 02/12/2005, Gorry Fairhurst wrote:
> >>In any case, the option will not make things any worse.
> >Do you mean there are no cases where application semantics can change as a 
> >result of using this option.
> 
> The application should care about application-layer timeouts, not about 
> transport-layer timeouts.

TCP provides an interface that the application can use to set this
timeout in RFC793.  Breaking applications that made use of it should not
be done lightly, even if there are alternative mechanisms that those
applications could have used.

IMHO, with my chair hat off.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm