Believe me, I'm crying with you, not at you. Somehow, perhaps in
some old education slides, the idea that routers routinely retransmit
has reached the level of an urban legend. X.25 switches do transmit,
but they are NOT routers.
Why do I get so emphatic about this? Because as long as people leap
into router based retransmission, they still haven't internalized
some the fundamental design approaches of the TCP/IP protocol suite.
From Brian Carpenter's recent summary, RFC 2775:
>2.1 The end-to-end argument
>
> This is an argument first described in [Saltzer] and reviewed in [RFC
> 1958], from which an extended quotation follows:
>
> "The basic argument is that, as a first principle, certain
> required end-to-end functions can only be performed correctly by
> the end-systems themselves. A specific case is that any network,
> however carefully designed, will be subject to failures of
> transmission at some statistically determined rate. The best way
> to cope with this is to accept it, and give responsibility for the
> integrity of communication to the end systems. Another specific
> case is end-to-end security.
>
> "To quote from [Saltzer], 'The function in question can completely
> and correctly be implemented only with the knowledge and help of
> the application standing at the endpoints of the communication
> system. Therefore, providing that questioned function as a
> feature of the communication system itself is not possible.
> (Sometimes an incomplete version of the function provided by the
> communication system may be useful as a performance enhancement.)'
>
> "This principle has important consequences if we require
> applications to survive partial network failures. An end-to-end
> protocol design should not rely on the maintenance of state (i.e.
> information about the state of the end-to-end communication)
> inside the network. Such state should be maintained only in the
> endpoints, in such a way that the state can only be destroyed when
> the endpoint itself breaks (known as fate-sharing). An immediate
> consequence of this is that datagrams are better than classical
> virtual circuits. The network's job is to transmit datagrams as
> efficiently and flexibly as possible. Everything else should be
> done at the fringes."
>
> Thus this first aspect of end-to-endness limits what the network is
> expected to do, and clarifies what the end-system is expected to do.
> The end-to-end argument underlies the rest of this document.
>
>2.2 End-to-end performance
>
> Another aspect, in which the behaviour of the network and that of the
> end-systems interact in a complex way, is performance, in a
> generalised sense. This is not a primary focus of the present
> document, but it is mentioned briefly since it is often referred to
> when discussing end-to-end issues.
>
> Much work has been done over many years to improve and optimise the
> performance of TCP. Interestingly, this has led to comparatively
> minor changes to TCP itself; [STD 7] is still valid apart from minor
> additions [RFC 1323, RFC 2581, RFC 2018]. However a great deal of
> knowledge about good practice in TCP implementations has built up,
> and the queuing and discard mechanisms in routers have been fine-
> tuned to improve system performance in congested conditions.
>
> Unfortunately all this experience in TCP performance does not help
> with transport protocols that do not exhibit TCP-like response to
> congestion [RFC 2309]. Also, the requirement for specified quality of
> service for different applications and/or customers has led to much
> new development, especially the Integrated Services [RFC 1633, RFC
> 2210] and Differentiated Services [RFC 2475] models. At the same time
> new transport-related protocols have appeared [RFC 1889, RFC 2326] or
> are in discussion in the IETF. It should also be noted that since the
> speed of light is not set by an IETF standard, our current notions of
> end-to-end performance will be largely irrelevant to interplanetary
> networking.
In other words, fundamental assumptions included:
IP is not an error-correcting service. It is, at best, error
detecting, and most error detecting is the responsibilility of the
data link service.
TCP was intended to be responsible for error correction. UDP was
intended to be error detecting only.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
