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