Subject: Re: strange boundary cases in RFC 1990 (Multilink)

From: [email-masked] (Vernon Schryver)
Date: Mon, 12 Jan 1998 18:40:46 -0700

> > We made a mistake by having the MRRU option negotiate two things:
> > Multilink and it's MRRU.  It should have always been seperate LCP
> > options.  One option for Multilink: either you agree on that or you
> > don't.  Another option for MRRU.  That way you can refuse to negotiate
> > MRRU (which is already the case in LCP for MTU) if you won't do
> > anything other than the required 1500 bytes, without refusing to do
> > Multilink.
> 
> I don't see how this follows. If server A doesn't want to do multilink
> unless server B's MRRU is at least 1500, then who is server B to argue?
> Server A is entitled to require this if it wants.

I agree with the second position, in part because as was hashed in the
mailing list, the intent for RFC 1990 was to follow the LCP default MRU
size.  Given the RFC 1990 requirement that every MP system support an
MRRU of 1500, it is wrong for any system to persistently demand other
than 1500 until the link dies.

In other words, there are only 3 cases:

    0. no RFC 1990 multilink
    1. desired MRRU other than 1500 and RFC 1990 multilink on
    2. desired MRRU=1500 and RFC 1990 multilink on

Consider how many Configure-Request options you want in each case,
whether you want an option separate from the MRRU option to request
MP.  Case #0 is irrelevant.  In case #2, a second multilink option
would be redundant, conveying no information but wasting bandwidth.  In
case #3 you could use either a pure "give me MP" option or you could
use "MRRU=1500" to signify "give me MP."  It is more simple (or at
least no more complicated) and more economical in bandwidth to do as
RFC 1990 says and use "give me MRRU=1550" to mean "give me MP with pure
default parameters."

> Clearly you can't have it "half-way", so therefore if one half isn't
> working, you have to call the whole thing off.
> 
> That is, the spec should change so that MRRU must be successfully
> negotiated in BOTH directions, or else multi-link is not valid at all

If the only kind of multilink you support is RFC 1990, and if you have
or might have more than one link in the bundle, that position
makes sense.  However, what if you also support what is variously
called "load balancing" or "BF&I" (non-standard but common) multilink?
Also, what if you will never have more than one link the bundle but
want the sequencing or fragmentation provided by RFC 1990.

Vernon Schryver,  [email-masked]

---

From: Archie Cobbs <[email-masked]>
Date: Mon, 12 Jan 1998 18:23:03 -0800 (PST)

> called "load balancing" or "BF&I" (non-standard but common) multilink?

Sorry, should have said "or else *RFC 1990* multi-link is not valid at all".
Of course, other things would still be possible.

> want the sequencing or fragmentation provided by RFC 1990.

Is this case really worth the trouble? I've never heard of anyone doing
that, but there may be a good reason to. Care to elaborate?

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com