Some quotation from RFC793:
[page 2]
"Some computer systems will be connected to networks via
front-end computers which house the TCP and internet protocol layers,
as well as network specific software. The TCP specification describes
an interface to the higher level protocols which appears to be
implementable even for the front-end case, as long as a suitable
host-to-front end protocol is implemented."
[page 8]
"The mechanisms of TCP do not preclude implementation of the TCP in a
front-end processor. However, in such an implementation, a
host-to-front-end protocol must provide the functionality to support
the type of TCP-user interface described in this document."
I think, we should differentiate between protocol semantic and interface
semantic.
From an application point of view not the TCP semantic
alone is important but also the semantic of the interface the
application uses to
communicate with the protocol stack.
Of course, when the acknowledgments are sent by some intermediate host
the meaning of
the acknowledgment has changed to some extent. If we would use an
application-network interface in which a "write-call" would return only
when the data are acknowledged by the peer TCP, then this semantic might
have some impact on the application design (although this gives
the sender no guarantee that the data was consumed by the destination
application).
Using the Berkeley socket interface the socket calls to send data return
when TCP has accepted the data for delivery (fits into the send-buffer,
assuming blocking mode). The
application is not informed about the success or failure of delivery. It
is even allowed to
close the socket after passing some data to the socket.
Although I agree, that the crash probability is increased when an
intermediate host is used, there is no difference for the application
whether the acknowledgments are sent by the destination host or an
intermediate host. If it wants to implement a reliable data transfer it
must implement its own mechanisms.
The only possibility for the application to know about the status of the
data delivery
is to use the linger option. This option moves the important role to the
fin packet, which should not be acknowledged by the intermediate host
until all data are received by the final destination host (which still
is no guarantee that the data was consumed by the application).
I think, Hussein, this goes somehow in the same direction as your per
packet and per session semantic definition?
Best regards,
Morten
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
> >
-- ------------------------------------------------------------------------ Morten Schl�ger Tel.: ++49 (030) 314-23834 Technical University Berlin Fax.: ++49 (030) 314-23818 Telecommunication Networks Group (TKN) morten@ee.TU-Berlin.DE Sekr. FT 5-2/Einsteinufer 25 10587 Berlin, Germany
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 05:26:31 EST