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

Lars Eggert <lars.eggert@nokia.com> Wed, 30 May 2007 07:32 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIfd-0002ye-Q7; Wed, 30 May 2007 03:32:37 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIfR-0002td-DY for tcpm@ietf.org; Wed, 30 May 2007 03:32:26 -0400
Received: from smtp.nokia.com ([] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtIfP-00005A-Ip for tcpm@ietf.org; Wed, 30 May 2007 03:32:25 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com []) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U7VpJN020407; Wed, 30 May 2007 10:32:07 +0300
Received: from esebh103.NOE.Nokia.com ([]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:32:00 +0300
Received: from mgw-int02.ntc.nokia.com ([]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:32:00 +0300
Received: from [] (esdhcp034150.research.nokia.com []) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U7VwEA023532; Wed, 30 May 2007 10:31:59 +0300
In-Reply-To: <200705291836.UAA04625@TR-Sys.de>
References: <200705291836.UAA04625@TR-Sys.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <8F01E60D-5498-4A5A-A23C-03C615EC2A17@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Wed, 30 May 2007 10:31:49 +0300
To: ext Alfred HÎnes <ah@tr-sys.de>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 30 May 2007 07:32:00.0282 (UTC) FILETIME=[9C2F5FA0:01C7A28C]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: tcpm@ietf.org, ext Fernando Gont <fernando@gont.com.ar>
Subject: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05
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="===============0029511750=="
Errors-To: tcpm-bounces@ietf.org


On 2007-5-29, at 21:36, ext Alfred HÎnes wrote:
> eventually, I have found some time to study your updated UTO
> draft, draft-ietf-tcpm-tcp-uto-05, and would again like to
> submit a few comments.

we appreciate your comments!

> (1)
> I appreciate the changes incorporated (including editorial
> suggestions I had sent for -04).
> In particular, IMHO the newly introduced formalization of the
> TCP behaviour, using the ENABLED and CHANGEABLE flags, has
> clarified and simplified the presentation.
> Yet, as an aid to implementors, I suggest to use more specific
> names that can be easily carried over unchanged into
> implementations and/or APIs without danger of name collisions;
> to be constructive, I suggest:
>    ENABLED     -->  TCP_USE_UTO
> and, to achieve more generic naming, also:
> For the same reasons it might be useful to change the names of
> the configuration variables in Section 3.1 as well, e.g.:
>    U_LIMIT    -->   TCP_UTO_MAX
>    L_LIMIT    -->   TCP_UTO_MIN

This has been suggested before, but I think it was in an off-list email.

Implementors are free to choose whatever variable names they like for  
their implementation - there is no expectation that these names will  
be used as-is. For example, RFC2581 and RFC2988 define similar state  
variables, for which implementations also choose different names.

For this reason I'm unconvinced that renaming the state variables is  
necessary. (At the very least, I wouldn't want to add the "TCP_"  
prefix. If the WG thinks some of the other name changes clarify  
things, I could be convinced to go with it.)

> W.r.t. the granularity of the UTO configuration (cf. second-to-
> last paragraph of Section 3.1), I had suggested to mention the
> possibility of configuration *per-interface* because knowledge
> of the first-hop link technology and its characteristics might
> perhaps be an incentive for implementations to adapt the UTO
> defaults and limits in a very user-friendly way, without specific
> manual configuration or knowledge (to be) built into applications.
> I cannot imagine support of "per-host" (better: "per-peer" ?)
> or "per-user" granularity without very specific (usually manual)
> configuration.
> Has this proposal been overlooked, or are there arguments against it?

Hm - we may have overlooked this suggestion. I'm fine with adding  
"per-outgoing-interface" to the list in that paragraph:

   Note that these limits MAY be specified as system-wide constants or
   at other granularities, such as on per-host, per-user, per-outgoing-
   interface or even per-connection basis.

> (2)
> The modified text uses the wording "UTO options" at several
> places (in particular, repaetedly in Section 3, twice in
> Section 3.2, and three times in Section 4.1).
> IMHO, this is a bit confusing, as you define only a single
> UTO option (i.e. option code and option format).
> I therefore propose to change "UTO options" in most places
> to "the UTO option", e.g. (near the end of Section 3):
>    A TCP implementation that does not support UTO options MUST  
> silently
>    ignore them [RFC1122], thus ensuring interoperability.
> ---
>    A TCP implementation that does not support the UTO option MUST
>    silently ignore it [RFC1122], thus ensuring interoperability.

I think this is a very minor point. Yes, there is only one type of  
UTO option, but during the lifetime of a connection, many UTO options  
may be exchanged.

> (4)
> The new wording at the end of 4.1 almost 'invites' middleboxes
> to modify the UTO.  This should be avoided!
> Such changes are obstructions to end-to-end transparency and security.
> If you leave this suggestion in the draft, you will have to deal
> with various IAB concerns !

Good point. The "or the option contents" part is problematic. Suggest  
to rephrase that paragraph to:

   Stateful firewalls usually time out connection state after a  
period of
   inactivity.  If such a firewall exists along the path, it may close
   or abort connections regardless of the use of the TCP User Timeout
   Option.  In the future, such firewalls may learn to parse the TCP
   User Timeout Option and adapt connection state management  

> As usual, if it deems useful to you, please forward these notes (or
> part of it) to the TCPM list, perhaps together with your comments.

As usual, thanks for the comments! Highly appreciated.


PS: Fernando, since you have the editing token, will you incorporate  
these changes?
tcpm mailing list