1. 29 11月, 2009 1 次提交
    • A
      sctp: on T3_RTX retransmit all the in-flight chunks · 5fdd4bae
      Andrei Pelinescu-Onciul 提交于
      When retransmitting due to T3 timeout, retransmit all the
      in-flight chunks for the corresponding  transport/path, including
      chunks sent less then 1 rto ago.
      This is the correct behaviour according to rfc4960 section 6.3.3
      E3 and
      "Note: Any DATA chunks that were sent to the address for which the
       T3-rtx timer expired but did not fit in one MTU (rule E3 above)
       should be marked for retransmission and sent as soon as cwnd
       allows (normally, when a SACK arrives). ".
      
      This fixes problems when more then one path is present and the T3
      retransmission of the first chunk that timeouts stops the T3 timer
      for the initial active path, leaving all the other in-flight
      chunks waiting forever or until a new chunk is transmitted on the
      same path and timeouts (and this will happen only if the cwnd
      allows sending new chunks, but since cwnd was dropped to MTU by
      the timeout => it will wait until the first heartbeat).
      
      Example: 10 packets in flight, sent at 0.1 s intervals on the
      primary path. The primary path is down and the first packet
      timeouts. The first packet is retransmitted on another path, the
      T3 timer for the primary path is stopped and cwnd is set to MTU.
      All the other 9 in-flight packets will not be retransmitted
      (unless more new packets are sent on the primary path which depend
      on cwnd allowing it, and even in this case the 9 packets will be
      retransmitted only after a new packet timeouts which even in the
      best case would be more then RTO).
      
      This commit reverts d0ce9291 and
      also removes the now unused transport->last_rto, introduced in
       b6157d8e.
      
      p.s  The problem is not only when multiple paths are there.  It
      can happen in a single homed environment.  If the application
      stops sending data, it possible to have a hung association.
      Signed-off-by: NAndrei Pelinescu-Onciul <andrei@iptel.org>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5fdd4bae
  2. 05 9月, 2009 3 次提交
    • V
      sctp: Try not to change a_rwnd when faking a SACK from SHUTDOWN. · d4d6fb57
      Vlad Yasevich 提交于
      We currently set a_rwnd to 0 when faking a SACK from SHUTDOWN.
      This results in an hung association if the remote only uses
      SHUTDOWNs (which it's allowed to do) to acknowlege DATA when
      closing.  The reason for that is that we simply honor the a_rwnd
      from the sack, but since we faked it to be 0, we enter 0-window
      probing.  The fix is to use the peers old rwnd and add our flight
      size to it.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      d4d6fb57
    • V
      sctp: Fix error count increments that were results of HEARTBEATS · b9f84786
      Vlad Yasevich 提交于
      SCTP RFC 4960 states that unacknowledged HEARTBEATS count as
      errors agains a given transport or endpoint.  As such, we
      should increment the error counts for only for unacknowledged
      HB, otherwise we detect failure too soon.  This goes for both
      the overall error count and the path error count.
      
      Now, there is a difference in how the detection is done
      between the two.  The path error detection is done after
      the increment, so to detect it properly, we actually need
      to exceed the path threshold.  The overall error detection
      is done _BEFORE_ the increment.  Thus to detect the failure,
      it's enough for the error count to match the threshold.
      This is why all the state functions use '>=' to detect failure,
      while path detection uses '>'.
      
      Thanks goes to Chunbo Luo <chunbo.luo@windriver.com> who first
      proposed patches to fix this issue and made me re-read the spec
      and the code to figure out how this cruft really works.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      b9f84786
    • V
      sctp: Send user messages to the lower layer as one · 9c5c62be
      Vlad Yasevich 提交于
      Currenlty, sctp breaks up user messages into fragments and
      sends each fragment to the lower layer by itself.  This means
      that for each fragment we go all the way down the stack
      and back up.  This also discourages bundling of multiple
      fragments when they can fit into a sigle packet (ex: due
      to user setting a low fragmentation threashold).
      
      We introduce a new command SCTP_CMD_SND_MSG and hand the
      whole message down state machine.  The state machine and
      the side-effect parser will cork the queue, add all chunks
      from the message to the queue, and then un-cork the queue
      thus causing the chunks to get transmitted.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      9c5c62be
  3. 03 6月, 2009 1 次提交
    • W
      sctp: fix to choose alternate destination when retransmit ASCONF chunk · 9919b455
      Wei Yongjun 提交于
      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: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      9919b455
  4. 03 3月, 2009 2 次提交
  5. 16 2月, 2009 1 次提交
    • V
      sctp: Fix the RTO-doubling on idle-link heartbeats · faee47cd
      Vlad Yasevich 提交于
      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: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      faee47cd
  6. 09 10月, 2008 1 次提交
    • V
      sctp: Rework the tsn map to use generic bitmap. · 8e1ee18c
      Vlad Yasevich 提交于
      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: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e1ee18c
  7. 01 10月, 2008 1 次提交
  8. 20 6月, 2008 1 次提交
    • V
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich 提交于
      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: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e3216cd
  9. 10 5月, 2008 1 次提交
  10. 13 4月, 2008 3 次提交
  11. 06 3月, 2008 1 次提交
  12. 05 2月, 2008 1 次提交
  13. 08 11月, 2007 1 次提交
    • V
      SCTP: Fix difference cases of retransmit. · b6157d8e
      Vlad Yasevich 提交于
      Commit d0ce9291 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 <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      b6157d8e
  14. 11 10月, 2007 1 次提交
  15. 31 8月, 2007 1 次提交
  16. 30 8月, 2007 1 次提交
  17. 05 5月, 2007 1 次提交
    • V
      [SCTP]: Set assoc_id correctly during INIT collision. · 07d93967
      Vlad Yasevich 提交于
      During the INIT/COOKIE-ACK collision cases, it's possible to get
      into a situation where the association id is not yet set at the time
      of the user event generation.  As a result, user events have an
      association id set to 0 which will confuse applications.
      
      This happens if we hit case B of duplicate cookie processing.
      In the particular example found and provided by Oscar Isaula
      <Oscar.Isaula@motorola.com>, flow looks like this:
      A				B
      ---- INIT------->  (lost)
      	    <---------INIT------
      ---- INIT-ACK--->
      	    <------ Cookie ECHO
      
      When the Cookie Echo is received, we end up trying to update the
      association that was created on A as a result of the (lost) INIT,
      but that association doesn't have the ID set yet.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07d93967
  18. 26 4月, 2007 2 次提交
  19. 11 2月, 2007 1 次提交
  20. 31 1月, 2007 1 次提交
  21. 24 1月, 2007 1 次提交
  22. 03 12月, 2006 8 次提交
  23. 22 7月, 2006 1 次提交
  24. 20 5月, 2006 1 次提交
  25. 18 1月, 2006 1 次提交
  26. 10 1月, 2006 1 次提交
  27. 04 1月, 2006 1 次提交