ED : PMTU Discovery

[TonyFlury]

I have a question about what algorithm uses for it's PMTU Discovery (Path MTU).

I have a troublesome ISP and trying to find the optimal MTU for a given play session seems to be a never ending business.

I used ping -f -l <length> 3.8.0.0 (The London base Amazon server) to identify that my network connection at the moment would accept packets of size 900, and set my O/S MTU to 930 - which through trial and error I have discovered is the lowest setting that will accept 900 byte packets (I assume the 30 is the packet over head for wifi, broadband etc).

However when I start the game and look at the MTU size it shows as 924, but when i try ping -f -l 924 3.8.0.0 it fails (as expected). and the game then fails with an Orange sidewinder - it seems to only allow 6 bytes between the O/S set maximum, and the game setting.

If I set the O/S maximum to 1500, then the game uses 1484 (an 16 byte allowance), but then my network curently can't cope with 1484 packets - so however the game is doing it's discovery it isn't actually based on the network route to any know destination.

The ED Path MTU discovery is broken in some way - does anyone have any clues; I am tired having to do endless 'ping -f' commands between game sessions, only for the game to use a setting that simply can't work.

@sallymorganmoore : Tagging you to see if there is way to get some more technical details - enough knowledge about how to do Path MTU discovery for ED would be useful - the information from Support 'to set the MTU' doesn't help when the game itself will ignore those settings in some circumstances.

 

[Fnord Velkor]

Years ago some of us had dreadful issues over this - there was even a FAQ produced by FDEV anout setting the MTU. Unfortunately the FAQ has disappeared (along with much other useful stuff) at a revamp of the support site a while back.

However, I have a note that the suggestion was to change the figure like this:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1450 store=persistent


I also have the note that the default should be:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent

(Which mine is)

I don't know how this should be read in this age of IPv6 - have you set your game to use IPv6?

Stuff you might find useful, if you have not found it already:

https://customersupport.frontier.co.uk/hc/en-us/articles/4405945325970-What-do-the-network-options-do-

 

[TonyFlury]

Years ago some of us had dreadful issues over this - there was even a FAQ produced by FDEV anout setting the MTU. Unfortunately the FAQ has disappeared (along with much other useful stuff) at a revamp of the support site a while back.

However, I have a note that the suggestion was to change the figure like this:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1450 store=persistent


I also have the note that the default should be:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent

(Which mine is)

I don't know how this should be read in this age of IPv6 - have you set your game to use IPv6?

Stuff you might find useful, if you have not found it already:

https://customersupport.frontier.co.uk/hc/en-us/articles/4405945325970-What-do-the-network-options-do-

my network is not stable enough to support 1500 mtu size - the most stable mtu size is somewhere between 800 and 900.
I have no idea why ED can't use a decent IP stack that deals with fragmentation - this was a solved problem in the 1960s. Instead FDEV seemed to roll their own and end up with a system that is very sensitive to things that are completely normal in any modern netwok - ie fragmentation.
Given where we are here though, without any clue as to how FDEV determines the MTU size makes it impossible to set our system correctly so that the game works as well as it ca.

 

[Jack Winter]

Yes, it was a nonexistent problem in the 60s, as IP wasn't invented yet!

 

[Fnord Velkor]

my network is not stable enough to support 1500 mtu size - the most stable mtu size is somewhere between 800 and 900.
I have no idea why ED can't use a decent IP stack that deals with fragmentation - this was a solved problem in the 1960s. Instead FDEV seemed to roll their own and end up with a system that is very sensitive to things that are completely normal in any modern netwok - ie fragmentation.
Given where we are here though, without any clue as to how FDEV determines the MTU size makes it impossible to set our system correctly so that the game works as well as it ca.

From that page I linked, FDEV write:


MTU (Maximum Transmission Unit) - denotes the largest size packet your connection is configured to handle.
Normally this is 1500 but can be as low as 800* without impacting your experience in the game.

**Note that we do not recommend manually configuring an MTU value as low as 800. Unless you are encountering issues that relate specifically to packet size, your MTU should be left at the default value assigned by your router and/or recommended by your ISP.


So there you go, they say they can handle it.

Good luck


P.S. I forgot to say - some of us back then found that using VPN overcame the packet termination issue.

 

[Northpin]

I have a question about what algorithm uses for it's PMTU Discovery (Path MTU).

I have a troublesome ISP and trying to find the optimal MTU for a given play session seems to be a never ending business.

I used ping -f -l <length> 3.8.0.0 (The London base Amazon server) to identify that my network connection at the moment would accept packets of size 900, and set my O/S MTU to 930 - which through trial and error I have discovered is the lowest setting that will accept 900 byte packets (I assume the 30 is the packet over head for wifi, broadband etc).

However when I start the game and look at the MTU size it shows as 924, but when i try ping -f -l 924 3.8.0.0 it fails (as expected). and the game then fails with an Orange sidewinder - it seems to only allow 6 bytes between the O/S set maximum, and the game setting.

If I set the O/S maximum to 1500, then the game uses 1484 (an 16 byte allowance), but then my network curently can't cope with 1484 packets - so however the game is doing it's discovery it isn't actually based on the network route to any know destination.

The ED Path MTU discovery is broken in some way - does anyone have any clues; I am tired having to do endless 'ping -f' commands between game sessions, only for the game to use a setting that simply can't work.

@sallymorganmoore : Tagging you to see if there is way to get some more technical details - enough knowledge about how to do Path MTU discovery for ED would be useful - the information from Support 'to set the MTU' doesn't help when the game itself will ignore those settings in some circumstances.

Open a support ticket, no point really to tag Sally to act as a relay between you and support (not to mention it's weekend and a holyday bank is Monday in UK)

Frontier Support

customersupport.frontier.co.uk

 

[Ned Flandalorian]

I don't know how this should be read in this age of IPv6 - have you set your game to use IPv6?

In theory IPv6 would solve a lot of problems the game has, but when I force it to use IPv6 (by disabling IPv4 - my connection has full IPv6 support) it behaves much worse due to having to use relays to talk to every other player because they don't have IPv6.

 

[robbyp]

I would be changing ISPs and/or your internet hardware, rather than trying to work around the issue.

 

[TonyFlury]

From that page I linked, FDEV write:


MTU (Maximum Transmission Unit) - denotes the largest size packet your connection is configured to handle.
Normally this is 1500 but can be as low as 800* without impacting your experience in the game.

**Note that we do not recommend manually configuring an MTU value as low as 800. Unless you are encountering issues that relate specifically to packet size, your MTU should be left at the default value assigned by your router and/or recommended by your ISP.


So there you go, they say they can handle it.

Good luck


P.S. I forgot to say - some of us back then found that using VPN overcame the packet termination issue.

I have been told they can't handle lower than 700, but 800 is fine - so it looks like even FDEV support have no clue.

 

[TonyFlury]

I would be changing ISPs and/or your internet hardware, rather than trying to work around the issue.

It isn't my internet hardware - and changing ISP is no guarantee of better quality : After all most ISPs don't have an entire cross country network, so in rural areas of the UK your only option is a virtual ISP - effectively companies buying network connectivity from the incumbent.

 

[TonyFlury]

Yes, it was a nonexistent problem in the 60s, as IP wasn't invented yet!

IP v4 is more or less a codified version of Arpanet which was invented in the 1960s and had multi-hop fragmention. I agree that IPV4 wasn't formally invented until 1982, but I know I was using a IPv4 network at home by 1984 and this was well before development started on ED. The point is that Fragmentation is hardly an unsolved problem yet for some reason FDEV decided to roll their own networking layer without fragmentation support.

 

[Crank Larson]

I have been told they can't handle lower than 700, but 800 is fine - so it looks like even FDEV support have no clue.

I'd suggest FD support is fine. The question is why are you playing around with your MTU? You shouldn't need to., and what you are asking doesn't make much sense. If you set MTU too low, it will affect your performance (though shouldn't break it as packets larger than the MTU get fragmented and rebuilt at the other end - the only thing affected should be performance, not connectivity).

 

[robbyp]

It isn't my internet hardware - and changing ISP is no guarantee of better quality : After all most ISPs don't have an entire cross country network, so in rural areas of the UK your only option is a virtual ISP - effectively companies buying network connectivity from the incumbent.

Yes, they are piggy backing on OpenReach system. But I can't believe that there is any problem with MTU sizes on OpenReach. Otherwise we would be inundated with people having these problems.
I can't understand why playing with MTU would affect your Elite performance.

IPv4 replaced the previous protocols used in Arpanet begining in 1982/3/4. I doubt you were using IPv4 at home in 1984. ISPs only came into being for users outside academic/military/government computer uses around 1989/90. UK Demon internet only started with a handful of modems in 1992. Everyone was using dial up to bulletin boards/prestel/compuserve in the 1980s.

 

[GroG79]

So much wrong into when it comes to MTU

Your 'MTU' does not travel the internet. If you get fragmented packages it is at your ISP hardware or even closer to you in your internal network. The default MTU is 1500 and you have no reason to change it. Unless you like to break things or are a fan of dial-up

 

[Fnord Velkor]

So much wrong into when it comes to MTU

Your 'MTU' does not travel the internet. If you get fragmented packages it is at your ISP hardware or even closer to you in your internal network. The default MTU is 1500 and you have no reason to change it. Unless you like to break things or are a fan of dial-up

As I mentioned above, some years ago some of us were having intermittent server comms problems (for example the thing that happened to me most was that the ship would not complete the landing sequence on a pad) - it was found (suggested?) that this was being caused by some packet fragmentation happening along the line, terminating the packet early (cutting it short). So FDEV suggested reducing the MTU so reducing the risk of this happening. It worked. Using a VPN also worked, I assume as that system bypassed the routing that was causing the packet to be truncated.

 

[Fnord Velkor]

..... Everyone was using dial up to bulletin boards/prestel/compuserve in the 1980s.

Some of us were using AMPRNet

 

[GroG79]

Reliably not completing the landing pad sequence because of packet fragmentation...
I really would like a Fdev Dev to comment on this Or a network expert.. I am sure we have one around.

Yes some Lore will never die

 

[Spaceman-FXL5]

If I set the O/S maximum to 1500, then the game uses 1484 (an 16 byte allowance), but then my network curently can't cope with 1484 packets - so however the game is doing it's discovery it isn't actually based on the network route to any know destination.

The ED Path MTU discovery is broken in some way - does anyone have any clues; I am tired having to do endless 'ping -f' commands between game sessions, only for the game to use a setting that simply can't work.

IIRC the packet header is 28 bytes and not 16, so you should try ping with 1472 size - that makes a packet size 1500 (1500 - 28=1472) and if that fails, work your way down in size until it replies. Then you can use that as your MTU.

 

[Fnord Velkor]

Reliably not completing the landing pad sequence because of packet fragmentation...
I really would like a Fdev Dev to comment on this Or a network expert.. I am sure we have one around.

Yes some Lore will never die

Laugh all you like but the point was that server communication wouldn't complete and so you ended up with a server timeout error. It wasn't just the pad sequence "handshake" that this happened on, any change of server status could cause it. The pad one was just the one that seemed to happen a lot to me. (The ship would land, make the sound but not do that last "settling" onto the pad - you know, where the options "go live" - station services, launch, enter hangar, refuel, rearm icons wouldn't be available.)

So take your chortling elsewhere and have a good bank holiday weekend.

EDIT - I was going to search for my old Reddit stuff where this was going on but frankly, I don't want to go back down that rabbit-hole.

 

[GroG79]

Let me also tell a story or two totally not related issues that too contains MTU


I set up a backup infrastructure years back for doing nightly backups for 300+ VMs. We needed to increase performance as a lot of days our nightly backup schedule ran into production hours.

I tested performance with Jumbo Frames (that is a MTU of 9000!!) between the host and the storage array. (Manager had read on the internet that that makes your network go faster...) After all the configuring and making sure the Backup host, the Storage and the Switches in between were in fact using jumbo frames and no packets were fragmented. The whole re-configuration yielded a whopping 1% performance increase! (While using up to 6 times less packages)
After playing the 'I told you so' card again I convinced the management to upgrade the storage of the backup host and the nightly backups never ran into the production window again.

Tldr.. Dont play with MTU

There was another time I ran into a problem that was 'fixed' by lowering the MTU.
There was a site to site connection. On this site to site the ISP setup QoS to make sure phone traffic was preferred over any other traffic. However we kept running into issues with the phone system. (a pbx) It turned out that on one hop the switches QoS was misconfigured. The QoS somehow removed a certain number of bytes from the packet from the incoming router causing the network problems. With the MTU lowered this did not happen as the misconfigured QoS did not chop up the packets to a smaller size. When the QoS problem was finally found and fixed by a clever network person the site to site connection lived long and prospered.

(Btw QoS is complicated. Also one to avoid at home. It adds bytes to packets to 'mark' them; so the systems further up the line knows which packets are more important. At the end of the line the added bytes should be removed from the packets.)