01 Oct, 2008

4 commits


23 Jul, 2008

1 commit


20 Jun, 2008

1 commit

  • RFC 4960, Section 11.4. Protection of Non-SCTP-Capable Hosts

    When an SCTP stack receives a packet containing multiple control or
    DATA chunks and the processing of the packet requires the sending of
    multiple chunks in response, the sender of the response chunk(s) MUST
    NOT send more than one packet. If bundling is supported, multiple
    response chunks that fit into a single packet MAY be bundled together
    into one single response packet. If bundling is not supported, then
    the sender MUST NOT send more than one response chunk and MUST
    discard all other responses. Note that this rule does NOT apply to a
    SACK chunk, since a SACK chunk is, in itself, a response to DATA and
    a SACK does not require a response of more DATA.

    We implement this by not servicing our outqueue until we reach the end
    of the packet. This enables maximum bundling. We also identify
    'response' chunks and make sure that we only send 1 packet when sending
    such chunks.

    Signed-off-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

05 Jun, 2008

2 commits

  • When fast retransmit is triggered by a sack, we should flush the queue
    only once so that only 1 retransmit happens. Also, since we could
    potentially have non-fast-rtx chunks on the retransmit queue, we need
    make sure any chunks eligable for fast retransmit are sent first
    during fast retransmission.

    Signed-off-by: Vlad Yasevich
    Tested-by: Wei Yongjun
    Signed-off-by: David S. Miller

    Vlad Yasevich
     
  • When we are trying to fast retransmit the lowest outstanding TSN, we
    need to restart the T3-RTX timer, so that subsequent timeouts will
    correctly tag all the packets necessary for retransmissions.

    Signed-off-by: Vlad Yasevich
    Tested-by: Wei Yongjun
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

18 Apr, 2008

1 commit


14 Apr, 2008

1 commit


13 Apr, 2008

2 commits


06 Mar, 2008

1 commit


01 Mar, 2008

1 commit

  • RFC 3873 specifies several MIB objects that can't be obtained by the
    current data set exported by /proc/sys/net/sctp/assoc. This patch
    adds the missing pieces of data that allow us to compute all the
    objects in the sctpAssocTable object.

    Signed-off-by: Neil Horman
    Signed-off-by: Vlad Yasevich
    Signed-off-by: David S. Miller

    Neil Horman
     

07 Feb, 2008

1 commit


05 Feb, 2008

1 commit

  • I was notified by Randy Stewart that lksctp claims to be
    "the reference implementation". First of all, "the
    refrence implementation" was the original implementation
    of SCTP in usersapce written ty Randy and a few others.
    Second, after looking at the definiton of 'reference implementation',
    we don't really meet the requirements.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     

29 Jan, 2008

1 commit


10 Nov, 2007

1 commit

  • When the code calls uncork, trigger a queue flush, even
    if the queue was not corked. Most callers that explicitely
    cork the queue will have additinal checks to see if they
    corked it. Callers who do not cork the queue expect packets
    to flow when they call uncork.

    The scneario that showcased this bug happend when we were not
    able to bundle DATA with outgoing COOKIE-ECHO. As a result
    the data just sat in the outqueue and did not get transmitted.
    The application expected a response, but nothing happened.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     

08 Nov, 2007

2 commits

  • Commit d0ce92910bc04e107b2f3f2048f07e94f570035d broke several retransmit
    cases including fast retransmit. The reason is that we should
    only delay by rto while doing retranmists as a result of a timeout.
    Retransmit as a result of path mtu discover, fast retransmit, or
    other evernts that should trigger immidiate retransmissions got broken.

    Also, since rto is doubled prior to marking of packets elegable for
    retransmission, we never marked correct chunks anyway.

    The fix is provide a reason for a given retransmission so that we
    can mark chunks appropriately and to save the old rto value to do
    comparisons against.

    All regressions tests passed with this code.

    Spotted by Wei Yongjun

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     
  • Just fix the bad format of the comment in outqueue.c.

    Signed-off-by: Wei Yongjun
    Signed-off-by: Vlad Yasevich

    Wei Yongjun
     

31 Aug, 2007

1 commit


26 Apr, 2007

1 commit

  • Spring cleaning time...

    There seems to be a lot of places in the network code that have
    extra bogus semicolons after conditionals. Most commonly is a
    bogus semicolon after: switch() { }

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

27 Feb, 2007

1 commit

  • The problem that this patch corrects happens when all of the following
    conditions are satisfisfied:
    1. PR-SCTP is used and the timeout on the chunks is set below RTO.Max.
    2. One of the paths on a multihomed associations is brought down.

    In this scenario, data will expire within the rto of the initial
    transmission and will never be retransmitted. However this data still
    fills the send buffer and is counted against the association as outstanding
    data. This causes any new data not to be sent and retransmission to not
    happen.

    The fix is to discount the abandoned data from the outstanding count and
    peers rwnd estimation. This allows new data to be sent and a retransmission
    timer restarted. Even though this new data will most likely expire within
    the rto, the timer still counts as a strike against the transport and forces
    the FORWARD-TSN chunk to be retransmitted as well.

    Signed-off-by: Vlad Yasevich
    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

11 Feb, 2007

1 commit


03 Dec, 2006

2 commits


30 Sep, 2006

1 commit

  • Currently if the sender is sending small messages, it can cause a receiver
    to run out of receive buffer space even when the advertised receive window
    is still open and results in packet drops and retransmissions. Including
    a overhead while updating the sender's view of peer receive window will
    reduce the chances of receive buffer space overshooting the receive window.

    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Sridhar Samudrala
     

23 Sep, 2006

1 commit

  • This patch adds more statistics info under /proc/net/sctp/snmp
    that should be useful for debugging. The additional events that
    are counted now include timer expirations, retransmits, packet
    and data chunk discards.

    The Data chunk discards include all the cases where a data chunk
    is discarded including high tsn, bad stream, dup tsn and the most
    useful one(out of receive buffer/rwnd).

    Also moved the SCTP MIB data structures from the generic include
    directories to include/sctp/sctp.h.

    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Sridhar Samudrala
     

22 Jul, 2006

1 commit


18 Jun, 2006

1 commit


03 Feb, 2006

1 commit

  • SCTP used to "fast retransmit" a TSN every time we hit the number
    of missing reports for the TSN. However the Implementers Guide
    specifies that we should only "fast retransmit" a given TSN once.
    Subsequent retransmits should be timeouts only. Also change the
    number of missing reports to 3 as per the latest IG(similar to TCP).

    Signed-off-by: Vlad Yasevich
    Signed-off-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    Vlad Yasevich
     

09 Jul, 2005

1 commit


21 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds