Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines
Victor Fajardo <vf0213@gmail.com> Tue, 04 May 2010 12:35 UTC
Return-Path: <vf0213@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 9FC113A6BC1 for <dime@core3.amsl.com>; Tue, 4 May 2010 05:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.509, 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 vWg+mYmzrl2o for <dime@core3.amsl.com>; Tue, 4 May 2010 05:35:04 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A83283A67D3 for <dime@ietf.org>; Tue, 4 May 2010 05:34:39 -0700 (PDT)
Received: by wwi18 with SMTP id 18so1081242wwi.31 for <dime@ietf.org>; Tue, 04 May 2010 05:34:22 -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=cyYPaPGcB5vYjvKEN6erQ+ggRskr4sDQWuyPWk8cCYk=; b=kGqxz4j4PNA4tm19jKz5kylEeI4+sk7pGXmb6743Z1yEhnvishewzRSHfuiBRoPo63 cfkvJC0rA9ME4sdMSwKCOEf2c1YVsIj1k2C+U8Se2gU5UcUVd8FFluCfi+vNUAcMeT2M /usLrQgxSRZPDfoRfRcn/aAAvKi0kVnM6meaU=
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=kerWRk2ttYi96hw1MDtVWkyRinuu/9BdLCbVTasHNVaZEYhVz/2c30uPK9sIIld9pK gx0MYUFMjU3z53Fo3/RqRr/MTWKon6JaorHU2jAwhEDHoKyR7zIV0hkcGgGNBkBSER5V iQ8Gav5JY6frFVBitAWWKnvUMgj+IUbcYPcU4=
MIME-Version: 1.0
Received: by 10.216.166.8 with SMTP id f8mr6883767wel.182.1272976462374; Tue, 04 May 2010 05:34:22 -0700 (PDT)
Received: by 10.216.187.195 with HTTP; Tue, 4 May 2010 05:34:22 -0700 (PDT)
In-Reply-To: <z2k618e24241005040340rf9e948a3m90c0661a67e57bf2@mail.gmail.com>
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>
Date: Tue, 04 May 2010 08:34:22 -0400
Message-ID: <s2y919c9f451005040534y62ae5780p7679cdd6acb221dd@mail.gmail.com>
From: Victor Fajardo <vf0213@gmail.com>
To: Victor Pascual Avila <victor.pascual.avila@gmail.com>
Content-Type: multipart/alternative; boundary="00163641747bd8ea1b0485c3ed5e"
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: Tue, 04 May 2010 12:35:05 -0000
Hi, I see. Then I would propose that in the current state of this spec, we can simply state a minimum (as stefan has mentioned) that a peer MUST be ready to handle un-ordered messages. Then someone can volunteer a more proper guideline for SCTP stream usage/assignment either in an errata or an another draft. regards, victor On Tue, May 4, 2010 at 6:40 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > IMO rfc4168 is pretty clear on the topic: > http://tools.ietf.org/html/rfc4168#section-5 > > -Victor > > On Tue, May 4, 2010 at 12:27 PM, Naveen Kottapalli > <naveen.sarma@gmail.com> wrote: > > IMHO we can specify the same as a caution note in the RFC like some of > the > > SIGTRAN protocols did. > > Yours, > > Naveen. > > > > > > On 4 May 2010 06:51, Stefan Winter <stefan.winter@restena.lu> wrote: > >> > >> Hi, > >> > >> > For me I think message ordering and/or delivery is an implementation > >> > issue (and hence SCTP stream assignments/usage as well). There are > >> > many ways to go about this (ordered global rx queues, per-session > >> > queues ... etc) and all of the depends on how you architecture your > >> > implementation. This is a good reason not to have it in a protocol > spec. > >> > > >> > >> I don't quite understand that. If you leave the decision of message > >> ordering to the implementation, you can easily run into one > >> implementation sending its transactions unordered or in different > >> streams, while the implementation on the other end expects them to come > >> in ordered and in the same stream. This will lead to poor/no > >> interoperability between the two implementations. I'd consider this > >> property to be part of the spec. At the very least, it should be spec'd > >> that the receiving end MUST be prepared to handle out-of-order or > >> cross-stream transactions. > >> > >> Greetings, > >> > >> Stefan Winter > >> > >> -- > >> Stefan WINTER > >> Ingenieur de Recherche > >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et > de > >> la Recherche > >> 6, rue Richard Coudenhove-Kalergi > >> L-1359 Luxembourg > >> > >> Tel: +352 424409 1 > >> Fax: +352 422473 > >> > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > -- > Victor Pascual Ávila > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Fajardo
- [Dime] RFC 3588 (Diameter Base Protocol) - Sectio… Victor Pascual Avila
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Pascual Avila
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Stefan Winter
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Naveen Kottapalli
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Pascual Avila
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Fajardo
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Fajardo
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Pascual Avila
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Sebastien Decugis
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Ralph Loader
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Sebastien Decugis
- Re: [Dime] RFC 3588 (Diameter Base Protocol) - Se… Victor Pascual Avila