On Thu, 23 Mar 2000, Iljitsch van Beijnum wrote:
> On Wed, 22 Mar 2000, Fred Wright wrote:
>
> > There's a potential downside, however, in the lack of link-level flow
> > control. Suppose ports A and B both want to send to port C. They can't
> > do this indefinitely at full speed, since the switch can only have finite
> > buffering. With a hub there'd be collisions and/or deferrals, and the
> > stations would only send data as fast as it could be delivered. But with
> > a switch running the ports in full-duplex mode, there's no possibility to
> > report collisions, and the only recourse is to drop packets, which must be
> > recovered by much slower higher-level retransmissions.
>
> This isn't really much of an issue with IP, because TCP uses a slow start
> algorithm and a back-off algorithm that decreases the speed at which
> packets are sent when packets are lost in transit. There could be problems
> with UDP, but UPD applications typically do not try to use all the
> available bandwidth.
And TCP's retransmissions cost far more time than the retransmission in
the NIC due to collisions or simple delays due to deferrals. TCP is a
bunch of kludges upon kludges to try to coax more performance out of what
was fundamentally a bad design in the first place, namely handling all
flow control and relaible delivery on an end-to-end basis.
It gets especially bad with multihop paths with very different kinds of
media involved. Combining a slow reliable link (e.g. error-correcting
modem) with a fast link that drops a lot of packets results in an
effective bandwidth well below that of the slow link, due to all the
retransmissions that are based on the speed of the slow link.
> However, you should never forget that in the real world packets get lost.
Of course. You should also never forget how much that hurts performance
when the loss is as little as 10% or so. This is such a problem on the
net in general that many routers now resort to delaying ACKs as a means of
flow control, even though that has a bunch of problems of its own.
> Although there are many vendors that claim their switches are non-blocking,
> there really isn't such a thing. So once in a while (or often, depending on
> traffic) switches will drop packets because they can't forward them fast
Once in a while is tolerable. Consistently dropping a large percentage of
as the primary means of flow control has performance problems.
> enough. Also, no medium is perfect: there are always CRC errors. And some
Actually, a properly constructed Ethernet often has a negligible rate of
CRC errors.
> types of equipment are designed to drop packets under certain conditions.
> For instance: a Cisco router will drop the packet if the MAC address for
> the next hop isn't in the ARP table. Packets are not buffered until there
> is an ARP reply, but simply discarded. Also, very few systems have both the
This was once common practice, but is now strongly discouraged by the RFCs
due to the problems it causes.
> hardware and software infrastructure to keep up with a continuous flow of
> packets at wire speed.
However this limitation often appears on the sending end, where packets
aren't dropped for flow control. And if it's an application limit, it's
handled via the window. The only places that actually drop packets due to
speed limitations are the receiving side up to the TCP layer, and the
intervening network.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
