Subject: Re: An update to LBD

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Apr 1998 11:25:18 -0600 (MDT)

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

> ...
>    The main disadvantage to the current MP technique is that it does not
>    constrain the fragmentation which may be done by the peer.  For sys-
>    tems employing general purpose CPUs in the data path and with
>    scatter-gather direct memory access (DMA) capability, this is often
>    not a problem.  For systems with very high bandwidth capabilities,
>    these features are often infeasible, and this problem makes MP unus-
>    able.

I think that slightly misses the point.  What you are trying to avoid is
not merely fragmentation by the sender, but two other things:
    1. fragment reassembly by the receiver
    2. packet (and fragment) re-ordering by the receiver.

It's easy, even in fast hardware, to fragment packets as you send them.
(By "fast", I mean silicon GBytes/second, albeit not in routers or
bridges.)  The bigger hassles are reassembling arbitrary sized fragments
and dealing with arbitrary orderings of the packets.  IP fragment
reassembly is messy, but PPP MP reassembly and re-ordering is far worse.
The PPP MP re-ordering requirement, including detecting and dealing with
lost packets and fragments requires a lot more machinery.

>    This draft describes a method similar to and compatible with MP for
>    detecting multiple links to the same node, but without the fragmenta-
>    tion or reordering protection of MP.  Instead, datagrams are distri-
>    buted without MP headers among the links in the bundle in any con-
>    venient manner, including based on a hash or on round-robbin service.

I don't see how this scheme is "compatible with MP."  It is "similar" and
"related," and it might be "semi-compatible" or "upward-compatible."  It
is not purely "compatible" because you cannot connect a typical PPP
implementation that supports RFC 1990 to an implementation that supports
this proposal and have things work well.  On one hand, an implemenation
of this scheme would not like MP fragments from RFC 1990 implementations,
and there are RFC 1990 implementations that would not appreciate not
receiving IP packets without MP headers while there are several links in
the bundle.

> ...
> 2.  No-Fragmentation Configuration Option Format

>                                ... Implementations MUST NOT Configure-
>    Nak this option.

Why not Configure-Nak for it?

>...
>    A summary of the No-MP-Headers Configuration Option format for LCP is

> ...
>    If this option is specified, then the No-Fragmentation option is
>    unnecessary.  Fragmentation without MP headers is not supported.

Instead of "not supported," how about "impossible"?

>                               ...  Implementations MUST NOT Configure-
>    Nak this option.

Why not?

vjs

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Apr 1998 14:34:14 -0400

> lost packets and fragments requires a lot more machinery.

That's close to the point.  There is also the issue that IP reassembly
is done only by the host at the end of the connection.  That host is
(somewhat) required to keep up with the transport and application
layers of things, so the overhead of IP or even MP is not much.  MP
(like PPP generally) is not only for end nodes but is also for links
at the core of a network.  In general I believe it is a good
philosophy to avoid reassembly at the core of the network and allow
only the end nodes deal with it.

Thus, I don't want MP fragmentation and I don't want MP reassembly and
I don't want MP reordering.  All of these are painful.  (Note that I
lump in MP fragmentation.  Yes, it's easy even at high speed, but it's
also useless if the corresponding reassembly can't be done.)

But I do like (well, after having lived with it for a while) the MP
model of negotiating parallel links between hosts.  If you can propose
a reasonable alternative that detects the error cases that MP can
detect and gives enough specificity that compatible implementations
are likely, then I'm all ears.  I agree that BF&I does work, and I
agree that there are compatible versions.  I'm *very* uncomfortable
without at *least* having a BCP which says how this should be done in
excruciating detail.

> of this scheme would not like MP fragments from RFC 1990

Nor would it ever see them -- the negotiation is such that the bundle
won't establish itself that way.

I see it as "compatible" since it will resolve to the right set of
parameters if both support LBD (use LBD), one exclusively supports it
(no MP at all), or neither supports it (use regular MP).

> receiving IP packets without MP headers while there are several links in

Nor would this be an issue, given that it must be negotiated and
agreed to by the peers.  Do any PPP implementations send Configure-Ack
for options that they don't even understand?

> Why not Configure-Nak for it?

It's a boolean, like short sequence numbers.  Except for an unsolicted
Nak, there's nothing that can be hinted here.  Either the peer
implements it, or it doesn't.  Allowing a general Nak doesn't make
much sense.

> Instead of "not supported," how about "impossible"?

Pretty close.  I suppose you could use the old ISO 7776 multilink with
this, but, then, that would be rather stupid.

-- 
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

---

From: John Bray <[email-masked]>
Date: Fri, 17 Apr 1998 12:42:19 -0700 (PDT)

On Fri, 17 Apr 1998, James Carlson wrote:

(snip)
> implements it, or it doesn't.  Allowing a general Nak doesn't make

I agree, there seems little point in including this in an unsolicited
NAK.  It would mean "I want you to tell me not to fragment".  If you
don't want to fragment, you don't have to, you don't need to tell the
peer to force you not to.

John