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

Ted Faber wrote:
> On Thu, Dec 08, 2005 at 04:51:13PM -0800, Fernando Gont wrote:
> 
>>At 02:28 p.m. 08/12/2005, Ted Faber wrote:
>>
>>
>>>>>Do you mean there are no cases where application semantics can change 
>>>
>>>as a
>>>
>>>>>result of using this option.
>>>>
>>>>The application should care about application-layer timeouts, not about
>>>>transport-layer timeouts.
>>>
>>>TCP provides an interface that the application can use to set this
>>>timeout in RFC793.  Breaking applications that made use of it should not
>>>be done lightly, even if there are alternative mechanisms that those
>>>applications could have used.
>>
>>Agreed.
>>
>>But we agreed that the application-specified UTO would take precedence. And 
>>that, in the event a system-wide toggle existed, it would default to off.
>>
>>So if you were using UTO, either the application programmer or the system 
>>administrator decided to do so.
> 
> 
> I think you mean that if you're using UTO negotiation it's because of an
> active decision, which is IMHO, correct.
> 

> 
>>(From a theoretical point of view, I'd probably argue that an application 
>>that really *breaks* because the user timeout ends up being longer than 2 
>>minutes or whatever, then it's already broken.  And, even then, we have
>>higher and lower limits for the UTO, which one would hope will keep the UTO 
>>"within acceptable values". But well, as I pointed out above, this would 
>>not even be the case.)
> 
> 
> If you're arguing that implementation of the user timeout is more likely
> to be flaky than more core features of the protocol, I agree.  Relying
> on the urgent pointer has similar practical issues.  So does relying on
> the UNIX sleep or usleep timers.
> 
> The mechanism described in 793 and 1122 is a perfectly reasonable
> definition of a timeout system that an application could use to take
> action if data's not delivered in a timely fashion.  In a system where
> those mechanisms are implemented to spec, I don't see why using them
> would break an application.  And that seems to be what you're saying.
> 

I agree - my concern was application of a SMALLER value (from the remote 
end) than currently defined by standard mechanism - and the impact this 
could have on an unsuspecting application.

Gorry

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