Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 05 Nov 2006 09:15:14 -0500
From:      Randall Stewart <rrs@cisco.com>
To:        Randall Stewart <rrs@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/netinet sctp_bsd_addr.c sctp_crc32.c     sctp_indata.c sctp_input.c sctp_output.c sctp_pcb.c sctp_structs.h   sctp_uio.h sctputil.c sctputil.h src/sys/netinet6 sctp6_usrreq.c
Message-ID:  <454DF1F2.6050006@cisco.com>
In-Reply-To: <200611051325.kA5DPIkb074516@repoman.freebsd.org>
References:  <200611051325.kA5DPIkb074516@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Randall Stewart wrote:
> rrs         2006-11-05 13:25:18 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/netinet          sctp_bsd_addr.c sctp_crc32.c 
>                          sctp_indata.c sctp_input.c sctp_output.c 
>                          sctp_pcb.c sctp_structs.h sctp_uio.h 
>                          sctputil.c sctputil.h 
>     sys/netinet6         sctp6_usrreq.c 
>   Log:
>   Tons of fixes to get all the 64bit issues removed.
>   This also moves two 16 bit int's to become 32 bit
>   values so we do not have to use atomic_add_16.
>   Most of the changes are %p, casts and other various
>   nasty's that were in the orignal code base. With this
>   commit my machine will now do a build universe.. however
>   I as yet have not tested on a 64bit machine .. it may not work :-(
>   
>   Revision  Changes    Path
>   1.2       +7 -7      src/sys/netinet/sctp_bsd_addr.c
>   1.3       +1 -1      src/sys/netinet/sctp_crc32.c
>   1.2       +4 -4      src/sys/netinet/sctp_indata.c
>   1.4       +7 -5      src/sys/netinet/sctp_input.c
>   1.2       +9 -9      src/sys/netinet/sctp_output.c
>   1.4       +8 -8      src/sys/netinet/sctp_pcb.c
>   1.2       +5 -4      src/sys/netinet/sctp_structs.h
>   1.2       +8 -8      src/sys/netinet/sctp_uio.h
>   1.3       +35 -21    src/sys/netinet/sctputil.c
>   1.2       +2 -2      src/sys/netinet/sctputil.h
>   1.3       +5 -4      src/sys/netinet6/sctp6_usrreq.c
> 
A few notes about this commit.. if your playing with SCTP
everything should work fine with a couple of cavets (besides
64 bit machines.. which may or may-not work :-0)

1) If you want to play with "mobility" type issues where you
    can have addresses come and go dynamically by your SCTP
    stack you need to:
    a) bind all addresses (INADDR_ANY).
    b) You need to enable the behavior with a sysctl
       net.inet.sctp.auto_asconf..
    c) This should enable you to do ifconfig inf new-addr netmask newmask
       and the association you create with a peer will stay up and
       reconfigure the addresses dynamically...

   Why: Well the reason it is a sysctl and must be activated is that
        currently the code needs some tweaking to make it so that if
        you had 10,000 associations up  and added an address you would
        not sink the machine :-( ... In theory we need to move this to
        a thread.. and/or to use the iterator (or both more like to help
        keep supporting apple and other platforms that do not have
        k-threads).

2) Paritial reliability is fully supported and can be accessed by
    using the send options described in the sctp-sockets draft in
    the IETF :-D

3) Authentication (sort-a like TCP-MD5.. but not requiring shared
    keys.. they are optional) is also fully supported.. you may
    use socket options to enable additional chunks (besides the
    required dynamic addressing ones) to be auth'd. Note that if
    you auth data, performance will drop to 1/5 of what it was :-0
    Shared keys can be set also by socket option
   (see the draft-ietf-tsvwg-auth .. soon to be RFC)... for more
    details. Note also, that you MAY not work with older versions
    that do not support the latest auth-draft (the one that finished
    WG-LC).. they added the chunks being auth'd to the key material.
    If you hit this problem (I don't any but BSD and IOS support this
    but you never know).. there is a compile option that can get the
    old draft behavior... send me an email in the "unlikely event of
    a water landing" :-)

4) If you are deep into playing with "TCP emulation mode, you will be
    turning on SCTP_EEOR on you socket (Explicit End Of Record). And
    setting your partial delivery point to 1 byte. This is cool and works
    gaining a bit of performance in the mix .. however there is currently
    a bug I am chasing. If the peer is NOT in this same mode.. and is in
    the more traditional.. implied-EEOR (where each send is considered a
    message) and the PD-API point is NOT set (left to default).. when the
    guy that is SCTP_EEOR mode closes the socket without sending the last
    data with an explicit EOR.. the peer will get stuck.. waiting for
    data. There is a missing wakeup somewhere that I need to find. All
    other modes (EEOR -> EEOR), (NON-EEOR -> NON-EEOR),
    (NON-EEOR -> EEOR) work fine.. its only the one case I have yet to
    nail.. I will try to get this fixed (and approved by gnn) as soon
    as I trace down this item.. I am hoping I can find it on my laptop
    on loopback.. or debugging will be a bit of a challenge :-0

5) You are best to not compile in any options .. just option SCTP ...
    however.. if you want to see LOTS of msgs on the console you can
    add SCTP_DEBUG... then you can either play with the sysctl var:
    net.inet.sctp.debug. This int is a bit mask that turns on various
    prints in the code.. if you are a REAL glutton make it 0xffffffff
    .. each bit has a different meaning... but please note I usualy
    NEVER compile with this option.. it adds a LOT of
    if(sctp_debug_on & MASK_VALUE) to the code... without it they
    disappear from the code at compile time. The other option is
    a socket option to set this value too... contact me offline if
    you want to know it..

6) If you want to enable Sally Floyd's High Speed TCP Congestion Control
    its a compile options option SCTP_HIGH_SPEED. In the future we will
    be adding more "pluggable" congestion control with a varient of
    Doug Leith's H-TCP as well as Sally's.. and make it a sysctl to
    switch amongst the choices :-)

7) If you really really are a junky for fun, there are a set of various
    logging utilites. You first start with SCTP_STAT_LOGGING options.
    this enables a 80,000 entry chunk of memory and all the utilities to
    log dynamically with minimal overhead (no locks, just an atomic op).
    Once you turn this on, you must select one of the other logging
    entries to get some real logs. There are things on cwnd/flight
    blocking/locking.. and all sorts of things. I actually have some
    tools where you can watch the cwnd/flight/rwnd in a conversation
    between two machines over time graphically... you suck this data
    out and then dump it into files which then can be plotted.. its
    kinda-cool actually.. but you have to be a real junky to want
    to play with this... if you are such a guy send me a private email
    and I will send you code and further instructions.

8) I will try to figure out where libsctp.a should go (the extra SCTP
    non-system call, system calls)... and a few select test tools.
    (advice would be appreciated).....

    You should, in theory, be able to take ANY TCP program and change
    the sd = socket(AF_INET, SOCK_STREAM, 0) [the 0 is sloppy programming
    in my mind now] and replace it with
    sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)
    and your program should work.. there are equivilants to TCP_NODELAY
    and other socket options (just change the TCP to SCTP :-D).

    Note I usually use the one-2-many model.. which is gotten via
    sd = socket(AF_INET, SOCK_DGRAM, IPPROTO_SCTP). This looks like
    udp more than anything else.. You just send to who you want to
    and if no assoc exists.. you will get one setup implicitly for
    you (also carrying your first message piggyback on the 3rd leg
    of the 4-way handshake) :-)

9) Tell me about anything strange please.. if there are issues (which
    there may be even besides the 64 bit ones) I want to know about it
    and get my small team working on fixing them. Most of the sctp geeks
    will be at the IETF so any problems this next week can hopefully be
    fixed fairly quickly :-)



Have fun and
Happy SCTPing :-)
R
-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454DF1F2.6050006>