I understand how the layer works to an extent, but cannot seem to figure out if the data link handles big frames more efficiently due to error detection or small frames better.

I am assuming from my understanding that the data link works better with small frames as it can save time by not having to keep retransmitting larger frames when an error is detected.

Is this reasoning correct?

Havent used stackexchange in a long while so apologies if these type of questions are no longer permitted


Bigger frames mean a higher useful data fraction (same header size, more payload). But bigger frames mean a higher probability of the frame getting corrupted by random errors (thus getting lost). Larger frames mean higher latencies (need to wait for all of it to arrive, be checked, and handed to the application to be able to use any data in it). They also mean larger buffers might be a problem in limited devices).

As you can see, frame size is an exercise in compromise among a host of conflicting desirable measures.

| cite | improve this answer | |
  • 1
    $\begingroup$ Larger fixed-size frames also increase the potential for internal fragmentation. Routing overhead is also lower with larger frames. The error handling overhead might depend on the kind of corruption which is typical and how errors are handled (e.g., ECC or retransmit). If the network/transport layers add headers to every data link layer, the header overhead can be considerable. $\endgroup$ – Paul A. Clayton Jan 24 '16 at 1:52
  • $\begingroup$ So almost a yes and no scenario with bigger frames with same header size etc that smaller frames but with the risks of corruption whereas lots of small frames creating higher routing overheads but less prone to internal fragmentation and errors. $\endgroup$ – Yobo The Great Jan 24 '16 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.