> On Sun, 29 Dec 1996, Tom Samplonius wrote:
>
> > > 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)
No, you didn't get this quite right. Using PAP the client software
still has a choice of what MTU size to use. It is just that that MTU size
can not be specified via a RADIUS entry.
> > 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.
I said that, not MZ. The quoting was clear, and the From: line intact,
so I'm not sure where you went wrong here.
> > 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.
Client == PPP TCP/IP product. I'm not at all talking about what users
do.
> > 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).
I'm also a customer of Livingston (and Ascend). I like the way the PM
series handles this.
Of course, we distribute custom install kits with an optimized PPP
TCP/IP stack, so we have complete control of both ends. This solves many
other support issues too. The software clients that can handle 1500, ask
for 1500, those that don't ask for something else.
> > > 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. :-)
If a particular product negotiates a 1500 MTU size, it sure as hell
better be able to handle it.
> Later,
>
> Joe
>
>
>
Tom