Subject: [Sigtran] Issues with SCTP TSN and Cum TSN

From: Jacques Rajchgod <[email-masked]>
Date: Wed, 13 Feb 2002 13:08:11 -0600

Hi, SIGTRAN...

Am looking at a following scenario:

1) An MGC (a) INIT Chunk is sent.
2) The INIT contains an INIT_TSN=X.
        This is the TSN that a's first DATA pack to a SG (b) will contain.
3) The INIT is ACK'ed by a SG (b).
4) b's INIT_ACK contains an INIT_TSN=Y.
        This is the TSN that b's first DATA pack to "a", will contain.
5) An exchange of COOKIE + ACK, followed by a couple of HEARTBEATS, take
place OK.
6) "a" then sends an SCTP Pack where a SACK chunk is bundled with a DATA
chunk:
        The SACK has its TSN set to "X", per a's indication advertised in
a's INIT at "1".
        However, the SCTP pack is found to contain a Payload CUMULATIVE_TSN.
        The CUM_TSN is set to "Y-1" (b's INIT_TSN minus 1)

I'll try to describe the scenario graphically below:

1) a SENDS:                        ------------- INIT,
INITIAL_TSN=X ----------->
2) a RECEIVES from b:        <----------- INIT_ACK, INITIAL_TSN= Y ---------
6) a SENDS                        ------------- SACK, INITIAL_TSN=X for
SACK, ASP_UP (bundled), CUM_TSN=Y-1 for DATA -------->

There is a number of issues I see in this scenario:

1) A CUM_TSN is supposed to be sent only AFTER having received data - not
before.
    (Ref: RFC 2960, Section 1.4, Page 10/11, 5th bullet from the top of
parag. Section 1.4 has a potential conflict with Section 3.3.4 --> SACK must
contain a
        CUM_TSN_ACK).
    (Ref: Section 6.2, Page 69 - usage of acknowledgement)
2) Since there hadn't been any DATA exchanged yet at the point being
described in above scenario, there is no business having a CUM_TSN present
in the SCTP pack
for PAYLOAD.
3) Since there hasn't been any DATA exchanged yet, at the point being
described in above scenario, A CUM_TSN present should be ignored by the
receiver.

Please kindly comment (True/False, or otherwise)...
My appreciation,
Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Feb 2002 15:00:44 -0600

Jacques,

You might check on [email-masked] where more SCTP'ers hang
out, but, this is normal behaviour.

The receiver of a SACK with Cummulative Ack of Y-1 should
discard the SACK and do nothing further with it other than
updating a_rwnd because it preceeds the Initial TSN.  This
is how an implementation acks nothing yet updates a_rwnd.
I provided you with a quote from RFC 2960 that the
implementation is allowed to send SACK whenever it wishes
to update a_rwnd.  That includes before data is sent.  If
the receiver of the SACK is aborting the association, IMO
the problem is with the receiver.

--brian

Jacques Rajchgod wrote:                                   (Wed, 13 Feb 2002 13:08:11)
>    5) An exchange of COOKIE + ACK, followed by a couple of HEARTBEATS,
>    take place OK.
>    
>    6) "a" then sends an SCTP Pack where a SACK chunk is bundled with a
>    DATA chunk:
>    
>            The SACK has its TSN set to "X", per a's indication advertised
>    in a's INIT at "1".
>    
>    1) a SENDS:                        ------------- INIT, INITIAL_TSN=X
>    ----------->
>    
>    6) a SENDS                        ------------- SACK, INITIAL_TSN=X
>    for SACK, ASP_UP (bundled), CUM_TSN=Y-1 for DATA -------->
>    
>    
>    
>    1) A CUM_TSN is supposed to be sent only AFTER having received data -
>    not before.
>    
>        (Ref: RFC 2960, Section 1.4, Page 10/11, 5th bullet from the top
>    of parag. Section 1.4 has a potential conflict with Section 3.3.4 -->
>    SACK must contain a
>    
>            CUM_TSN_ACK).
>    
>    described in above scenario, there is no business having a CUM_TSN
>    present in the SCTP pack
>    
>    for PAYLOAD.
>    
>    described in above scenario, A CUM_TSN present should be ignored by
>    the receiver.
>    
>    
>    

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran