> > 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.
Right. (sarcasm mode on). My clients (thousands of them) have not a clue
as to what MTU they want, and by your own admission, using PAP (the
preferred method of negotiation for 90% of my users), they cannot ask for
it anyhow. (sarcasm mode off)
> I do not like the idea of global default MTU size.
MZ, who the hell cares what you like or don't like? I get asked for things
I don't particualrly like all the time. I provide them (if possible), or
facilitate them because that's how I get paid.
> If a client works best with a different MTU size, it should ask for it.
Again, most of the people I serve have no clue as to what MTU size is or
how to change it. I dare you to pick an ISP at random, sample his
customers and find 1% of them that even know what MTU is. It's much, much
simpler to make a tweak in the term server, and watch the results, rather
than walk 2000+ customers through changing their MTU size.
> 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.
Again, sir. Who cares what _you_ want.
I'm telling you what I as a customer want from Livingston, based on my
(not small) experience as an ISP. My simple minded Linux based term
servers can do it (and a heck of a lot more). My ascend Maxes can do it.
My PM(whatevers) cannot.
I'm still waiting to hear _valid_ technical reasons why it cannot be done
(none so far). I have heard quite a bit of rhetoric and opinion.
> 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.
Yes, maybe for you.
Again, I don't care what works best for you, sir. I think I know what
would be best for my network and customers. You simply cannot know my
network or needs better than I. I do know that running with the MTU set at
1500 causes problems with many customers. I would like the ability to
change that (and I have in the past with other vendors equipment).
> > 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.
Right. (sarcasm here). It is poorly designed for the vast majority of the
cases where it is used, in a commercial environment. And yes, in the
negotiations, I should be free to say: NO!, that's wrong. we will do
it THIS WAY.
A global or per port MTU/MRU setting (and they are not quite
complementary), allows me to get around one major flaw in that design.
> What you are talking is not a design flaw, but an implementation flaw.
Tell me the difference, beyond semantics. :-)
Later,
Joe