MTU Question for DSL

[JF Mezei]

The fine folks at Teksavvy decided that their MTU would be 1452. (MSS 1412).

From a PPPoE point of view, the max MTU can be 1492 so that with the extra
8 bytes of overhead, it comes to 1500, the max for regular ethernet.

From a ATM point of view, since each packet has a 48 byte payload, you'd
want your PPPoE packet (MTU + 8) to be a multiple of 48 bytes. Right ?

1500 isn't a multiple of 48. The nearest multiple is 1488 bytes. (31 ATM
frames).

So, how come Teksavvy has chosen 1452 as MTU instead of 1480 ? With an MTU
of 1480, it would generate 1488 byte packets which fit perfectly into 31
ATM packets.

Not trying to criticise Teksavvy, just wondering what other factor I would
have overlooked.

If ISPs have a different ATM packet size coming into their router, where s
the weakest link ? The link into the ISP that needs to be optmized, or the
individual DSL links into customers with the 48 byte ATM packets that
would need to be at their optimum usage ?

[tsiguy]

Post by JF Mezei
The fine folks at Teksavvy decided that their MTU would be 1452. (MSS 1412).
From a PPPoE point of view, the max MTU can be 1492 so that with the extra
8 bytes of overhead, it comes to 1500, the max for regular ethernet.
From a ATM point of view, since each packet has a 48 byte payload, you'd
want your PPPoE packet (MTU + 8) to be a multiple of 48 bytes. Right ?
1500 isn't a multiple of 48. The nearest multiple is 1488 bytes. (31 ATM
frames).
So, how come Teksavvy has chosen 1452 as MTU instead of 1480 ? With an MTU
of 1480, it would generate 1488 byte packets which fit perfectly into 31
ATM packets.
Not trying to criticise Teksavvy, just wondering what other factor I would
have overlooked.
If ISPs have a different ATM packet size coming into their router, where s
the weakest link ? The link into the ISP that needs to be optmized, or the
individual DSL links into customers with the 48 byte ATM packets that
would need to be at their optimum usage ?

...

Hi JF,

We're pure ethernet so as a result the MTU settings are different.
The new Gig-E will allow Jumbo packets so you'll be able to get 1492
at that point, and being as we'll be removing the ATM network all
together with the new Gig-E, there's a possibility we might be able to
go 1500 too.

Rocky

[Shaman]

Post by JF Mezei
The fine folks at Teksavvy decided that their MTU would be 1452. (MSS 1412).

No, they did not. It's essentially the "widest" MTU you can use over a
L2TP tunnelled PPPoE connection. In your math, you overlooked the
overhead of the various protocols and frame headers involved.

[Malcolm Ferguson]

Post by Shaman

Post by JF Mezei
The fine folks at Teksavvy decided that their MTU would be 1452.
(MSS 1412).

No, they did not. It's essentially the "widest" MTU you can use over
a L2TP tunnelled PPPoE connection. In your math, you overlooked the
overhead of the various protocols and frame headers involved.

In fact that 1452 number's been around for years. I seem to remember
reading about it when I first signed up for Sympatico's 1 Meg service
back in 1999.

Malc

[JF Mezei]

Post by Malcolm Ferguson
In fact that 1452 number's been around for years. I seem to remember
reading about it when I first signed up for Sympatico's 1 Meg service
back in 1999.

So, can someone explain where this number comes from:

Ethernet frame allows 1500
PPPoE allows 1492

So why 1452 as MTU ? (1452 is the MSS if your MTU is 1492).

With Teksavvy, one is limited to 1412 as MSS (1452 as MTU).

Someone mentioned I should do the math. Can that person please explain
where I went wrong and what overhead I am missing ?

---

Re: tsiguy's statement that they are removing ATM. You may be removing ATM
from your end, but ATM remains between customer modems and at least the
DSLAM if not the BAS.

[Steve]

No one actually knows. We think it was because so many routers were sold with
a default size of 1452. Now we are told since sympatico has OC3's you use 1492
and the 3rd party isp's use 1452 because they don't have OC3's. When teksavvy
gets that Gig-E then the MTU setting will be set at 1492 maximum. If the
internet worked properly everyone on dsl would just use 1492 but since it
seems bell has fallen way behind in upgrading their network people have to
make concessions to compensate for this and to try to bring up web pages
faster and or so they don't get the couldn't find web page error.

Post by JF Mezei

Post by Malcolm Ferguson
In fact that 1452 number's been around for years. I seem to remember
reading about it when I first signed up for Sympatico's 1 Meg service
back in 1999.

Ethernet frame allows 1500
PPPoE allows 1492
So why 1452 as MTU ? (1452 is the MSS if your MTU is 1492).
With Teksavvy, one is limited to 1412 as MSS (1452 as MTU).
Someone mentioned I should do the math. Can that person please explain
where I went wrong and what overhead I am missing ?
---
Re: tsiguy's statement that they are removing ATM. You may be removing ATM
from your end, but ATM remains between customer modems and at least the
DSLAM if not the BAS.

...

[JF Mezei]

Post by Steve
No one actually knows. We think it was because so many routers were sold with
a default size of 1452. Now we are told since sympatico has OC3's you use 1492
and the 3rd party isp's use 1452 because they don't have OC3's.

ISTOP supported 1492 as far as I remember.

[Steve]

Because of different routing. It was bell's copper but Ralph always referred to it
as our own lines.

Post by JF Mezei

Post by Steve
No one actually knows. We think it was because so many routers were sold with
a default size of 1452. Now we are told since sympatico has OC3's you use 1492
and the 3rd party isp's use 1452 because they don't have OC3's.

ISTOP supported 1492 as far as I remember.

[tsiguy]

Post by Steve
No one actually knows. We think it was because so many routers were sold with
a default size of 1452. Now we are told since sympatico has OC3's you use 1492
and the 3rd party isp's use 1452 because they don't have OC3's.ISTOP supported 1492 as far as I remember.

Thinking Istop also used the 1452 based on their old documentation...

http://www.istop.com/1MFAQ.html

[Madonna]

If the internet worked properly everyone on dsl would just use 1492 but since it
seems bell has fallen way behind in upgrading their network people have to
make concessions to compensate for this and to try to bring up web pages
faster and or so they don't get the couldn't find web page error.

An MTU too large won't give you 404 errors, a broken URL will.

The problem you will get with an MTU too large is, for example, a failure to send
email with attachments.

[DevilsPGD]

Post by Madonna

If the internet worked properly everyone on dsl would just use 1492 but since it
seems bell has fallen way behind in upgrading their network people have to
make concessions to compensate for this and to try to bring up web pages
faster and or so they don't get the couldn't find web page error.

An MTU too large won't give you 404 errors, a broken URL will.
The problem you will get with an MTU too large is, for example, a failure to send
email with attachments.

While true, modern browsers don't make it immediately obvious (to my
grandmother) whether the error message was returned by the server, or
due to a connection problem with the server.

A too large MTU may result in random connection problems.

[tsiguy]

Post by JF Mezei
The fine folks at Teksavvy decided that their MTU would be 1452. (MSS 1412).
From a PPPoE point of view, the max MTU can be 1492 so that with the extra
8 bytes of overhead, it comes to 1500, the max for regular ethernet.
From a ATM point of view, since each packet has a 48 byte payload, you'd
want your PPPoE packet (MTU + 8) to be a multiple of 48 bytes. Right ?
1500 isn't a multiple of 48. The nearest multiple is 1488 bytes. (31 ATM
frames).
So, how come Teksavvy has chosen 1452 as MTU instead of 1480 ? With an MTU
of 1480, it would generate 1488 byte packets which fit perfectly into 31
ATM packets.
Not trying to criticise Teksavvy, just wondering what other factor I would
have overlooked.
If ISPs have a different ATM packet size coming into their router, where s
the weakest link ? The link into the ISP that needs to be optmized, or the
individual DSL links into customers with the 48 byte ATM packets that
would need to be at their optimum usage ?

...

I think its somethig like this:

Because we're doing Ethernet over ATM right now we have a max of 1500
bytes per packet.

20 bytes of IP
8 bytes of TCP/UDP
12 bytes of L2TP (the tunneling protocol used to go through bells
network)
8 bytes of PPPoE header

That leaves 1452 as the max payload that can be delivered.

Once we have the new Gig-E in place we will be Straigh Ethernet and we
be able to do jumbo packets of 1540. That will bump up the max of
1492, the "standard".

Rocky

[Some Guy]

Post by tsiguy
Once we have the new Gig-E in place we will be Straigh Ethernet
and we be able to do jumbo packets of 1540.

There are jumbo packet sizes larger than that (4k and 8k). Why not
use those?

[Geoffrey Welsh]

Post by Some Guy

Post by tsiguy
Once we have the new Gig-E in place we will be Straigh Ethernet
and we be able to do jumbo packets of 1540.

There are jumbo packet sizes larger than that (4k and 8k). Why not
use those?

Unless ALL of the other links along the path support jumbo frames, they'll
just get fragmented anyway.

[tsiguy]

Post by Geoffrey Welsh

Post by Some Guy

Post by tsiguy
Once we have the new Gig-E in place we will be Straigh Ethernet
and we be able to do jumbo packets of 1540.

There are jumbo packet sizes larger than that (4k and 8k). Why not
use those?Unless ALL of the other links along the path support jumbo frames, they'll

just get fragmented anyway.
--
Geoffrey Welsh <Geoffrey [dot] Welsh [at] bigfoot [dot] com>
I'm a cynic. Optimists say the glass is half full, pessimists say the
glass is half empty, and cynics observe that our education system can't
produce purchasing managers who can order the correct size of glass.

...

Bell's talking as if their new Optical Ethernet-only cloud will be
completely non-ATM.... :-)

Rocky

[JF Mezei]

Post by tsiguy
Bell's talking as if their new Optical Ethernet-only cloud will be
completely non-ATM.... :-)

It may be ATM free between the BAS and you, but unless Bell is willing to
give all DSL subscribers new modems, it will remain ATM based between the
customer modem and at least the DSLAM (more likely the BAS).

Where I think it may make a difference is in applications that really
require 1492 MTUs and can't have packets coming in in a fragmented fashion.
But those would not be optimal for the ATM line.

[tsiguy]

Post by JF Mezei

Post by tsiguy
Bell's talking as if their new Optical Ethernet-only cloud will be
completely non-ATM.... :-)It may be ATM free between the BAS and you, but unless Bell is willing to

give all DSL subscribers new modems, it will remain ATM based between the
customer modem and at least the DSLAM (more likely the BAS).
Where I think it may make a difference is in applications that really
require 1492 MTUs and can't have packets coming in in a fragmented fashion.
But those would not be optimal for the ATM line.

...

My understanding is that it should bring us back to at least the 1492
level....

[Geoffrey Welsh]

Post by tsiguy

Post by Geoffrey Welsh

Post by Some Guy
There are jumbo packet sizes larger than that (4k and 8k). Why not
use those?

Unless ALL of the other links along the path support
jumbo frames, they'll just get fragmented anyway.

Bell's talking as if their new Optical Ethernet-only cloud will be
completely non-ATM.... :-)

I'm not sure where that comment fits in the conversation, Rocky. My point to
"Some Guy" was that using significantly larger (4-8K) packets for internet
communication was not likely to be useful, since there are so many unknown
links between any two points and it's not likely that all will support jumbo
frames.

[Madonna]

Post by Geoffrey Welsh

Post by tsiguy

Post by Geoffrey Welsh

Post by Some Guy
There are jumbo packet sizes larger than that (4k and 8k). Why not
use those?

Unless ALL of the other links along the path support
jumbo frames, they'll just get fragmented anyway.

Bell's talking as if their new Optical Ethernet-only cloud will be
completely non-ATM.... :-)

I'm not sure where that comment fits in the conversation, Rocky. My point to
"Some Guy" was that using significantly larger (4-8K) packets for internet
communication was not likely to be useful, since there are so many unknown
links between any two points and it's not likely that all will support jumbo
frames.

...

You'll at least get jumbo frames to your ISP's pop server.


But how much throughput gain will jumbo provide?

[Shaman]

Post by Madonna
But how much throughput gain will jumbo provide?

Something like two percent.

[Marcus Coles]

It's like a foreign language to this point and click kinda guy :-), but
this may help explain.
http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

Then again perhaps it has something to do with everybody's router
configuration or perhaps busted flippers on Bell's machines. ;-)


Marcus

[Geoffrey Welsh]

Post by Marcus Coles
http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

That article does not address the effects of the L2TP encapsulation between
the BAS and third party ISPs.

[JF Mezei]

Post by Geoffrey Welsh

Post by Marcus Coles
http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

That article does not address the effects of the L2TP encapsulation between
the BAS and third party ISPs.

Does it really matter ?

Since ethernet PPPoE packets are destined to the ethernet address of the
BAS, it means that the BAS has to reassemble an ethernet frame from
multiple ATM frames coming from the customer's DSL modem. At which point
the BAS has a payload that is 1462 bytes long (1454 TCP, 8 PPPoE).

Does L2TP add more than 38 bytes of overhead ? tsiguy's message alluded to
12 bytes of overhead. So this would still allow a single PPPoE frame to fit
inside 1500 bytes.

[Geoffrey Welsh]

Post by JF Mezei

Post by Geoffrey Welsh
That article does not address the effects of the L2TP encapsulation
between the BAS and third party ISPs.

Does it really matter ?

I suppose if the goal is to minimize ATM overhead on your DSL link - where
there is no L2TP - no.

But how much are we really gaining by switching to an MTU of 1480 (31 full
ATM frames, at over 9.4% overhead) from an MTU of 1452 (30 full frames and
one with 20 bytes payload, with just under 9.6%)?

(Mind you, you're apparently not the first person to wonder:
http://en.wikipedia.org/wiki/Maximum_transmission_unit#ATM_Backbones)

Post by JF Mezei
Does L2TP add more than 38 bytes of overhead ? tsiguy's message
alluded to 12 bytes of overhead. So this would still allow a single
PPPoE frame to fit inside 1500 bytes.

The actual L2TP header is only 12 bytes, but you have to remember that your
Ethernet frame - complete with PPPoE header, IP header, TCP header, etc. - is
now inside another datagram with its own overhead. In "MTU Tuning for L2TP"
(http://www.cisco.com/warp/public/471/l2tp_mtu_tuning.html), Cisco says "In
the case of L2TP over UDP, the overhead of all the protocols includes an
additional set of IP, UDP and L2TP headers. The IP header is 20 bytes, the
UDP header is 8 bytes, and the L2TP header is generally 12 bytes." and "For a
1500 byte PMTU and a standard 40 byte L2TP header, set the IP MTU to 1460
(1500-40 byte header)." If we then subtract 8 bytes for PPPoE, we get
TekSavvy's recommended 1452. Given that unexpected things can happen when
PPPoE frames are fragmented, it may be safer to use an MTU no larger than
that, maybe (30*48)-8 = 1432?

(There was a time that, rather than debate these finer points, people just
said "to heck with it... 576 always works.")

[JF Mezei]

Post by Marcus Coles
It's like a foreign language to this point and click kinda guy :-), but
this may help explain.
http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

Many thanks. Had not taken into consideration that the whole ethernet frame
was encapsulated into ATM packets (1518 bytes), as well as ATM requiring 8
extra bytes to allow for a series of ATM packets to be reassembled as a
single ethernet frame.

The math does come to 1454 alas :-) At least now I know.

Re: ISTOP. Interesting FAQ. When I was with them, I was tood to switch from
1500 whcih I had with Videotron cable down to 1492. I think Ralph allowed
packets of 1492 MTU. The FAQ suggests using 1454 which makes better use of
the DSL/ATM portion. So my using 1492 would result in some padded ATM
packets (wasted bandwidth). I know I had it at 1492 because when I moved
to Teksavvy, I modifided my router to have MTU of 1454, and even if you
raise it, Teksavvy's router forces it down to 1454.

[JF Mezei]

Post by JF Mezei
1500 whcih I had with Videotron cable down to 1492. I think Ralph allowed
packets of 1492 MTU.

OK, thinking back, it is possible that I had set my router to 1492 but
never actually veryfied what MTU was being negotiated during connections,
so it is possible that Ralph's router also limited MTU to 1454.

[unknown]

Post by JF Mezei
The fine folks at Teksavvy decided that their MTU would be 1452. (MSS 1412).

Isn't everyone supposed to be doing RFC1191 path MTU discovery?

http://rfc.net/rfc1191.html

____________________________________________________________________
Gardner Buchanan gbuchana(a)teksavvy(dot)com
FreeBSD: Where you want to go. Today.

[Steve]

The author is clueless. Even at the time none of that forklore meant
anything. Today the cisco routers take care of everything... what with
millions of people connected to thousands of p2p servers at the same time
you can quickly see the author hadn't a clue what he was even talking about
at the time.

Post by unknown

Post by JF Mezei
The fine folks at Teksavvy decided that their MTU would be 1452. (MSS 1412).

Isn't everyone supposed to be doing RFC1191 path MTU discovery?
http://rfc.net/rfc1191.html
____________________________________________________________________
Gardner Buchanan gbuchana(a)teksavvy(dot)com
FreeBSD: Where you want to go. Today.