SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler

[Randall Stewart]

Peter:


Yes, I do get all the bugs reported to me (usually) directly..
And I try to turn them around within a week (if possible)... I
have a couple on my plate right now from Chiba Hirotsugu ... in
fact the last batch of bugs was also from Chiba...

I know of at least 4 sites actively using the code and reporting
bugs and issues Marko, Chiba, The U-D guys (there are about
4 different projects at U-D and a LOT of folks in the PEL lab
so I won't try to name them all), Alessio (performance tests
I think), Jian Wang (doing some cwnd type testing)... and there
are others that have reported bugs... in fact some have even
pulled it into their products (QNX I think).. they of course
are behind us (just like KAME is too)..

I have put on my web site patch-24 (which I have, as yet, not sent
to KAME and probably will-not). Patch 25 will come out as soon
as I finish fixing Chiba-san's issues... resolving all known
bugs :-D

I have not heard of any compile issues with SCTP and KAME.. if
there are it is probably due to changes in KAME that need
changes in the SCTP side too... We always cvs update and
compile to validate BEFORE we send in the patch to Itojun.

There have been SOME issues with the formatting.. in some
cases code as accidentally disappeared.. but this will
happen on a project like ours as we send patches in and
try to integrate it :-D

Anyway.. I do think it is stable enough for inclusion in
stable BSD... if you have another 4.x round.. BUT we have
not went in and fully got things working on 5.x... I know
one of our team members (Kozuka-san) has made an effort
to make it compile.. but it as yet does not function :-0

I also, before patch 25, would like to finish a third round
of performance optimization. I finally have a second machine
with a Gig-E interface and 2.XMhz .. so I think I can
try to squeak it up a bit more... ah.. plans for next
week if I can find the cycles :-o

Anyway.. after patch-25 I intend on taking my new machine
to the 5.3 strain and trying to figure out what I need
to do to make it work :-0 (maybe patch26 :-D)

R


Peter Lei wrote:
> I think this is because any bugs that are found are usually
> communicated directly to us.
> 
> I think Randy has a better handle on how many people are using
> this stack.  I'm quite sure it is stable enough to go in to
> -current.
> 
> While the SCTP API hasn't gone through last call, it's fairly
> stable and we have both "converted" many applications from TCP
> to SCTP using the sockets API, as well as had portability between
> the KAME SCTP stack and the linux stack for some test applications
> used at the last interop event (except for the standard sockets
> issues that one runs into even for TCP like no sin_length field
> in the sockaddr struct).
> 
> The same stack has also been ported to Mac OSX as a native kernel
> build as well as an loadable/unloadble NKE w/a minor kernel change.
> 
> I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP.
> The major changes to our SCTP code when it gets committed into KAME
> has been that of code format/style.
> 
> What is the existing criteria for a measure of "stability"?
> 
> regards,
> --peter
> 
> SUZUKI Shinsuke wrote:
> 
>>>>>>> On Thu, 21 Oct 2004 21:32:48 +0200
>>>>>>> molter at tin.it(Marco Molteni)  said:
>>
>>
>>
>>> SCTP in KAME is complete, stable and fully supported.
>>> It is mainly developed by the SCTP RFC author, Randall Stewart.
>>
>>
>>
>> KAME Project haven't received SCTP-related bug report so much, and I
>> think it's due to a lack of testers, SCTP-API standard, and SCTP-ready
>> applications.
>> #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP
>> #application fails in compilation due to a change by SCTP.  So it's
>> #difficult to conclude that SCTP is already stable...
>>
>> So I'm not still sure if SCTP in KAME is complete and stable enough to
>> merge into -current.  (If someone can contribute to this kind of
>> evaluation, it's quite appreciated, of course!)
>>
>> Thanks,
>> ----
>> SUZUKI, Shinsuke @ KAME Project
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
> 


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)
_______________________________________________
freebsd-arch at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"