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

On Fri, Dec 16, 2005 at 10:32:00AM -0800, Fernando Gont wrote:
> 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".

Correct is hard to dispute.  If TCP behaves properly and the application
behaves as I specified, both ends know if the transfer succeeds or
fails; that's correct.

I think you mean that you find it distasteful. :-)  I can't argue with
that.

> 
> 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")

I understand that you can incorrectly use code an application using TCP.
That doesn't mean you can't code an application that uses it correctly.

> >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.

That's why I identified the transport as TCP, which has this property.
The inclusion of that property is intentional.  Depending on
non-existant properties is certainly a bad design. :-)

> I'd not put such a requirement on the underlying transport protocol if I 
> were to design an application layer protocol.

There are good reasons for an engineer not to design an app the way I
suggested.  I don't think it's particularly clean myself, but I do think
it's correct and I do think it's done.  And it has the benefit of not
having to redesign TCP's state synchronization machinery at the
application.

> 
> 
> >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.

Again, I'm not arguing that all applications must be designed the way I
layed out.  There are certainly applications that can't be.  You said
that the app must be broken w/o additional application layer processing,
which I took to mean that breaking applications w/o that processing by
changing UTO semantics was acceptable to you.  I presented a single
instance of an application that used TCP signalling to signal
application level state as a counter example.  I just want those sorts
of applications taken into account when we discuss UTO changes.  That's
my whole point.

-- 
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