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

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:

> 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,
> 
> -- 
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm