Re: Doubt regarding SCTP TSN/SSN
Randy Stewart <randall <at> lakerest.net>
2009-09-02 10:34:36 GMT
Nagesh:
Can you redraw this picture exactly has
you meant it to be... By the time
you send it I will have had my morning coffee 
R
On Sep 2, 2009, at 4:21 AM, Nagesh wrote:
> Hi Michael,
> Thanks for the reply, assuming that there is no DATA4 but receive
> DATA5 after DATA3, then what should be the behavior?
>
> Thanks and Regards,
> Nagesh.
>
> ****************************************************************************
> ***********************************************
> This e-mail and attachments contain confidential
> information from
> HUAWEI, which is intended only for the person or entity whose
> address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure,
> reproduction,
> or dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the
> sender by
> phone or email immediately and delete it!
>
>
> -----Original Message-----
> From: Michael Tüxen [mailto:Michael.Tuexen <at> lurchi.franken.de]
> Sent: Wednesday, September 02, 2009 1:12 PM
> To: Randy Stewart
> Cc: Nagesh; tsvwg <at> ietf.org
> Subject: Re: [tsvwg] Doubt regarding SCTP TSN/SSN
>
> Hi Randy,
>
> I think DATA4 will be discarded by the receiver because
> DATA2 uses the same TSN(2). It will be lost! Nothing
> I find acceptable for implementing reliable transfer.
> And I would like to stress one point: There are implementations
> which would abort this association since the sender is
> assigning the TSN in a way which is not intended by
> the RFC... And as the example shows, results in message
> loss.
>
> Best regards
> Michael
>
> On Sep 2, 2009, at 9:24 AM, Randy Stewart wrote:
>
>> Nagesh:
>>
>> Assuming that all of the fragments have both
>> the B and E bits in place (i.e. they are NOT fragmented), it
>> should be accepted....
>>
>> Note that this is highly unusual to assign TSN's NOT in order and
>> there are a couple of consequences of this behavior you must be
>> willing to handle:
>>
>> 1) When TSN's are sent out of order, they will cause a SACK with GAP
>> ACK Block to be sent without delay. In your example that would
>> not have been any different. But if you had reversed TSN 2/3
>> (instead
>> of 1/2) then an extra SACK would be sent. This will cause a bit of
>> extra network traffic (extra sack's).
>>
>> 2) Since you are getting a gap-ack block, you will NOT be allowed to
>> grow
>> your cwnd by an MTU when the TSN arrives for 0+2. You can only do
>> so when the cumulative TSN is moved, which it would not be. This
>> done on a regular basis would slow your sender down quite
>> considerable.
>>
>> 3) If you bundle these TSN's together (i.e. they are smaller than an
>> MTU). They MUST
>> be kept in TSN order... In other words you will need to bundle
>> them in the packet
>> as follows:
>> -------------------------
>> IP Header
>> -------------------------
>> SCTP common header
>> -------------------------
>> TSN=0 SSN=0 SID=0
>> -------------------------
>> TSN=1 SSN=2 SID=0
>> -------------------------
>> TSN=2 SSN=1 SID=0
>> -------------------------
>> This may be a bit strange in your software and will cause a bit of
>> churn during processing
>> by the receiving peer.. but as long as you are capable of the
>> above it is ok.
>>
>> 4) Never try this with fragmented messages. If you do not order
>> TSN's in sequence in a
>> fragmented message the peer most likely will send you an abort.
>> Since such
>> behavior is NOT allowed.
>>
>>
>> All of the above being said, some peers may abort this behavior
>> anyway. Since
>> some peers are rather picky about TSN ordering. They should not
>> abort the association from a "whats legal perspective"... but you
>> never know..
>> It would be far better for an implementation NOT to do this.. but it
>> is allowable (within
>> the caveats above)....
>>
>>
>> R
>>
>>
>> On Sep 2, 2009, at 1:00 AM, Nagesh wrote:
>>
>>> Hi Group,
>>> I have a following doubt regarding SCTP TSN/SSN Handling.
>>>
>>>
>>> SCTP
>>>
> SCTP
>>> (Peer
>>> Node
>>> )
> (Local
>>> Node)
>>> Association is established with Local Init TSN
>>> = 0
>>>
>>> ß
>>>
> ----------------------------------------------------------------------------
> -----------------à
>>> DATA1
>>>
>>>
> ----------------------------------------------------------------------------
> ---------------------à
>>> TSN(0) SSN(0) StreamId = 0
>>>
>>> DATA2
>>>
>>>
> ----------------------------------------------------------------------------
> ---------------------à
>>> TSN(2) SSN(1) StreamId = 0
>>>
>>> DATA3
>>>
>>>
> ----------------------------------------------------------------------------
> ---------------------à
>>> TSN(1) SSN(2) StreamId = 0
>>>
>>> DATA4
>>>
>>>
> ----------------------------------------------------------------------------
> ---------------------à
>>> TSN(2) SSN(3) StreamId = 0
>>>
>>> DATA5
>>>
>>>
> ----------------------------------------------------------------------------
> ---------------------à
>>> TSN(3) SSN(3) StreamId = 0
>>>
>>> What should be the behavior when we receive DATA4 and
>>> DATA5 since the SSN is in sequence but the TSN is out-of-order?
>>>
>>> Request you to please clarify my doubt.
>>>
>>> Thanks and Regards,
>>> Nagesh.
>>>
>>>
>>>
> ****************************************************************************
> ***********************************************
>>> This e-mail and attachments contain confidential
>>> information from HUAWEI, which is intended only for the person or
>>> entity whose address is listed above. Any use of the information
>>> contained herein in any way (including, but not limited to, total
>>> or partial disclosure, reproduction, or dissemination) by persons
>>> other than the intended recipient's) is prohibited. If you receive
>>> this e-mail in error, please notify the sender by phone or email
>>> immediately and delete it!
>>>
>>
>> -----
>> Randall Stewart
>> randall <at> lakerest.net
>>
>>
>>
>>
>>
>
-----
Randall Stewart
randall <at> lakerest.net
RSS Feed