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

[Lars Eggert <[e-mail]>]

Hi,

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
>
>    CHANGEABLE  -->  TCP_ACCEPT_UTO
>
> and, to achieve more generic naming, also:
>
>    LOCAL_UTO   -->  TCP_LOCAL_UTO
>
> 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  
accordingly.

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

Lars

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

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm