netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martijn van Oosterhout <kleptog@svana.org>
To: James Chapman <jchapman@katalix.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	bcrl@kvack.org, davem@davemloft.net, netdev@oss.sgi.com,
	mostrows@styx.uwaterloo.ca
Subject: Re: PPP-over-L2TP kernel support, new patch for review
Date: Fri, 24 Sep 2004 04:34:09 +1000	[thread overview]
Message-ID: <20040923183355.GB13753@svana.org> (raw)
In-Reply-To: <1095888533.4151ee95ed23c@www.katalix.com>

[-- Attachment #1: Type: text/plain, Size: 2964 bytes --]

On Wed, Sep 22, 2004 at 10:28:53PM +0100, James Chapman wrote:
> Hi Herbert,
> 
> Quoting Herbert Xu <herbert@gondor.apana.org.au>:
> 
> > James Chapman <jchapman@katalix.com> wrote:
> > >
> > > The biggest difference in our approaches is that Martijn and I use a
> > > PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel
> > > socket while Ben uses a new AF_L2TP tunnel socket and no separate
> > > socket per session. Both have their merits.
> >
> > Can you elaborate on the merits of having a socket? It would seem to me
> > that not having a socket is a lot more scalable.  After all IPsec doesn't
> > carry a socket around per session.
> 
> What I meant by "both have their merits" is that both general
> approaches have their merits. It's a shame Martijn isn't available
> right now (he's moving home to a new country) as he came up with the
> initial kernel driver concept. Anyway, I'm sure he'll chime in later.

Ok, I've just cut off the power connector of my laptop and whacked a
new one on, so I'm just beginning ot catch up. I'd just like to comment
that the socket-per-connection is part of the kernel generic-PPP
support. The PPP packets not handled by the kernel need to be
transported somewhere and I guess the decision was made to pass it
though a PPPoX socket.

If you want to get away from the one socket per session model, you
can't use PPPoX sockets. You need something in the kernel to hold the
ppp generic data structure. I imagine Ben's uses an array in the kernel
and passes stuff to userspace in a way so the user-space daemon can
identify the session it belongs to.

I don't see why this PPPoX solution won't scale to thousands of
sessions. Sure, you get one socket per session plus one socket per
tunnel, but IRC servers run with thousands of sockets and the costs
here aren't much more. Sure, someone needs to write a PPP daemon that
can handle multiple simultaneous connections, but that's orthoginal to
the issue at hand.

If you want to remove the one socket per session requirement, someone
needs to redo the PPPoX support. In fact, the whole PPPoX idea seems to
have been a bit of a dud since even with it there it seems to be better
to just invent your own character device/protocal family/etc than use
it. When I started I just used the PPPoX stuff since I figured that was
going to be the "supported" way to use the in-kernel PPP stuff.

Also, if Ben's stuff is handling the case of taking seperate L2TP
sessions and merging them through to another LNS server, then it is a
completely orthoginal system, since that doesn't require full PPP
support anyway...

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

  parent reply	other threads:[~2004-09-23 18:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-20 21:11 PPP-over-L2TP kernel support, new patch for review James Chapman
2004-09-20 21:17 ` David S. Miller
2004-09-21  9:55   ` James Chapman
2004-09-21 21:04     ` Benjamin LaHaise
2004-09-21 23:07       ` Herbert Xu
2004-09-22  0:00         ` Michael Richardson
2004-09-22  1:14         ` Benjamin LaHaise
2004-09-22  2:42           ` David S. Miller
2004-09-22  3:03           ` jamal
2004-09-22  9:58       ` James Chapman
2004-09-22 10:53         ` Herbert Xu
2004-09-22 21:28           ` James Chapman
2004-09-22 22:05             ` Herbert Xu
2004-09-23 18:34             ` Martijn van Oosterhout [this message]
2004-09-21 21:11   ` Benjamin LaHaise

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040923183355.GB13753@svana.org \
    --to=kleptog@svana.org \
    --cc=bcrl@kvack.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jchapman@katalix.com \
    --cc=mostrows@styx.uwaterloo.ca \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).