Re: [Dime] Message mis-sequencing over SCTP

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.

Le 31/03/2010 22:51, Tom Taylor a écrit :
> 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:
>> 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
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

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