Re: [Lksctp-developers] sctp header files

[Jon G. <jg...@us...>]

Garima gupta wrote:
> 
> hi,
>   According to RFC 2960 sctp's main difference to tcp is
> multhoming and the concept of association, so what i plan to do is
> to find how exactly are we going to have an edge over tcp when
> using sctp.
> 

You'll want to include multi-streaming and partial ordering supporting
too.  These are essential to bypass (no pun intended) TCP Head of Line
(HOL) blocking issues.  

BTW, an association is just a fancy name for an SCTP connection.  

Framing overhead in the SCTP could be compared against the application
providing such functionality.  In this case the overhead of framing is
moved from the application 
layer down to the transport layer.  But, depending on what one is
measuring, SCTP 
shouldn't be penalized for a feature that many applications would take
advantage of
and typically do it themselves on top of TCP.  This is just one of the
places
where one would be careful in stating what they were really measuring.  

> As my work involves around sctp's performance i think lksctp
> implementation is the choice over www.sctp.de's userland
> implementation.
> 

Probably, though we have not tuned towards performance yet.  

> finally one last doubt as i don't want to endup reinstalling linux
> for the 3rd time :
> to get the lksctp working on fresh linux RH 8.0 is:
> 

I have not used RH 8.0 so cannot speak to what is there.

> *) download and compile kernel source (just the kernel in this
> case and  we don't have to copy some lksctp-*.tar.gz and mix(by
> makefile ofcourse) it with linux kernel source from kernel.org)
> 

Specifically, linux-2.5.41 for the patch with regards to the patch you 
are downloading.

Maybe I should step back a bit and mention our versioning scheme..

lksctp-2.5.41-0_6_0 represents a 0.6.0 version of LKSCTP patched on top
of a 
2.5.41 version of the linux kernel source.  We used to distribute
tarballs of
our entire source, but lksctp is now included in the stock Linux kernels
from
ftp.kernel.org.   The patch updates the kernel source with some changes
that
didn't quite make it into 2.5.41.  

As I mentioned, you'll want to compile a kernel and make sure it works
before even
worrying about sctp support.  One of the reasons it was thought
important to 
get lksctp into the stock kernel is that we hope distributions (e.g. RH)
will have
sctp compiled in, so an SCTP application writer doesn't have to know how
to build kernels.   But.. we are still on the bleeding edge for the
moment.  

> *) apply lksctp-2_5_41-0_6_0.patch on compiled kernel.
> 

Well.... apply on top of a pre-compiled kernel.  You'll need to compile
the linux
kernel with the patch.   

> *) and install tools and header files in
> lksctp-tools-2_5_41-0_6_0.tgz on machine running on new kernel.
> 

Yes.

> Please point out where iam not correct.
> 
> Hope you understand the reason for asking this question as there
> is some confusing due to different versions of lksctp package and
> kernel source.
> 
> >Performance measurements are always black voodoo.  But, yes I
> >would
> >immediately throw out measurements of a user-level SCTP vs a
> >kernel
> >level TCP.  ;-)
> >
> >BTW, what sort of performance comparisons are you trying to
> >make?
> >The two protocols in general are intended to solve different
> >problems to where relevancy of performance between the two can
> >depend
> >on the network characteristics and traffic patterns.   SCTP is at
> >some
> >level a superset of TCP functionality, so theoretically should
> >have more raw overhead (but may regain a bit by less bit
> >banging).
> >However, when using SCTP in its designed for scenarios, it
> >should
> >perform better.
> >
> 
> >
> >It depends a bit on what you are trying to measure.  The test
> >application can likely be written in either style API.. so the
> >test should be be portable to the UDP-style API.
> >
> >Until we have TCP-style API implemented you will not have
> >complete API transparency (but even when we do it might not be
> >completely transparent).
> >
> >Hopefully these answers are a little helpful.
> >
> >Best Regards,
> >jon
>