04-14-2012 09:00 AM - edited 03-07-2019 06:08 AM
hi:
allow me to apology, i know this question should not be posted in this fourm. however i got no answer elswhere.
back to the old school days teacher used to tell me the maximum IP packet size is 65535 bytes. and i know it is
because the maximum length word in IP is 2 bytes and one byte = 8 bits thus 2^16 = 65536 .
here is my question since the length is convered from bytes to bits howcome the answer become "bytes" , i mean isn't it suppose
to be 65536 bits??
and why most of people say it is 65535 instead of 65536??
sorry for my Stupility.
any answer is appreciated.
Solved! Go to Solution.
04-14-2012 09:14 AM
The counter is in bits but what it is counting is bytes. So he maximum size of IP packet is 65535 bytes not 65535 bits.
2^16 = 65536 and since we start at 0 the largest value that can be in 16 bits is 65535 (giving a total of 65536 numbers).
HTH
Rick
04-14-2012 09:24 AM
Hi Dannan,
The IPv4 "Total Length" header field has 16 bits to indicate the size of the packet in bytes.
So we have 16 bits that can have a maximum value of 1111111111111111 =65,535
The result that we received is just a "16 bit word" that gives us a certain indication on how big the packet is. As the rule states, the received value represents the packet size in bytes so you can just look at it as a number not as an amount of bits.
I hope I could clear things up for you.
04-15-2012 04:38 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
All good questions - although honestly unsure I can provide 100% accurate answers.
For ICMP ping packets, if you look at this Wiki page, http://en.wikipedia.org/wiki/Ping, you'll see the ICMP packet has 28 bytes of required data and another optional data part, shown with an additional 4 bytes. Without doing some additional research, it's not clear whether the 4 bytes is optional in being part of the packet or optional in having any content. If the latter, there's your 32 bytes, 20+8+4.
As to why standard Ethernet MTU is 1500, it's just a number selected when the media standard was chosen. Lots of factors go into picking such a number, one of the most significant being how difficult and expensive does it make the hardware. I.e., there's nothing truly special about 1500 as other media has different MTUs and as hardware has become cheaper, Ethernet is one of the few that has gone back and optionally supported (vendor specific) even larger MTUs, "Jumbo" Ethernet (often with MTUs about 9,000 bytes).
BTW, picking a MTU, as I understand it, usually is most concerned with the hardware that needs to support it, but it also considers how likely the media might have have errors during transmission. All it takes is a single bit corruption to negate a whole MTU's worth of data, unless the transmission also supports ECC which further increases complexity and cost.
Also BTW, picking a media MTU is somewhat like picking a computer's #-bit processing capability. Microprocessors started at 4-bit then 8-bit then 16-bit then 32-bit then 64-bit (an example of the last, 32-bit vs. 64-bit Windows).
Is there a minimum transfer unit? Yes there is! It's also media and protocol dependent. For example, if IPv4 headers require 40 bytes, they cannot be smaller than that. Additionally there's the minimum requirements for the L2 headers. I'm sure you've heard minimum size for Ethernet is 64-byte packets; often used in worst case performance testing metrics.
There are even other standards that try to be independent of physical media requirements such as IPv4 expects any media to be able to handle a minimum MTU of 576; i.e. larger isn't required but is supported.
01-18-2014 01:52 AM
Hello,
I was looking to answer some of my different questions about ip frame size and i saw your question. It happen i am reading
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series) and just reading topic about data link layer and that where i found answer to question
"ethernetv2 ‘s MTU is 1500 bytes?"
I cant very well answer by myself therfore i am pasting snipped from the book:
"
The unfortunate consequence of requiring multiple Ethernet frames to hold a larger upper-layer PDU is that each frame contributes a fixed overhead (14 bytes header, 4 bytes CRC). To make matters worse, Ethernet frames cannot be squished together on the network without any space between them, in order to allow the Ethernet hardware receiver circuits to properly recover data from the network and to provide the opportunity for other stations to interleave their traffic with the existing Ethernet traffic. The Ethernet II specification, in addition to specifying a 7-byte preamble and 1-byte SFD that precedes any Ethernet frame, also specifies an inter-packet gap (IPG) of 12 byte times (9.6μs at 10Mb/s, 960ns at 100Mb/s, 96ns at 1000Mb/s, and 9.6ns at 10,000Mb/s). Thus, the per-frame efficiency for Ethernet II is at most 1500/(12 + 8 + 14 + 1500 + 4) = 0.975293, or about 98%. One way to improve efficiency when moving large amounts of data across an Ethernet would be to make the frame size larger. This has been accomplished using Ethernet jumbo frames [JF], a nonstandard extension to Ethernet (in 1000Mb/s Ethernet switches primarily) that typically allows the frame size to be as large as 9000 bytes. Some environments make use of so-called super jumbo frames, which are usually understood to carry more than 9000 bytes. Care should be taken when using jumbo frames, as these larger frames are not interoperable with the smaller 1518-byte frame size used by most legacy Ethernet equipment.
"
Hopefully this will allows you understand that better.
Rgeards,
Lukasz
04-14-2012 09:14 AM
The counter is in bits but what it is counting is bytes. So he maximum size of IP packet is 65535 bytes not 65535 bits.
2^16 = 65536 and since we start at 0 the largest value that can be in 16 bits is 65535 (giving a total of 65536 numbers).
HTH
Rick
04-14-2012 09:24 AM
Hi Dannan,
The IPv4 "Total Length" header field has 16 bits to indicate the size of the packet in bytes.
So we have 16 bits that can have a maximum value of 1111111111111111 =65,535
The result that we received is just a "16 bit word" that gives us a certain indication on how big the packet is. As the rule states, the received value represents the packet size in bytes so you can just look at it as a number not as an amount of bits.
I hope I could clear things up for you.
04-14-2012 09:32 AM
thank you guys, you have helped to clear my mind. have a nice weekend.
04-14-2012 06:34 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Stupidity isn't the question asked but the question not asked.
The other posters have correctly answered your question, but to stretch your mind a little . . . (and perhaps help you in understanding similar)
How could one send a IP packet of length 0? You can't, so logically knowing this you could "shift" the IP packet length by 1 (i.e. 0=1, 1=2, etc.) and have packets up to 65,536 bytes in length.
Similarly, since the length field is 2 bytes, we could logically increase the IP size by another 1, and have packets up to 65,537 bytes in length. Continuing this scheme, you could not count the first required 20 bytes of an IPv4 allowing the packet's size to be up to 65,555 bytes in length. Or, the 0..65,535 could count the length of the optional non-header portion of the IP packet, in bytes.
The reason I mention this is because counters count what they want to count, i.e. the number range that a bit field can represent can be applied in various ways. For example, the IPv4 Internet Header Length (4 bits) counts 32-bit words. Or, TCP scaled RWINs multiples a 16-bit value (of bytes) by some power of 2.
04-15-2012 01:27 AM
thanks Joseph.
your help is much appreciated.
i wonder if you could answer my other simple questions , i am always afraid to ask.
why the minium icmp ping packet is 32 bytes ?
and ethernetv2 ‘s MTU is 1500 bytes?
is there a minimum transfer unit (opposite to MTU)?
04-15-2012 04:38 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
All good questions - although honestly unsure I can provide 100% accurate answers.
For ICMP ping packets, if you look at this Wiki page, http://en.wikipedia.org/wiki/Ping, you'll see the ICMP packet has 28 bytes of required data and another optional data part, shown with an additional 4 bytes. Without doing some additional research, it's not clear whether the 4 bytes is optional in being part of the packet or optional in having any content. If the latter, there's your 32 bytes, 20+8+4.
As to why standard Ethernet MTU is 1500, it's just a number selected when the media standard was chosen. Lots of factors go into picking such a number, one of the most significant being how difficult and expensive does it make the hardware. I.e., there's nothing truly special about 1500 as other media has different MTUs and as hardware has become cheaper, Ethernet is one of the few that has gone back and optionally supported (vendor specific) even larger MTUs, "Jumbo" Ethernet (often with MTUs about 9,000 bytes).
BTW, picking a MTU, as I understand it, usually is most concerned with the hardware that needs to support it, but it also considers how likely the media might have have errors during transmission. All it takes is a single bit corruption to negate a whole MTU's worth of data, unless the transmission also supports ECC which further increases complexity and cost.
Also BTW, picking a media MTU is somewhat like picking a computer's #-bit processing capability. Microprocessors started at 4-bit then 8-bit then 16-bit then 32-bit then 64-bit (an example of the last, 32-bit vs. 64-bit Windows).
Is there a minimum transfer unit? Yes there is! It's also media and protocol dependent. For example, if IPv4 headers require 40 bytes, they cannot be smaller than that. Additionally there's the minimum requirements for the L2 headers. I'm sure you've heard minimum size for Ethernet is 64-byte packets; often used in worst case performance testing metrics.
There are even other standards that try to be independent of physical media requirements such as IPv4 expects any media to be able to handle a minimum MTU of 576; i.e. larger isn't required but is supported.
04-15-2012 11:08 PM
thanks for your answer . you are truely an internet hero . word cannot express my gratitude to you.
04-16-2012 02:25 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I wouldn't exactly consider answering your questions heroic (laugh), but I'm pleased if you found my answers helpful.
You'll find many others who are willing to help others in these forums, and who provide excellent information, from the forum oldies like Rick to new(er) posters like Nathaneal.
Even when you don't post specific questions, you can find lots of worthwhile nuggets of information contained on these forums. I try to skim posted questions, daily, not just looking for questions I might be able to answer, but to also learn myself. Searching these forums for earlier posts is often as useful, if not more so, then searching the Internet as a whole or searching Cisco's main web site.
01-18-2014 01:52 AM
Hello,
I was looking to answer some of my different questions about ip frame size and i saw your question. It happen i am reading
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series) and just reading topic about data link layer and that where i found answer to question
"ethernetv2 ‘s MTU is 1500 bytes?"
I cant very well answer by myself therfore i am pasting snipped from the book:
"
The unfortunate consequence of requiring multiple Ethernet frames to hold a larger upper-layer PDU is that each frame contributes a fixed overhead (14 bytes header, 4 bytes CRC). To make matters worse, Ethernet frames cannot be squished together on the network without any space between them, in order to allow the Ethernet hardware receiver circuits to properly recover data from the network and to provide the opportunity for other stations to interleave their traffic with the existing Ethernet traffic. The Ethernet II specification, in addition to specifying a 7-byte preamble and 1-byte SFD that precedes any Ethernet frame, also specifies an inter-packet gap (IPG) of 12 byte times (9.6μs at 10Mb/s, 960ns at 100Mb/s, 96ns at 1000Mb/s, and 9.6ns at 10,000Mb/s). Thus, the per-frame efficiency for Ethernet II is at most 1500/(12 + 8 + 14 + 1500 + 4) = 0.975293, or about 98%. One way to improve efficiency when moving large amounts of data across an Ethernet would be to make the frame size larger. This has been accomplished using Ethernet jumbo frames [JF], a nonstandard extension to Ethernet (in 1000Mb/s Ethernet switches primarily) that typically allows the frame size to be as large as 9000 bytes. Some environments make use of so-called super jumbo frames, which are usually understood to carry more than 9000 bytes. Care should be taken when using jumbo frames, as these larger frames are not interoperable with the smaller 1518-byte frame size used by most legacy Ethernet equipment.
"
Hopefully this will allows you understand that better.
Rgeards,
Lukasz
01-18-2014 02:55 AM
thanks for your answer. i really didn't expect people to answer 2 years old question but because of people like you we become more intelligent.
01-18-2014 07:55 AM
I am getting a lot of help from forums like this so, if i can add my two cents and will be usefully for someone that would be great...a little straight my comment this was not explanation of MTU size explanation is a few pages before what i paste, i guess i was half asleep answering that and pasting here..But regards, this book TCP/IP Illustrated is great and it can connect a lot of dots, at least for me.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide