IETF Logo Mail Archive

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

Victor Pascual Avila <victor.pascual.avila@gmail.com> Wed, 06 October 2010 16:09 UTC

Return-Path: <victor.pascual.avila@gmail.com>
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 5C2663A716D for <dime@core3.amsl.com>; Wed, 6 Oct 2010 09:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level:
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 F3h-V5Hr8Ko7 for <dime@core3.amsl.com>; Wed, 6 Oct 2010 09:09:27 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EB6EE3A7151 for <dime@ietf.org>; Wed, 6 Oct 2010 09:09:26 -0700 (PDT)
Received: by bwz9 with SMTP id 9so6964073bwz.31 for <dime@ietf.org>; Wed, 06 Oct 2010 09:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=L4ynPHpF4wlIJGzwNcQymi5c7xSnW+ylHsE3ufJw5gc=; b=h5/R5y0HcIa37e6/XzN0uGn2KUWmKc8s311/2xkvNZqmHg74EcNitnIzuXe8mwF3fD 2CBPOXbjWW3KaK2RNzLV+mxvF5WwLAjP+bVR2/v2n6Rs/GaoaIp1vbVafF1rRDEQvW/j Pf52ATn64uUnRSSF8y0hyRnjI2j2CuvlQMPmo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZmrvShviMJgabzM+1UAH/dtfx0IvMvYY86/7QMNs0JbqJcxvlPkeVBovKfiOB4MrsI QgxC9OMFPreO93oAE2RsPkUVVj1Yp7T8T52iezymrOIi+dcxLgwW+dE4HoWf+8NLq43m MXxoYkOTyTSWT2HWUxoV/UWM2VBk9RErngieE=
MIME-Version: 1.0
Received: by 10.204.112.136 with SMTP id w8mr5577751bkp.162.1286381426152; Wed, 06 Oct 2010 09:10:26 -0700 (PDT)
Received: by 10.204.78.144 with HTTP; Wed, 6 Oct 2010 09:10:25 -0700 (PDT)
In-Reply-To: <20101005194658.2f21157e.suckfish@ihug.co.nz>
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>
Date: Wed, 06 Oct 2010 12:10:25 -0400
Message-ID: <AANLkTimAbUShpYNNPu3QSjpPS2w9Q8JUHV3RPq8YZdPM@mail.gmail.com>
From: Victor Pascual Avila <victor.pascual.avila@gmail.com>
To: Ralph Loader <suckfish@ihug.co.nz>
Content-Type: multipart/alternative; boundary="0016e6de16c4f3a1250491f50305"
Cc: dime@ietf.org
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: Wed, 06 Oct 2010 16:09:30 -0000

Hi Ralph,

please see my response below.

On Tue, Oct 5, 2010 at 2:46 AM, Ralph Loader <suckfish@ihug.co.nz> wrote:

> > The only exception that is worth clarification in my opinion is the
> > interaction between applications and Base Protocol messages such as
> > CER/CEA or STR/STA: for example if a new message is sent just after the
> > CEA and received out of order by the other peer, it will be discarded.
> > Also, if an STR is sent straight after a message and received before
> > this message, the message will be dropped as well. This might be worth
> > stating in the RFC. It is quite easy to work around these issues in the
> > implementation, as long as they have been anticipated.
>
> How is an end-point sending a CEA and then sending a request over separate
> SCTP streams meant to work-around this issue?  [I might be out of date, but
> I thought that the Diameter RFCs required that an implementation using SCTP
> MUST use multiple streams, which implies some out-of-order delivery.]
>
In order to prevent head-of-the-line-blocking, one could either send
over multiple SCTP streams using ordered delivery (and map Diameter sessions
intro SCTP streams) or send over a single stream using unordered delivery
(this is actually how SIP over SCTP works).

-Victor

v2.29.0 | Report a Bug | By Email | System Status