[Top] [All Lists]

Re: RFC: PPP over X

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: RFC: PPP over X
From: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Thu, 3 Feb 2000 12:01:27 -0800
Cc: netdev@xxxxxxxxxxx, axboe@xxxxxxx, Mark Spencer <markster@xxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Marc Boucher <marc@xxxxxxx>, paulus@xxxxxxxxxxxxx, Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>, Ben LaHaise <bcrl@xxxxxxxxxx>
In-reply-to: <Pine.GSO.4.20.0002021030520.22723-100000@xxxxxxxxxxxxxxxx>; from hadi@xxxxxxxxxx on Wed, Feb 02, 2000 at 10:42:47AM -0500
References: <Pine.GSO.4.20.0002021030520.22723-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
jamal wrote:
> This is not posted to l-k because i didnt see the need for it.

Probably a good idea.  If it is going to happen on a vger list
it should realy be linux-ppp

> Hopefully, the result here is that we have a solution quickly decided so
> we can submit into 2.3

I really don't see why the channels stuff in 2.3 shouldn't just
stay as is - it's really very clean.  The real work that needs
to be done is to pppd to support plugins that deal with different
channel types better.

> The issue as i see it:
> Too many "PPP over X" type protocols (PPPOE, L2TP, PPP over ATM, PPP
> over SONET etc) and there will be a lot more coming probably.

...PPTP, ISDN-PPP (is that using the new ppp_generic code yet?),
RFC 1598 (PPP-over-X25), RFC 1973 (PPP-over-Frame), RFC2363

> The problem IMO:
> Too many solutions; same end goal --> kernel cluttering. 

The problem as I see it is just that more things need to
convert to the channels stuff (ppp_generic and friends)

> Advantage:  
> -No changes required for any PPP/d (user/kernel)

I don't see this an advantage - recent pppd's have a plugin mechanism
which could make these changes very clean (see the PLUGINS
file in a recent pppd).  All that is really needed is the tty-specific
stuff in pppd to have hooks put around it so it can be supplanted
easily by non-tty variants.  Then each PPP-o-X can just have
its own module.

The only challenge is getting a firm enough grasp on all the
pppd code that deals with ttys so the small surgical changes
can be made without upsetting other ports.  I haven't had
time to divine this level of understanding of all those
twisty little passages.

> -has both the discovery and data switcing encap/decap into the kernel 
> -PPPd talks to a brand new socket family (created for PPPOE).
> Code size in the kernel (At the moment about 60k)
> This includes also the server part.
> Contribution from the socket addition: about 30% of this

I think this is fine.   PPPoE is a full-fledged protocol with all
the mux/demux needs that implies.  It's just going to be a
little large if you want a flexible implementation.  None of
that has anything to do with the choice of ppp implementation.

Look at the ppp-o-atm code - since the VCC mux/demux is handled
by the higher layer (it's just over a standard PPP socket)
the code to use the ppp_generic channel interface is almost
trivial.  If I had to rewrite it to emulate a tty interface
not only would the performance suck eggs, but the code would
be much larger.

PPP is a packet-oriented interface and the current (2.3)
ppp_generic stuff reflects that nicely.

> Advantages:
> does not use the tty interface. Uses the channel interface; 
> Disadvantage: 
> -Bloats the kernel.

Again, wrong.  For a simple to implement protocol it bloats
the kernel less than ppp_async does.

> -The socket use could become a maintainance nightmare
> (claim: it looks very clean at the moment).

It's not a maintence nightmare.  Quite the opposite - using
a socket family gives you all the socket infastructure (like
module auto-load) for free.

> -Creating a whole socket family for just PPPOE is a bad idea

I don't think so - it has its own addressing, so it needs
its own address family.

> 1.  pppoxd negotiates a connection and identifies parameters
>     eg in PPPPOE the sid and remote MAC address for the connection.
> 2.  pppoxd opens a connection to the pppox interface.
>     to grab a fd which will be used by pppd.
>     eg if the interface used was a socket then for pppoe,
>     this determines the definition of sockaddr_pppoe.
> 3.  pppoxd hands-off the fd to pppd.

Why make a new pppoxd?  Wouldn't it be easier to just use a pppd plugin?

> WHAT Needs to be decided
> ------------------------
> We are all curently in violent agreement that discovery should be in
> user space (includes Michal).

Then I'll be the violent dissenter, I guess.  I don't think discovery
is analagous to ARP (which also has a right to be in the kernel, IMO)..
it's more analagous to TCP connect.

Michal's code provides very clean socket semantics.. I think those
should be preserved.  When I looked at the code months ago there
were a bunch of implementation problems (HZ=100 assumptions,
needs a better hashed structure for holding connections (look
at tcp code), didn't properly verify MAC on incoming data
frames, etc)  I spent a couple hours at a local diner with
a printout of the pppoe code doing an audit and came up with a
dozen or so suggested improvements.... then I managed to
lose all my notes before doing anything with them :-(

> The main decision to make is what interface should PPPd be
> talking to? For 2.2, the only viable solution is the tty one.

I think we should just write off 2.2 - 2.4 is on the way.
If someone wants all these PPP-o-X things in 2.2 that badly
then they should do a back-port of ppp_generic and friends.

> So what should be the device that pppd talks to? Is it a new socket 
> family, tty device, a new char device etc.?

Depends on the "X" in PPP-o-X!

  tty: can talk to a tty device just like now
  PPPoE: new socket family
  PPPoA: ATM_PVC socket

> Note that we currently have a limitation in pppd in that it is very 
> friendly to ttys. A small change will be required in the pppd daemon.
> No changes in the kernel PPP.

OK, now you're talking sense. :-)

> I propose addition of a new syntax to the pppd options:
> "channelname <channelname>" eg "channelname l2tp"
> The pppd code should check for this syntax (which is mutually
> exclusive with the devicename option). When this option is passed,
> any assumptions that pppd is talking to a tty device are nullified.

I think this can all be handled by the plugin architecture.  We just
need a hook installed to let us interpret the devicename ourselves.

        pppd plugin .../ PPPoEoptions... eth0
        pppd plugin .../ PPPoATMoptions... 0.0.101

> >From the kernel side, My proposal is that whatever interface chosen is,
> it should be able to very easily add new "PPP over X"s; so a registration
> API is a requirement.

No, it isn't.  The registration takes place at another level
  * tty: registers a new line discipline (register_ldisc)
  * PPPoE: registers a new socket family
  * PPPoA: registers a new atm "backend" (actually the way you register
    a backend in linux-atm is really gross... on my todo list for 2.5
    is clean that up)

All the register/unregister stuff (like autoloading) then gets
dealt with at another level.

<Prev in Thread] Current Thread [Next in Thread>