Re: TCP end-to-end Semantics

From: Jacob Heitz (jheitz@eng.ascend.com)
Date: Tue Jan 09 2001 - 10:45:36 EST

  • Next message: Anil Agarwal: "Re: TCP end-to-end Semantics"

    I, the application, expect from you, TCP, the following:

    When my peer application has received all the data I sent
    in order and uncorrupted AND I have received all the data
    the peer application has sent to me in order and uncorrupted,
    I expect a successful Close-Indication from you. If an
    unrecoverable error occurs, I expect an Error-Indication.

    It's that simple.

    The application indicates to TCP that it has no more data
    to send with a Close-Request.

    If you, TCP, cannot make that promise, then your usefulness
    to me is greatly diminished and I need to do my own error
    detection and correction and may as well use UDP.

    Alhussein Abouzeid wrote:
    >
    > What is a system? and what are "TCP end-to-end semantics"? Where are they
    > defined?
    >
    > I think saying remote and intermediate "system" does more harm
    > than good in clarifying the issue.
    >
    > I do not think that the failure of the receiver to deliver data
    > to the application after ACKing it is a problem of the transport layer
    > anyway. If we accept layering, and we accept the end-to-end philosophy,
    > then the guarantee that a transport protocol provides is between the two
    > _transport_ end points not the two _application_ end points. Right?
    >
    > Now, there can be two ways to treat the end-to-end argument. If you (or
    > your application) are a hardliner and require that the transport
    > protocol ACK packets only if they are received at the destination, then
    > spoofing is a violation. If, on the other hand, you apply the end-to-end
    > on a "session" basis, i.e. a transport protocol will only terminate the
    > session when all packets of the session are received, then, in principle,
    > one can argue that there exists an intermediary spoofer (e.g. that
    > doesn't complete the handshake except after the reception of all packets
    > at the receiver) that will not be violating the semantics, even if it
    > plays with the data packets/ACKs to its convenience during the course of
    > the session.
    >
    > In other words, it depends on whether you define a "per packet" or a "per
    > session" semantics. I've looked, and I failed to find any substantial
    > study on how this affects the application layer. I think that it will generally
    > depend on the application.
    >
    > My 6 piastres (= 2 cents)
    >
    > -Hussein.
    >
    > On Mon, 8 Jan 2001, Craig Partridge wrote:
    >
    > >
    > > In message <200101082207.XAA74699@info.iet.unipi.it>, Luigi Rizzo writes:
    > >
    > > >> You're right, spoofing ACKs does violate TCP semantics. Some folks argue
    > > >> that if their intermediate node, that spoofs ACKs, also buffers data then
    > > >> you're safe, but they're wrong -- as the intermediate could fail.
    > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > > >
    > > >how is this different from what you say next
    > > >
    > > >> guarantee that your data reached the remote system. This guarantee, however
    > > >,
    > > >> is only for the end system -- it does not say the end application received
    > > >> the data (it may never read it).
    > > >
    > > >i.e. how is your "remote system" different from any intermediate in the
    > > >way -- you may have a better chance of detecting its failure, but no
    > > >guarantees, anyways. The receiving end could well be an on-board CPU+memory
    > > >on the network card (for however a bad idea this can be) and go
    > > >equally unnoticed.
    > > >
    > > >Maybe we could say some intermediate device violates semantics iff
    > > >there is a procedure that deterministically (or with very high
    > > >probability) makes it behave differently from an implementation on
    > > >the end-system ?
    > >
    > > Hi Luigi:
    > >
    > > That's an astute point, thanks!
    > >
    > > The answer is that I view the probability of failure as part of the TCP
    > > semantics. That is, TCP says it provides connectivity between two end
    > > points ("reliable inter-process communications between pairs of
    > > processes in host computers...").
    > >
    > > My view is that means that TCP's host-to-host behavior is a function solely
    > > of the two end points. (One could also say this view is a logical consequence
    > > of the simple dumb network approach, of which IP is an example).
    > >
    > > So my second example, where the receiver could fail to deliver the data after
    > > ACKing it, in a normal TCP is solely a function of the receiver suffering
    > > one of a (fairly short) list of errors. Adding an intermediary doesn't
    > > change the receiver probability, but adds the probability of the failure
    > > of the intermediary. So the probability of failure is now different from
    > > what it was if just the two hosts were involved.
    > >
    > > Thanks for an insightful question and I'll be interested to know what
    > > you think of my reply :-)
    > >
    > > Craig
    > >



    This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 11:33:33 EST