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

[Victor Fajardo <[e-mail]>]

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.

regards,
victor




On Mon, May 3, 2010 at 6:26 AM, Victor Pascual Avila <
[e-mail]> wrote:

> Any opinions? Is the below worth to be clarified in 3588bis?
>
> Thanks,
> -Victor
>
> On Mon, Apr 26, 2010 at 9:54 AM, Victor Pascual Avila
> <[e-mail]> wrote:
> > Hi,
> >
> > Apologies in case this is not the appropriate list for the question
> > below-- I'd appreciate pointers to any other list.
> >
> > RFC 3588 - Section  2.1.1 (SCTP Guidelines) states the following: "To
> > prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams
> > available to the association to prevent head-of-the-line blocking."
> > While RFC 3539 - Section 3.8.1 (Using SCTP Streams to Prevent Head of
> > Line Blocking) also addresses multi-streaming, it's not clear to me
> > whether:
> >
> > a) Diameter transactions need to be mapped into SCTP streams (ie; send
> > Diameter messages belonging to the same transaction over the same SCTP
> > stream and messages belonging to different transactions over different
> > SCTP streams-- as long as there are enough available streams)
> > b) Ordered vs unordered delivery: for the above mechanism, I
> > understand TLS would require ordered delivery. When TLS is not used
> > (say, IPSec is used instead), do we really need ordered delivery?
> >
> > Thanks in advance for any clarification,
> > --
> > Victor Pascual Ávila
> >
>
>
>
> --
> Victor Pascual Ávila
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>