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

From: Randall Stewart (randall_at_stewart.chicago.il.us)
Date: 10/23/04

  • Next message: Randall Stewart: "Re: Removing T/TCP and replacing it with something simpler" 
    Date: Sat, 23 Oct 2004 09:05:46 -0400
To: Peter Lei <peter.lei@ieee.org>

    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@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@freebsd.org mailing list
    >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
    >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    >>
    > 

    -- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Randall Stewart: "Re: Removing T/TCP and replacing it with something simpler"

    Relevant Pages