1

I'm new to networking, just a question on frame size. I was reading a book which says:

An interesting characteristic of character/byte stuffing, is that the size of a frame is dependent on the data that is being sent in the payload of the frame. It is in fact not possible to make all frames exactly the same size, given that the data that might be carried in any frame is arbitrary.

I'm confused,let's we want to transmit a 10MB of data, if we limit the size of the frame body to be sth like maximum 500 bytes, no matter how many times we do byte stuffing in each frame, the size of frame is always fixed, unless the book mean the "actual valid data", am I correct?

Improve this question

1 Answer 1

Reset to default
4

An interesting characteristic of character/byte stuffing, is that the size of a frame is dependent on the data that is being sent in the payload of the frame. It is in fact not possible to make all frames exactly the same size, given that the data that might be carried in any frame is arbitrary.

That isn't actually true. Some protocols (like ATM) use fixed frame (cell) sizes and stuff unused portions. Other protocols (like Ethernet) use variable frame sizes with minimum and maximum sizes - the minimum might require some stuffing as well for very small payloads.

The frame size is a property of the protocol - the need for stuffing is a result of that, not the other way around. Of course, it's possible to make all frames the same size. It might just not be practical or efficient. Since data is packetized anyway, oversized data chunks must be carried over to the next frame(s).

let's we want to transmit a 10MB of data, if we limit the size of the frame body to be sth like maximum 500 bytes, no matter how many times we do byte stuffing in each frame, the size of frame is always fixed, unless the book mean the "actual valid data", am I correct?

If you transmit 10 MB of data with a frame payload of 500 bytes you need 20,000 frames. You don't use stuffing when it's not required, it's wastes bandwidth. If your data doesn't fit neatly into a certain number of frames, the last one is either stuffed (for a fixed size) or it's just smaller than the maximum (for a variable size).

Fixed frame sizes have the problem of bad efficiency. Imagine a real-time application (like VoIP), where a frame might carry as little as 64 bytes payload. UDP over IPv4 over Ethernet does that with "just" 66 bytes overhead.

If you now had a fixed payload size of 500 bytes, the overhead would be 434 bytes larger - per frame.

Of course, you can tailor a protocol to your application, to use a smaller, fixed frame size - but then it would be inefficient for large payloads.

Variable frame sizes allow a protocol to adapt to a wide variety of applications, with different payload sizes. It can carry small payloads with a tolerable amount of overhead and large payloads with a very small overhead.

Improve this answer
14
  • Thanks for your answer. I'm still a little bit confused. isn't that fixed size always better than variable size framing?Let's say we want to transmit 10 MB+100 bytes, for fix size framing, the 20001th frame is still 500 bytes. For variable size framing, the last frame is 100 bytes, only 400 bytes is saved, compared to 10MB, it is almost nothing.
    – secondimage
    Apr 22, 2020 at 15:03
  • 1
    Fixed-size frames require stuffing for small payload. Stuffing is equivalent to wasted bandwidth, so no, it's not better. It may be easier to handle though. A network link doesn't only transmit a single connection but it may carry hundreds of even thousands of connections.
    – Zac67 ♦
    Apr 22, 2020 at 15:20
  • I checked your edited answer. still have a question, so why not every protocol (like VoIP in your example) makes a frame carry more bytes like 500 bytes payload, so all protocol frame have the same size? we can also reduced the number of frame required?
    – secondimage
    Apr 22, 2020 at 15:36
  • 1
    Each cell has the 5 bytes overhead and 48 bytes payload. The additional overhead in the last cell (AAL5 PDU) is comparable to Ethernet's overhead. The 5 bytes per cell is what folks refer to as the "cell tax." IP-over-ATM has a much worse problem than just 10% overhead, though -- packet loss. When one cell is lost, a whole packet cannot be reassembled. An ATM network element using random cell drops to mitigate congestion therefore turns 1% cell loss into 20% - 30% loss of large (1024-1500 byte) IP packets. Now you need a smarter cell drop strategy; why use cells at all?
    – Jeff Wheeler
    Apr 22, 2020 at 23:54
  • 1
    In reality, there are many frames that carry only little payload - we're not all just downloading files. If you look at TCP SYN/ACK, or protocols like HTTP, SMTP, SMB, etc. there are a lot of small packets going back and forth - but this is getting off-topic here. Think of why SDH or ATM were abandoned and there is practically nothing left but IP and Ethernet. It's all about cost, and cost is all about efficiency. Adaptability is key.
    – Zac67 ♦
    Apr 23, 2020 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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