Excessive retransmissions on Ethernet

Question

The CSMA/CA variants of Ethernet handle excessive failed transmissions due to repeated collisions by dropping the current frame and relying on upper layers for retransmissions:

After 16 attempts station B will reset its collision counter allowing it to compete more aggressively again. But it also discards the frame it was attempting to transmit, requiring that it be queued for transmission again by software.

I realize that on modern (i.e. switched) Ethernet networks, CSMA/CA isn't used anymore, and the channel capture effect mentioned in the source doesn't occur, but I'm trying to understand the network layer separation and interaction as implemented by the Linux kernel in that situation.

On Linux, at which layers are those retransmissions handled? Will it be done at the IP layer, or does the dropped Ethernet frame also result in a dropped network layer packet and a dropped TCP segment or UDP datagram?

The difference between the two approaches would seem to be that in the second case, the excessive retry would be interpreted as congestion and lead to a decrease of the TCP congestion window size. Does that happen, or is the dropped frame transparent to TCP?

Answer 1

IP does not make delivery guarantees, and in fact many protocols that build on top of IP (probably most notably UDP) also do not make such guarantees.

Delivery guarantees in TCP/IP are handled by TCP. TCP can work over a guaranteed-delivery protocol, but is designed in such a way that it does not require it. If the underlying protocol does not guarantee delivery, TCP will.

So, in the normal case of TCP/IP, a dropped Ethernet frame leads to a dropped or corrupted IP packet, which in turn translates to a dropped or corrupted TCP or UDP packet. If it is TCP (or some other protocol which makes delivery guarantees) then TCP is responsible for detecting the failure and retrying the transmission.

This is irrespective of operating system or IP stack implementation, since it deals with the protocols themselves. Any TCP implementation that does not detect lower-level (IP or lower) transmission failures is in violation of the specification.

Also note that outright collisions are only one way in which packets can become corrupt or mangled at a level that TCP has no way to prevent and can only detect (and react to). And IP can work over non-Ethernet carriers, too; see RFC 1149 for one example.