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

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.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG