You are right. This does seem like an undesirable consequence of the CSMA-CD protocol.

I suspect this behavior was selected because it is implementable, and because it is not so easy to come up with an alternative that is simple and avoids this problem.

Recall, the only thing that is observable to B when it tries to send is whether that send was successful or a collision occurred. B can't see anything about whether it "wins" or "loses"; it has no visibility of the other parties. It doesn't know that A is also trying to send at the same time. If B tries to send and succeeds, then B doesn't know whether that's because no one else wanted to send; or A wanted to send and previously "won" (already finished sending); or A wants to send but has "lost" (hasn't sent yet and has a backoff time that is still in the future) -- B has no way to distinguish between those cases.

It sounds like one of your alternative proposals is that B should give up permanently as soon as it is involved in a two consecutive collisions. That doesn't seem to make sense to me. When B gives up permanently, that means that it just powers down and never sends on the network again? You can't have permanent disconnection -- that wouldn't be useful. There has to be some point at B is going to try to send something again, so it's just a question of what that condition is.

It sounds like another of your proposals is that if B collides with A, and A gets to send first, then B should wait until A is finished. That's harder to implement, and I'm not sure it has much benefit for B (B is still stuck waiting). Why is it hard to implement? It's hard to implement, because it's not clear how B would know when A is "done" transmitting. It's not even clear what "done" means. Even A won't know when it is done; A doesn't necessarily know what other packets it might want to send in the near future. So now we get into some design space where we try to figure out what we mean by "done", and how B would know when A is done (maybe it's that A hasn't sent anything in the last 20ms?). It's not enough to have A declare how much more it currently has to send as soon as it succeeds on a retransmission attempt and then require B to wait until that much has been sent, because what if after A finishes sending that much, A discovers it has more that it wants to send? (Presumably, there's some application running on A that periodically wants to send stuff. A's ethernet card can't predict what future sends the application will want to do. Maybe the application will end up continuously trying to send packets, one after another, rapid-fire.) If A tries to send some new message as soon as it finishes the previous one, you'll be back to the same scenario where A is more likely to win, so this doesn't eliminate the problem.

Or, if you were proposing that each PC remembers who won the last time and you alternate, that is also problematic, for a different reason. It doesn't scale well to more than two PCs on the same network.

The standard protocol is memoryless; it doesn't require keeping track of past history. This makes it scalable, efficient, and simple.

You are right. This does seem like an undesirable consequence of the CSMA-CD protocol.

I suspect this behavior was selected because it is implementable, and because it is not so easy to come up with an alternative that is simple and avoids this problem.

Recall, the only thing that is observable to B when it tries to send is whether that send was successful or a collision occurred. B can't see anything about whether it "wins" or "loses"; it has no visibility of the other parties. It doesn't know that A is also trying to send at the same time. If B tries to send and succeeds, then B doesn't know whether that's because no one else wanted to send; or A wanted to send and previously "won" (already finished sending); or A wants to send but has "lost" (hasn't sent yet and has a backoff time that is still in the future) -- B has no way to distinguish between those cases.

It sounds like one of your alternative proposals is that B should give up permanently as soon as it is involved in a two consecutive collisions. That doesn't seem to make sense to me. When B gives up permanently, that means that it just powers down and never sends on the network again? You can't have permanent disconnection -- that wouldn't be useful. There has to be some point at B is going to try to send something again, so it's just a question of what that condition is.

It sounds like another of your proposals is that if B collides with A, and A gets to send first, then B should wait until A is finished. That's harder to implement, and I'm not sure it has much benefit for B (B is still stuck waiting). Why is it hard to implement? It's hard to implement, because it's not clear how B would know when A is "done" transmitting. It's not even clear what "done" means. Even A won't know when it is done; A doesn't necessarily know what other packets it might want to send in the near future. So now we get into some design space where we try to figure out what we mean by "done", and how B would know when A is done (maybe it's that A hasn't sent anything in the last 20ms?). It's not enough to have A declare how much more it currently has to send as soon as it succeeds on a retransmission attempt and then require B to wait until that much has been sent, because what if after A finishes sending that much, A discovers it has more that it wants to send? (Presumably, there's some application running on A that periodically wants to send stuff. A's ethernet card can't predict what future sends the application will want to do. Maybe the application will end up continuously trying to send packets, one after another, rapid-fire.) If A tries to send some new message as soon as it finishes the previous one, you'll be back to the same scenario where A is more likely to win, so this doesn't eliminate the problem.

Or, if you were proposing that each PC remembers who won the last time and you alternate, that is also problematic, for a different reason. It doesn't scale well to more than two PCs on the same network.

The standard protocol is memoryless; it doesn't require keeping track of past history. This makes it simple, scalable, and reasonably efficient in many scenarios.

If you meant that B always loses every time, and A always wins, that isn't fair. If both are trying to send a lot of traffic, A will take over the entire capacity of the network, and B will get nothing -- not very satisfactory.

If you mean that each PC remembers who won the last time and you alternate, that is also problematic, for a different reason. It doesn't scale well to more than two PCs on the same network.

The standard protocol is memoryless; it doesn't require keeping track of past history. This makes it scalable, efficient, and simple.

Your understanding of the standard protocol seems faulty. In the standard protocol, if there is a collision, both parties back off; so both A and B would be picking from {0,1,2,3} (rather than A picking from {0,1} and B from {0,1,2,3}).

You are right. This does seem like an undesirable consequence of the CSMA-CD protocol.

I suspect this behavior was selected because it is implementable, and because it is not so easy to come up with an alternative that is simple and avoids this problem.

Recall, the only thing that is observable to B when it tries to send is whether that send was successful or a collision occurred. B can't see anything about whether it "wins" or "loses"; it has no visibility of the other parties. It doesn't know that A is also trying to send at the same time. If B tries to send and succeeds, then B doesn't know whether that's because no one else wanted to send; or A wanted to send and previously "won" (already finished sending); or A wants to send but has "lost" (hasn't sent yet and has a backoff time that is still in the future) -- B has no way to distinguish between those cases.

It sounds like one of your alternative proposals is that B should give up permanently as soon as it is involved in a two consecutive collisions. That doesn't seem to make sense to me. When B gives up permanently, that means that it just powers down and never sends on the network again? You can't have permanent disconnection -- that wouldn't be useful. There has to be some point at B is going to try to send something again, so it's just a question of what that condition is.

It sounds like another of your proposals is that if B collides with A, and A gets to send first, then B should wait until A is finished. That's harder to implement, and I'm not sure it has much benefit for B (B is still stuck waiting). Why is it hard to implement? It's hard to implement, because it's not clear how B would know when A is "done" transmitting. It's not even clear what "done" means. Even A won't know when it is done; A doesn't necessarily know what other packets it might want to send in the near future. So now we get into some design space where we try to figure out what we mean by "done", and how B would know when A is done (maybe it's that A hasn't sent anything in the last 20ms?). It's not enough to have A declare how much more it currently has to send as soon as it succeeds on a retransmission attempt and then require B to wait until that much has been sent, because what if after A finishes sending that much, A discovers it has more that it wants to send? (Presumably, there's some application running on A that periodically wants to send stuff. A's ethernet card can't predict what future sends the application will want to do. Maybe the application will end up continuously trying to send packets, one after another, rapid-fire.) If A tries to send some new message as soon as it finishes the previous one, you'll be back to the same scenario where A is more likely to win, so this doesn't eliminate the problem.

Or, if you were proposing that each PC remembers who won the last time and you alternate, that is also problematic, for a different reason. It doesn't scale well to more than two PCs on the same network.

The standard protocol is memoryless; it doesn't require keeping track of past history. This makes it scalable, efficient, and simple.