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

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

Last time I asked on the list, I got a detailed explanation that it was impossible.

Cheers,
Ralph.

> 
> 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 <vf0213@gmail.com
> > <mailto: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
> >     <mailto: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 <mailto: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
> >         <mailto: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 <mailto:DiME@ietf.org>
> >         >> https://www.ietf.org/mailman/listinfo/dime
> >         >>
> >         >
> >         >
> >         > _______________________________________________
> >         > DiME mailing list
> >         > DiME@ietf.org <mailto:DiME@ietf.org>
> >         > https://www.ietf.org/mailman/listinfo/dime
> >         >
> >         >
> >
> >
> >
> >         --
> >         Victor Pascual Ávila
> >         _______________________________________________
> >         DiME mailing list
> >         DiME@ietf.org <mailto: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
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

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