Subject: Re: draft-heath-ppp-v44-02.txt

From: [email-masked]
Date: Wed, 15 Jan 2003 13:09:21 -0800

James

It looks like I misunderstood the way a multi-link bundle is negotiated 
via CCP.  If they are separately negotiated, as you say, then Individual 
Link Mode is not defined correctly.  In fact that mode is probably not 
necessary at all since each link can negotiate and use Multi-Datagram 
mode, providing a history number is not needed to keep the links separate 
at the receiver.

Maybe the best thing would be to remove Individual Link Mode if multiple 
histories are not used in real PPP implementations anyway.

thanks
Jeff

James Carlson <[email-masked]>
01/15/2003 12:42 PM

        To:     [email-masked]
        cc:     [email-masked], [email-masked], Karl Fox <[email-masked]>, 
Thomas Narten <[email-masked]>
        Subject:        Re: draft-heath-ppp-v44-02.txt

[email-masked] writes:
> thanks for your comments.  I will change the ID to include the same type 

> of sequence and recovery mechanisms used in other RFC's.
> 
> It seems like you are also saying that no one will use what I describe 
as 
> "Individual Link Mode" which is multiple histories over a PPP link.  If 
> that is true, do you think I should I just remove that mode. 

Thanks for pointing that out; I'd missed that on the first read of the
draft because I'd incorrectly assumed that this was just a
redocumenting of RFC 1962 "Individual Link" mode operation.  It's
apparently not.

For RFC 1962 individual link compression, each link is independent,
and the peers need to negotiate CCP 80FB independently on each link.

The mechanism described in this draft appears to be different.  If I
understand it correctly, CCP using 80FB is being negotiated once at
the bundle level (meaning that all links must then use it), and the
multiple dictionaries feature is used to separate out the traffic.

Why does this draft redefine CCP operation in this way?  How does the
initial negotiator predict how many dictionaries might be needed?
What happens if the allocated number of dictionaries is exceeded when
MP link N+1 joins the bundle?

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: James Carlson <[email-masked]>
Date: Wed, 15 Jan 2003 16:28:11 -0500

[email-masked] writes:
> via CCP.  If they are separately negotiated,

RFC 1962:

2.1.  Sending Compressed Datagrams
[...]
   When using multiple PPP links to a single destination, there are two
   methods of employing data compression.  The first method is to
   compress the data prior to sending it out through the multiple links.
   The second is to treat each link as a separate connection, that may
   or may not have compression enabled.  In the second case, the PPP
   Protocol field MUST be type hex 00FB (Individual link compressed
   datagram).

RFC 1990:

5.  PPP Link Control Protocol Extensions
[...]
   Compression may be used separately on each member link, or run over
   the bundle (as a logical group link).  The use of multiple
   compression streams under the bundle (i.e., on each link separately)
   is indicated by running the Compression Control Protocol [5] but with
   an alternative PPP protocol ID.

> as you say, then Individual 

Correct.

> histories are not used in real PPP implementations anyway.

I can't say I've ever seen it used, except when doing testing.  ;-}

The problem is that (in implementation) you need to have a reason to
want to use one history over another when deciding how to compress a
given packet.  Other than hashing over the 5-tuple (and hoping that
the flows related to incompressible data cause only *some* of your
histories to thrash), I haven't seen any concrete ideas put forward.

Given the environments in which data compression is used (i.e., lower
speed links often associated with small numbers of users and flows),
it's not clear that there are important benefits to be gained.