Query regarding SCTP ordering queue handling.

sandeep kandula <sandeepkandula30@gmail.com> Tue, 23 November 2010 07:10 UTC

Return-Path: <sandeepkandula30@gmail.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C4CAD28C19B for <tsvwg@core3.amsl.com>; Mon, 22 Nov 2010 23:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id CdATycHcGGgI for <tsvwg@core3.amsl.com>; Mon, 22 Nov 2010 23:10:51 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id 8503C28C1A3 for <tsvwg@ietf.org>; Mon, 22 Nov 2010 23:10:51 -0800 (PST)
Received: by iwn40 with SMTP id 40so9563618iwn.31 for <tsvwg@ietf.org>; Mon, 22 Nov 2010 23:11:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type; bh=JwaRDKOJ/kppRQQ08xLmV+mSYnzWQpxPfDlDZCAgayc=; b=jmQJoXedcyrLNbV8Fn4PVmpEheaB7OjkJsiLrDKqFk5wYktmpfh1hSYlRsaHc5PJe5 G17UBpEDZl/M3RnwoCZQ08C1Pk99eEHZltUGdsFeYQ/TQ2iAfEsESF31nEUNaIU6bQFk hq/bD2ZsLELbG0hF7aI0q3AKmHohRDkiv3kGo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=RvbR8Imb1nlXv2D8GIx4pMfjD8zAwjmFr2cntdUhpxYs6qyDm0I6ltr0wTzZmdOK/k n0zyx63GapLlGeKRZB/1fJomwfTcTtLfKLH9/VTXODWFFOgdDK8Qh6Kyt+z7NwAm5bSU Mrr+gcrKNsh3ZpgHtzNkyzZIsece+Z3f3Yz7o=
Received: by with SMTP id x11mr8007280ibw.22.1290496306942; Mon, 22 Nov 2010 23:11:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 22 Nov 2010 23:11:26 -0800 (PST)
From: sandeep kandula <sandeepkandula30@gmail.com>
Date: Tue, 23 Nov 2010 12:41:26 +0530
Message-ID: <AANLkTin+ow4bdkV5Z16P1vg1GptC+VRh3Fj6mJbrADBC@mail.gmail.com>
Subject: Query regarding SCTP ordering queue handling.
To: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="005045029341f5913f0495b31502"
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 07:10:52 -0000

We have scenario as explained below, please let me know how SCTP has to
handle this situation.

   1. 1.       There is an association established between two nodes (say
   Node A and Node B) and traffic is flowing between these nodes.

   1. 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.

   1. 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.

   1. 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.

   1. 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?

V Sandeep Kandula.*