> My question has nothing to do with congestion avoidance or flow control
> or TCP in general. *After* a packet leaves the TCP layer, it is dropped
> by someone (IP or network). I believe it would be the same when I use
> UDP or something else.
>
But it is. UDP is (are) data-grams that are not guaranteed to go anywhere.
The TCP layer establishes "connections" which ultimately result in
datagrams. These "special" datagrams are retried as required to establish
a virtual "perfect" link between the two hosts. Not only is retrying
necessary, but also datagrams may arrive out or order. They can also
be duplicated. User-level Datagrams (UDP) are not retried. They have
to be fixed up at the application layer.
Duplication on Ethernet generally results when the sending Serial
Network Interface Controller (SNIC) detects a collision, but the packet
got through anyway. The SNIC will retransmit packets when it detects a
collision, typically up to 15 times before it even reports an error (NE*
SNIC).
Out-of-order packets generally result from routing changes or duplicate
routes when a switch may select another route that it thinks corresponds
to its minimum "cost".
Lost packets generally result from noise generating a bad CRC and/or
collisions which are not detected by the sender because there was
some intermediate hop that had the collision. Also, packets are
dropped as a "throttle" when there is congestion that must be handled
in hardware (a switch). Observe the problem with a 100mb port sending
data to a 10mb port, you have 10 times more bandwidth than the 10mb port
can handle. Hardware generally throttles such interfaces by deliberately
generating collisions if the average bandwidth exceeds its buffering
capability. Some switches just drop such packets. The same problem
occurs when xBase-T interfaces with a T-1 link. There is a bandwidth
mismatch. Routers do a good job of helping to preserve bandwidth
because they buffer packets. However, when there are many datagrams
being sent through the same router and RAM is exhausted, something
has to give.
Now, inside the computer, we also have another bandwidth mismatch.
If you have many datagrams being sent/received as would happen in
a name-server or an active web server, there may be practically
continuous I/O. RAM and CPU speed is many times faster than SNIC
speed. Somebody has to make a decision. Do we drop packets we have
already received because we run out of buffers, or do we drop packets
we are about to transmit because the SNIC is busy?
Somebody decided that packets that are already received are more
precious than data not transmitted yet. Therefore, to maximize the
buffers available for reception, there is no transmit queue for
multiple packets to be sent. It seems reasonable.
Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/