Several weeks ago I successfully defended my MSc thesis. For anyone interested here is the abstract and a PDF version.
The IP Per Process Model: Bringing End-to-end Network Connectivity to Applications
The application of the end-to-end principle in the design of the Internet has been fundamental to its success. One of the most important advantages of the end-to-end principle is that it allows the introduction of new services and protocols into the network without requiring changes to intermediate nodes. This greatly reduces the difficulties associated with developing and deploying new transport layer protocols and network services.
Traditionally network protocol implementations are placed inside the operating system kernel. An alternative to this design found in the computing literature is user-level networking. User-level networking places the protocol implementation and processing inside the application. Among other advantages this design simplifies network stack development and deployment.
This thesis offers a network stack model based on user-level networking which has the primary goal of extending the benefits of the end-to-end principle to applications. This model is referred to as the IP per Process Model. A prototype of this model named Pnet/UNL has been built and evaluated against the Linux network stack. Performance evaluation shows this prototype to compare favorably against the Linux network stack on a 100 Mbps network but the performance gap widens at 1 Gbps.
2 replies on “Thesis”
I noticed that you didn’t mention the possible overhead on the pnet/unl side
caused by each packet passing through the kernel IP stack as well as the two
endpoints (and possibly through netfilter). It might be interesting to see how
much of the overhead is due to doing more processing vs. context switch
overhead etc. Granted, this will be happening in the real world, although
something like CONFIG_NET_FASTROUTE from linux 2.4 might allow pnet/unl to
match native stack numbers.
First off, thanks for reading the document.
Packets destined for the Pnet interface only go through the stack as far up as IP routing so the overhead should be pretty low. You are correct about the Netfilter overhead still being a factor though. It would have been interesting to build a kernel without Netfilter (I assume that is possible) for comparison. However, I also mention that the firewall features of the kernel have benefits in terms of application and network protection so Netfilter is somewhat necessary to the model anyway.
Regarding CONFIG_NET_FASTROUTE, I didn’t know about this feature. I’ll have to investigate it further.