Client MTU setting and TCP

  • 2
  • Question
  • Updated 2 weeks ago
  • (Edited)
Actually its two questions: 

The new MTU setting in V3 is only intended for the UDP data, right? For the TCP part: is PMTU working? Our Flex still has to go through some tunneling and I've moved from OpenVPN (UDP with mssfix/fragment setting) to Wireguard and realized that TCP seems to ignore the PMTU to the client, so we have to do MSS clamping at the gateway. Everything working nice and fast, but still.... would be nice without MSS clamping.

ICMP is allowed on all GWs (PMTU from my home network to the radio)

$ traceroute --mtu 192.168.92.8
traceroute to 192.168.92.8 (192.168.92.8), 30 hops max, 65000 byte packets
 1  192.168.178.1 (192.168.178.1)  0.260 ms F=1500  0.206 ms  0.205 ms
 2  10.15.14.1 (10.15.14.1)  18.205 ms F=1420  19.992 ms  19.586 ms
 3  192.168.92.8 (192.168.92.8)  19.874 ms  18.288 ms  19.853 ms


Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 62 Posts
  • 37 Reply Likes

Posted 1 month ago

  • 2
Photo of David-N5PSM

David-N5PSM

  • 174 Posts
  • 43 Reply Likes
I don't understand your two questions yet......    However, I suspect you are asking if the MTU setting is to "Throttle back" the UDP traffic in order to give better usability in poor internet conditions.  I can understand this regardless weather we are talking about V2.5 or V3   Where is the second question?  Please straighten me out.
Photo of Michael Walker

Michael Walker, Employee

  • 1048 Posts
  • 311 Reply Likes
You would only change the MTU values if you feel that your packets are being fragmented or broken up.  It is not a throttle feature.  In fact setting it too low is better than setting it too high (within reason).

For most of us on Cable modems or DSL modems, you should not have to touch the setting.  Do not change it without doing some testing.

If you think your MTU value is wrong there, you can do some tests using Windows command prompt to test it.  

https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router


As an example, I know a value of 1500 works at home, but as I sit here at a Tim Horton's in Canada (eh?) I can see it should be set to 1492 as I did the above test.

Mike va3mw
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 62 Posts
  • 37 Reply Likes
Thanks Michael. The concept of how TCP/IP works is very clear to me. Let me try to explain my question a bit more detailed:

The MTU Value in FRS Clients (Maestro, Mobile & Windows) only seems to affect the UDP traffic: 

My question is about Path MTU discovery.

My PMTU across the routed subnets / tunnel is 1420. 

(Windows Client MTU 1500)<->(Router MTU 1500)<->(Encrypted Tunnel/WAN MTU 1420)<->(Router2 MTU 1500)<->(Flexradio 6xxx) it results in a Path MTU of 1420.

This should be discovered by a mechanism called "Path MTU Discovery (PMTUD) RFC 1191".
Now I want to figure out if that is not taking place by the radio by a bug or by design

The Problem is, without MSS clamping on Router2, the radio still pushes out TCP packets > 1420, witch results in connection loss on the client side within a few seconds. That happens because the router would otherwise drop packages with the DF flag set which is by RFC the correct behaviour.

No, we don't want to use SmartLink. We stick to the routed VPN variant with a little help of my https://github.com/krippendorf/flex6k-discovery-util-go at all peers.

To be clear: Technically it is working fine with MSS clamping enabled, which is not how it should be. With PMTUD working on the radio MSS clamping would not be necessary. MSS clamping is kind of a dirty workaround to fix exactly those situations. We've got a latency around 15ms in cable to cable situations, even with DAX IQ and high frame rates.

FYI, here is how i handle the MSS fix on router2, the relevant rule (--clamp-mss-to-pmtu): 
*mangle
...
-A POSTROUTING -o enp2s0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
(Edited)
Photo of Roland HB9VQQ

Roland HB9VQQ

  • 27 Posts
  • 3 Reply Likes
To me it seems like the flex implementation is lacking PMTU functionality
Photo of Roland HB9VQQ

Roland HB9VQQ

  • 27 Posts
  • 3 Reply Likes
Showing actual MTU size per interface on Windows

netsh interface ipv4 show interfaces



ETH 4 is my VPN interface with an MTU Size of 1400. So every time I switch from (W)LAN (MTU 1500) to VPN (for remote OPS) and without PMTU I need to reconfigure the MTU Size in SSDR in order to prevent fragmented packets.

Things get even worse if a link in the path between two endpoints has a lower MTU than 1400.
Without PMTU this is not manageable and will lead to connection issues (packet fragmentation) sooner or later.

Would be nice to see a statement from Flex.

https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html#anc6

73

(Edited)
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 62 Posts
  • 37 Reply Likes
Exactly, what happens in our case: 


Things get even worse if a link in the path between two endpoints has a lower MTU than 1400.
Without PMTU this is not manageable and will lead to connection issues (packet fragmentation) sooner or later.
What happens is, that packets with DF flag will be dropped at the edge of the LAN subnet.
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 553 Posts
  • 323 Reply Likes
I remember a discussion long ago, and the conclusion was that the radio does not support Path MTU Discovery. That stuck me, at the time, as less than a great choice, but given my personal needs (LAN only) I didn’t pursue the issue further.


Peter

K1PGV
(Edited)
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 62 Posts
  • 37 Reply Likes
No statement from FRS? 
Photo of Michael Walker

Michael Walker, Employee

  • 1047 Posts
  • 311 Reply Likes
What is your question?
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 62 Posts
  • 37 Reply Likes
Question is, if path MTU discovery will be implemented in the radio firmware / radio network stack
Photo of Michael Walker

Michael Walker, Employee

  • 1047 Posts
  • 311 Reply Likes
Hi Frank

We have a policy of not commenting on future features until they are released.  So, at this time, I guess the answer is no comment.  

73, Mike