> > 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.
If that is what your PPP-clients want, they can ask for it during PPP
negotiation.
I do not like the idea of global default MTU size. If a client works
best with a different MTU size, it should ask for it. If it can't ask for
it, it should be fixed, rather than have the access server ram a single
MTU size down everybody's throught.
With my personal PPP setup, a MTU size of 1500 does instead give me the
best performance, and that is why I set the PPP client to ask for 1500.
> 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 if you want the access server to force protocol settings on
clients. This is NOT what PPP was designed for. It was designed for
client and server to negotiate agreeable protocol parameters.
What you are talking is not a design flaw, but an implementation flaw.
Tom