MTU setting discussion

[wwwlstr0707]

I’m curious, if for arguments sake you have an ip mtu set to 1400 on and interface, and the ingress traffic is 1400 bytes, which then egresses an interface with an ip mtu of 1500, will all those packets remain 1400 bytes?

[MHM Cisco World · Accepted solution]

will all those packets remain 1400 bytes? Yes it will be 1400 as it seen by ingress interface 

MHM

[wwwlstr0707]

Awesome thanks!  But I was going somewhere with this too. What if two 700 byte packets were received, would there be any mechanism that would combine them into one packet?  I don’t know of one but finding a doc that states that specifically has been difficult. Just trying to educate a non tech higher up. Thanks again. 

[MHM Cisco World]

and device not buffer packet to form big mtu, this need a huge memory so router forward packet as it receive, even small than 700 VoIP can be less 700 bytes. 

NOW unless the packet larger than MTU of egress, the ingress will fragment. 

MHM

[Joseph W. Doherty]

Not usually on network device.

Further, if your two 700 byte packets are part of a fragmented packet, they still would not be combined on a usual network transit device.

Besides the overhead issues of a transit device trying to combine packets, unfragmented or fragmented, remember IP doesn't guarantee packet sequencing nor that all packets will take the same path.  So, how would a network transit device "know" what packets should be combined of even count on a packet isn't available that it logically could combine?  It would also break protocols that ACK individual packets.

So, usually only the destination deals with reconstruction of any data stream.

BTW, there are a couple of technologies that dice and recombine in transit.  Two that come to mind are various tunnel protocols and ATM, but both have intermediate senders and receivers of their traffic.

In theory a "transit" device, that's an IP "destination" could effectively do what you're asking about.  (I don't know of any such app, but it wouldn't be difficult to program.  If there are none, most likely because there's little need/benefit.)

[wwwlstr0707]

Thanks for the added information. Really good point on the sequence numbers and ACKs too, hadn’t really thought that through…

[MHM Cisco World]

how do de-fragment ?
Client-R1-R2-Server 
cleint send 1500 and between R1 and R2 is 1400
R1 do fragment 
R2 not do de-fragment, it server how do that. 

then when router do de fragment ?

when it destination of packet (i.e. for us packet)

MHM

[Joseph W. Doherty]

Yup, correct.

[wwwlstr0707]

Thanks as always. Just making sure smaller to larger mtu kept the smaller packet size is what I was after. 

[Joseph W. Doherty]

It depends on what the egress interface is doing.

For example if the igress is a GRE/IPSec tunnel, it will add nearly a 100 bytes to the packet, which as the egress supports a MTU 100 bytes larger, fragmentation will be avoided.

[Joseph W. Doherty]

Oh, I just recalled a 3rd party encryption device that would place multiple transit packets into its own packet being sent to its peer.  This was to reduce tunnelling overhead, for every original packet, especially beneficial for small packets.

However, two problems I saw with this product.  First, it could increase latency waiting to fill a larger packet.  Second, as it mixed combining packets, you might have something like VoIP and FTP together, but you couldn't tell that nor provide them separate QoS treatment.

[wwwlstr0707]

Funny. This whole conversation was started due to the use of a third party encryption device. Which I’m convinced is doing exactly that. I just had no way to prove it and it’s an IPsec tunnel that I cannot decrypt so there’s no telling what’s in those packets…

[Joseph W. Doherty]

Ah, well if there was a way to obtain packet counts on both sides of the encryption device, less packets on the encrypted side vs. the non encrypted side would indicate that's happening.

This technique is a bit different from what I thought you were asking about.  Just as a "classic" tunnel embeds a original packet into a tunnel packet, this technique can embed multiple original packets into the tunnel packet.  On the other side of the tunnel, the original packet or packets is/are removed and forwarded.

What I earlier had in mind, that I thought you were asking about, was somehow combining multiple packets' data, sort of the inverse of fragmentation, even for small non fragmented packets.  If you preserve the original packets, you would use more bandwidth unless doing tunneling, especially encrypted tunneling, which adds overhead per packet.

Possibly a best example of these two different approaches would be if working with a series of telnet packets, each containing just a single character. Almost all such a packet is overhead which is only increased by a per packet tunnelling overheard.  Placing multiple such packets into a tunnel packet would reduce tunnelling overhead, and would be easy to do.  Combining a series of telnet packets into a single telnet packet would be even better (like the Naggle approach at the source) but complex for transit traffic.

[wwwlstr0707]

First thing, thank you for the continued thoughts on this!  Second, you are right, my original question was very much asking about the inverse fragmentation, so to speak. That was deliberate because I wanted to make sure I was grasping the concept correctly. And also so I was phrasing it correctly and not getting bogged down in the minutia of IPsec. It was just by happenstance you mentioned crypto devices. Unfortunately I have pretty limited access so it might take some time before I can confirm everything you’re talking about. But now I have a much better idea what I’m looking for. Thanks for that!