How can a 13 bit number represent 16 bit number?Or why is fragmentation offset multiple of 8?

[shivajikobardan]

This is more of a mathematics confusion rather than a computer science confusion, so please treat it like that. I understand the computer science behind it(I hope so) but my confusion lies in the basic math part that is there.




I am studying about ipv4 fragmentation.
This is ipv4 header. The fields of concern here are-:
-> identification(16 bit)

-> Flags(3 bit)

-> fragment offset(13 bit)

-> Total length(16 bit)

In order to understand these concepts of fragmentation, I have solved multiple problems. One of them is below.

Here initially we have 5000 byte datagram of which 20 byte is header.
The MTU is 1500 bytes.

The answer is this-:

But I am unable to realize this simple concept that I believe even a 5th grader can understand even though I am college level undergraduate student. It is being pretty shameful for me.I am leaving my shame aside and asking this instead of giving up. I have asked this everywhere and everyone says this is basic math but it is not clicking in my head. Imma memorize this lol. I can solve any numerical problem related to fragmentation but this curiosity isn’t letting me to learn further and go to ipv6.
It would be immensely helpful to me if anyone can help me via that above example to understand this simple concept. I am unable to relate with this concept.
I agree there are 2^13 offset values ie 0,1,2,3,4,5,6,7,8,9…..8191. So that is the total no. of fragments possible 8192 fragments. But datagram can be only as big as 2^16-1 bytes. But why are we dividing them? It doesn’t make any sense. Maybe it is trying to say that 8192 fragments need to span 65535 bytes which gives 7.99987793 as the answer. But I have calculated it later, and fragmentation doesn’t work like that.

Opinion 1-:

Max “true” fragment offset possible=sum of all previous DATA ONLY excluding header
=65535-n*20 bytes.

Where 65535 is the max total length possible.n is the number of fragments and 20 bytes is the header length
The max value of offset possible is 8191. 65535-n*20 bytes should be represented by 8191 (both max values). But this opinion takes nowhere.


Opinion 2-:
Max. 13 bit number=8191
Max 16 bit number=65535
So 65535/8191=8.0000sthsth (not exactly 8).

So the problem is like how can max offset value represent the max data size. But as i said in opinion 1, max data size can never be 65535 as header also takes up some space.

Opinion 3–:
Say i want to understand this example by a dummy example. Say fragmentation offset field is of 1 bit. And total length field is of 4 bit. What would happen?

Here are some answers that I have read which gave me further confusions-:
https://networkengineering.stackexc...26/why-ip-fragmentation-is-on-8-byte-boundary

https://learningnetwork.cisco.com/s/question/0D53i00000Kt7dxCAB/fragment-offset-concept

 

[Dr.Peterson]

It would be immensely helpful to me if anyone can help me via that above example to understand this simple concept. I am unable to relate with this concept.
I agree there are 2^13 offset values ie 0,1,2,3,4,5,6,7,8,9…..8191. So that is the total no. of fragments possible 8192 fragments. But datagram can be only as big as 2^16-1 bytes. But why are we dividing them? It doesn’t make any sense. Maybe it is trying to say that 8192 fragments need to span 65535 bytes which gives 7.99987793 as the answer. But I have calculated it later, and fragmentation doesn’t work like that.

Have you worked through the example you show in detail?

The first packet starts at offset 0, and contains 1480 bytes of the message; this is 1480/8 = 185 sets of 8 bytes.

The second packet therefore starts at offset 185, which means 185*8 = 1480 bytes into the message. Do you see that the "offset" (measured in sets of 8 bytes) is multiplied by 8 to get the actual offset in bytes? That is why each fragment (except the last) must consists of a whole number of sets of 8 bytes; that is, it must be a multiple of 8 bytes long, because the next fragment will start at a multiple of 8 bytes into the message.

Nothing here says that the entire datagram must be a multiple of 8 bytes. Rather, 8 bytes is being used as a unit of measurement for the fragments.

And the reason they do this is, apparently, that they only have 13 bytes in which to fit the offset!

If you still don't understand, you'll need to keep clarifying your uncertainty until we understand it.

 

[JeffM]

As I understand it (the English in the text shown is atrocious), a single block contains at most 1480 bytes of the datagram, which itself can contain at most 2^(16) - 1 =65535 bytes. Thus, it can take up to 45 blocks to contain the entire datagram. Notice that 1480 is evenly divisible by 8. Let's call 8 consecutive bytes a "phrase."

The block also contains the count of how many actual bytes of the datagram are contained in the block. Presumably because the blocks may not be processed in sequence, the block also gives the address where the data contained in the block fits into the datagram. But it gives that address in terms of phrases rather than bytes.

Phrase address 0 corresponds to byte address 0; phrase address 185 corresponds 1480; phrase address 370 corresponds to byte address 2960, and so on.

What is the maximum possible phrase address given a maximum length in bytes of 65535? Obviously, 8190. How many bits does it take to represent 8190 < 8192 = 2^13? Obviously, 13 bits.

The text is hard to parse. They talk about bytes and bits, but they do not talks about addresses, and they never bother to assign a term to the groupings of 8 consecutive bytes that I have called phrases.

It has been 55 years since I worked with computers, but I have done highly technical writing for decades. When I say the explanation given is atrocious, that is the opinion of someone whose career was built on clear and accurate writing.

By the way, it is not advanced math. It is basic arithmetic.

 

[shivajikobardan]

Have you worked through the example you show in detail?

The first packet starts at offset 0, and contains 1480 bytes of the message; this is 1480/8 = 185 sets of 8 bytes.

The second packet therefore starts at offset 185, which means 185*8 = 1480 bytes into the message. Do you see that the "offset" (measured in sets of 8 bytes) is multiplied by 8 to get the actual offset in bytes? That is why each fragment (except the last) must consists of a whole number of sets of 8 bytes; that is, it must be a multiple of 8 bytes long, because the next fragment will start at a multiple of 8 bytes into the message.

Nothing here says that the entire datagram must be a multiple of 8 bytes. Rather, 8 bytes is being used as a unit of measurement for the fragments.

And the reason they do this is, apparently, that they only have 13 bytes in which to fit the offset!

If you still don't understand, you'll need to keep clarifying your uncertainty until we understand it.

i feel like i do understand, but i would want to skip this now, as i have understood the working of fragmentation which was the goal of course. there is nth that i haven't read(about why it happens), so i need to get satisfied and move on i guess. thanks for your kind gesture.