Subject: Re: draft-ietf-pppext-aodi-01.txt

From: James Carlson <[email-masked]>
Date: Mon, 8 Nov 1999 17:47:20 -0500 (EST)

> >It appears to me that the two are logically independent.  One could
> >choose to implement AO/DI.  Or BACP.  Or both.  The fact that you need
> >to bring up B channels during high demand does not compel the use of
> >BACP.
> 
> I believe the main reason for BACP was to get the phone numbers for the
> B-channels.  You statement is correct that BACP is not needed but it does
> allow the user to know only the X.25 number.  We (Adtran), as well as other
> AO/DI vendors, can run AO/DI without BACP coming up.

Then it's an option and not a necessary feature.  The draft says that
BACP use is required.  (Actually, it's hard to read and doesn't use
the standard language.  As best I can tell, BACP use is not made
optional for AO/DI, and I believe this to be an error.)

(Yes, I realize that what is in the draft is a fait accompli -- that
the draft authors were already shipping it and are just submitting it
for blessing by the wg.)

> >It seems that this is not necessary.  A simpler implementation would
> >signal up a B channel when needed, and begin sending data over it
> >using ordinary load balancing techniques instead of MP.  Since you're
> >assuming TCP/IP operation (which also seems unnecessary), a temporary,
> >non-persistent reordering is harmless.
> 
> What about 2 B-channels?  Multilink is necessary for that case.  For me,
> adding the D-channel in the bundle made things much easier to implement.

Yes, with two B channels you may well want (though not require) MP.
My point here is that you require non-RFC-1990-compliant hacks --
ignoring the minimum sequence number on an otherwise active link -- in
order to do this.  If hacks are necessary just for AO/DI, it would be
nice to put them somewhere other than in an established protocol.  If
they're generally useful, then they belong in RFC 1990, not here.  If
they're not useful, then they should be removed.

> >A side benefit of doing this is that RFC 1990 need not be modified to
> >allow idle member links.
> 
> Like it or not AO/DI is done and out there working.  I thought RFC 1990
> specifies how to fragment PPP packets not require how to chose what link to
> transmit them on.  I don't see how keeping a link idle is violating RFC
> 1990.

Let's start with this:

   Senders SHOULD avoid keeping any member links idle to maximize early
   detection of lost fragments by the receiver, since the value of M is
   not incremented on idle links.  Senders SHOULD rotate traffic among
   the member links if there isn't sufficient traffic to overflow the
   capacity of one link to avoid idle links.

Note that M would be constant if one link were idle.  The RFC doesn't
allow you to ignore an active member link in calculating M.

> >Why is this difference introduced?  There's certainly nothing
> >essential about modifying the Proposed Standard RFC 1598 header format
> >that enhances AO/DI in any way.  At best, it's an unnecessary
> >incompatibility.
> 
> It was decided (not by me) to use "B-channel" type transmission over the
> X.25 channel to make implementation easier to port into existing ISDN
> devices.

Again, there appears to be no good reason here to modify a Proposed
Standard RFC in an incompatible manner.  I fail to see how adding FF
03 between the X.25 header and the PPP Protocol ID actually makes the
implementation any "easier."  In fact, I would expect to have it make
things harder, since you would also likely need to retain RFC 1598
compatibility (unless you're on an isolated network and don't care
about interoperability).

> >>    In the interim, AO/DI recommends that until ISO the call originator
> >>    set the NLPID of the CUD to 0xCF.
> >
> >I can't parse that.
> 
> Why's that?  Implementers of AO/DI are able to decode using that value.

Sorry.  I meant that I can't parse the sentence.  It's not English.

> >>    AO/DI recommends against header substitution by the transmitter.
> >
> >Why modify an existing Proposed Standard?  It may well be cleaner in
> >some regard, but so what?
> >
> 
> I believe there are more deeper reasons.  One being L2TP.  L2TP can't deal
> with RFC 1598 header to well.  Pretending the X.25 link is another B-channel
> link makes things much easier for all.  That equates to faster time to
> market and more compatible implementations.

I don't follow that at all.  The translation between the LAC-to-user
and the LAC-to-LNS formats is extremely obvious for the X.25 case,
isn't it?  The fact that L2TP is a little silly in this matter (it
wants to see the address and control fields) isn't much of an issue.
The translation looks something like:

	X.25			L2TP (PPP) data
	----			---------------
	XX XX (address)
	YY (control)
	CF (NLPID)		-> FF 03
	PPP Protocol		-> Unmodified
	data			-> Unmodified

That certainly doesn't look hard to me.  It ought to be trivial in
comparison to dealing with the LAP-D protocol.

Assuming that inserting two bytes to the front of a packet does not
delay the product to market significantly, modifying the well-
established RFC 1598 doesn't seem to me to get anything faster to
market.  Instead, I would expect it to make things take longer, given
that you've now got two modes of operation.

> >If you're doing this in order to use the MRRU to get around X.25 MRU
> >limitations (the well-known MP-on-one-link hack), then say so.
> >
> 
> The X.25 transport delay will be large compared to the switched circuit.
> Adding the X.25 link in the bundle assures me that packets transmitted will
> always be received and submitted to the application in order when B channels
> are dropped and raised.

If all you're worried about is the transition between D-channel-only
and B-channel-only operation, and not trying to fragment between them
actively, then there are likely to be simpler available mechanisms
than drilling a hole in RFC 1990 to allow idle links and then
carefully specifying all the hacks necessary to handle the timing
problems this introduces.

I think the one reasonable explanation of the use of MP on the D
channel could have been to extend the X.25 MRU using the (I think!)
well-known MP on one link hack.  This hack consists of negotiating MP
with a single link, setting the LCP MRU to the (tiny) X.25 MRU and the
LCP MRRU to something larger (like 1500), and then fragmenting to the
X.25 MRU using MP on that one link in order to make it appear to have
a more normal MRU at the network level (corresponding, of course, to
the negotiated MRRU).

Oddly, though, this draft doesn't reference this usage of MP and
instead appears to advocate modifying X.25's MRU (!).

> >>    For a longer term solution, we may want to consider an extension to
> >>    MP or BAP that would include "Idle-Link" and "Idle-Link-Ack"
> >>    primitives.
> >
> 
> I personally don't think that a modification to the MP/BAP RFCs is
> necessary.  AO/DI is implemented now and we all idle the D-channel link when
> at least one B-channel is up.  It doesn't mean that one cannot receive on
> the idle link (D-channel in this case) it only says to stop transmitting
> fragments on it.

Which, of course, breaks a conforming RFC 1990 implementation of MP,
since the M value never changes, and lost fragments will stall the
connection indefinitely, and requires timers going into and out of
this mode, and does not have the operational experience that regular
MP does.

If the idling-a-link trick is reasonable and useful, then I'd
certainly much perfer to see it part of a 1990 update draft.
Otherwise, burying it here almost seems to guarantee future
incompatibilities.

> >This seems to assume that a single human user sits behind the
> >connection.  This may be true with some PCs, but is generally false
> >elsewhere.
> 
> AO/DI is a DSL competitor and is for humans 99% of the time IMHO.

That's not at all a good justification.  We're not trying to build
single-purpose mechanisms here.  This is precisely the same fallacy
behind RFC 1877 and the IPCP subnet mask option mistakes.

Point of fact, one of xDSL's current target markets is in fact
businesses, where the other end of the link is a small router or
bridge, and certainly not attached to a particular human.

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp