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?
The E2E argument makes assertions about the differences
between composing services (e.g., ACKs here) or not.
The ultimate effect of that would be applications that
write IP packets.
We tend to accept some slack inside the endhost as a tradeoff.
> 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.
The problem is that the end system can THINK all the packets have been
received, and have a different set of packets than were sent.
(see the earlier example I posted - where the spoofer ACKs,
the source window rolls-around, and then the path changes).
Joe
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 13:31:29 EST