Re: Setting MTU (fwd)

Joe Portman (baron@aa.net)
Sun, 29 Dec 1996 14:18:08 -0800 (PST)

> Once upon a time Joe Portman shaped the electrons to say...
> >No, that's just the way it works on a portmaster. On other terminal
> >servers, you can globally set the MTU, or set it on a per port basis, and
> >the PPP service will only negotiate a connection up to that MTU size.
>
> Let me clarify - you cannot set MTU *BY USER* for PPP when users use PAP
> or CHAP. Why? Because MTU is negotiated BEFORE PAP/CHAP so that it is
> set before the userid is known. Therefore it is too late to set it by
> the userid.

> >1500, BTW is just an arbitrary number the PM chooses.
>
> This is not true. 1500 is the default MRU as specified by the RFC. It
> is NOT arbitrary.

To quote you, BFD. A default of 1500 on a modem based link is sub-optimal.
To blindly follow the default without giving me a choice is indeed
arbitrary.

The average modem buffer size, average UART buffer size and a lot of other
real-world factors point to 256, 384, 512 being far better numbers for
modem based PPP links. Real world testing (right here over a period of
months) bears this out.

The RFC's were mostly written well before commercial modem based PPP
became the widespread standard it is today.

Witness the bass-ackwards protocol/authentication dilemma. You must
choose your protocol parameters before you are authenticated.

Only a room full of morons would have designed it that way with the
current environment. Given the previous environment (synch ppp between
routers), it makes a lot more sense.

In any case, stuff the RFC, I have real world needs to back up my request.

> ---cut---
> The maximum length for the Information field, including Padding,
> but not including the Protocol field, is termed the Maximum
> Receive Unit (MRU), which defaults to 1500 octets. By
> negotiation, consenting PPP implementations may use other values
> for the MRU.
> ---cut---

To quote you (again): BFD. That default size is not optimal for the modem
world. In any case, it is not optimal for all customers.

> >choose what they would like their maximum negotiated MTU to be, you just
> >have chosen not to.
>
> We could allow it to be set on the port, yes. And we chose not to, yes.

You could also allow it to be set globally and you have chosen not to.

A real world example:

We ran with a global MTU of 512 for over a year, which solved all kinds of
problems with peoples cheap modems, cheap serial ports (especially macs)
and other consumer grade hardware. Impact on people with good equipment
was minimal.

We can still tune the MTU on any port on any one of our dedicated line
servers without requiring the customer to change a thing, or to use a
script. Works quite well, and a major reason my PM2E's serial ports were
never used. (that and VLSM) :-)

Until broken NT servers (using MTU discovery, but not honoring the
results) forced us to use a default MTU of 1500, we never, ever ran our
serial links with large packet sizes, except at direct customer request.

Many computer/modem combo's these days will choke on 1500 byte packets
delivered with full compression from a high performance terminal server.

One dropped byte means a full 1500 byte retransmission. A few of these and
the customer starts asking "why is my PPP link so _damned_ slow?".

Nuff said,
-----------------------------------------------------------------------------
Joe Portman - Alternate Access Inc. Affordable, Reliable Internet
-----------------------------------------------------------------------------