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

[Sebastien Decugis <[e-mail]>]

 Hello,

Sorry to jump in the discussion like this. I don't quite understand the
issue discussed. Messages pertaining to one session come as
Request/Answer sequence, there is no new request generated until the
previous answer was received -- at least in the Diameter applications I
know -- unless the ordering is not important such as in Accounting
application (which contains account record number). The ordering in
Diameter is provided at the application level, there is no need to be
more specific at the transport level.

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.

My two cents,
Sebastien.

Le 05/10/2010 06:05, Victor Pascual Avila a écrit :
> 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 <[e-mail]
> <mailto:[e-mail]>> 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
>     <[e-mail]
>     <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>> 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: [phone]
>         >> Fax: [phone]
>         >>
>         >>
>         >>
>         >> _______________________________________________
>         >> DiME mailing list
>         >> [e-mail] <mailto:[e-mail]>
>         >> https://www.ietf.org/mailman/listinfo/dime
>         >>
>         >
>         >
>         > _______________________________________________
>         > DiME mailing list
>         > [e-mail] <mailto:[e-mail]>
>         > https://www.ietf.org/mailman/listinfo/dime
>         >
>         >
>
>
>
>         --
>         Victor Pascual Ávila
>         _______________________________________________
>         DiME mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
>
> -- 
> Victor Pascual Ávila
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime

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