Subject: Re: Silent Packet Loss & Header Compression

From: Ignacio Goyret <[email-masked]>
Date: Wed, 23 May 2001 08:28:38 -0700

At 09:56 AM 5/23/01 -0400, James Carlson wrote:
>> Does this sequencing have the additional benefit of helping to overcome the
>> problem of  silent loss of packets? (Which can have unpleasant effects on
>> Van Jacobson decompressors.)
>
>That and CCP problems, yes.  Of course, it's not at all clear to me
>*why* you would want to run VJ over the tunneled portion of the
>connection.  It doesn't help there at all.
>
>Basically, this reveals a known architectural flaw in L2TP.  There's
>no good reason not to allow differences in the negotiated options as
>seen between the "client" and LAC versus between the LAC and LNS.  In
>other words, it's perfectly legitimate for the LAC to negotiate VJ
>compression with the client by adding and stripping the necessary IPCP
>option on the fly, and leave the LNS out of the equation.  The LAC
>would then maintain the VJ state on the serial link and the LNS would
>see regular IP frames only.  As long as the translation is done
>correctly, it's completely transparent, and it repairs substantial
>flaws in LCP renegotiation, CCP operation, and SLI semantics.

That would fail fatally if the client is using MP since no single LAC is
guaranteed that it will have access to all the channels composing an MP
link, which is one of many reasons why LACs should not do anything like that.

---

From: James Carlson <[email-masked]>
Date: Wed, 23 May 2001 12:04:12 -0400 (EDT)

> link, which is one of many reasons why LACs should not do anything like that.

Running MP over L2TP over a lossy or delay-prone network is a bad idea
to begin with.  Having the MP links bundled in a LAC-local manner (as
with Bay's MMP) and then representing the bundle as a single PPP
session to the LNS is a much better answer.

Note that because of the Endpoint-Discriminator issues, MP over L2TP
where the LAC endpoints are *not* reasonably local to each other just
doesn't work anyway.

-- 
James Carlson, Internet Engineering       <[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