headers
Santhanakrishnan yayathi | 28 Nov 2011 04:53
Favicon

[SCTP] Multi-Homing Path Failure detection

Dear Experts,
In the SCTP multi-homing scenario, I have certain doubts on the Path failure detection as below.
                        Two end points A and B have two paths between them named Path1 and Path2.
 
1)       End point A sends some DATA in Path1 to B. But it did not receive SACK in that path from B. Now the RTO expired in A and it incremented the Error counter for the Path1 destination address in B. And A retransmits the old DATA chunks (that were sent to B in Path1 and unacknowledged) in Path2. And also transmits some new DATA chunks. Now B acknowledges with the latest TSN (old and new DATA chunks transmitted by A). Now is it ok to clear the error counter of Path1 in A (as the old DATA chunks destined to Path1 destination address were also acknowledged by SACK received in Path2)? If A clears the error counter of Path1 in this case, I think it may encounter the same cycle of problem again. What is the suggested and desirable approach here?
 
2)       Also when an endpoint receives a DATA in certain path, Should it reply the SACK in the same path or it can also reply in other paths (in case when this alternative path also destines to the same Source Address back)?
 
Please clarify on this.
 
Regards
Santhana
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 1 comment |
headers
Michael Tüxen | 29 Nov 2011 09:34
Picon

Re: [SCTP] Multi-Homing Path Failure detection

On Nov 28, 2011, at 4:53 AM, Santhanakrishnan yayathi wrote:

Hi Santhana,

please note that SCTP related issues are discussed nowadays on tsvwg <at> ietf.org.
See comments in-line.

Best regards
Michael
> Dear Experts,
> In the SCTP multi-homing scenario, I have certain doubts on the Path failure detection as below.
>                         Two end points A and B have two paths between them named Path1 and Path2.
>  
> 1)       End point A sends some DATA in Path1 to B. But it did not receive SACK in that path from B. Now the RTO expired
in A and it incremented the Error counter for the Path1 destination address in B. And A retransmits the old
DATA chunks (that were sent to B in Path1 and unacknowledged) in Path2. And also transmits some new DATA
chunks. Now B acknowledges with the latest TSN (old and new DATA chunks transmitted by A). Now is it ok to
clear the error counter of Path1 in A (as the old DATA chunks destined to Path1 destination address were
also acknowledged by SACK received in Path2)? If A clears the error counter of Path1 in this case, I think it may
You don't clear the error counter for Path1. You do clear the error counter for Path2.
After retransmitting the first TSN, this TSN is not outstanding anymore on Path1, but on Path2.
Please see the rules in
http://tools.ietf.org/html/rfc4960#section-8.2
> encounter the same cycle of problem again. What is the suggested and desirable approach here?
>  
> 2)       Also when an endpoint receives a DATA in certain path, Should it reply the SACK in the same path or it can
also reply in other paths (in case when this alternative path also destines to the same Source Address back)?
http://tools.ietf.org/html/rfc4960#section-6.4
reads:

 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.

 However, when acknowledging multiple DATA chunks received in packets
 from different source addresses in a single SACK, the SACK chunk may
 be transmitted to one of the destination transport addresses from
 which the DATA or control chunks being acknowledged were received.
>  
> Please clarify on this.
>  
> Regards
> Santhana
> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 0 comments |

Gmane