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