The Internet protocol suite was designed to work over many networking technologies, each of which may have different sized packets. While a host will know the MTU of its own interface and possibly that of its peers (from initial handshakes), it will not initially know what the lowest MTU on a chain of links to any other peers are. Another potential problem is that higher-level protocols may create packets larger than a particular link supports.
To get around this issue, IP allows fragmentation, which refers to dividing the datagram into pieces, each small enough to pass over the single link that is being fragmented for, using the MTU parameter configured for that interface. This fragmentation process takes place at the IP layer (OSI layer 3) and marks packets it fragments as such, so that the IP layer of the destination host knows it should reassemble the packets into the original datagram. This method implies a number of possible drawback.
- All fragments of a packet must arrive for the packet to be considered received. If any fragment is dropped, the entire packet is lost.
- When the MTU of a particular link is less than the size of most or all packets that have to be sent over that link, almost everything has to be fragmented. In certain cases the overhead this causes can be considered unreasonable or unnecessary. For example, various tunneling situations cross the MTU by very little as they add just a header's worth of data. The addition is small, but each packet now has to be sent in two fragments, the second of which carries very little payload. The same amount of payload is being moved, but every intermediate router has to do double the work in terms of header parsing and routing decisions
- As it is normal to maximize the payload in every fragment, in general as well as when fragmenting, any further fragmentation that turns out to be necessary will increase the overhead even more
- There is no simple method to discover the MTU of links beyond your direct peers
0 komentar:
Posting Komentar