Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines

Sebastien Decugis <sdecugis@nict.go.jp> Tue, 05 October 2010 07:44 UTC

Return-Path: <sdecugis@nict.go.jp>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E983A6D98 for <dime@core3.amsl.com>; Tue, 5 Oct 2010 00:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 zF---Bo-+Hwc for <dime@core3.amsl.com>; Tue, 5 Oct 2010 00:44:18 -0700 (PDT)
Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id B711A3A6E41 for <dime@ietf.org>; Tue, 5 Oct 2010 00:44:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 84CE59409D for <dime@ietf.org>; Tue, 5 Oct 2010 09:45:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr
Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsQ-erZWhZoR for <dime@ietf.org>; Tue, 5 Oct 2010 09:45:08 +0200 (CEST)
Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 021299409B for <dime@ietf.org>; Tue, 5 Oct 2010 09:45:07 +0200 (CEST)
Message-ID: <4CAAD76C.6020904@nict.go.jp>
Date: Tue, 05 Oct 2010 16:44:44 +0900
From: Sebastien Decugis <sdecugis@nict.go.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: dime@ietf.org
References: <s2v618e24241004260054z7f767689nfba37fbf82b1f030@mail.gmail.com> <v2x618e24241005030326x810b6d7fr977d506896c9802e@mail.gmail.com> <h2o919c9f451005031041h40693491y64995e345b93384f@mail.gmail.com> <4BDFB5CC.5080908@restena.lu> <p2pce72e8461005040327o5abded5tf3c2555f10169be8@mail.gmail.com> <z2k618e24241005040340rf9e948a3m90c0661a67e57bf2@mail.gmail.com> <s2y919c9f451005040534y62ae5780p7679cdd6acb221dd@mail.gmail.com> <AANLkTikLB6+B4bOJTDBSGs23QbSJpwTyzq2vg47CArXA@mail.gmail.com> <4CAA81D7.6050605@nict.go.jp> <20101005194658.2f21157e.suckfish@ihug.co.nz>
In-Reply-To: <20101005194658.2f21157e.suckfish@ihug.co.nz>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 07:44:20 -0000

 Hi,

> How is an end-point sending a CEA and then sending a request over separate SCTP streams meant to work-around this issue? 
Sorry if it was not clear, I meant it as "the only exception to
out-of-order delivery *not* being an issue".
So, what I was describing is an actual issue (in my opinion) with
multi-stream use.

It can be worked around in the implementation, for example by allowing
messages to be sent over a different stream only after a new message has
been received from the remote peer (confirming the remote peer moved the
connection to OPEN state), or after a reasonable delay (for example a
few seconds). If the first option is chosen, it can be a good practice
to always send a DWR after the CEA is received (as it is done after a
network failure recovery).

I hope this clarifies my point ^^.

Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)