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

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 4 Oct 2010 17:05:36 -0400

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 <[email-masked]> 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 <
> [email-masked]> 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
>> <[email-masked]> 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 <[email-masked]> 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
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/dime
>> >>
>> >
>> >
>> > _______________________________________________
>> > DiME mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/dime
>> >
>> >
>>
>>
>>
>> --
>> Victor Pascual Ávila
>>  _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
>

-- 
Victor Pascual Ávila

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 05 Oct 2010 10:39:35 +0900

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 <[email-masked]
> <mailto:[email-masked]>> 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
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         >>
>         >> Hi,
>         >>
>         >> > implementation. This is a good reason not to have it in a
>         protocol spec.
>         >> >
>         >>
>         >> Fondation RESTENA - Réseau Téléinformatique de l'Education
>         Nationale et de
>         >> la Recherche
>         >> [email-masked] <mailto:[email-masked]>
>         > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

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

---

From: Ralph Loader <[email-masked]>
Date: Tue, 5 Oct 2010 19:46:58 +1300

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

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 05 Oct 2010 16:44:44 +0900

Hi,

> How is an end-point sending a CEA and then sending a request over separate SCTP streams meant to work-around this issue? 
Sorry if it was not clear, I meant it as "the only exception to
out-of-order delivery *not* being an issue".
So, what I was describing is an actual issue (in my opinion) with
multi-stream use.

It can be worked around in the implementation, for example by allowing
messages to be sent over a different stream only after a new message has
been received from the remote peer (confirming the remote peer moved the
connection to OPEN state), or after a reasonable delay (for example a
few seconds). If the first option is chosen, it can be a good practice
to always send a DWR after the CEA is received (as it is done after a
network failure recovery).

I hope this clarifies my point ^^.

Sebastien.

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 6 Oct 2010 12:10:25 -0400

Hi Ralph,

please see my response below.

On Tue, Oct 5, 2010 at 2:46 AM, Ralph Loader <[email-masked]> wrote:

> 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.]
>
In order to prevent head-of-the-line-blocking, one could either send
over multiple SCTP streams using ordered delivery (and map Diameter sessions
intro SCTP streams) or send over a single stream using unordered delivery
(this is actually how SIP over SCTP works).

-Victor