One Tue, 14 Mar 2006 11:37:38 -0300, Arnaldo Carvalho de Melo wrote:
On 3/13/06, Saurabh Jain <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I am trying to write a new rate based transport protocol in linux
> kernel (either as a module or directly within the kernel). Basically
> it would be similar to UDP but with features like dynamic rate
> control, connection and state management, error control like TCP. Is
> there any established framework which i can use? I know there is one
> for window based protocols like TCP where one can dynamically
register
> different congestion control mechanisms. I would appreciate if
> somebody can give me some direction in this regard.
Look at how DCCP and TCP share code, using abstractions such as:
struct inet_connection_sock
struct inet_request_sock
struct inet_timewait_sock
struct inet_hashinfo
I suggest too that you read my OLS 2004 paper:
One of the limitations of those abstractions is that they are not
generic enough for SCTP to use them. It is probably asking too much to
generalize everything, but it would be nice if everything weren't bound
so tightly to the idea of a one-to-one, single address, single path
socket. XFRM, the IP layer, the sock layer, the inet sock layer, and
the inet connection sock layer all have that assumption hard coded into
them in various ways.
For example, a one-to-many style SCTP socket is equivalent to a group of
inet_connection_socks presenting a UDP style interface, one
inet_connection_sock per SCTP association. But since
inet_connection_sock is a _sock_, it cannot be used as the base
implementation for an SCTP association.
Similarly, struct sk_buff carries a destructor pointer, that is
typically used to release memory to sk_wmem_alloc, but the destructor is
called with a "struct sock *" argument, from skb->sk. A more general
implementation would replace skb->sk with a pointer to an intermediate
abstraction or a void *, or add a destructor context argument. Currently
in order to work correctly SCTP has to consider memory reclaimed as soon
as it hits the IP layer, because flow control is done at the association
level, not the socket level.
XFRM has the same problem - it only allows security policies to be
overridden at the socket level, where an SCTP socket may handle
thousands of associations, with independent security policies. It would
also be nice to share congestion control implementations - SCTP does
congestion control on a path ("transport") basis, not a per socket
basis, and the congestion control interface would have to be similarly
general purpose.
There are dozens of fields in struct sock, struct inet_sock, and struct
inet6_sock that are superfluous overhead in the SCTP case. It would be
better if struct sock etc were one level higher in abstraction, rather
than carrying so much baggage from the TCP view of the world. Perhaps
two thirds of the current fields belong at lower levels of abstraction.
In view of the goal of reducing the kernel footprint, such a
re-factoring might be worth considering.
- Mark B.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
