Re: SCTP bundling of SACK + DATA on a non-primary path.

Mikhail P.

No it is not a violation (thanks Michael T.), but in general 
bundling is "a good thing", reducing per packet overhead,
particularly important on receipt.  Perhaps you don't trust 
non-PRIMARY paths enough.  Such a path may have been the
PRIMARY one recently, changed just by some ULP decision.
In your scenario, thes non PRIMARY PATH was at least able to 
to deliver the original DATA to you.  SCTP should correctly 
manage and avoid any paths that are encountering difficulties 
(fast failover discussions aside).

Chris Benson.

On Wed, 9 Mar 2011, Michael Tüxen wrote:

>>  Date: Wed, 9 Mar 2011 17:04:18 +0100
>>  From: Michael Tüxen <[email protected]>
>>  To: Mikhail Plotkin <[email protected]>
>>  Cc: Chris Benson <[email protected]>,  <[email protected]>
>>  Subject: Re: [Sigtran] SCTP bundling of SACK + DATA on a non-primary path.
>>  
>>  On Mar 9, 2011, at 4:58 PM, Mikhail Plotkin wrote:
>>  
>>  > Thanks Chris!
>>  > It seems that "by default" words are the key to this issue.
>>  > Yet another question: would it be a violation of the RFC if the implementation chooses to NOT bundle SACK with DATA in the cases when SACK is answered to a DATA received from a non-primary destination address?
>>  You can do that. Bundling on the sender side is optional as indicated
>>  by the last sentence of section 6 (just before subsection 6.1) of RFC 4960.
>>  
>>  However, most implementation support it.
>>  
>>  Best regards
>>  Michael
>>  > 
>>  > BR/ Mikhail
>>  > 
>>  >> Mikhail,
>>  > 
>>  >> 
>>  > 
>>  >> I do not believe that there is a conflict of rules.
>>  > 
>>  >> 
>>  > 
>>  >>>> In chapter 6.4 FOURTH PARAGRAPH it says:
>>  > 
>>  >>>> 
>>  > 
>>  >>>>    An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
>>  > 
>>  >>>>    etc.) to the same destination transport address from which it
>>  > 
>>  >>>>    received the DATA or control chunk to which it is replying.
>>  > 
>>  >> 
>>  > 
>>  >> This is a clear instruction (actually just advice) for replies.
>>  > 
>>  >> 
>>  > 
>>  >> And from the same Section 6.4, THIRD PARAGRAPH:
>>  > 
>>  >>>>    By default, an endpoint SHOULD always transmit to the primary path,
>>  > 
>>  >>>>    unless the SCTP user explicitly specifies the destination transport
>>  > 
>>  >>>>    address (and possibly source transport address) to use.
>>  > 
>>  >> 
>>  > 
>>  >> This is a statement (advice) about what to do "by default".  
>>  > 
>>  >> "By default" means in the absence of any other applicable rules 
>>  > 
>>  >> like the FOURTH PARAGRAPH cited above.
>>  > 
>>  >> 
>>  > 
>>  >> Replies should follow the FOURTH PARAGRAPH rule.  Other data 
>>  > 
>>  >> should usually be transmitted on the PRIMARY path unless the 
>>  > 
>>  >> user (ULP requested otherwise).  There are some other cases 
>>  > 
>>  >> that may affect path selection (for example, if previously
>>  > 
>>  >> sent DATA was not SACK'd, try re-sending to another address).
>>  > 
>>  >> 
>>  > 
>>  >> Although you might decide to designate your "BEST" path as 
>>  > 
>>  >> the PRIMARY path, the other paths aren't expected to be as 
>>  > 
>>  >> "BAD" as your question implies.  They are certainly REQUIRED
>>  > 
>>  >> to be bi-directional (to exchange HEARTBEATs at least).
>>  > 
>>  >> 
>>  > 
>>  >> Perhaps I should have gone for the shorter answer: You are not 
>>  > 
>>  >> required to send all messages on the PRIMARY path.  But that's
>>  > 
>>  >> what you should do if there is no other applicable "rule" for
>>  > 
>>  >> path or detsination selection.
>>  > 
>>  >> 
>>  > 
>>  >> Chris.
>>  > 
>>  >> 
>>  > 
>>  >> 
>>  > 
>>  >> On Thu, 3 Mar 2011, Mikhail Plotkin wrote:
>>  > 
>>  >> 
>>  > 
>>  >>>> Date: Thu, 03 Mar 2011 16:35:17 +0300
>>  > 
>>  >>>> From: Mikhail Plotkin 
>>  > 
>>  >>>> To:  
>>  > 
>>  >>>> Subject: [Sigtran] SCTP bundling of SACK + DATA on a non-primary path.
>>  > 
>>  >>>> 
>>  > 
>>  >>>> Hi All,
>>  > 
>>  >>>> 
>>  > 
>>  >>>> I need a piece of advise regarding interpretation of the rules from RFC 4960.
>>  > 
>>  >>>> In chapter 6.4 it says:
>>  > 
>>  >>>> 
>>  > 
>>  >>>>    An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
>>  > 
>>  >>>>    etc.) to the same destination transport address from which it
>>  > 
>>  >>>>    received the DATA or control chunk to which it is replying.  This
>>  > 
>>  >>>>    rule should also be followed if the endpoint is bundling DATA chunks
>>  > 
>>  >>>>    together with the reply chunk.
>>  > 
>>  >>>> 
>>  > 
>>  >>>> We see the issue here:
>>  > 
>>  >>>> If the rule above is followed, SACK+DATA may be sent via the path which is different from the primary path. It may result in some problems, even to packets losses, especially  if paths are uni-directional. Moreover it seem to conflict with another rule from the same chapter:
>>  > 
>>  >>>> 
>>  > 
>>  >>>>    By default, an endpoint SHOULD always transmit to the primary path,
>>  > 
>>  >>>>    unless the SCTP user explicitly specifies the destination transport
>>  > 
>>  >>>>    address (and possibly source transport address) to use.
>>  > 
>>  >>>> 
>>  > 
>>  >>>> A possible solution could be NOT to bundle DATA with SACK if the SACK is going to be sent via not primary path. But then, there is another rule in chapter 6.1:
>>  > 
>>  >>>> 
>>  > 
>>  >>>> Before an endpoint transmits a DATA chunk, if any received DATA
>>  > 
>>  >>>> chunks have not been acknowledged (e.g., due to delayed ack), the
>>  > 
>>  >>>> sender should create a SACK and bundle it with the outbound DATA
>>  > 
>>  >>>> chunk, as long as the size of the final SCTP packet does not exceed
>>  > 
>>  >>>> the current MTU.
>>  > 
>>  >>>> How should we resolve these seeming contradictions?
>>  > 
>>  >>>> Thanks.
>>  > 
>>  >>>> _______________________________________________
>>  > 
>>  >>>> Sigtran mailing list
>>  > 
>>  >>>> [email protected]
>>  > 
>>  >>>> https://www.ietf.org/mailman/listinfo/sigtran
>>  > 
>>  >>>> 
>>  > 
>>  >> 
>>  > 
>>  >> 
>>  > _______________________________________________
>>  > Sigtran mailing list
>>  > [email protected]
>>  > https://www.ietf.org/mailman/listinfo/sigtran
>>  > 
>>

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran