At 08:14 PM 1/8/01 -0800, Alhussein Abouzeid wrote:
>What is a system? and what are "TCP end-to-end semantics"? Where are they
>defined?
TCP's e2e semantics are described in RFC 793. With respect to the
relationship to applications above TCP, it says:
Much of this document is written in the context of TCP implementations
which are co-resident with higher level protocols in the host
computer. 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.
Translation: the communication between TCP and its client applications is
"reliable" in the same sense that communication between TCPs is "reliable".
Between TCPs, "reliable" means that either the packets will be delivered
and acknowledged, or after some number of retransmission attempts TCP will
take the connection down and advise its client application of the failure.
Between TCP and its client, that communication is provided by the operating
system, and will either deliver the data or will inform both TCP and the
application that the OS link has failed. It is technically possible that
TCP could acknowledge the delivery of the data to a hung application and
exchange FIN/FIN-ACK, and then have the application die an untimely death
without fully processing the data, but the presumption is that OS failure
or application failure at that specific point is so unlikely that it is
acceptable to leave that to the application or the user to detect and correct.
If TCP is terminated somewhere else - the above text mentions front-end
processors - the clear expectation is that the communication link between
the TCP and the client remains "reliable". I think the problem that Craig
is mentioning is that when TCP Acks are spoofed, the probability of that
end case is greater - the link between the guy spoofing the Ack and the
ultimate destination is not necessarily as well guaranteed. It seems to me
that this concern can be obviated only by having the spoofer cache the data
exchanged on the connection and itself assure the delivery of the data -
retransmit.
>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?
Of course, the ultimate judge of whether the right thing happened has to be
the user of the application. But using that argument to justify failing to
deliver the data to the application does indeed significantly weaken the
legitimate expectations of the user. Per the text I quoted above, the user
can legitimately expect that if TCP says the data was delivered, the data
was indeed delivered to the application - only an OS failure or an
application failure will cause the application to not receive and consume
it. If you go on to argue that this is not a legitimate expectation, then
all applications have to have some form of reliability guarantee in them as
well.
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 16:22:34 EST