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
Describe the effect on network delay when comparing fragmentation during transmission to fragmentation at source.
The source shouldn't fragment. It shouldn't create packet sizes larger than what it believes is PMTU. Source may not know PMTU, and if it doesn't, it will send a packet too large which will either be fragmented downstream or dropped with a message back to the source it's "too large".
From a performance perspective, the only hit to performance, if source is not exceeding PMTU would be more overhead to payload compared to a path with a larger PMTU (if the source can create packets the larger size).
There is a performance hit if the source receives a "too large" packet. Data that generated the "too large" will need to be resent (which incurs additional latency for that particular data). If the "too large" ICMP message doesn't indicate max size (possible in older implementations), then source finds max by trial and error (which incurs additional delay).
Source will "age out" max MTU, and when it does, it will again repeat process of dealing with "too large". (NB: the age out is because MTU can vary per path, and the "too large" might be specific to one path and active transmission path may have changed.)
I managed to find that fragments impose processing load on the routers that have to split the packets. Fragmentation also introduces overhead in the bandwidth used for transmission, because each fragment has to contain both the L2 and L3 header.
Yes, that's all true. Impact varies based on platform and how much fragmentation is required. On many devices, CPU increase can be very noticeable. Device's PPS rate is generally reduced. How much additional latency is added would also vary per platform. Typically additional delay probably isn't significant, reduced PPS rate may be.
PS:
With fragmentation, receiver has to reassemble packet, which also incurs additional latency.
Typically additional latency isn't an issue with fragmentation as you're probably dealing with just a few additional milliseconds.
What can be a major problem is additional processing demand which pushes a network device, performing fragmentation, beyond its current capacity limits.
Another issue with fragmentation, a fragmented packet can be lost, but source only knows of original packet.
You really want to avoid fragmentation. If you know the path's MTU is smaller than your local MTU, you might be better off setting your local MTU to match. If you control the network devices where the fragmentation occurs, Cisco's ip tcp mss-adjust command is a good way to avoid fragmentation (if it's supported on the Cisco device).
