Collision Detection – CSMA/CD
While by this point I have covered various aspects of the workings of Ethernet, one major issues still remains.  What happens when the nodes are sharing the transmission medium and a collision occurs (e.g. two nodes try to send data at the same time)?  Luckily, this scenario was taken into account as Ethernet was developed and the CSMA/CD protocol was deployed to handle this type of conflict.  CSMA/CD stands for Carrier Sensing Multiple Access/Collision Detection and while this probably sounds confusing to a lot of you right now, it will be cleared up in just a bit.  While I could now take a time out and explain this protocol in great detail, I’ve instead decided to keep things within the scope of this article and instead focus on how it ties in with Ethernet, and also why exactly it is necessary.  The main components of the CSMA/CD protocol basically breakup as follows:

1. An adapter on a host can start transmitting data at any time.

2. The adapter possesses a means to sense whether other adapters are transmitting and will not do so if this is the case.  This is what the term “carrier sensing” refers to.

3. If an adapter does transmit and a collision occurs, that transmission is aborted and a jam signal is sent into the transmission line by the sender making sure other nodes also transmitting on the same transmission medium are aware that a collision has just occurred.  Right here is the place now where we need to backtrack just a little bit and explain things in a little bit more detail.  Recall that I mentioned earlier that the Ethernet frame’s data field needed to be a minimum size, namely 46 bytes. The reason for this is solely that the sender of the frame can detect that a collision has occurred.  Consider the scenario now where the frame sent is too small (e.g. 0 byes).  In this case the sender might be done transmitting before the collision occurs in the medium (especially if the transmission distance is long enough, i.e. a long transmission medium).  The end result: The sender of the frame thinks the frame was successfully sent, the receiver of the frame senses the collision and drops the frame and the data is not resend.  A smart reader might at this point begin to scratch his/her head:  If the receiver of the frame senses the collision (e.g., since it’s sending data at the same time), consequently sending a jam signal into the medium, how can the sender of the original frame not be aware of the collision since it would sense the jam signal?  The problem with collision detection is that the sender has to be transmitting to properly detect there was a collision with the frame it sent.

Diagram of a collision during data transmission

In other words, if the sender of a frame is done transmitting and a collision occurs it is already too late because the sender only becomes aware that there was a collision.  It has NO means of knowing that its frame was the one involved in the collision unless the collision happened while it was still transmitting.  Thus the only way that a frame will get resend by a sender is when a collision occurs when the sender is still transmitting (allowing the sender to successfully detect the collision).  If the frame has already been sent and the collision occurs, the frame is dropped and not resend.  Hence a minimum frame size is necessary given a certain specified transmission distance.  As can be seen later on the in this article, this whole dilemma of collision detection provides a major hurdle for increased Ethernet speeds.  What does one do?  Increase the frame size as speeds increase, or decrease the distance between adjacent hosts?  More on this later on when I discuss 100baseT and 1000baseT ethernet technologies.

4. If a collision is detected by an adapter, the adapter waits a finite random time interval before transmitting again.  The random wait interval is chosen from the following set:

(0…….2^n-1)

Where n is the nth collision number and can range from 0 to 10.  After the 10th collision, n remains at value 10.  To put all of this into perspective, after the first collision occurs each adapter chooses a random time from to 0 to 2^0, i.e. (0,1).  For the 2nd collision it will be from 0 to 2^2, or (0,1,2).  As you can see, when the number of collisions increases, the pool of wait times increases exponentially.  Why not increase linearly instead?  The main reason for this is that there is no awareness of how many nodes are hooked into the same transmission medium when the collision occurs.  By increasing the pool of wait times exponentially, the odds that another collision will occur in the future will decrease since the chance that each of the nodes will pick different wait times increases.

In Conclusion, the CSMA/CD protocol is pretty extensive and well thought out.  While it does have its drawbacks it does allow for traffic to flow smoothly across a shared medium.  Enough with the technicalities now though, let’s move on to talking about faster Ethernet technologies.