At Teksavvy, they lowered it to 1452, something about it fitting into ATM
frames without wasted payload in ATM packets.
Recently though, steve told me that they were not using large packets and
that the limitation was no longer needed. So I boosted my MSS to 1452 (MTU
1492), however, the line still shows MSS 1412 MTU 1452.
(there is a 40 byte overhead for the TCPIP protocol).
So it appears that Teksavvy still imposes an MSS of 1412. (MTU 1452).
Does any other ISP have that strange MTU ?
Are there plans within Teksavvy to lift this back up to the expected MTU of
1492 (MSS 1452) ????
Heard that the DSL cloud would be switching from ATM to Ethernet. When that
happens, will MTU be lifted to 1492 ? And when is this expected ?
The new Gig-E we're bringing in apparently will be able to handle Jumbo
Packets so the 1492 setting will likely be usable as of around end of
Feb. Once this Gig-E's in we'll be converting one of the other two to
the same and off-loading all LAN products on to the third.
No it wasn't, actually. You would eventually get failed uploads with a
MTU of 1492. Downloads aren't affected by the MTU on the client side.
> At Teksavvy, they lowered it to 1452, something about it fitting into
> ATM frames without wasted payload in ATM packets.
1452 is what any ISP providing PPPoE over Bell's infrastructure should
be providing to their customer as a setting. It is set in the RADIUS
server, but some systems (Windows being on the list) refuse to properly
configure the connection that way.
> Recently though, steve told me that they were not using large packets
> and that the limitation was no longer needed. So I boosted my MSS to
> 1452 (MTU 1492), however, the line still shows MSS 1412 MTU 1452.
This is not true to my knowledge. The MTU still should be set to 1452
because of the L2TP overhead to tunnel across Nexxia's network.