Subject: Re: picking an MRRU for MP

From: Vernon Schryver <[email-masked]>
Date: Sat, 27 May 2000 07:31:07 -0600 (MDT)

> From: James Carlson <[email-masked]>

> ...
> > I would prefer that the code choose a "good" value for the MRRU. Probably
> > based on the configured MRU values for the links that could be bundled
> > together so that the customer's settings for the MRU gets reflected into
> > the MRRU.

I don't think you can escape that easily.  Yes, an arbitrary value is ok
for your initial Configure Request, but how do you respond to values in
Configure Nak's or Configure Requests from the peer?  How do you know
whether to ignore or go along with a Nak, send a Nak in response to a
Configure Request, or refuse to bring the link up?  I think you must
compute what your code is willing to receive (perhaps limited above by
your buffering machinery) and what it needs to send (perhaps limited below
by what you PPP code has already told the upper layers about IP, whether
you're doing bridging, and what you hope do do with ECP and CCP).

> ?  There's no particularly good relationship between MRU and MRRU that
> I think you can use here.  MRRU on MP links is basically the IP MTU.
> The MRU is hidden by MP and constitutes the maximum fragment size.
> ...

Yes, except that the MRRU must be large enough to hold any PPP overhead
plus an IP MTU or if you're bridging, an Ethernet (or other) datagram.
The PPP overhead I'm thinking of is for CCP, ECP, and probably something
else.

Vernon Schryver    [email-masked]

---

From: [email-masked]
Date: Mon, 29 May 2000 10:58:20 -0400

James,

> As a general matter, I absolutely hate software that
> thinks it knows better than I about what I need to do
> in all cases.
> ...  AIX is after all Unix, not Windows.  ;-}

<g> Yes, I agree in principal with what you're saying. But speaking for
myself, I often have trouble locating the correct design balance point.
Hence this note requesting feedback about choosing the MRRU.

As AIX is not Windows, it also true that the AS/400 ... the platform I'm
working for ... is definitely not AIX. there is a history and (I think) a
strong customer preference on the AS/400 for a *CALC configuration
parameter. A cynical explanation of *CALC might be: "I don't know. I don't
care. I just want this frickin' thing to work because it is just a means to
an end that I have not reached yet. Machine, YOU figure it out and stop
irritating me!"

This is the option I'd prefer to provide my customers.

However, your comments do have me reconsidering exposing the MRRU as a
customer configuration value. But I still feel that all this does is toss
my ignore about the MRRU over the fence into the lap of an even more
confused customer. And just what is the point of that?

When and why would someone using MP want to choose a MRRU value larger
than, say, 1524 bytes (or so)?  And, most important to me: Does this reason
apply to my customers? The type of physical links we could bundle together
won't be much different that what Windows can do: aynch (or synch) modem
over a phone line and basic rate ISDN.  Given this context, is it really a
benefit to a customer to flog s/he with another configuration choice? Or is
the way Windows does it sufficient enough to be preferable?

-john martz, 8-852-5539,  [email-masked]
IBM AS/400 TCP/IP PPP development (and stuff)

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 29 May 2000 09:45:19 -0600 (MDT)

> From: [email-masked]

> apply to my customers? ...

I think a important questions are:

 1. How is the IP MTU for your PPP link computed?
 2. How is the TCP MSS computed?

In a typical UNIX box, the IP MTU is the related to the MTU of the so
called network interface.  For example, if the network interface has a
physical MTU of 1518, but has a 14 byte header and 4 byte trailer, then
the typical UNIX system will use an IP MTU of 1500.  If the interface
has an MTU of 1524 (obtained from a PPP peer's MRRU value in its
Configure-Request) but it is using CCP over instead of below MP, then
the IP MTU will be about 1518 (assuming no special considerations).

In many UNIX boxes the TCP MSS is computed from the IP MTU and.  For
example, ignoring complications such as TCP-LW, if the IP MTU is 1500,
then the negotiated TCP MSS will be 1460.  If of the two TCP peers' IP
MTU is 1518, then it is likely to ask for a TCP MSS of 1478.  In some
boxes, the requested TCP MSS for all TCP connections even on Ethernets.

Most BSD dervived TCP/IP implements cannot understand a network
interface with an IP MTU that changes.  At best, you must turn down
the interface to let IP know that the interface's MTU has changed,
and that can have distinct unpleasant effects on applications.  What
does your code do when CCP is negotiated after LCP?  Does it renege
on the initial IP MTU negotiated and reported to the IP code?  What
happens if the CCP scheme negotiated changes?

Slogging through the "IP fragmentation considered harmful," "PMTU
Discovery," "blackholes," etc. swamps would need 1000's more words.  So
let's just say on many systems, an IP MTU that changes or that is not
one of the familiar values is distinctly undesirable.

So what does your code do when it encounters a PPP peer that wants a
strange PPP MRRU, MTRU, MRU, or MTU?  If you just go along with the peer,
you'll need to worry about those swamps.  If you don't, your customers
will probably find some lame PPP peers that won't work with your code.
Thus, what choice do you have except well chosen default values and
knobs controlling the values for emergency use?