Subject: Re: LCP renegotiation

From: Philip Rakity <[email-masked]>
Date: Thu, 12 Feb 1998 12:41:29 -0800 (PST)

Andy,

If ADSL technology takes off, there will be many millions of lines running
AAL5/PPP.  The problem should be fixed.

Concerning MRU size, The 1500 byte default MRU fails when bridging is
negotiated, since the bridge frame is larger than 1500 bytes.  It is true
that IP works, but that is only true if other Pseudo NCPs such as
compression and encryption are not negotiated.  A value of 1600 bytes (if
not negotiated) solves this problem and will work since there are no L2TP
systems in the field today.  My collegues would prefer 2000 bytes !!

Philip Rakity
FlowPoint

On Thu, 12 Feb 1998, Andy Valencia wrote:

> There appear to be three issues which are most immediately in front of the
> WG.
> 
> 1. non-HDLC PPP and L2TP
> 
> I strongly recommend that non-HDCL-like media approach the question of
> operating within L2TP by considering L2TP as it stands today, and adapting.
> I believe this will require aping some HDLC characteristics as the PPP frame
> enters the tunnel.  This will at a minimum include address/control/proto,
> and probably blithely ignoring any place ACCM rears its head.
> 
> The question must not be whether L2TP could be better adapted to accomodate
> AAL5, but whether devices doing PPP over AAL5 can be made to fit into L2TP as
> described.  Otherwise we will stop L2TP, laboriously construct more
> protocol, stop L2TP until an interoperability workshop, refine the
> description, create more protocol, and finally interoperate.  We'll be back
> to request advancement in, say, another year.
> 
> Of course, by this time, PPP-over-FOO will have appeared, and off we go
> again.
> 
> 2. Outbound dial
> 
> I was remiss in omitting outbound dial as a special case of LCP treatment.
> In many ways it resembles the "PPTP scenario", as the LNS takes primary
> responsibility for LCP, but it has the additional wrinkle that the LAC did
> not initiate the action.
> 
> If I were to solve this with an operational note, I would recommend that the
> default ACCM quotes ^S and ^Q, and that the LNS will always negotiate
> towards this mask unless a different one has been administratively set.  I
> know that you could shoot for all-0's and work with 99%+ of all modern
> LAC's, but masking ^S/^Q also covers 99% of the legacy equipment which
> exists, too.
> 
> For MRU, I would recommend sticking to the PPP mandated value unless
> otherwise set by administrative control.  Again, this covers the 99% case,
> and even in cases where some other value was desired, it is usually possible
> for the special case to jump through a known hoop, rather than operate
> against a vague haze of generality.  This was our experience interoperating
> with Shiva in this area.
> 
> 3. Snooping LCP
> 
> You do NOT want to create a protocol which has the LAC snooping LCP.  In my
> opinion, it's the wrong place to solve the wrong problem.  If the LNS owns
> LCP negotiation, the immediate goal of the WG is "simply" to document the
> parameters which should be coordinated to guarantee operation.  If the
> incremental benefit of automation of this is found compelling, only then
> would new AVP's be called for.  Whoever's doing LCP negotiation has a set of
> information which guides their actions.  Some of this information may be
> determined dynamically (to wit, renegotiation on an LNS after the LAC has
> already done it and then forwarded--he can look at the previous negotiation
> parameters), others known a priori (operational notes).  Over time we may
> add mechanism whch moves items from the latter set to the former.  Again, I
> do not think it prudent to hold any L2TP advancement until the latter set
> has become the null set.
> 
> 						Regards,
> 						Andy Valencia
>

---

From: Andy Valencia <[email-masked]>
Date: Thu, 12 Feb 1998 13:05:18 -0800

[Philip Rakity <[email-masked]> writes:]

>AAL5/PPP.  The problem should be fixed.

That's fine.  As a new technology emerges and gains operational experience,
we do more protocol work to support it.  If our protocols don't advance
because we're always defending against each possible future, our protocols
don't advance at all.

We already DO have millions of lines running HDLC-ish PPP.  L2TP tells how
to enable a new class of service.  There's nothing in any of these
discussions which says (1) L2TP can't do what it needs to now (through a
mixture of explicit protocol options, plus operational notes), and (2) can't
be enhanced within its framework to handle futures.  This protocol needs to
move forward.  It has rough consensus, it has running code, and we have
proof by existence in L2F and PPTP that it works in the Real World.

							Andy Valencia

---

From: Richard Shea <[email-masked]>
Date: Thu, 12 Feb 1998 16:57:01 -0500

Andy Valencia wrote:
> we do more protocol work to support it.

Ideally, as new access technologies are introduced the L2TP protocol
should not have to change at all.  L2TP is supposed to tunnel PPP, a
datalink protocol.  It shouldn't be specific to PPP-over-HDLC,
PPP-over-ADSL, PPP-over-whatever.  I know that having LCP options
present for HDLC framing screws this up.  And any future technology
which adds physical-layer-dependent options to LCP will cause the same
problems.  And we can't even foresee that at this point.

Why can't we simply have L2TP have the option of tunneling HDLC or not
tunneling HDLC?  Then any non-HDLC protocol that doesn't add LCP options
to the picture can fit into L2TP "today".  And we don't have to have the
LAC stripping or not stripping the HDLC address and control fields if it
doesn't need them?  And more importantly, the LNS won't ask for ACFC
options when they are not appropriate.  Afterall, the ppp client dialing
into the LAC isn't even supposed to "know" that its traffic is being
tunneled.

In the future, if access technologies add LCP options to PPP then we
will deal with that when it comes.

It seems to me we have a non-negligible problem with a simple solution. 
Isn't this a change that could be made even to a Proposed Standard?  I
don't understand the resistance.  I also don't want to hold up the spec,
but I don't see that this necessarily DOES hold up the spec from
advancing.

> If our protocols don't advance because we're always defending
> against each possible future, our protocols don't advance at all.
> 

I think protocols advance and don't hung up on possible futures when
they are defined in such a way that they don't have dependencies on
layers below or above them.  Why is TCP/IP ubiquitous?  In large part
probably because all you need is a TCP port number and things start
working.  TCP doesn't worry about futures of what it will carry because
it was defined not to have dependencies on what it carries.

I honestly see it as a weakness of the protocol as currently defined (or
at least as currently explained!) that we are even having this
discussion.

> proof by existence in L2F and PPTP that it works in the Real World.

Again, I don't think we have to stall the protocol, it shouldn't be a
huge change.  And may save us countless future changes and amendments
down the road.

Richard.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Richard Shea                                  [email-masked]
Bay Networks, Extranet Access                     978-266-1011 x210

---

From: Brian Lloyd <[email-masked]>
Date: Thu, 12 Feb 1998 14:11:03 -0800

First, a disclaimer: I haven't been paying a lot of attention to L2TP so
far so please forgive me in advance for saying something obviously wrong
and/or stupid about L2TP.  But that has never stopped me in the past so ...
;^)

At 12:41 -0800 2/12/98, Philip Rakity wrote:
>negotiated, since the bridge frame is larger than 1500 bytes.

We thought of that back in the dim, dark, recesses of time long passed.
That is why multilink can run over a single line.  Go ahead and negotiate
any MMRU you want and the MP will do intra-network fragmentation for you.
That was the only way to bridge 8K FDDI frames over PPP links that had an
MTU of 1500 octets.

>It is true

Several years back the folks trying to create multilink made the
presumption that PPP is a link protocol.  It wasn't and it isn't.  PPP is a
datagram-based networking protocol for degenerate networks of two nodes.
OK, so it also just happens to have its own link protocol too.  In any
case, if you view it as both the link *AND* the network layers (no,
IP/IPX/whatever is the *internetwork* layer) you will find that it becomes
relatively easy to cleanly separate the functionallity.

Treat your link differently from your network.  Multilink provides a means
to "hide" the link-layer related "problems" from the internetwork layer.
So, has anyone considered using multilink over a single logical link as a
way to hide the problems at the LCP layer for L2TP?  Do so and your concern
about what is negotiated at the LCP layer becomes moot.  Who cares whether
the framing is sync or async; who cares what the ACCM map looks like; who
cares if you are doing link-layer compression or encryption.  That is
between the LAC and its client.  Let MP serve to manage the L2TP tunnel as
it would any other 2-node point-to-point network.

OK, I'm sorry.  I should have kept my mouth shut.  Throw a few rocks at me
and I will go (more or less) quietly.

Brian Lloyd                                    Lucent Technologies
[email-masked]                       3461 Robin Lane, Suite 1
http://www.livingston.com                      Cameron Park, CA  95682
+1.530.676.6399 - voice                        +1.530.676.3442 - fax    O-

---

From: Philip Rakity <[email-masked]>
Date: Thu, 12 Feb 1998 14:56:30 -0800 (PST)

Brian,

There is no support for MLP in PPP over AAL5, that is why I suggested
making the default MRU large.

regards,

Philip Rakity
FlowPoint

---

From: Brian Lloyd <[email-masked]>
Date: Thu, 12 Feb 1998 14:37:53 -0800

At 13:57 -0800 2/12/98, Richard Shea wrote:
>datalink protocol.

Network protocol.

>It shouldn't be specific to PPP-over-HDLC,
>PPP-over-ADSL, PPP-over-whatever.

100% correct.

>I know that having LCP options
>present for HDLC framing screws this up.

It does no such thing.  You ack the options then ignore them.  For
instance, PPP allows one to offer the ACCM option over sync links where
they have no meaning.  ACK the option then ignore it.

>And any future technology

So treat PPP as it really is, i.e. both a link and a network layer
protocol.  Negotiate LCP locally and don't worry about it beyond that.

>into the LAC isn't even supposed to "know" that its traffic is being

And for that matter, the LNS probably doesn't need to know the details of
the link.

>...

Aha!  You and I seem to be in agreement.  Maybe I am not so crazy after all.

---

From: Richard Shea <[email-masked]>
Date: Thu, 12 Feb 1998 18:27:45 -0500

> and/or stupid about L2TP.  But that has never stopped me in the past

You're forgiven... ;)

[..]
> it would any other 2-node point-to-point network.

Link-layer compression and enryption isn't between the LAC and its
client, it's between the LNS and it's client.  ACCM escaping happens
between the LAC and its client, but the ACCM value is in some cases
negotiated between the LNS and the client.  Whether the framing is sync
or async is really unimportant from the LNS's point of view from a
packet handling standpoint anyway.

I'll have to think about the MP suggestions for handling MTU some more,
but my initial feeling is that it won't be too helpful.

I think the MP suggestions (if I understand them correctly) are too
divergent from the current state of L2TP for consideration.  If what you
are saying is that single link would be negotiated between the LAC and
client with the bundle terminated at the LNS, this is too far afield
from the operational model of L2F/PPTP/L2TP for consideration (IMO).  I
have a feeling Andy will agree with me on this one... :)

Richard.

---

From: Brian Lloyd <[email-masked]>
Date: Thu, 12 Feb 1998 15:30:58 -0800

>making the default MRU large.

"... those who ignore the lessons of history ..."

Then negotiate a larger MRU.  What's the big deal?

---

From: Philip Rakity <[email-masked]>
Date: Thu, 12 Feb 1998 15:47:52 -0800 (PST)

Brian,

The forgive me for not fully explaining the context of the 1500 byte MRU
discussion.  In L2TP, the client computer sends data to a LAC which
forwards the data to an LNS.  The LAC acts like a bit pump.  The LAC needs
to allocate space for the PPP frames that it receives/sends to the client
computer/LNS.  The question is how big must those buffers be for the LAC
to work.  

There are two proposals to solve this problem.

a) By definition they must be size X (where X will be defined in L2TP
spec)

b) Have the LAC tell the LNS its buffer sizes, so that the PPP negotiation
preformed by the LNS can be properly done.

regards,

Philip Rakity
FlowPoint

---

From: Brian Lloyd <[email-masked]>
Date: Thu, 12 Feb 1998 16:00:14 -0800

At 15:27 -0800 2/12/98, Richard Shea wrote:
>divergent from the current state of L2TP for consideration.

I'm sorry.  I didn't realize that the protocol had reached standard state.
I thought it was going to proposed standard.  That is what I get for tuning
in late.

>If what you

Oh, I understand and that is why I don't think anyone will take my comments
too seriously.  It strikes me that there is a possibility that the current
L2TP draft protocol may be as flawed as the originally proposed Multilink
protocols.

My point was to suggest a different way of looking at the problem.  I used
Multilink because it has been down this road before.  *Maybe* multilink is
appropriate and maybe it isn't.  I *suspect* that L2TP might benefit from
using the network layer model for PPP instead of the link layer model.  The
partitioning of functionallity simplifies some things.  Think about it.

History: PPPEXT fragmented into two camps over how to do Multilink.  The
two groups came to me for adjudication.  I looked at both proposals,
pronounced both as being flawed, and then proposed a new architecture based
on them model wherein PPP is really two layers, i.e. link and network,
instead of just one.  The problems then disappeared with the new model.

I suspect that we have a similar sort of problem here.  On the other hand,
maybe I am completely off base and my comments are invalid in which case I
beg the group's pardon.

---

From: Richard Shea <[email-masked]>
Date: Thu, 12 Feb 1998 19:13:00 -0500

Brian Lloyd wrote:
> >> So, has anyone considered using multilink over a single logical
> link
> >> as a
> >

Nope, you were correct -- it will be going to Proposed Standard.  I was
coming more from the angle of where the inertia is and the fact that
people are chomping at the bit to ship, etc., etc..  From a practical
standpoint, not from a technical one, I don't think it will be
considered.  Sorry for the confusion.

[..]
> partitioning of functionallity simplifies some things.  Think about

I will.  Unfortunately, something coming from an angle as different as
this won't be called L2TP (IMHO).  It would be a competing protocol
called something else.

Richard.

---

From: Brian Lloyd <[email-masked]>
Date: Thu, 12 Feb 1998 17:34:16 -0800

At 16:13 -0800 2/12/98, Richard Shea wrote:
>Nope, you were correct -- it will be going to Proposed Standard.

Oh good.  I can remove my tongue from my cheek then.

>I was

Well, we certainly wouldn't want good protocol engineering to stand in the
way of shipping product now, would we.

>this won't be called L2TP (IMHO).  It would be a competing protocol

A rose by any other name ...

The purpose of L2TP, as I understand it, is to allow the PPP session to be
managed remotely from the LNS essentially tunneling the "link" session from
the LAC to the LNS.  No internet (small 'i') layer routing involved.  Call
it what you will but it does the same thing.

Other than the initial negotiation for Multilink, there is really no need
for the LNS to bother with LCP negotiation.

Clearly I need to look at L2TP a lot more closely than I have.  More from
me on this later.  (No, that is not a threat.)

---

From: Richard Shea <[email-masked]>
Date: Fri, 13 Feb 1998 08:32:18 -0500

> Oh good.  I can remove my tongue from my cheek then.

Aha.

> way of shipping product now, would we.

IMHO, I don't think the real goal of L2TP was ever good protocol
engineering.  To quote Bill Palter's email from last night: 

"We set out to try and merge L2F and PPTP incorporating the best
features of both, and to get the specification done quickly so that we
would not end up with three standards and need to support all of them in
every implementation (in order to be competitive)."

So, basically whatever faults (and features!) L2F and PPTP had were
inherited by L2TP and some new features and tweaks were added.

I think tunneling PPP has its applications, but I'm not sure it is a
good fit in many other applications.  Here are a few problems I see with
it as it is or will be deployed:

(1) This discussion.

(2) L2TP-over-IP fragmentation.  It is not necessarily easy to avoid
fragmentation of encapsulated L2TP packets.  On the Internet at least
there is a wide range of packet loss characteristics.  Each time you
fragment a packet you increase the probability that the datagram being
fragmented will be dropped.  Each time you drop a packet you introduce
timing complexity and throw a wrench in the stateful
compression/encryption protocols.

(3) Current popularity of stateful compression and encryption protocols
in PPP.  Tunneling stateful protocols across a network which drops
packets much more routinely (say 3% to 5% of the time, NOT atypical of
Internet) than a real point-to-point connection leads to serious
performance degredation.

(4) Termination of multilink on the LNS.  Just like IP fragmentation,
multilink terminated at the LNS increases probability of datagram loss. 
Also, the timing of link-packet reception due to the network traversal
is sure to affect performance.

(5) Acknowledgement by packet, not by byte.  Unlike TCP which has a byte
window size, L2TP has a packet window size.  Which means it cannot
adjust well with (perhaps intermittent) high-latency conditions between
the LAC and LNS (especially if it tries to avoid fragmentation).  Part
of the reason this is necessary is because the packet window size is
needed so that the stateful compression/encryption protocols can adjust
better to packet loss conditions.

I was going to address these problems one at a time over time, but it
seems the can was open so the worms had to come out. ;)

Of these, (1) is being currently addressed, I wrote an I-D to try and
fix (2) (to which I've received NO feedback), (3) has been discussed but
you can't do much with the installed base that is already out there, and
(4) and (5) haven't been discussed at all to my knowledge.

The company I work for (which was New Oak which was acquired by Bay) did
just what Bill Palter mentioned.  I implemented PPTP, L2F, and now L2TP
not because they are necessarily great protocols, but because they are
all out there and people are asking for them (and the reason for the
company is to make money!).  Our product also has an IPSEC client which
uses IPSEC tunnel-mode to tunnel traffic to our box from a PC.  We
basically covered it all because there is no clear winner, not from a
marketing point of view and not from a technical point of view.

Now, having said all this I have to go show my face at the CIUG in a
little more than a week and test my L2TP LNS implementation with all the
people I've probably pissed off now!

I believe, however, that my criticisms have technical merit and unless
someone can address (1)-(5) and convince me that they are satisfactorily
addressed by the L2TP spec I stand by them.

BTW, (1)-(5) exist for PPTP, L2F, and L2TP, with the exception of L2F
which didn't do any flow control and so (5) wasn't a problem (but not
having flow control probably makes (3) worse in that case).

[..]
> me on this later.  (No, that is not a threat.)

I welcome it.

Richard.

---

From: Brian Lloyd <[email-masked]>
Date: Fri, 13 Feb 1998 11:40:15 -0800

At 5:32 -0800 2/13/98, Richard Shea wrote:>IMHO, I don't think the real
goal of L2TP was ever good protocol
>engineering.  ...

I got that feeling.  Still, we should try to make it as good as possible.

>inherited by L2TP and some new features and tweaks were added.

Do you really believe that we would not be better served by looking at the
problem and seeing if we can remove the warts?

>good fit in many other applications.

I agree whole-heartedly.

>Here are a few problems I see with

>(1) This discussion.

:^)

>compression/encryption protocols.

Mmmm, maybe.  I have heard this argument before, way back in the connection
vs. connectionless, IP vs. OSI wars of the 80's.  One of the interesting
things we learned is that the network is so much more reliable than anyone
anticipated and that your error recovery routines don't need to be all that
efficient, they just have to work.

If losing the occasional packet breaks things all to pieces or packet loss
reaches the magnitude that error recovery become a significant problem then
you need a reliable transport medium like TCP to carry your tunnel data.
But TCP doesn't preserve packet boundaries, does it.

But let's turn this problem around.  You have a problem because you want to
use stateful encryption and/or compression algorithms that depend on
previous data over a transport that is unreliable.  Either you accept the
performance hit that comes from losing data and having to resynch your
compression/encryption engines or you switch to using block cyphers and
per-packet stateless compression.

>Internet) than a real point-to-point connection leads to serious

So switch from CBC to ECB cyphers and per-packet stateless compression when
the packet loss rate is high enough or just decide that you are going to
use these stateless modes from the beginning with L2TP and be done with it.

>is sure to affect performance.

Sure it is.  But that is what you get when you want to do something like L2TP.

>window size, L2TP has a packet window size.

You don't really have a choice if you consider the packet to be atomic.  So
far, this is packet oriented not stream oriented.  IF you want to switch
you have to take a new look at what you are trying to do.

>Which means it cannot

I think it is difficult to punt this one unless you are going to switch to
a stream-oriented transport and that engenders a whole new can of worms.
On the other hand, if you put out two packets very close together (probably
adjacent in the network) they are likely to form a packet train in the
network and arrive very close together.  I suspect that you aren't likely
to experience latency spreading in the case of a pair of multilink payload
packets.  We need experiential data to determine whether or not this is a
problem.

>seems the can was open so the worms had to come out. ;)

Seems we like worms.

>marketing point of view and not from a technical point of view.

You seem to be talking sense to me.  I agree that the PPTP/L2F/L2TP
mechanism is probably a poor technique in general.  I can think of much
better ways to accomplish these things but the Telcos want to get into this
market and they like switched circuits.  They understand them and
PPTP/L2F/L2TP make the internet look like remotely-switched circuit
sessions back to the remote ISP.

>people I've probably pissed off now!

Well, if people can't stand the heat, they should probably stay out of the
kitchen.

>addressed by the L2TP spec I stand by them.

Your criticisms seem very valid to me.  I haven't finished reading the L2TP
draft but so far it strikes me as being a whole lot more complex than it
needs to be.  I think we need to apply Ockham's razor and rethink how this
thing gets done.

>> me on this later.  (No, that is not a threat.)

I am not sure everyone will welcome me quite as much as you do.

---

From: Richard Shea <[email-masked]>
Date: Fri, 13 Feb 1998 17:22:21 -0500

Brian Lloyd wrote:
[..]
> But TCP doesn't preserve packet boundaries, does it.

Performance measurements I took in a simulated environment based on
packet loss and latency I measured on the real Internet suggest this is
a problem.  Tunneled TCP performance fell off very quickly with increase
in latency between the tunnel endpoints, and I measured packet loss
rates anywhere from barely any to 10% or so on a regular basis.  So with
fragmentation causing a packet loss jump from 5% to 10% or 10% to 20%
you see noticable performance degredation.

I should note I took these measurements between a WinNT 4.0 Workstation
PC with PPTP and our implementation of PPTP, so there could have been
implementation-dependent effects here.  I would love to have time to do
a simulation, or hopefully with L2TP do cross-vendor tests making the
same measurements, probably across the real live Internet.

Of course, if the network is better behaved than the typical Internet
path then this isn't as big of a deal.

> per-packet stateless compression.

That would be great, but you are tunneling traffic at the LAC unknown to
the client dialing in, and that client can be doing anything.  There is
a huge installed base of stateful compression/encryption implementations
which won't migrate very quickly to stateless until everyone (i.e.
users) upgrades their software to stateless implementations.

I also remember reading on one of these lists that PPP DES-CBC does
cross-packet chaining which I would consider semi-stateful.  Again, this
creates a "double your packet loss" phenomenon.  VJ -- same sort of
thing (I know.. "So don't negotiate it").  It seems the CCP compression
algorithms can be done stateless today fairly easily so that is probably
easier to change.

[..]
> Sure it is.  But that is what you get when you want to do something

I hear ya.  I've been floating around a concept in my head of suggesting
an extension to the protocol so that when you discover a new link being
tunneled to you you "push" the processing of the link back to the NAS
that tunneled the primary link to you, so that the NAS can reassemble
the original mulilink datagram and tunnel that over to you as one unit. 
Jeez that sounds worse written out than it did in my head! ;)  I'll give
you one guess what that starts to sound like...

[..]

I know we can't really do anything about this one, but it does effect
performance I think.  I don't think L2TP (or PPTP) is too efficient at
utilizing the bandwidth between the LNS and LAC.  In part this is
because its hands are tied by the need to keep the window sizes small
because of the stateful stuff we talked about above.  So unlike TCP
which can increase performance over high bandwidth/high delay
connections, L2TP can't respond as well by increasing the window size --
otherwise it exposes itself to packet loss (which is non-negligible as
I've measured before) and the performance problems associated with that.

Performance is also affected when their is a mix of small packet and
large packet data being tunneled, and the presence of the small packets
brings down the overall throughtput of the connection (since small
packets eat up as much of the window as large packets).  Not much you
can do about it, but worth recognizing anyway.

Richard.

---

From: Brian Lloyd <[email-masked]>
Date: Fri, 13 Feb 1998 17:47:49 -0800

>you see noticable performance degredation.

Gee, I didn't know that things had gotten that bad.  If I saw 1% packet
loss across my network I would be tearing things apart to find the problem.
I haven't seen packet loss rates on the order of 10% since my packet radio
days.  In fact, it was high packet loss rates on the packet radio networks
we were building that led Phil Karn to roll his "new" round-trip timing
algorithm for TCP.

>same measurements, probably across the real live Internet.

This is a good point.  Here we have some experiential data that implies
that packet loss rates are higher than I supposed (maybe this is not
news to others).  That negates my assumption that the network is
sufficiently reliable that the packet loss correction algorithms don't
have to be all that efficient because they don't get exercised all that
often.

A lot of the asumptions we put into PPP originally were that
the links over which they would run would be high-reliability digital
links with very low bit error rates, e.g. ISDN, T1, etc., or they would
be running over modem connections and most modems do error correction
(MNP or V.42) thus making them essentially error free also.  They either
worked well or they didn't work at all.  Now we are talking about running
PPP over poor reliability virtual links with high packet loss rates and we
are going to expect to have to reset the compression dictionaries and lose
lots of cypher blocks on a regular basis.  If indeed this is the

>path then this isn't as big of a deal.

Yeah, right.  I believe that one of the main driving forces behind PPTP,
L2F, and L2TP is to allow a company to "wholesale" ports to ISPs and
"the Enterprise".  The transit network is going to be the Internet in
general.  (Just what we need when the network is already suffering from
congestive collapse is to add a ton more traffic by tunneling all these
PPP sessions across the network.  Hello!  Is anyone thinking about this?)

<tongue-in-cheek>
But that is OK.  The ISP will just tell its customers that the problems
are in the network and they shouldn't be concerned by that fact that
they are only getting 20%-30% of their channel capacity.  I am sure that
the customers will be pleased, accept that information, and go away
happy! </tongue-in-cheek>

>algorithms can be done stateless today fairly easily so that is probably

I doubt that, with the current crop of modems, anyone would really notice
VJ was on or off so I agree, negotiate away.

<useless-but-interesting-trivia>
Van wrote his header compression so that TELNET wouldn't be painful over
slow modems or over Telebit modems.  VJ header compression gets the IP
datagrams for TELNET sessions short enough that the Telebit Trailblazer
modem isn't triggered into its long packet mode so latency was greatly
reduced. </useless-but-interesting-trivia>

>you one guess what that starts to sound like...

It sounds like the way that Livingston does multi-chassis MP.

Gee, it also sounds like pushing the link processing back to the LAC.
Next you are going to suggest that we just push all the PPP processing
back to the LAC and just tunnel the IP datagrams.  Well, that *would*
be a solution to L2TP but I don't think that is what we are shooting
for here.  ;^)

>can do about it, but worth recognizing anyway.

OK, L2TP is a bad idea and we should do something else.  Case closed.

Uh, I don't think you are going to sell that one around here.  :^)

Let's get back on track and see what we can do to make L2TP work as well
as it possibly can.

---

From: Richard Shea <[email-masked]>
Date: Fri, 13 Feb 1998 21:57:52 -0500

[..]
> we were building that led Phil Karn to roll his "new" round-trip

The current internet packet loss rates are all over the map and can be
horrendous (especially intermittently).  Especially if the traffic has
to go from one providers network to the other and they don't have a
partner agreement.  Then the traffic goes to the MAE's where I think the
problems (latency and packet loss) are the worst.

[..]
> lots of cypher blocks on a regular basis.  If indeed this is the

You trailed off here, but I can imagine what was coming.. ;)

[..]
> Let's get back on track and see what we can do to make L2TP work as

Let's.  Knowing the limitations and problems we can go after the
solutions.  I think intractable problems are worth knowing about, hence
me diversion into the ack of byte vs. packet business.

Perhaps everyone was already aware of the issues I was bringing up, and
if so I apologize to both mailing lists for wasting their collective
time the latter half of this week.  I think the lack of a difinitive
answer to the problems posed is justification for the discussion
however.

I also suggest this be the last email sent to BOTH ietf-ppp and to l2tp,
and we move this to l2tp-only.  Anyone interested in the continuation of
the l2tp protocol can move onto that list.  [email-masked],
message body: subscribe.

Richard.