Subject: Re: [tcpm] WGLC for UTO (fwd)

From: Alfred Hönes <[email-masked]>
Date: Tue, 13 Nov 2007 11:15:32 +0100 (MEZ)

----- Forwarded message from Alfred Hönes -----

> From: Alfred Hönes <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> In-Reply-To: <[email-masked]> from Lars Eggert at Nov "13, 2007 10:22:40" am
> Message-Id: <[email-masked]>
> Date: Tue, 13 Nov 2007 10:56:36 +0100 (MEZ)
> Subject: Re: [tcpm] WGLC for UTO

> On Tue, 13 Nov 2007 10:22:40 +0200, Lars Eggert wrote:
>> Hi,
>> 
>> FYI, I'll shortly submit my working copy as -07.
>> 
>> Thanks to the new submission system, it will be a simple thing to
>> push out an -08 revision before the cutoff, if the WG would like to
>> see further changes.
> 
> Indeed, both: it was nearly instantaneous, and I have a few more nits.
> 
> 
> (1)  Section 3
> 
> I'm still not content with the delineation between "USER TIMEOUT"
> and "USER_TIMEOUT" -- the latter being the per-connection
> instantiation (TCB variable) of the former, according to the first
> hanging list entry in Section 3.
> 
> Accordingly, in the last list entry, the second instance of
> "USER_TIMEOUT" should be changed to "USER TIMEOUT".
>                                                          v
>    CHANGEABLE (Boolean)
> |     Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT
>       parameter) may be changed based on an UTO option received from the
>       other end of the connection.  Defaults to true and becomes false
>       when an application explicitly sets USER_TIMEOUT.
> ---                                                      v
>    CHANGEABLE (Boolean)
> |     Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT
>       parameter) may be changed based on an UTO option received from the
>       other end of the connection.  Defaults to true and becomes false
>       when an application explicitly sets USER_TIMEOUT.
> 
> The second-to-next paragraph, starting
> 
>    Before opening a connection, ...
> 
> explicitely deals with setting the per-connection variables (in
> the TCB, presumably by a suitable extension to the socket API).
> Hence, it should refer to setting the "USER_TIMEOUT".
> So please change:
>                    vvvvvvvvvvvvvvvv
>                                      [...].  If an application
> |  explicitly sets the USER TIMEOUT, CHANGEABLE MUST become false, to
>    prevent UTO options from the other end to override local application
>    requests.  [...]
> ---                vvvvvvvvvvvv
>                                      [...].  If an application
> |  explicitly sets USER_TIMEOUT, CHANGEABLE MUST become false, to
>    prevent UTO options from the other end to override local application
>    requests.  [...]
> 
> 
> (2)  Section 3.1
> 
> Below the recommended formula and the explanation of its terms,
> the draft now says:
> 
>    The RECOMMENDED formula results in the maximum of the two advertised
>    values to be adopted for the user timeout of the connection on both
> |  ends, provided they are within the upper and lower limits.  [...]
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> This might be misunderstood as referring to a *conditional* assignment,
> only to be performed when this precondition is met; but the formula
> describes an *unconditional* assignment, and a two-sided clipping
> operation on the right-hand side.
> That might be better reflected by saying:
> 
>    The RECOMMENDED formula results in the maximum of the two advertised
>    values to be adopted for the user timeout of the connection on both
> |  ends, after clipping to the preset upper and lower limits.  [...]
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Please also consider replacing the newly introduced "preset" by "local"
> if you want to emphasize the fact that these limits are indeed a local
> matter, which means that the values adopted on the two ends of the TCP
> connection might well be different:
> 
>    The RECOMMENDED formula results in the maximum of the two advertised
>    values to be adopted for the user timeout of the connection on both
> |  ends, after clipping to the local upper and lower limits.  [...]
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I have tried to find a short phrase not expanding the text further;
> I you prefer, chose more verbose wording.
> 
> 
> Kind regards,
>   Alfred.
> 
> -- 
> 
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
> +------------------------+--------------------------------------------+

----- End of forwarded message from Alfred Hönes -----

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Nov 2007 11:00:59 +0200

>> hanging list entry in Section 3.

I've made the changes you suggest.

>> |  ends, provided they are within the upper and lower limits.  [...]

I've rephrased that as: "The RECOMMENDED formula results in the  
maximum of the two advertised values, adjusted for the configured  
upper and lower limits, to be adopted for the user timeout of the  
connection on both ends."

I'll shortly submit -08 with these fixes, so that we have an up-to- 
date version to discuss at the IETF.

Lars