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

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 20 Sep 2006 17:06:31 +0100

Fernando,

Thanks for generating a new revision,  and appologies for taking a 
little while to get back to you on the changes that you made.

It seems you have responded to most (if not all) my substantial 
comments,  and also tightened the
language, I like these improvements, and to me, this seems much safer in 
this respect.

I would like to check one point:
Section 3.1:

/Very short user timeout values can affect TCP transmissions over
high-delay paths.  If the user timeout occurs before an
acknowledgment for an outstanding segment arrives, possibly due to ..../

- This rev of the draft also includes a change to mandate the  minimum 
value to be at least the RTO value, which should at least help in this case?

and note two minor NiTs below.

Best wishes,

Gorry

---

End of section 1:

I think phrase below is good guidance, but could be strengthened:
/If such a system-wide toggle were provided, it would default to "off".

Perhaps some text something like:

An implementation that provides a system-wide toggle, should assign the 
default value to disable this feature.
---

/It must be noted that the two endpoints of the connection will not   
necesarilly adopt the same user timeout./

- Could be better worded, but agreed.

----

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Sep 2006 17:23:44 -0300

Gorry,

Thanks so much for your comments. You'll find my responses inline....

>language, I like these improvements, and to me, this seems much 
>safer in this respect.
>
>- This rev of the draft also includes a change to mandate 
>the  minimum value to be at least the RTO value, which should at 
>least help in this case?

Agreed. However, the document argues to enforce a minimum *L_LIMIT* 
value of at least one RTO, with L_LIMIT being a parameter of the 
RECOMMENDED (ie, not mandatory) scheme for selecting the user timeout.

So two possible ways to fix this would be:

a) State that the minimum allowed value for the user timeout is one 
RTO (in any case.... not just in the recommended scheme)
b) Make the recommended scheme mandatory.

I would personally argue in favour of (a). But well, opinions are welcome.

>An implementation that provides a system-wide toggle, should assign 
>the default value to disable this feature.

How about:
"An implementation that provides a system-wide toggle, SHOULD assign 
the default value to disable this feature"
(ie, RFC2119 speak)

>- Could be better worded, but agreed.

Any suggestions?

Thanks so much!

Kindest regards,

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Sep 2006 21:04:14 -0700

...
> "An implementation that provides a system-wide toggle, SHOULD assign the
> default value to disable this feature"
> (ie, RFC2119 speak)

It would be useful to omit the comma. It doesn't parse otherwise ;-)

"An implementation that provides a system-wide toggle SHOULD assign the
 default value to disable this feature"

However, this still reads oddly; I'd prefer:

"If an implementation provides a system-wide toggle to enable/disable
UTO, that toggle SHOULD be initialized to disable UTO."

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Sep 2006 08:35:46 -0300

>UTO, that toggle SHOULD be initialized to disable UTO."

Okay, taken.

Thanks!

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 Sep 2006 17:42:21 +0100

Fernando Gont wrote:

>> language, I like these improvements, and to me, this seems much safer 
>> in this respect.
>>
> a) State that the minimum allowed value for the user timeout is one RTO 
> (in any case.... not just in the recommended scheme)
<snip>

It is only necessary to mandate an algorithm, if things break without 
it. This doesn't seem to be what you are saying, so I'd suggest (a) too.

I'd prefer to say that the used value MUST be larger than the measured 
RTO. So does that imply if RTO increases above the current user time out 
that something needs to happen, we need to get the correct language 
here. Any suggestions?

Gorry

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Sep 2006 23:15:11 -0300

At 13:42 26/09/2006, Gorry Fairhurst wrote:

>It is only necessary to mandate an algorithm, if things break 
>without it. This doesn't seem to be what you are saying, so I'd 
>suggest (a) too.

Agreed. Will update the draft accordingly, then.

>I'd prefer to say that the used value MUST be larger than the 
>measured RTO. So does that imply if RTO increases above the current 
>user time out that something needs to happen, we need to get the 
>correct language here. Any suggestions?

I think there are two possible ways to go here:

a) Enforcing a minimum UTO of a RTO only when *choosing* the UTO. 
(i., connections establishment, API call from the application, or 
receipt of an UTO from the remote endpoint). After all, the UTO is 
meant more to increase the User Timeout than to decrease it 
(therefore, users are expected to use long UTOs, rather than short 
ones). And this keeps things simple...

b) Everytime the RTO is updated, it should be rounded to the next 
higher value in seconds. If the current User Timeout is less than 
this value, the User Timeout should be updated, and an UTO should be 
sent to the remote TCP endpoint. This is probably "the right thing to 
do". But makes things a little more complicated.

Any thoughts?

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Sep 2006 23:15:11 -0300

Any thoughts?

Kindest regards,

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 28 Sep 2006 21:56:31 +0100

You're correct.

My concern on this issue was always what happened when a host used first 
a short delay path and an app chose a short UTO. The host/path then 
changed to to one that had very significant delay.

So, I believe that (a) is a MUST - things break quickly if you do this, 
and it should not be made this way.

(b) Seems perfectly valid, but could be troublesome to mandate to implement.

So... just to backtrack to an earlier discussion on this: Using the 
recommended algorithm you say" Consequently, the lower limit (L_LIMIT) 
SHOULD be set to at least 100 seconds." Is there a reason why we don't 
specify a required minimum UTO value for all cases? A value of 100 
seconds seems big for an RTO, over a normal Internet path.

Gorry

Fernando Gont wrote:

>> RTO. So does that imply if RTO increases above the current user time 
>> out that something needs to happen, we need to get the correct 
>> language here. Any suggestions?
> 
> 
> a) Enforcing a minimum UTO of a RTO only when *choosing* the UTO. (i., 
> connections establishment, API call from the application, or receipt of 
> an UTO from the remote endpoint). After all, the UTO is meant more to 
> increase the User Timeout than to decrease it (therefore, users are 
> expected to use long UTOs, rather than short ones). And this keeps 
> things simple...
> 
> b) Everytime the RTO is updated, it should be rounded to the next higher 
> value in seconds. If the current User Timeout is less than this value, 
> the User Timeout should be updated, and an UTO should be sent to the 
> remote TCP endpoint. This is probably "the right thing to do". But makes 
> things a little more complicated.
> 
> Any thoughts?
> 
> Kindest regards,
> 
> -- 
> Fernando Gont