IETF Logo Mail Archive

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

Victor Fajardo <vf0213@gmail.com> Tue, 04 May 2010 12:25 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 3B1B03A6BBA for <dime@core3.amsl.com>; Tue, 4 May 2010 05:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.032
X-Spam-Level:
X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.566, 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 gbqgz6V7VyW2 for <dime@core3.amsl.com>; Tue, 4 May 2010 05:25:26 -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 0247F3A68E4 for <dime@ietf.org>; Tue, 4 May 2010 05:24:33 -0700 (PDT)
Received: by wwi18 with SMTP id 18so1073576wwi.31 for <dime@ietf.org>; Tue, 04 May 2010 05:24:15 -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:content-type; bh=mLmt47WG1Ii+Aig4tM236Uat5UIQNofUH4qN8GSmIh8=; b=qL/AavDZpMdUSPshxjy6XUpvChuLtRmzyILywyR52JpWrOnd/CVvqkK/2mq94gPGnt oRz4EqczlZslrBywRdfyVL395QL92eTn6qsLCslbEz/fZSUpDBesI0ni1Pr/EZrMa//R MlR1ysKjciUVdVeWLfxp5+R+gYH7Se3aVm69c=
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 :content-type; b=xtPJkSTd+xzxOWBwoEF3t/Aqru77WiL2fZzald8Aw4PKeze7hFTJ6ryyNUgrmy0/zK jSLAQCNWlNixLA+Vqskud+of0jgH9WunNc52yTURMjSXJ12O5NmdG0rajx0tzF0VaQE6 Unl9MFGx5xSNNHhPV1ofItOBF3hlibg2S2pi0=
MIME-Version: 1.0
Received: by 10.216.93.21 with SMTP id k21mr1647491wef.68.1272975855453; Tue, 04 May 2010 05:24:15 -0700 (PDT)
Received: by 10.216.187.195 with HTTP; Tue, 4 May 2010 05:24:15 -0700 (PDT)
In-Reply-To: <w2m919c9f451005040523r9ca76e40od33c773e6b0455fc@mail.gmail.com>
References: <s2v618e24241004260054z7f767689nfba37fbf82b1f030@mail.gmail.com> <v2x618e24241005030326x810b6d7fr977d506896c9802e@mail.gmail.com> <h2o919c9f451005031041h40693491y64995e345b93384f@mail.gmail.com> <4BDFB5CC.5080908@restena.lu> <w2m919c9f451005040523r9ca76e40od33c773e6b0455fc@mail.gmail.com>
Date: Tue, 04 May 2010 08:24:15 -0400
Message-ID: <z2v919c9f451005040524g63c022bi2e08c16298305950@mail.gmail.com>
From: Victor Fajardo <vf0213@gmail.com>
To: Stefan Winter <stefan.winter@restena.lu>, dime@ietf.org
Content-Type: multipart/alternative; boundary="0016e6d7e9a3ac07f60485c3c90c"
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:25:27 -0000

Hi Stefan,

I don't mind stating in the spec that a node MUST be prepared to handle
out-of-order messages. What I do mind is stating in the spec how it should
be done. I don't consider the 'how' part a property of the spec.

regards,
victor


On Tue, May 4, 2010 at 8:23 AM, Victor Fajardo <vf0213@gmail.com> wrote:

> Hi Stefan,
>
> I don't mind stating in the spec that a node MUST be prepared to handle
> out-of-order messages. What I do mind is stating in the spec how it should
> be done. I don't consider the 'how' part a property of the spec.
>
> regards,
> victor
>
>   On Tue, May 4, 2010 at 1:51 AM, 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
>>
>>
>

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