Re: Query regarding SCTP ordering queue handling.

Randy Stewart <randall@lakerest.net> Tue, 23 November 2010 12:27 UTC

Return-Path: <randall@lakerest.net>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264DC3A68FD for <tsvwg@core3.amsl.com>; Tue, 23 Nov 2010 04:27:45 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH51WC56wVh6 for <tsvwg@core3.amsl.com>; Tue, 23 Nov 2010 04:27:44 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id BC0873A6938 for <tsvwg@ietf.org>; Tue, 23 Nov 2010 04:27:42 -0800 (PST)
Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id oANCSWmc007340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Nov 2010 07:28:33 -0500 (EST) (envelope-from randall@lakerest.net)
Subject: Re: Query regarding SCTP ordering queue handling.
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=windows-1252
From: Randy Stewart <randall@lakerest.net>
In-Reply-To: <F21220AC-F297-4DE2-86FF-B64EE1B68D96@lurchi.franken.de>
Date: Tue, 23 Nov 2010 04:28:33 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E36B4EC2-C8A7-4986-9893-CA5F6B1659AA@lakerest.net>
References: <AANLkTin+ow4bdkV5Z16P1vg1GptC+VRh3Fj6mJbrADBC@mail.gmail.com> <F21220AC-F297-4DE2-86FF-B64EE1B68D96@lurchi.franken.de>
To: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1082)
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2010 12:27:45 -0000

Michael:
I agree with your assessment .. but I do have a query for Sandeep (I assume
this is how you interpreted his request but it is not clear)...


On Nov 22, 2010, at 11:48 PM, Michael Tüxen wrote:

> On Nov 23, 2010, at 8:11 AM, sandeep kandula wrote:
>> We have scenario as explained below, please let me know how SCTP has to handle this situation.
>> 
>> 	• 1.       There is an association established between two nodes (say Node A and Node B) and traffic is flowing between these nodes.
>> 	• 2.       Node A sent a data chunk with TSN 25 to Node B. Even though this is complete chunk, due to error at sending side, the B-bit was sent while sending before the checksum is calculated.

So you would normally have the B and E bit set, so the E bit is NOT set would be how I would guess
you mean?


>> 	• 3.       On reception of chunk (TSN 25) at Node B, it will be keep this chunk in ordering queue as it is expecting the other fragments and will not provide it to SCTP user. Node B will acknowledge the TSN 25 with a SACK.
>> 	• 4.       As B-bit was set due to error at Node-A, it will not transmit any other fragment of the packets to Node-B.
>> 	• 5.       Node-B will be waiting for infinitely for other fragments of the packets and it will be able to deliver it user.
>> Is this the expected behavior of the SCTP at Node-B? If not, can anyone please tell what shall be correct behavior of the SCTP at Node-B? How SCTP can overcome from such situations?
> Node B is behaving correctly. To overcome this situation, fix Node A.
> 
> Please note, that the situation might change if Node A sends another message.
> Then Node B might be able to figure out that Node A is violating the protocol
> specification and might (depending on the implementation) send an ABORT. It
> might include an error cause indicating a protocol violation.

I know that the BSD implementation would send an ABORT if say TSN 26 were sent with B bit set. Since
it would recognize the peer (A) has violated the protocol sending to chunks with B=1/E=0 set in a row.

R

> 
> Best regards
> Michael
>> 
>> Regards,
>> V Sandeep Kandula.
> 
> 

-----
Randall Stewart
randall@lakerest.net