Subject: Re: An MP alternative

From: Vernon Schryver <[email-masked]>
Date: Wed, 8 Apr 1998 09:26:34 -0600 (MDT)

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

> > then why do any MP negotiating?  Given the relatively specialized,
> > specially configured, or known-to-be cooperating peers, what's the point
> > of MP negotiating?
>
> Because the underlying MP negotiation mechanism provides a number of
> worthwhile benefits:
> ...

> > If there is no MP header or fragmenting, then how is this MP alternative
> > different from what I've been calling 'BF&I multilink' for years, what

> It's not different.  Ross Callon and I had a conversation about
> ...

Ok, I guess.
Personally, the only error detecting I see from using MP negotiations is
mis-matched MRU's, and I don't see a problem there.  Why not let the peers
bring up links with varying MRUs?  So what if you have 3 links with 9K
MRU's and one link with 256?  You'd just do the obvious, wouldn't you?
There is nothing except the MRU that the MP negotiation can protect, is
there?

You might use end-point discriminators to ensure that the peers know
that they are doing BF&I.

I think you need more words than what I think are in your draft to avoid
confusion among computers, implementors, and users.  Because at least some
MP installations switch freely between using and not using MP headers
after having negotiated classic MP, I think you need an explicitly
negotiated flag.  Currently, and I think according to explicit words in
RFC 1990, if you do not include an MP header, your packets are outside of
the scope of MP.  They can bypass the MP queues on the sender or the
receiver.  How do you keep one computer from thinking that a PPP packet
without MP header is outside of the scope of MP in the old sense unless
you explicitly negoiate the new scheme?  Having an explicit bit in a
Configure-Request would not only prevent that confusion among computers,
but it would also keep implementors from accidentally agreeing to do
something other than what they intended, and it would help users staring
at PPP packet traces.

I don't understand your position on the MRU vs. MRRU.  It seems that
you need the MRRU <= MRU, and probably <, to accomodate BCP, ECP, or CCP.
Maybe that's what you meant, but that it seemed otherwise implies the
words need to be tightened.

I think it would be a bad idea to declare MRRU=0 to mean BF&I.  Zero is
too likely to be a bogus old-style MRRU requested by a lame old-style MP
implementation.  Just as it's better to make 0 be an illegal instruction
to make applications core-dump sooner, it's better to make MRRU=0 illegal.
Also consider the many years of hassles we have had in IPCP with the
special meaning of 0.  We should have enough LCP Configure-Request numbers
remaining if you really need an explicit negotiation of BF&I.  Personally,
I don't see the utility of such chit-chat, other than perhaps end-point
discriminators and/or the LCP ID.

Your draft should mention that for IP protocols, it is generally desirable
but not absolutely vital to not reorder packets, and why (e.g.  TCP
performance reductions due to reordering).  Your talk of hashes sounds
fine to me, but I am bothered by what I infer to be the notion that such
schemes are 100% perfect in preventing re-ordering.  Hashing aint perfect
in practice.  For example, when you add or remove link in the bundle, your
hash function is likely to hiccup and could re-assign a stream to a
different link, and so allow a little re-ordering.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Apr 1998 10:33:38 -0400

> mis-matched MRU's, and I don't see a problem there.

Mismatched paths (over SONET/SDH infrastructure) or misidentified
peers can be far more hazardous.  As are links where the peer IP
address is not what was expected.  IPCP nicely handles the latter
checks, and MP nicely specifies that there be only *one* IPCP
negotiation session per bundle, which simplifies the error cases.

>  Why not let the peers

The "obvious" is not so obvious when the implementation is in
hardware.  Knowing how and when to fragment (calculate MIN(link-MTU)?)
depending on when the link is chosen is one part of the problem.  The
other part of the problem is that mismatched MRU/MTUs among links may
well be configuration errors.

> There is nothing except the MRU that the MP negotiation can protect, is

IPCP peer addresses.

> that they are doing BF&I.

Yes; that's essentially the point here.  I could have written an I-D
which says just that, but then it begs a number of questions, such as
what to do in any error cases.  I believe a tighter description of the
usage is needed.

> you explicitly negoiate the new scheme?

All of the data is "outside the scope" in the old sense.  None of it
is sent with MP headers at all.  None of it is sequenced or reordered.

If this option is chosen, there's only one way to send data and
negotiate per this I-D.  The old in-or-out-of-MP ambiguity doesn't
exist.

> Having an explicit bit in a

That's fair.  Certainly MRRU==0 is noticable and distinguished, but
I'm not opposed to a separate option.  I'll try proposing one.

> words need to be tightened.

No.  I'm not reconstructing at all, so there's no MRRU at all.  Since
there's no reassembly, I need to show that the peer's MRU is exposed
to the network layer as the local MTU, just like with non-MP links.

> implementation.

Another good reason to use a separate option.  I'd like to think
people didn't do dumb things like this, but I can believe they did.

> different link, and so allow a little re-ordering.

Yes, link add/drop can cause a "little" reordering as the hash map
changes.  I should note this.

-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02173-7999 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" ------- http://id.wing.net/People/carlson/ppp