Re: Transmission of DATA Chunks - question on CMT SCTP
Randy Stewart <randall@lakerest.net> Fri, 28 January 2011 12:58 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 4745A3A688E for <tsvwg@core3.amsl.com>; Fri, 28 Jan 2011 04:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 WOjYkOZKA0rc for <tsvwg@core3.amsl.com>; Fri, 28 Jan 2011 04:58:22 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 2E58B3A688C for <tsvwg@ietf.org>; Fri, 28 Jan 2011 04:58:21 -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 p0SD19ID093267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 08:01:10 -0500 (EST) (envelope-from randall@lakerest.net)
Subject: Re: Transmission of DATA Chunks - question on CMT SCTP
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Randy Stewart <randall@lakerest.net>
In-Reply-To: <CF340E42AED0874C81947E18863DE77B0A52FB6D22@EXMB03.eu.tieto.com>
Date: Fri, 28 Jan 2011 08:01:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A38BF50-8846-42A4-9E8C-ED6F4F276668@lakerest.net>
References: <CF340E42AED0874C81947E18863DE77B0A52FB6D22@EXMB03.eu.tieto.com>
To: "<Karen.Nielsen@tieto.com>" <Karen.Nielsen@tieto.com>
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: Fri, 28 Jan 2011 12:58:24 -0000
On Jan 27, 2011, at 6:50 AM, <Karen.Nielsen@tieto.com> <Karen.Nielsen@tieto.com> wrote: > Hi, > > In RFC 4960 Section 6.1 it is stated that transmission of new data should await retransmissions. > That is: > > C) When the time comes for the sender to transmit, before sending new > DATA chunks, the sender MUST first transmit any outstanding DATA > chunks that are marked for retransmission (limited by the current > cwnd). > > In our SCTP implementation we have followed this rule literally on a per association basis. That is, we do not send new data on any path of the association, if there > is data marked for retransmission which is awaiting transmittal. But I also know of SCTP implementations where this rule is obeyed only on an path basis. I.e. data for retransmission > is somehow locked to a particular path and new data may flow out on other paths even if there is data waiting to be retransmitted on a per association basis. > > I would like to know if anybody knows what is the chosen approach in the CMT setting in this respect - ? > > Also I am interesting in knowing if there is any clear consensus on how the RFC 4690 should be interpreted in the non CMT case - ? I personally do not feel that you have to block sending new data to a path if some other path has outstanding data marked for retransmission. As long as the sender is obeying the cwnd for each path I see no issue here... I tend to like to lock a chunk to a path and only allow it to change to a different path if a T3-rxt happens. I like to keep any FR set so that you FR to the destination it was sent to... this allows multiple-fr of the same chunk.. until you finally hit a T3 on a chunk and move it to another path... CMT is a bit different but may benefit by the same rule.. I can't, off the top of my head, remember how Jana and I implemented it in FreeBSD.. I guess I need to get a cup of coffee and go take a look ;-) R R > > Thanks ! > > BR, Karen > > > ***************************************************************************************** > Karen Egede Nielsen > Software Architect, Ph.D. > > Tieto Denmark A/S > IP Solutions, Telecom & Media > Skanderborgvej 232, 8260 Viby J, DK-Denmark > Direct Phone / Mobile +45 25134336 > E-mail: karen.nielsen@tieto.com > ***************************************************************************************** > www.tieto.com > > > ----- Randall Stewart randall@lakerest.net
- Transmission of DATA Chunks - question on CMT SCTP Karen.Nielsen
- Re: Transmission of DATA Chunks - question on CMT… Randy Stewart