Re: [Dime] RFC 3588 (Diameter Base Protocol)

Hi Victor,

quick question: SCTP provides the "unordered delivery" feature, which means
that the receiving side may receive unordered Diameter messages. Does
Diameter provide any AVP indicating a sequence number or such that would
enable message re-ordering?

Many thanks in advance,
-Victor

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

> 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
>>
>
>

-- 
Victor Pascual Ávila

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