[GSoC] L2TP pseudo device

[Jordan Gordeev]

I've been looking at the "Create a L2TP (RFC 2661) pseudo device"
proposed Google Summer of Code idea.
I want to share some of my thoughts with you and hear your opinion.

When implementing L2TP, there are two primary desirable characteristics
- 1) performance and 2) flexibility. It's natural to want to divide the
implementation into two components - one userland and one in the kernel,
where the userland component ensures flexibility and the kernel
component ensures performance. A third desirable characteristic is
generality - i.e. applicability to other PPP-carrying mechanisms, such
as PPPoE.

Here's my first idea for design of an L2TP implementation:
All network-layer protocols are handled by the kernel.
All control protocols (LCP, other link-layer control protocols,
NCP's like IPCP, IPV6CP, etc.) are handled by a userland program.
The userland program uses a socket (or a character device) to send
and receive control-protocol packets. These control-protocol packets
will appear on the kernel/userland socket interface as PPP frames.
The kernel component and the userland component will need to
interact - the userland component will send commands to the kernel
component and the kernel component will send event notifications to the
userland component.
I believe it's a good idea to use the same socket, that is used for
control-protocol packets, for commands/event notifications too. A
special "NetBSD L2TP Control Protocol" can be invented for this purpose.

Having the userland application handle all control-protocol packets has
the disadvantage of even the simplest requests - LCP Echo-Request's -
going from kernel to userland and back, with the overhead this incurs.
It would be nice to have at least some parts of some control protocols
handled in the kernel. This leads to the second design idea:
All network-layer protocols are handled by the kernel.
Some control-protocol packets are handled by the kernel.
Some control-protocol packets are handled in userland.
The division of responsibilities between the kernel and userland is
fixed.
The control-protocol packets handled by the kernel are those, for
which "imagination" or access to external resources (e.g. RADIUS
servers) is not required.

This idea can be extended to the third design idea:
All network-layer protocols are handled by the kernel.
Some control-protocol packets are handled by the kernel.
Some control-protocol packets are handled in userland.
The division of responsibilities between the kernel and userland is
dynamic.
The userland application can get more responsibilities, or off-load
responsibilities to the kernel, whenever it wishes.

In my opinion, the best mix of performance and flexibility is achieved
in the second design idea, although I like the other ideas too.
Do you like the second idea the most?
Have you got any suggestions you want to share?

Regards,
Jordan Gordeev


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Jordan Gordeev
I've been looking at the "Create a L2TP (RFC 2661) pseudo device"
proposed Google Summer of Code idea.
I want to share some of my thoughts with you and hear your opinion.
When implementing L2TP, there are two primary desirable
characteristics - 1) performance and 2) flexibility. It's natural to
want to divide the implementation into two components - one userland
and one in the kernel, where the userland component ensures
flexibility and the kernel component ensures performance. A third
desirable characteristic is generality - i.e. applicability to other
PPP-carrying mechanisms, such as PPPoE.

ok but you are aware of NetBSD already supporting pppoe, aren't you?

Post by Jordan Gordeev
All network-layer protocols are handled by the kernel.
All control protocols (LCP, other link-layer control protocols,
NCP's like IPCP, IPV6CP, etc.) are handled by a userland program.

ok

Post by Jordan Gordeev
The userland program uses a socket (or a character device) to send
and receive control-protocol packets. These control-protocol packets
will appear on the kernel/userland socket interface as PPP frames.

ok

Post by Jordan Gordeev
The kernel component and the userland component will need to
interact - the userland component will send commands to the kernel
component and the kernel component will send event notifications to
the userland component.

ok

Post by Jordan Gordeev
I believe it's a good idea to use the same socket, that is used for
control-protocol packets, for commands/event notifications too. A
special "NetBSD L2TP Control Protocol" can be invented for this purpose.

I disagree. This should be another type of socket.
But I can also see it being desirable to have both packet types on the
one socket so that ordering is preserved.

You may wish to think about different socket types or protocol types for
a given address family of a socket with there being a "wildcard" to let
you receive all.

Post by Jordan Gordeev
All network-layer protocols are handled by the kernel.
Some control-protocol packets are handled by the kernel.
Some control-protocol packets are handled in userland.
The division of responsibilities between the kernel and userland is
dynamic.
The userland application can get more responsibilities, or off-load
responsibilities to the kernel, whenever it wishes.

What are your thoughts on the latter point?
How would you design a mechanism to implement that without making it
specific to this project?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de