Which protocol handles fragmenting more nowadays?

[PeshoCSKA]

Hello all, I heard somewhere that even though traditionally the IP protocol handles packet fragmentation, nowadays most packets that travel throuhg the Internet are fragmented by TCP instead. I am doing some research which involves virtually simulating networks running on the TCP/IP protocol suite. Does anybody have any idea?

Thanks,
Peter

 

[JasonDeckard]

Hi Pescho,

Fragmentation is handled by IP. Although firewalls commonly analyze TCP headers, the TCP portion of a transmission is nothing but payload to the layer 2 and 3 devices handling it.

Hope that helps,
Jason Deckard

http://www.closedsocket.com/

 

[PeshoCSKA]

Jason, thanks for the reply. It is true that intermediate nodes go only as high as level 3, but how about the host, where communication starts? Would the initial host more often fragment large outgoing chunks of data on the TCP level or on the IP level?

Thanks,
Pesho

 

[JasonDeckard]

Pescho,

Sorry for the delayed reply (I haven't been checking this board very often). The host will fragment the payload, but it will not fragment TCP packets.

If I have 100k to send, my host may break those up into chunks of 8192 bytes each. Along the way, those 8k packets may be fragmented due to MTU. Fragmentation is a way of repackaging existing packets into smaller ones, and the host has no need to repackage anything - it simply creates the packet at the size it desires.

I hope that helps,
Jason Deckard

http://www.closedsocket.com/

 

[mpennac]

Jason, TCP does break up most of the data on the sending host.

For example. If a server wanted to send 64K of data to a client, it would hand that 64K down to TCP. TCP would look at the MTU for the network connection to determine the Maximum Segment Size (MSS). The MSS is the maximum amount of data that can be put into a frame. On a typical Ethernet connection the calculation is as follows:

Maximum Frame size for Ethernet = 1518 Bytes
Ethernet Header = 18 Bytes
IP Header = 20 Bytes
TCP Header = 20 Bytes

1518 - 18 - 20 - 20 = 1460 (The MSS for most connections)

TCP will split that 64K up into 1460 byte chunks and send them to the client, who will based on sequence numbers in the TCP header, reassemble the data and hand the upper layer the original 64K data block.

Microsoft will typically set the Do Not Fragment Bit in the Flags section of the IP header. This tells all intermediate layer 3 devices not to fragment these frames. Instead any layer 3 device that needs to fragment the frame will send an ICMP Destination Unreachable message back to the sending device. This message will contain the MTU for the circuit that caused fragmentation.

The sending device will then set the MTU for that connection to the MTU contained in the ICMP error message. This MTU is valid only for that one detination IP address, the information is stored in the sender's routing table.

This is a good process, since firewalls don't typically reassemble IP fragments. As a result, they my pass the fragment that contains the original TCP header, but discard the rest of the fragments.

As a note, the amount of data placed in the TCP data portion of the frame is based on the advertised MSS of the receiving device. If the sender has a MSS of 1460 and the receiver has an MSS of 300, only 300 bytes will be placed in the data portion by the sender.

NFS was an example of a protocol that let IP do the fragmentation. NFS would hand 8K down to the IP layer and let IP break it up into fragments that meet the size of the MTU.

Mike

http://www.nps-llc.com

 

[JasonDeckard]

I don't mean to confuse anyone, but I understood the question to be which protocol handled fragmentation. I take that to mean which protocol fragments and reassembles packets (as opposed to files), and that protocol is IP.

http://www.closedsocket.com/

 

[PeshoCSKA]

Hello all, thank you for your comments. Here is what I meant by my question. When a big chunk of data travels down the protocol stack, it has to be broken somewhere to fit the MTU of the layer 2 frames, right?

Now, the way I see it, there are two options. The standard thing that have been done before as I understand it is to let IP deal with the fragments - fragment at the host, possibly fragment further at routers along the path and then reassemble everything together at the target host.

The other option, which I wasn't aware of until recently is to have TCP handle fragmentation.

Each of these options I guess has its own advantages and disadvantages. For example, if TCP sends a segment, one of the fragments produced by IP gets lost, TCP probably has to retransmit all the data again. On the other hand, if TCP handles fragmentation, it needs to wait for acknowledgements for all fragments.

I didn't know that firewalls might drop packets that don't have the original TCP header. Mike, why would they do that, do you know?

What I was really wondering was if I can find out which protocol handles the majority of message fragmentation in reality. I am building a network topology simulation and I want to make the system handle fragmentation possibly in the way that most hosts do it on the Internet nowadays.

Mike, do you know what portion of the TCP/IP implementations nowadays handle fragmentation in the way that you are describing it?

Thank you all,
Peter

 

[mpennac]

Peter, all TCP implementations are designed to handle up to 64K bytes of data from the upper layers, typically the application layer. They will all break this data up into datagrams not greater than the Maximum Segment Size and hand that data along with the TCP header down to the Network Layer (IP).

One thing we would want to look at is why would we break the data up into smaller chunks than the MSS?

Voice Over IP is one reason. Imagine an intersection where you wanted small vehicles, VoIP frames to get the rightaway if they arrived at the intersection at the same time as a triple trailer semi-truck. If the truck were to enter the intersection first, the small vehicle would have to wait a long time before it could go. If we limit the length of the vehicle (MTU) we can reduce the impact on the small vehicles. This reduces Jitter across the WAN circuits and improves voice quality.

This is part of the reason ATM cells are so small. It allows data, video and voice to be prioritized.

I've capture millions of frames in networks all over and the only time I expect to see IP attempt to fragment frames is if someone has decreased the MTU on a WAN circuit to improve the VoIP performance.

For the simulation, you want to make sure that if a host were to receive an ICMP Destination Unreachable - Fragmentation Needed, but Don't Fragment Set, the host would decrease the MTU to the size specified in the ICMP message.

On the firewall part, the first fragment contains the TCP header from the original frame. None of the other fragments contain the TCP header. If the firewall does statefull inspection of the frames, it will not find the information necessary in the frames not containing the TCP header. Could be that some firewalls will reconstruct the frame before processing it. Its just one of the problems I have seen in the past.

As Jason mentioned, even if TCP has broken the data up into what it thinks is the right size, IP could still try to break it up into smaller data units. An interesting test is to use a packet capturing analyzer (Ethereal) to capture some frames going out over the Internet from a host. You will find that pretty much all of the TCP frames have the Don't Fragment Bit set in the IP header. This is known as Path MTU Discovery. If you search Microsoft's Knowledgebase, you will find some pretty good articles on how to turn this off and the impact it will have. (PMTUDiscovery). Also check out Path MTU Black Hole Discovery. This is for situations where a router along the path will not send you the ICMP Destination Unreachable message back.

Good luck with your simulation!

Mike

http://www.nps-llc.com