Subject: Re: [Dime] Message mis-sequencing over SCTP

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 1 Apr 2010 14:01:25 +0100

I feel it'll be good to add a caution note about this and the leave the rest
to the implementors.

This is because, even if we allocate the separately streams for diameter
base protocol messages and user messages, still the problem persits.  An
example is, if the CEA is sent on stream 0 and the rest of user messages on
other streams, the delivery of messages is not guaranteed by SCTP.

Yours,
Naveen.

On 1 April 2010 07:11, Nilanjan <[email-masked]> wrote:

> I think, this mis-sequencing can only happen CEA followed by new request
> using different stream-id in case of SCTP.
>
> 1) This is because CEA does not have any Confirmation defined in protocol,
> so peer does not have any knowledge of whether CEA is reached and accepted,
> before issuing a request. This may have implementation solution like
> forcing
> all initial REQ immediately after sending CEA to use same stream-id of CEA
> until any msg from peer received (any REQ/RES).
>
> I am thinking this mis-sequencing is limited to only very small scenario,
> since
>        a) Generally CER is sent by Diameter Client, who likes to send REQ
> to Diameter server, even though Diameter is Peer-to-peer protocol.
>        b) This is only when we need to send REQ immediately after sending
> CEA, and not giving enough time to reach CEA packet to peer (max time to
> live) or to see whether peer disconnects to Diameter connection (in case of
> CEA is not accepted)
>        c) Sending application request before starting watch-dog message
>
> So, this may be required to keep in protocol, and can be left to
> implementation.
>
> 2) In case of Diameter session application, some AVP defined like
> (CC-Request-Number in case of CCA), which can be used to reordering any
> messages using different stream-id in case of SCTP.
>
> Kind Regards,
> Nilanjan
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ralph Loader
> Sent: Thursday, April 01, 2010 9:21 AM
> To: Tom Taylor
> Cc: [email-masked]
> Subject: Re: [Dime] Message mis-sequencing over SCTP
>
> > Sounds like a good point. Seems to me the rules should be:
> >
> >   - use only stream 0 until the Diameter connection has been set up
> >   - all messages relating to the same session must use the same stream.
>
> Is the second suggested rule (same session must use the same stream)
> actually of any use?
>
> IIRC, in principal, messages on the same session may take different routes
> to their destination (where multiple Diameter proxies are available) and
> that makes enforcing ordering on a single hop irrelevant to the session?
>
> The Diameter application must either enforce ordering or cope with
> reordering, anyway?
>
> Cheers,
> Ralph.
>
> >
> > That should be added to section 2.1.1.
> >
> >
> > Naveen Kottapalli wrote:
> > > Hi,
> > >
> > > Am just wondering whether the mis-sequencing in the delivery of packets
> when
> > > SCTP is being used as transport layer would cause any problem.  For
> example,
> > > take an association with 5 out-streams to send out the Diameter
> messages.
> > > Immediately after sending CEA on stream 0, all other messages are sent
> over
> > > other streams like 1, 2, 3, and 4.
> > >
> > > There is a chance that the other Diameter messages will reach the peer
> > > before the CEA is processed?   Does the existing draft miss the
> sequencing
> > > problem over SCTP?
> > >
> > > Yours,
> > > Naveen.
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dime
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ralph Loader <[email-masked]>
Date: Fri, 2 Apr 2010 08:17:55 +1300

>   - use only stream 0 until the Diameter connection has been set up

How is the end-point that sends the CEA meant to know when the connection set-up is complete?

The connection set-up is complete when the other end-point processes the CEA, and the end-point sending the CEA doesn't know when that happens.

Ralph.

> > Am just wondering whether the mis-sequencing in the delivery of packets when
> > SCTP is being used as transport layer would cause any problem.  For example,
> > take an association with 5 out-streams to send out the Diameter messages.
> > Immediately after sending CEA on stream 0, all other messages are sent over
> > before the CEA is processed?   Does the existing draft miss the sequencing
> > problem over SCTP?
> > 
> > Yours,
> > Naveen.
> > 
> > 
> >

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 1 Apr 2010 21:41:46 +0100

As a request-response kind of protocol, there is no acknowledgement defined
for any answer message.  An answer message will be treated as a confirmation
to the request message.  And this is the implicit behavior of Diameter
protocol.

 The sender of CEA knows the result of capability negotiation before the CEA
is being processed by peer.  This enables the sender of CEA to move the peer
either to OPEN / CLOSED states, before the CEA is processed by peer.  So,
there is no provision left for the sender in delaying the message transfer
to a peer in OPEN state.

Yours,
Naveen.

On 1 April 2010 20:17, Ralph Loader <[email-masked]> wrote:

> The connection set-up is complete when the other end-point processes the
> CEA, and the end-point sending the CEA doesn't know when that happens.
>
> Ralph.
>
>