From santhanakrishnan.yayathi@huawei.com Sun Nov 27 19:54:28 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204421F0C34 for ; Sun, 27 Nov 2011 19:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+CWujWLHM12 for ; Sun, 27 Nov 2011 19:54:27 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7F21F8B80 for ; Sun, 27 Nov 2011 19:54:27 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVC00IKHQUIZR@szxga05-in.huawei.com> for sigtran@ietf.org; Mon, 28 Nov 2011 11:54:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVC00H0SQTZ79@szxga05-in.huawei.com> for sigtran@ietf.org; Mon, 28 Nov 2011 11:54:18 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFH43702; Mon, 28 Nov 2011 11:54:18 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 Nov 2011 11:54:01 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.165]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Mon, 28 Nov 2011 11:53:24 +0800 Date: Mon, 28 Nov 2011 03:53:55 +0000 From: Santhanakrishnan yayathi X-Originating-IP: [10.18.1.32] To: "sigtran@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/noSlkJ9WWSycpdn9JMz7w)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [SCTP] Multi-Homing Path Failure detection Thread-index: AcytgVmMRExTSct6TDO0wdvmnsm9sg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Sigtran] [SCTP] Multi-Homing Path Failure detection X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 02:10:27 -0000 --Boundary_(ID_/noSlkJ9WWSycpdn9JMz7w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT 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 --Boundary_(ID_/noSlkJ9WWSycpdn9JMz7w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
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
--Boundary_(ID_/noSlkJ9WWSycpdn9JMz7w)-- From Michael.Tuexen@lurchi.franken.de Tue Nov 29 00:34:50 2011 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E33021F8B51 for ; Tue, 29 Nov 2011 00:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPYcyvvbM0ev for ; Tue, 29 Nov 2011 00:34:49 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 896A321F8B54 for ; Tue, 29 Nov 2011 00:34:49 -0800 (PST) Received: from [192.168.1.200] (p508FA20D.dip.t-dialin.net [80.143.162.13]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 04E3C1C0C0BD4; Tue, 29 Nov 2011 09:34:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 29 Nov 2011 09:34:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D911C2A-F4F5-466A-A2BE-00E449D42CA1@lurchi.franken.de> References: To: Santhanakrishnan yayathi X-Mailer: Apple Mail (2.1251.1) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] [SCTP] Multi-Homing Path Failure detection X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 08:34:50 -0000 On Nov 28, 2011, at 4:53 AM, Santhanakrishnan yayathi wrote: Hi Santhana, please note that SCTP related issues are discussed nowadays on = tsvwg@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. > =20 > 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? > =20 > 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. > =20 > Please clarify on this. > =20 > Regards > Santhana > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran