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

The in-kernel part of our PPP is as well. Maybe pppd needs a few changes...

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

pppd does this as well.

> 	o It would be trivial to support synchronous framed protocols,
> 	  like true HDLC. This is useful for ISDN.

We have a complete in-kernel version of PPP which doesn't even need pppd.
This IS currently used for ISDN. There was a patch floating around back in
the BISDN days that used our in-kernel standard PPP implementation and a
modified pppd to do PPP-over-ISDN.

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

Thats a counter argument from the performance point of view ;-)

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

So let's check this one and improve our in-kernel PPP. Hey, I realy like
running 4MB RAM ISDN router machines, doing multiple simultaneous PPP
sessions.

The rest I can't comment on - but the one I grok is multilink support: I
would love to have that for the in-kernel version, but I failed searching
for a remote site to test it against, so working on it would be hard for me.

No pun intended, but I don't see the point. I'm heavily using PPP over ISDN,
both at work and at home. I never ever got performance problem, neither when
doing binary downloads (at 7.9kByte per second) or when surfing the web. You
didn't state how you got your statistics - so I think it's probably some
bogus performance meter (a web browser telling you it got one packet of 1000
bytes in 0.2 seconds, so it must have been 5kB/s).

The other performance issue is round trip time - how does it compare there?


Martin