TT router MTU 1432

That's right for TalkTalk - unfortunately we don't know the OP's ISP...

b4dger,

Less of the sarcasm, please!

Yes, I've just been in touch with my ISP about this. Their view is that the default for the Windows value is 1500. They've also mentioned that Path MTU Discovery may not work correctly, in so far as deriving the smallest overall MTU for efficient working, if ICMP is disabled.

ICMP is disabled, in my case, but for reasons of security I'm loath to permanently enable it.

What are they recommending you try, given your circumstances?

EDIT: One of the reasons open forums can be useful is so that people can search for
'mtu yourisp' etc. etc.

Edited by b4dger (Wed 18-Nov-09 12:49:02)

You've a good point there, yarwell. Yes, when you think about it, doing that ping test is merely finding the lowest overall MTU in the system.

Do you happen to know the path for the Windows MTU value in the Windows Registry? I could at least go there then and see what value my XP is currently using.

They're not recommending any one particular value; all they've said is that the default value for the Windows MTU is 1500. As I've already pointed out as well, they've said that automatic adjustment may not function properly if ICMP is disabled, thereby preventing the website server from pinging the router. They may comment further, in which case I'll post anything of note here.

Postscript: Well, what the contact at my ISP said was not quite what I wrote above. So, to clarify, here's precisely what the contact said:

"On the router I'd suggest 1500, as this is the Windows default.

Path MTU discovery should mean the MTU is automatically sized to the
smallest MTU setting on the path between your PC and the remote web
server, but it's possible that this may not be working correctly -
particularly if you have disabled ICMP on your router".

Edited by deleted (Wed 18-Nov-09 15:02:42)

Your test conclusion and logic is flawed.

Pinging a remote server to try and discover the Windows MTU is not going to work. You are actually discovering the maximum payload possible without fragmentation over the entire route to that server.

You should set the MTU on the PPP interface to a value that prevents fragmentation. Ideally you should also set the same MTU on the LAN interfaces (ethernet / wireless). If using Cisco kit a simpler solution is to use the mss-adjust setting on the LAN side to force the packet size down for the whole ethernet segment (your LAN).

As you are seeing maximum possible packet sizes of 1430 or 1432, this suggests both an ethernet backhaul of some description from the exchange and that your PPP session is further tunnelled within your ISPs network - most likely an L2TP tunnel between LAC and LNS. Unless of course you running your connection through some kind of VPN which will introduce its own overheads. You most certainly don't want to be increasing the MTU on your router.

There is much discussion about optimal IP MTU for DSL circuits, a common misconception being that having it as large as possible is best.

A more theoretical way to look at this is to consider the various transport layers that your connection uses and optimise your payload for the most heavily utilised. In the case of a typical DSL connection to the internet the bottleneck is clearly the DSL section (using ATM), so you should try to optimise for that to maximise throughput.


SO where do we start...


ATM Cell size is 53 bytes. However 5 bytes of that is used for the header leaving 48 bytes for payload.

The IP data payload your PC (etc.) generates is encapsulated into the PPP session adding 2 bytes of header to every packet.

To optimally use the ATM part of the connection (from DSLAM/MSAN to DSL CPE) you really want to fill every ATM cell completely. Bear in mind that ATM will pad the final cell for a packet if the packet does not completely fill the cell, rather than take the 1st chunk of the next packet and incorporate it.

So if your IP + PPP packet size is not divisible by 48 then you are effectively introducing artificial overhead or waste in that some ATM cells are not fully loaded.

So some examples:
IP MTU = 1400 + 2 bytes PPP = 1402
1402/48 = 29.21 (to 2 d.p.)


IP MTU = 1430 + 2 bytes PPP = 1432
1432/48 = 29.83 (to 2 d.p.)


Neither are optimal for PPPoA, the closest would be 1440 (1440/48 = 30). However, you have already ascertained that your connection can't support that without fragmentation.

So 1390 is really the highest IP MTU optimal for the PPPoA transit in this case. (1390+2)/48 = 29.


Of course this is all highly theoretical and assumes that you are going to be sending/receiving maximum sized IP packets the whole time.

Whether in practise this would result in higher throughput is questionable. On the one hand the DSL link is the bottleneck in your end to end connection to wherever you are pulling data from, so optimising that makes sense. The trade off is that you're having to generate and process more packets at the IP layer. Whilst the core fabric of the internet will have no issue churning these extra packets back and forth, your equipment might - having a decent ethernet adaptor will mitigate this in most cases.

You will still have to contend with XP's rather flaky IP stack and it's discovery methods of course.

All food for thought, not that anyone will listen of course... everyone seems to be convinced that bigger is always better when it comes to MTU.

GeeTee,

Most interesting to get an alternative view. I do kinda agree with your contention that biggest is not necessarily best, because what I remember, when I last visited the issue of MTU some several years ago now, is that that's precisely what was concluded by the pundits of the time.

Getting MTUs optimised is by no means straightforward, it seems. Even the article on it, on kitz.co.uk, gives many different examples of Windows MTU, each apparently working fine for the individuals concerned. Sure, 1500 is a good starting point for the Windows value but it won't necessarily be an efficient value for Windows to be using. Indeed, as far as I can gather, Windows XP will automatically try to optimise the value.

On your treatise posted here, although you've arrived at an MTU as low as 1390, you still seem to be of the view that this is only theoretical and so I'm still thinking that perhaps, in practice, my best bet might be to just try some values. Incidentally, I didn't think that 48 was the divisor, since most Windows MTU values I've seen used are 1430, 1458, 1478 and 1500. But perhaps I'm not understanding precisely in which part of the end-to-end connection you're considering.

My memory's not so good these days but I thought that Windows stored its MTU value in the Windows Registry. I've looked for it on my machine and have not been able to find it. I tried HKey Local Machine\System\Current Control Set\Services\TCPip\Parameters\Interfaces, and then tried looking in all of the adapter IDs listed there. But there were no DWords for an MTU anywhere there. I stress that I don't want to alter the Windows MTU, I just want to find out what its current value is, so that I can see if the router's value is correspondingly correct and, if it isn't, I can then alter it in the router's GUI.

Edited by deleted (Wed 18-Nov-09 14:35:03)

In reply to a post by meditator:

Yes, zebedee, I had much the same experience back in the days when I was using Windows 2000. Using Dr TCP caused me more problems than it solved. Nowadays, though, I gather that Windows XP automatically adjusts its own MTU to an optimum value, so the use of an app such as Dr TCP (there are several others around, I think) should not be necessary.

I don't think you're right there. As far as I'm aware, only Vista and Windows 7 dynamically alter the MTU, not XP.

In reply to a post by meditator:

I thought that Windows stored its MTU value in the Windows Registry.

I'm guessing it will only be there if it's not left to default.

Default and Manually changing: http://support.microsoft.com/kb/826159