MTU for cable modem connection to shaw.ca

Peter wrote in part:

All good questions.

Those of us with PPPoE are recommended not use MTUs not to exceed 1492 so the encapsulation overhead can fit.

I think there is an optimum for MTU depending on underlying transport layers (ATM or whatever) so there aren't small/short packets routinely created.

-- Robert

Thanks Robert.

I had hoped that another Shaw subscriber would tell me his connection is 1500. I'd like to find that 576 is erroneous.

Regards, Peter E.

576 is the largest MTU that is guaranteed never to require fragmentation in IP. You might try increasing the MTU (but, as Robert said earlier, not necessarily to the full 1500, to allow further encapsulation) and see if it causes any problems. You could also talk to Shaw tech support to see what they say (yeah, I know--a silly suggestion).

Now, if your router and ISP *really* require 576 MTU, you might try reducing the MTU on your attached system(s) to 576 also, so that there is no fragmentation being performed in your edge router.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

It migher or might not be. Unfortunately, I wouldn't necessarily trust another Shaw subscriber _unless_ I had some indication the same technology is used. Many of these consumer telecoms/cableco's have agglomerated systems and often use heterodox technologies.

Perhaps the best thing is to just try different settings and see what you get from a good bandwidth testing site (hopefully in-house).

576 is not horrible -- 9 * 64 . I personally use 1472 (23 * 64) since I'm pretty sure the PPPoE runs on ATM which has 64-byte payloads.

-- Robert

That is incorrect. One can toda and at least in the past often had MTUs smaller than 576 bytes. 576 is the minimum, maximum size for IP fragment reassembly. That is to say a conforming IV (v4) system must be able to reassemble IP datagram fragments into full IP datagrams of at least 576 bytes in size.

Nowadays, and perhaps for a while, certainly in _practice_ using an MTU of 576 bytes would avoid IP fragmentation, but it is by no means a guarantee.

rick jones

That's not quite correct, either. A Data Link used in an IPv4 internetwork *must* support at least a 576 byte MTU; it cannot require IP to fragment messages into smaller chunks. (Of course, the Data Link itself can fragment and reassemble on a given link, transparent to IP, as is the case for 802.11 and ATM. However, the IP MTU is still at least

576 bytes.)

Interestingly, a device that supports ONLY those protocols that use messages that are never larger than 576 bytes (e.g., RIP, SNMP, ICMP) does not even have to include fragment reassembly in order to be IPv4 compliant. This was an important factor for the design of early, SNMP-managed embedded systems (e.g., low cost managed hubs). Fragment reassembly requires additional memory (because fragment buffers must be held until reassembly is complete), and processing power, which would have needlessly added to the cost of simple, managed devices.

I believe it *is* a guarantee, but am open to seeing an authoritative reference (i.e., an Internet Standard RFC) that says otherwise.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

This is always confusing, but I believe that Rick is correct.

The source is RFC 791, page 13:

"All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams. The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information."

Certainly, link layers can cut the size of a packet down, but I do not think that is what this text is expressing. This text says that a RECONSTITUTED IP packet must be capable of being at least 576 bytes long.

Bert

Later-on in the RFC, I believe page 25:

Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled.

Which then implies that one can have an IPv4 MTU of < 576 octets.

rick jones

And not far from there we find:

Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets.

Which gives us a minimum IPv4 MTU of 68 octets.

rick jones

Rich Seifert wrote: < In article , < Rick Jones wrote: (snip) That is incorrect. One can toda and at least in the past often had MTUs smaller than 576 bytes. 576 is the minimum, maximum size for IP fragment reassembly. That is to say a conforming IV (v4) system must be able to reassemble IP datagram fragments into full IP datagrams of at least 576 bytes in size. < That's not quite correct, either. A Data Link used in an IPv4 < internetwork *must* support at least a 576 byte MTU; it cannot require < IP to fragment messages into smaller chunks. (Of course, the Data Link < itself can fragment and reassemble on a given link, transparent to IP, < as is the case for 802.11 and ATM. However, the IP MTU is still at least < 576 bytes.)

That is what I always believed, too. < Interestingly, a device that supports ONLY those protocols that use < messages that are never larger than 576 bytes (e.g., RIP, SNMP, ICMP) < does not even have to include fragment reassembly in order to be IPv4 < compliant. This was an important factor for the design of early, < SNMP-managed embedded systems (e.g., low cost managed hubs). Fragment < reassembly requires additional memory (because fragment buffers must be < held until reassembly is complete), and processing power, which would < have needlessly added to the cost of simple, managed devices.

Such as routers. I believe I used to know routers that would accept only 576 bytes addressed to the router. For forwarded packets, larger ones would be accepted. In the case of a router, I wouldn't expect SNMP if it was simple enough not to do reassembly, but RIP and ICMP. It was most easily noticed with large ping packets.

-- glen

err - 53 byte cell......

payload for a "raw" cell is 48 bytes, with some extra packet level overhead.

but - 30+ cells needed anyway for a 1472 byte packet, so you are unlikely to noice the 1% or so difference...

You are correct. I don't know where I heard 64 bytes.

I will have to readjust -- how much overhead does PPPoE add to IP? Or does that get stripped out at the DSLAM?

Well, 1.6% isn't zero, and I'm more worried about the extra latency. MTU is very easy -- set once and forget. Why not set a number closer to optimal?

-- Robert

Robert Redelmeier wrote in part:

Looking some more, I found:

which indicates MTU=1454 is optimal for PPPoE over ATM .

-- Robert

The story I heard is that when they were working on the ATM standard the US wanted 64, Europe wanted 32 so they compromised on 48.

-- glen