[c-nsp] PPPoE, MPMRRU and interface MTU

[Andre Beck]

Hi,

On Wed, Sep 07, 2005 at 11:25:56AM -0500, Jessup, Toby wrote:
> Try the easy stuff first.

The easy stuff is of course already in use ;)

There wouldn't be a way to sell sub-1500-MTU-products today were it not
for TCP MSS clamping to hack around it somewhat. Every decent platform
has it.
 
> Before messing with changing protocol encapsulations consider using the
> Cisco ip tcp adjust-mss command. Easy, harmless and likely to fix the
> blocked PMTUD problem for most applications (for anything using TCP
> flows).

If you ask me, MSS clamping is neither easy (except for the fact that
a command exists to do it that you can "drop and forget") nor harmless.
It is nothing but a hack that works with just one single protocol. Well,
the problematic servers in the Internet are reached with this protocol
only, and so it works quite good in reality, but nevertheless it is
bad style to manipulate every TCP SYN in a way that breaks what the
hosts issuing them thought up. I would also expect it to have a per-
formance impact on most platforms, as it requires identifying TCP SYN
segments - and mangling them.

Despite the fact that it is hard (or impossible) to achieve an MTU 1500
preserving path using MP on IOS platforms (at least those I've tested),
this is not actually messing, it is IMO a perfectly clean and easy
solution, as MP has everything to do it. I just can't configure it for
this application on IOS, but that could easily be fixed by Cisco. It
just requires that

a) The MTU of a Virtual-Access interface not be copied stupidly from
   the interface (Dialer or Template) it is cloned from, but set
   according to the PPP LCP negotiation results (down as well as *up*)
b) The MTU of a MP Virtual-Access bundle interface likewise neither
   be copied nor be set by the MRU negotiation, but by the *MRRU*
   negotiation result
c) The user given more control of the MRU negotiation process with at
   least a chance to specify a minimum, maximum and default for
   acceptable MRU as well as special exceptions like "give up on
   trying to force the peer to accept our MRU limits after 5 tries
   that were ignored by them"

I'd imagine something like this:

int dialer1
 encaps ppp
 [...]
 mtu negotiated				<-- There is *no* value known yet
 ppp mtu adaptive			<-- should work on dialers, too
 ppp link mru local min 576
 ppp link mru local max 1452
 ppp link mru local default 800		<-- try to equalize fragment size
 ppp link mru remote min 576
 ppp link mru remote max 1452
 ppp link mru remote default 800	<-- try to equalize fragment size
 ppp multilink
 ppp multilink mrru local 1524		<-- this cmd actually exists
 ppp multilink mrru remote 1524		<-- this cmd actually exists

This would lead to a VA with a negotiated MTU of 800 and up to 1452 should
the peer refuse MP negotiation, or a VA with MP negotiated, which has an
MTU of 1524 or above (the mrru command specifies the acceptable minimum)
and is forced to a fragment size of less or equal 1452, ideally 800 (to
somewhat equalize fragment size of large packets). Whether the default
should be lower than the maximum depends on whether the majority of
users is using MP or not. As long as there is significant non-MP use
it would be better to default to the max so the peer doesn't need to
force negotiation up to 1452. But given the above knobs and handles
would exist, *you* could define it, there wouldn't be some guessing of
all this from the mtu value with limited success. Or allow different sets
of values for the MP and non-MP case, which is easy to do as presence
of MP is announced in the first ConfReq.

A workaround as of now might be to just go with the forcibly set value
of "mtu 1500" and a very small "ppp multilink fragment delay" which
serves as a means to temporally limit fragment size. Of course it
would be nicer to have something like "ppp multilink fragment size 1452"
but there isn't. The obvious disadvantage of this setup is that MP is
then required for proper operation. Should MP be refused and just PPP
be negotiated, the MTU will be too large. This is simply because the
mtu statement is overloaded with concurrent functionality, thus the
above idea of how to separate them.

Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-