Re: [Lksctp-developers] SCTP_UNORDERED vs. multiple output streams

[Michael T. <Mic...@lu...>]

On Jun 18, 2013, at 9:15 PM, Neil Horman wrote:

> On Tue, Jun 18, 2013 at 08:46:41PM +0200, Michael Tuexen wrote:
>> On Jun 18, 2013, at 7:54 PM, Neil Horman wrote:
>> 
>>> On Tue, Jun 18, 2013 at 10:14:51AM +0200, Adam Endrodi wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> 
>>>> Earlier I had this question:
>>>> 
>>>> On Fri, Mar 22, 2013 at 09:39:27AM -0400, ext Neil Horman wrote:
>>>>> On Tue, Mar 19, 2013 at 10:42:40AM +0100, Adam Endrodi wrote:
>>>>>> 
>>>>>> I'm working on a DIAMETER (RFC 6733) application which will communicate
>>>>>> over SCTP.  The protocol's standard makes explicit recommendation about
>>>>>> its use in this environment:
>>>>>> 
>>>>>> # 2.1.1.  SCTP Guidelines
>>>>>> # 
>>>>>> #    Diameter messages SHOULD be mapped into SCTP streams in a way that
>>>>>> #    avoids head-of-the-line (HOL) blocking.  Among different ways of
>>>>>> #    performing the mapping that fulfill this requirement it is
>>>>>> #    RECOMMENDED that a Diameter node send every Diameter message (request
>>>>>> #    or response) over stream zero with the unordered flag set.  However,
>>>>>> #    Diameter nodes MAY select and implement other design alternatives for
>>>>>> #    avoiding HOL blocking such as using multiple streams with the
>>>>>> #    unordered flag cleared (as originally instructed in RFC 3588).
>>>> 
>>>> And the answer was:
>>>> 
>>>>>> Specifically I would like to ask:
>>>>>> -- What are the performance benefits on the sending side of using
>>>>>>    out of order message delivery?  Are they really delivered out
>>>>>>    of order in the Linux implementation?
>>>>> On the send side there are no direct benefits.  There are however indirect
>>>>> benefits in that unordered delivery increases the likelyhood that the the
>>>>> receiver will not have its recieve window reduced as a result of blocked
>>>>> reordering caused by a lost or out of order chunk.  Typically a linux host
>>>>> will not send data in a given stream out of order, but other features (such
>>>>> as multihoming) may cause chunks to arrive at a host in a different order
>>>>> than they were sent.
>>>> 
>>>> Now my question is whether in this context, is there any difference between
>>>> sending messages regardless of ordering vs. sending them out on multiple
>>>> streams, changing them in a round-robin fashion, does it give the same
>>>> benefits and does it have the same drawbacks?
>>>> 
>>> Yes, there are definately differences.  That said, I don't know enough about
>>> DIAMETER to guide you in one direction or the other regarding the use of
>>> multiple streams vs. complete out of order delivery.  The best information I can
>>> give you is that, if, from a given single application instance, if its data is
>>> required to be ordered (or even reassembed in order at the peer end), using
>>> streams would be preferable, as the ordering would be handled within the
>>> protocol.  If all DIAMETER messages are self contained, and there is no chance
>>> of fragmentation of a given diameter message, then unordered delivery seems like
>>> it should work just as well.
>>> 
>>> Reading a bit about DIAMETER, it seems that its protocol definition lends itself
>>> to messages that may exceed the maximum mtu of some network paths.  As such, I
>>> would recommend ordered delivery using streams.
>> Not sure why you are considering the relation between ordered/unordered messages
>> and SCTP level fragmentation. SCTP supports unordered messages which require
>> SCTP level fragmentation...
>> 
> Sorry, yes, confusing my terms.  Of course you can reassemble unordered
> fragmented sctp messages.  That said, theres still the possibilty of multiple
> messages that might need ordering to contend with.  I'm not sure if diameter has
> any possibilty of doing that, but if it does multiple ordered streams seems like
> the way to go.
I think
http://tools.ietf.org/html/rfc6733#section-2.1.1
describes pretty well the protocol constraints.

Best regards
Michael
> Neil
> 
>> Best regards
>> Michael
>>> 
>>> Neil
>>> 
>>>> Thanks,
>>>> adam
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Windows:
>>>> 
>>>> Build for Windows Store.
>>>> 
>>>> http://p.sf.net/sfu/windows-dev2dev
>>>> _______________________________________________
>>>> Lksctp-developers mailing list
>>>> Lks...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>> 
>>> Build for Windows Store.
>>> 
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Lksctp-developers mailing list
>>> Lks...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>> 
>> 
>> 
>