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

From: Lars Eggert <[email-masked]>
Date: Wed, 30 May 2007 10:31:49 +0300

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 May 2007 08:22:00 -0300

>things, I could be convinced to go with it.)

I agree with Lars here.

>   interface or even per-connection basis.

Will commit this into the draft.

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

>   User Timeout Option and adapt connection state management

Will commit this change.

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

Yes.

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

Thanks!

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

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 30 May 2007 12:02:02 -0700

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Wednesday, May 30, 2007 12:32 AM
> To: ext Alfred HÎnes
> Cc: [email-masked]; ext Fernando Gont
> Subject: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05
> 
> > (1)
> >
> > 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
> >
> > 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
> 

Hmm.. The current email, (I don't see Alfred's original email on the list) is off-list as well :-)

Anyways, I suggested the same thing which Alfred is mentioning above, here is the snippet of the email exchange (actually the last one, which hopefully captures the crux) :-

============================== BEGIN EMAIL EXCH. ===================================
-----Original Message-----
From: Anantha Ramaiah (ananth) 
Sent: Wednesday, May 16, 2007 5:23 PM
To: 'Fernando Gont'; [email-masked]
Cc: Lars Eggert; Ted Faber
Subject: RE: UTO draft. 

Fernando,
   No sweat. Just leave it as it is. From what I recall, the variable names weren't that long.. Anyways, I see that when you are writing the equations, it might tend to get split up into 2 lines.
  Also Lar's point about TCP_USER_TIMEOUT is well taken as well.. 
-Anantha  

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2007 11:56 PM
> To: [email-masked]; Anantha Ramaiah (ananth)
> Cc: Lars Eggert; Ted Faber
> Subject: Re: UTO draft. 
> 
> Hi All,
> 
> One of Anantha's comments suggested to precede all variables with the 
> prefix "UTO_". I was meaning to commit the change.
> But it turns out that it results in the names of the variables being 
> terribly long, the recommended formula spanning more than one row, 
> etc.
> 
> So, unless anybody feels strong about committing this change (please 
> speak up), I will not commit it.
> 
> As pointed out by Lars, implementations are free to do this type of 
> thing internally.  (And, after all, TCP's timeout is not named 
> "TCP_USER_TIMEOUT"... and the same is true for the name of virtually 
> all variables/constants).
> 
> Thanks,
> 
> --
> Fernando Gont

=========================== END EMAIL EXCH. ================================

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

True.. But the point is to try to use some intuitive names, you don't want to chose something slike X Y Z etc., I am not saying that you have done so, simply trying to be argumentative since, IMO the above argument does seem to make sense. :-) But your other points are well taken.

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

Sure that is a good plan of action, leave it to the consensus of the WG. Anyways it is a minor thing, so no big deal, really.

-Anantha