1. 03 Jun, 2009 1 commit
    • Wei Yongjun's avatar
      sctp: fix to choose alternate destination when retransmit ASCONF chunk · 9919b455
      Wei Yongjun authored
      
      
      RFC 5061 Section 5.1 ASCONF Chunk Procedures said:
      
      B4)  Re-transmit the ASCONF Chunk last sent and if possible choose an
           alternate destination address (please refer to [RFC4960],
           Section 6.4.1).  An endpoint MUST NOT add new parameters to this
           chunk; it MUST be the same (including its Sequence Number) as
           the last ASCONF sent.  An endpoint MAY, however, bundle an
           additional ASCONF with new ASCONF parameters with the next
           Sequence Number.  For details, see Section 5.5.
      
      This patch fix to choose an alternate destination address when
      re-transmit the ASCONF chunk, with some dup codes cleanup.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      9919b455
  2. 16 Feb, 2009 2 commits
    • Vlad Yasevich's avatar
      sctp: Fix the RTO-doubling on idle-link heartbeats · faee47cd
      Vlad Yasevich authored
      
      
      SCTP incorrectly doubles rto ever time a Hearbeat chunk
      is generated.   However RFC 4960 states:
      
         On an idle destination address that is allowed to heartbeat, it is
         recommended that a HEARTBEAT chunk is sent once per RTO of that
         destination address plus the protocol parameter 'HB.interval', with
         jittering of +/- 50% of the RTO value, and exponential backoff of the
         RTO if the previous HEARTBEAT is unanswered.
      
      Essentially, of if the heartbean is unacknowledged, do we double the RTO.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      faee47cd
    • Lucas Nussbaum's avatar
      sctp: Allow to disable SCTP checksums via module parameter · 06e86806
      Lucas Nussbaum authored
      
      
      This is a new version of my patch, now using a module parameter instead
      of a sysctl, so that the option is harder to find. Please note that,
      once the module is loaded, it is still possible to change the value of
      the parameter in /sys/module/sctp/parameters/, which is useful if you
      want to do performance comparisons without rebooting.
      
      Computation of SCTP checksums significantly affects the performance of
      SCTP. For example, using two dual-Opteron 246 connected using a Gbe
      network, it was not possible to achieve more than ~730 Mbps, compared to
      941 Mbps after disabling SCTP checksums.
      Unfortunately, SCTP checksum offloading in NICs is not commonly
      available (yet).
      
      By default, checksums are still enabled, of course.
      Signed-off-by: default avatarLucas Nussbaum <lucas.nussbaum@ens-lyon.fr>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06e86806
  3. 08 Oct, 2008 1 commit
    • Vlad Yasevich's avatar
      sctp: Rework the tsn map to use generic bitmap. · 8e1ee18c
      Vlad Yasevich authored
      
      
      The tsn map currently use is 4K large and is stuck inside
      the sctp_association structure making memory references REALLY
      expensive.  What we really need is at most 4K worth of bits
      so the biggest map we would have is 512 bytes.   Also, the
      map is only really usefull when we have gaps to store and
      report.  As such, starting with minimal map of say 32 TSNs (bits)
      should be enough for normal low-loss operations.  We can grow
      the map by some multiple of 32 along with some extra room any
      time we receive the TSN which would put us outside of the map
      boundry.  As we close gaps, we can shift the map to rebase
      it on the latest TSN we've seen.  This saves 4088 bytes per
      association just in the map alone along savings from the now
      unnecessary structure members.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e1ee18c
  4. 01 Oct, 2008 2 commits
  5. 04 Aug, 2008 1 commit
    • Herbert Xu's avatar
      sctp: Drop ipfargok in sctp_xmit function · f880374c
      Herbert Xu authored
      
      
      The ipfragok flag controls whether the packet may be fragmented
      either on the local host on beyond.  The latter is only valid on
      IPv4.
      
      In fact, we never want to do the latter even on IPv4 when PMTU is
      enabled.  This is because even though we can't fragment packets
      within SCTP due to the prtocol's inherent faults, we can still
      fragment it at IP layer.  By setting the DF bit we will improve
      the PMTU process.
      
      RFC 2960 only says that we SHOULD clear the DF bit in this case,
      so we're compliant even if we set the DF bit.  In fact RFC 4960
      no longer has this statement.
      
      Once we make this change, we only need to control the local
      fragmentation.  There is already a bit in the skb which controls
      that, local_df.  So this patch sets that instead of using the
      ipfragok argument.
      
      The only complication is that there isn't a struct sock object
      per transport, so for IPv4 we have to resort to changing the
      pmtudisc field for every packet.  This should be safe though
      as the protocol is single-threaded.
      
      Note that after this patch we can remove ipfragok from the rest
      of the stack too.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f880374c
  6. 22 Jul, 2008 1 commit
  7. 19 Jul, 2008 1 commit
  8. 19 Jun, 2008 1 commit
    • Vlad Yasevich's avatar
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich authored
      
      
      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: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e3216cd
  9. 04 Jun, 2008 4 commits
  10. 09 May, 2008 1 commit
  11. 24 Mar, 2008 1 commit
  12. 29 Feb, 2008 1 commit
  13. 05 Feb, 2008 1 commit
  14. 28 Jan, 2008 5 commits
  15. 20 Dec, 2007 1 commit
  16. 07 Dec, 2007 1 commit
  17. 09 Nov, 2007 1 commit
  18. 07 Nov, 2007 4 commits
  19. 11 Oct, 2007 1 commit
  20. 10 Oct, 2007 6 commits
  21. 26 Sep, 2007 2 commits
  22. 16 Sep, 2007 1 commit