Subject: [Dime] Message mis-sequencing over SCTP

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 31 Mar 2010 14:36:56 +0100

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.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 31 Mar 2010 09:51:17 -0400

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.

That should be added to section 2.1.1.

Naveen Kottapalli wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 31 Mar 2010 21:08:40 +0100

I feel, we can handle the same way as SIGTRAN is handling.

Yours,
Naveen.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 01 Apr 2010 10:46:09 +0900

Hi,

Here is my implementer point of view on this issue:
 - this issue *does* occur, I saw several messages dropped because of
this in my tests. This is problematic because since the connection is
not dropped, there is no reason for the sender to re-issue the message.
 - I fixed the problem by forcing all messages on the responder side to
be sent on the same stream as the CEA, until a new message is received
from the initiator (so that we are sure the connection is in open state).

I am not sure if this is worth mentioning in the document, or if it is
considered as an implementation-specific solution. If there is an
agreement to add a small paragraph about it in 3588bis, I can volunteer
to write a text describing the issue and a solution...

Best regards,
Sebastien.

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

---

From: Ralph Loader <[email-masked]>
Date: Thu, 1 Apr 2010 16:50:42 +1300

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

---

From: "Nilanjan" <[email-masked]>
Date: Thu, 1 Apr 2010 11:41:26 +0530

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

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