Subject: [tsvwg] Doubt regarding SCTP TSN/SSN

From: Nagesh <[email-masked]>
Date: Wed, 02 Sep 2009 10:30:59 +0530

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!

---

From: Randy Stewart <[email-masked]>
Date: Wed, 2 Sep 2009 03:24:47 -0400

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:

> (Peer  
> Node 
> )                                                                                                       (Local 
>  Node)
> ß 
> ---------------------------------------------------------------------------------------------à
>                                           DATA1
>                    
> -------------------------------------------------------------------------------------------------à
> -------------------------------------------------------------------------------------------------à
> -------------------------------------------------------------------------------------------------à
> -------------------------------------------------------------------------------------------------à
> -------------------------------------------------------------------------------------------------à
>             What should be the behavior when we receive DATA4 and  
> DATA5 since the SSN is in sequence but the TSN is out-of-order?
>
> ***************************************************************************************************************************
>            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
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 2 Sep 2009 09:42:29 +0200

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:

> 4) Never try this with fragmented messages. If you do not order  
> TSN's in sequence in a
>> 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

---

From: Nagesh <[email-masked]>
Date: Wed, 02 Sep 2009 13:51:40 +0530

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.

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: Wednesday, September 02, 2009 1:12 PM
To: Randy Stewart
Cc: Nagesh; [email-masked]
Subject: Re: [tsvwg] Doubt regarding SCTP TSN/SSN

Hi Randy,

Best regards
Michael

SCTP
>> )
(Local 
-----------------à
---------------------à
---------------------à
---------------------à
---------------------à
---------------------à

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 02 Sep 2009 19:12:48 +0900 (JST)

IMO. Should abort assciation. 
I guess the B/E bits of DATA5 is 00 or 01, but there is no gap in TSN.
this should not happen.

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: Nagesh <[email-masked]>
Subject: Re: [tsvwg] Doubt regarding SCTP TSN/SSN
Date: Wed, 02 Sep 2009 13:51:40 +0530
Message-ID: <[email-masked]>

---

From: Randy Stewart <[email-masked]>
Date: Wed, 2 Sep 2009 06:33:35 -0400

Michael:

Ahh I missed that... shows me I am not
to get up at 3:30am and reply to email.

Nagesh:

I stand corrected... note that my response
would be valid if Data4 was TSN3 and Data5 was TSN4

R

On Sep 2, 2009, at 3:42 AM, Michael Tüxen wrote:

>> 2) Since you are getting a gap-ack block, you will NOT be allowed  
>> to grow
>> 3) If you bundle these TSN's together (i.e. they are smaller than  
>> an MTU). They MUST
>> It would be far better for an implementation NOT to do this.. but  
>> it is allowable (within
>> the caveats above)....
>>
>>
>> R
>>
>>

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Wed, 2 Sep 2009 06:34:36 -0400

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:

> information from

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Wed, 2 Sep 2009 06:35:41 -0400

Nishida-san:

Yes if we don't have both B and E bit.. an abort
would surely be generated ;-)

R

-----
Randall Stewart
[email-masked]

---

From: Nagesh <[email-masked]>
Date: Wed, 02 Sep 2009 16:22:38 +0530

Hi Randy,

      Please find the complete scenario. 

    SCTP                  			                       SCTP
(Peer Node)                                                  (Local Node)

            Association is established with Local Init TSN = 0
     --------------------------------------------------------------

                                          DATA1
     ------------------------------------------------------------->     
         U=0  B=1  E=1  TSN(0)   SSN(0)   StreamId = 0

                                          DATA2
     ------------------------------------------------------------->
         U=0 B=1 E=1    TSN(2)     SSN(1)   StreamId = 0

                                          DATA3
     -------------------------------------------------------------->
         U=0 B=1 E=1    TSN(1)     SSN(2)   StreamId = 0

                                          DATA4
     --------------------------------------------------------------->    
         U=0 B=1 E=1    TSN(2)     SSN(3)   StreamId = 0

                                          DATA5
     ---------------------------------------------------------------->
         U=0 B=1 E=1    TSN(3)     SSN(3)   StreamId = 0

Scenario 1: When receive DATA4 after DATA1, DATA2 and DATA3, (Here DATA4 is
having duplicate TSN).       

Scenario 2: When receive DATA5 after DATA1, DATA2 and DATA3 (*NO* DATA4).
Here after receive DATA5, TSN is in order but SSN is out-of-order.

Thanks and Regards,
Nagesh.

-----Original Message-----
From: Randy Stewart [mailto:[email-masked]] 
Sent: Wednesday, September 02, 2009 4:11 PM
To: Nagesh
Subject: Re: [tsvwg] Doubt regarding SCTP TSN/SSN

Nagesh:

Can you draw out more fully your last reply to Michael.

Also please include state of B/E bits...

I have my morning coffee and I would like to know
fully what you meant ;-)

R

---

From: Randy Stewart <[email-masked]>
Date: Wed, 2 Sep 2009 08:02:59 -0400

On Sep 2, 2009, at 6:52 AM, Nagesh wrote:

> (Peer Node)                                                  (Local  

Well this would be a duplicate TSN. As Michael pointed
out this would not be legal. Most implementations would
drop the TSN and send back a SACK telling you they already
received the packet. Some, as Michael pointed out, would recognize
the different stream sequence and send you an abort.

The FreeBSD implementation would not send an abort but
it would send a Duplicate SACK indication discarding Data4. Data 5
would be accepted and processed....

> Here after receive DATA5, TSN is in order but SSN is out-of-order.

So In this scenario there is NO DATA4... which means all
TSN's are present only once and they all have B/E bit set.

My earlier comments would apply here. This is not illegal has
long as you obey the caveats I mentioned in my first email... However
there will be some implementations that send you an ABORT.

The FreeBSD implementation would accept this without objection. You
would get an extra sack out of the lot though..

R

-----
Randall Stewart
[email-masked]

---

From: Nagesh <[email-masked]>
Date: Wed, 02 Sep 2009 18:41:32 +0530

Hi Stewart,
	Thanks a lot for your detailed reply. Your answer clarifies all my
doubt.

Thanks again,

Regards,
Nagesh.

-----Original Message-----
From: Randy Stewart [mailto:[email-masked]] 
Sent: Wednesday, September 02, 2009 5:33 PM
To: Nagesh
Cc: [email-masked]
Subject: Re: [tsvwg] Doubt regarding SCTP TSN/SSN

R

-----
Randall Stewart
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 03 Sep 2009 03:41:38 +0900 (JST)

this is just curiosity...
In my understanding, if U = 0 and not fragmented, DATA4 and DATA5 
cannot have the same SSN. How does this happen? 

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: Nagesh <[email-masked]>
Subject: Re: [tsvwg] Doubt regarding SCTP TSN/SSN
Date: Wed, 02 Sep 2009 18:41:32 +0530
Message-ID: <[email-masked]>

---

From: Randy Stewart <[email-masked]>
Date: Wed, 2 Sep 2009 18:08:06 -0400

> cannot have the same SSN. How does this happen?

It would only happen with a errant sender. Something
software wise would have to corrupt in the sender.

In such cases a receiver MIGHT ignore it.. or it MIGHT
send an ABORT.. an implementation decision

R

-----
Randall Stewart
[email-masked]