Reasons of Retransmission with TCP and what if received frame size is bigger than MTU configured on switch

[ashish7aditya]

Dear Experts,

I need your support to understand that what can be the possible reasons for packet re-transmission in TCP based applications?

also how the switch and router treats a frame if the size of the received frame is greater than the MTU size configured on the interface? Will it drop the frame or it will fragment the frame and will pass the frame?

I am sending a VLAN tagged Ethernet(802.3ac) frame towards a switch on whose receiving interface MTU =1500Bytes. So, all the frames for which payload is >1500Bytes i.e. Ethernet frame size will be 1542(7+1+6+6+4+2+1500+4+12)Bytes will be dropped or will be fragmented into smaller PDUs and will be passed?

Further I believe large round trip delay can also lead to packet re transmission? In this case how to check this and how to fix this ?

Best Regards!

[Vinit Jain]

First of all, it will totally depend on if the application is sending the traffic with DF bit set or not. if the DF-bit is set, then the packet will get dropped. If its not, in that case, fragmentation will happen. now fragmentation process is taken care by CPU (software processed) thus this can lead to increase in CPU utilization and at times cause packet loss.

if you are seeing large round trip delay, this could be possible because of fragmentation. retransmission generally happens when there is packet loss.

You can check fragmentation using the below command:

show ip traffic | in frag

If you see the fragmentation counter incrementing, this would help you confirm if fragmentation is really happeneing or not.

If you want to troubleshoot retransmissions, we need to isolate first where the packet loss might be happening. 

Regards

Vinit

[ashish7aditya]

Further let me know whether RTT should be anaysed or packet delay for understanding the cause of low TCP throughput on EnodeB which is connected through microwave radio link.

We did FTP sessions over the mw link segment alone and were able to achieve 330mbps(did with iPERF) but when we see laptop or mobile connected through Enode-B(supporting peak of 225mbps) we are not able to achieve anything beyond 150mbps?

[Joseph W. Doherty]

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

(sorry for late response - just found your post)

An ingress interface receiving a too large frame/packet will drop.

An egress interface receiving a too large frame will drop.

An egress interface receiving a too large packet will fragment, unless packet has DF set, then it will drop and notify sender packet was too large.

Yes, a too long RTT delay can lead to a retransmission.  It would think the packet was lost.  This is unusual because the time out is usually quite "generous" and I believe it's dynamically adjusted based on the average of seen RTTs.

How to fix would be to find the cause for the excessive RTTs and remediate.

Detection of this happening can be a bit difficult.  Basically you would be looking for an ACK that was sent before your retransmitted packet arrived to trigger it.  For example you know RTT is at least x milliseconds and the ACK arrives less than that after you transmitted the duplicate.

BTW, one issue to watch for, if your packets get fragmented, if one fragment doesn't arrive, it's like the whole packet didn't arrive.

It's possilbe, but would be unusual on a full time out (more likely with fast retransmit), that your original packet (or missing fragment) arrives before your retransmitted packet.  This would trigger the ACK and then your retransmitted packets is a needless dup.