On 7 May 1999, Perry E. Metzger wrote:

> I've asked several times, and you haven't answered: What is it that
> this userland PPP does that our kernel version does not do? You keep
> saying "compression" but we have compression. What is different here?

AFAIR, earlier today I posted a URL for the manpage, in the hope that it
would answer such questions. In fact, I posted an excerpt too. I will post
the URL again if needs be. Interested parties would do well to have a
glance before going on the offensive; however, for those who must here are
a few reasons that I can think of off the top of my head:

	o It is transport neutral; TCP or serial line, it doesn't matter.

	o It supports the M$ extensions properly, including MS-CHAP,
	  which is basically essential in a M$ centric environment.

	o It supports multilink PPP.
	
	o It would be trivial to support synchronous framed protocols,
	  like true HDLC. This is useful for ISDN.
	
	o It supports both the LCP and M$ callback protocols.

	o The configuration is a lot less cryptic than pppd(8), and can
	  be modified online. Each individual site that you define can
	  have a totally different configuration. Henceforth the interface
	  is much easier for the novice user.

	o It can be fully controlled with pppctl(8) via domain sockets.

	o The logging and debugging facilities are far more extensive.

	o If you have no requirement for NAT or filtering in-kernel,
	  ppp(8) can do it.

	o There is access control on a per user basis (eg, user jsoap
	  is permitted to bring up the link to our site in the North
	  Pole, but nothing else).

	o The compression, for whatever reason, has proven itself
	  over the last year on all of the FreeBSD systems that I've
	  used it on to be superior to in-kernel ppp's. This is unusual,
	  since it appears to be plain PFC, VJ, deflate and predictor w/ a
	  few knobs and parameters available to tweak them with.

Andy.