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

Fernando Gont <> Wed, 30 May 2007 11:30 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HtMNn-0005MQ-6S; Wed, 30 May 2007 07:30:27 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HtMNm-0005LU-Fy for; Wed, 30 May 2007 07:30:26 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1HtMNl-0007eO-TW for; Wed, 30 May 2007 07:30:26 -0400
Received: from ( []) by (Postfix) with ESMTP id 86E5DF0C423; Wed, 30 May 2007 08:30:25 -0300 (ART)
Received: from ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id l4UBUJqN019465; Wed, 30 May 2007 08:30:23 -0300
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 30 May 2007 08:22:00 -0300
To: Lars Eggert <>, ext Alfred HÎnes <>
From: Fernando Gont <>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 ( []); Wed, 30 May 2007 08:30:25 -0300 (ART)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc:, ext Fernando Gont <>
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: <>, <>

At 04:31 a.m. 30/05/2007, Lars Eggert wrote:

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

I agree with Lars here.

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

Will commit this into the draft.

>>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
>>    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 agree that in a few instances the use of "UTO options" may be a 
little bit confusing. Will try to change the text as suggested.

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

Will commit this change.

>PS: Fernando, since you have the editing token, will you incorporate
>these changes?


Alfred: Let us know if the text suggested by Lars addresses your 
comments. Once again, thanks so much for your thorough review!


Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

tcpm mailing list