Subject: Re: LCP renegotiation

From: "Philip A. Prindeville" <[email-masked]>
Date: Thu, 12 Feb 1998 15:19:19 -0800 (PST)

> Date: Thu, 12 Feb 1998 12:41:29 -0800 (PST)
> From: Philip Rakity <[email-masked]>
> To: Andy Valencia <[email-masked]>
> cc: [email-masked], ietf working group <[email-masked]>
> Subject: Re: LCP renegotiation
> 
> 
> Andy,
> 
> If ADSL technology takes off, there will be many millions of lines running
> AAL5/PPP.  The problem should be fixed.

I was just telling myself not to jump back in when this arrived...

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

I think you are pushing back the problem.  We implemented L2F as
an exercise here and learned a lot in the process.  First, L2F
adds its own overhead, so by the time you've added 10 bytes (or
more, if you are aligning your L2F header) of L2F overhead and
8 bytes of UDP header, plus 20 bytes of IP header, you've blown
the 1500 byte Ethernet MTU (plus 4 bytes of PPP header).  And
two bytes of L2F trailer if you are generating checksums as well.

We didn't want to fragment our L2F packets, so we forced the NAS
(or LAC, in L2TP parlance) to negotiate down the MRU (which worked
better for us anyway, because our modems actually perform best
with an ~1100 byte packet).

I *thought* this would solve our problem.  Well, it would have, if
Microsoft had read RFC 1122 carefully (the Requirements for Internet
Hosts).  Sections 3.3.3 (on the relationship of the MTU_S and
IP fragmentation and the transport-layer MSS) and 4.2.2.6 (same,
but from the TCP viewpoint) were completely violated.  Winsock/DUN
CONFACK the MRU, and then ignore it, sending 1460 byte MSSes
even if the LAC (NAS) says don't send me more than 1400 (or 1100)
byte packets.

I've spent a week on the phone and sending email with Microsoft
techies, and had to lead them to this document... If I had a 
working ThinkPad powersupply, I could tell you if 98 was afflicted
by this non-conformance too.  I note with some optimism that the
NT 4.0 Resource Guide actually references RFC 1122....

I think counting on users' systems to handle MRU correctly is
problably naive (as was I).

Why not just have the LAC signal to the LNS what MRU it supports
when the connection is opened but before any traffic is sent (not
unlike the TCP MSS)?

-Philip

> Philip Rakity
> FlowPoint

---

From: "Philip A. Prindeville" <[email-masked]>
Date: Thu, 12 Feb 1998 15:59:22 -0800 (PST)

> Date: Thu, 12 Feb 1998 18:44:46 -0500
> From: Richard Shea <[email-masked]>
> To: "Philip A. Prindeville" <[email-masked]>
> CC: [email-masked], [email-masked], [email-masked], [email-masked]

> Philip A. Prindeville wrote:
> > 
> [..]
> > 
> > I think you are being naive.  As you go up the ISO reference
> > model it gets easier to abstract things away because the lower
> > layers are designed to deal with such details.
> > 
> > The news is:  *we* are at the lower layer.  These are the issues
> > that we have to concern ourselves with so that no one else will
> > have to.
> > 

> Well, the TCP-like abstraction is certainly an ideal which we can't
> achieve at this level, as you point out.  My point was that L2TP could
> be defined to attempt to contain the more physical-level characteristics
> of the link to the end with the actual physical connection (i.e. the
> LAC).

No argument there.  I think that the LAC should deal with the
details to the greatest degree possible.  But it should inform
the LNS of any particularities it might have to deal with (like
MRU).  The case of out-going calls is particularly sticky.  If
the LAC told the MRU what value it should negotiate when the
LNS/LAC handshake, then the LNS could enforce that value during
the negotiation.  Similarly for the ACCM.

If the above works, then why not tell the LNS "hey, this is an
HDLC link"... or not, as the case may be.

> If we changed L2TP to differentiate HDLC and non-HDLC sessions at the
> LNS, then the LNS would be able to satisfy the ACF handling for HDLC
> links; And for non-HDLC links the LNS would just not include ACCM or
> ACFC options, and not prepend the ACF on any packets it sent out (nor
> expect to receive them!).  Then, as long as all of the PPP-over-X
> protocols can take care of framing at the LAC and simply forward
> rfc1661-style PPP frames between the LAC and LNS we are all set.

> I don't yet understand (which may be entirely my fault!) why this
> wouldn't be effective.

Idem.

> If in the future some portion of PPP framing has to be known at the LNS
> then we can add in that functionality to the L2TP protocol at that time
> (fairly simply).

Mmmmmmmm.....  stuff gets entrenched awfully quickly.

-Philip

> Richard.

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

---

From: "Philip A. Prindeville" <[email-masked]>
Date: Fri, 13 Feb 1998 14:35:13 -0800 (PST)

For what it's worth, I also would like to see a "clean" protocol
go out the door a couple of weeks later than one that will come
back to haunt us.

-Philip

---

From: "Philip A. Prindeville" <[email-masked]>
Date: Fri, 13 Feb 1998 18:52:03 -0800 (PST)

I think it is also worh noting that the IETF could be sidelined
if they stop being relevant.  As long as people believe that
what the collective wisdom of the IETF is greater than that of
any single vendor, people will be biased (in a positive way) to
standards put forth by the IETF.

The moment we start cranking out sloppy work just to get something
out in a timely fashion, we lose any advantage we might have had
over vendors and their proprietary solutions.

I know from my own experience purchasing equipment at France Telecom
that I was always hesitant to go with a vendor-specific protocol
unless it was *really* clearly head-and-shoulders above the rest
(i.e. EIGRP).

Or am I just being pompous?

-Philip

---

From: "Philip A. Prindeville" <[email-masked]>
Date: Fri, 13 Feb 1998 19:19:15 -0800 (PST)

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

> At 14:22 -0800 2/13/98, Richard Shea wrote:

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

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

I have seen similar data.  Especially going through MAE-West or
on to Europe through Renater in Paris from San Francisco.  But
I don't think the LNS and the LAC will be that far apart typically.

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

> 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

We are working with radio modems in the IMS band (fairly standard)
that currently work as reliable links, but this in turn has negative
side-effects on TCP running atop these links (if you've ever done IP
over X.25, you'll know what I mean):  the RTT variance is a bitch.
We want to be able to do it in unreliable (datagram) mode when doing
PPP over these radios, but then we will see the real loss rates.

Around 6pm when people start getting home and powerup their laptops,
the traffic on the radio net becomes significant.

> >Of course, if the network is better behaved than the typical Internet
> >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?)

I second that.  Corporate customers will probably end up out-sourcing
RF coverage from my client.  (And yes, we are thinking about it.   In
most cases, the corporate customer is less than 6 hops away, and these
are short hops.)

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

My only problem with this is that when the customer does a traceroute,
the first "hop" is almost the entire network path....  Hmmmm... if
we knew how far apart the LNS and LAC were (easy enough to find out),
we could simply decrement the TTL of the IP datagram by that value
at each end (well, once only for each direction).  Do <tongue-in-
cheek>s nest?

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

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

We've certainly noticed when STAC or MPPC was on!  A note:  MPPC
hasn't been released yet on Ciscos which is what we use predominantly
in-house and STAC has an issue between Ciscos and 95 (the Ciscos want
EXTENDED and uSoft wants to do SEQUENCED history -- this bug has been
around a *long* time and I'm surprised Cisco hasn't fixed it yet).
Getting compression to work at all took a lot of tweaking (tweaking
that most sites wouldn't be able to do).

-Philip

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