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

At 09:19 a.m. 14/12/2005, Ted Faber wrote:

> > The point is that if you;re really concerned about data being delivered,
> > you should be implementing an application layer timeout mechanism.
> > If there's no TCP timeout, it does not mean that the data were delivered.
>
>I understand the difference between a transport ack and acknowledgements
>from higher layers.  Some applications (correctly!) use transport state
>to synchronize application state.

Well, I'm not sure to what extent this is "correct".

For example, if BGP connections were "decoupled" from the underlying TCP 
connection, then we'd not care about reset attacks against TCP, for 
example. (Or, well, at least we'd not be so "scared")

>Consider a file transfer appliaction that opens a TCP connection for
>each file.  The connection is closed when the file is saved to disk.  A
>transmitter knows the file has been delivered correctly if and only if
>the receiver closes its connection correctly.  The receiver knows the
>whole file has been transmitted when the sender closes its side of the
>connection (a receiver never closes its connection before a sender
>does).  Voila, application synchronization using TCP signalling.

This assumes that the underlying transport protocol allows each direction 
of the connection to be closed independently of the other.
I'd not put such a requirement on the underlying transport protocol if I 
were to design an application layer protocol.

>Such an application may well want to use TCP's existing UTO mechanism as
>a timeout.

The timeout may help in some scenarios, but still does not solve the usual 
requirement of the application layer.

If the point of using the TCP timeout is just to avoid waiting forever, 
okay. But, in the more general case of an application wanting to know what 
the result of the last command sent was, you will still need the 
application-layer thing.

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org

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