why the minimum ethernet packet size is 64 bytes

The following is the answer for ATul Singh about Ethernet Frame:

The smallest packet size is 64 bytes.
14 bytes (MAC Header) + 46 bytes (Data) + 4 bytes (CRC) = 64 bytes

The smallest packet size is defined in RFC document (RFC894). IEEE choose this number not because they like the number 64, but because they have to choose a size big enough to hold transport layer segment data (TCP and UDP protocol) :

TCP header has minimum size of 20 bytes and maximum of 60 bytes.
The size of a UDP header is 8 bytes.

In order for an IP packet to contain a minimum sized TCP segment in its data field, the data field has to be larger than 20 bytes.

The packet size is defined in RFC document (RFC894). The smallest IP packet size is 64 bytes.
64 bytes - 14 bytes (MAC Header) - 4 bytes (CRC) = 46 bytes (Data).
46 bytes data field is large enough to carry small TCP segments.

64 = 2 power 6.

A next smaller packet size is 32 bytes (2 power 5).

32 bytes - 14 bytes (MAC Header) - 4 bytes (CRC) = 14 bytes (Data).

14 bytes is too small to hold the smallest TCP segments in the data.


You may ask why not cut a TCP segment into smaller pieces then put into many IP packets? Well, we can't. We have to carry one TCP segment per IP packet. The reason we can cut an application layer message into small pieces then wrap each piece into a TCP segment is because TCP has a sequence number for putting these small pieces together to get an application message at receiver side; IP has no sequence number, and IP packets delivery has no guarantee for the order --  if you cut a TCP segment into small pieces, there is no way to put them together from many IP packets at receiver side. At Link layer (particularly physical layer), an IP packet is cut into bits and sink down to the wires. The bits are sent in a sequential bit stream, so the receiving side always receives the bits in order therefore can put the bits into IP packet.

You may still question why:  if you cut a TCP segment into small pieces, there is no way to put them together from many IP packets at receiver side. Well, with the same "no sequence number" argument, if you cut a UDP segment into small pieces, there is no way to put them together from many IP packets at receiver side. "no way" to get a TCP or UDP segments from unordered IP packets also means we can not parse the TCP or UDP segments in order to get an application message. Even though application layer can provide means for resemble messages from pieces, we can not get those application layer messages.