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

From: [email-masked]
Date: Wed, 13 Feb 2002 21:27:01 +0200

Hi Jacques!
 
Let's see...

-----Original Message-----
From: ext Jacques Rajchgod [mailto:[email-masked]]
Sent: 13. February 2002 21:08
To: Sigtran
Subject: [Sigtran] Issues with SCTP TSN and Cum TSN

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.

[Arias-Rodriguez Ivan (NRC/Helsinki)] If you haven't received data yet, why sending a SACK chunk at all? I don't get the point...
 
     (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).
[Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, a SACK MUST contain a Cum TSN ACK... But, there isn't any place were it says something like "a datagram MUST have a SACK" :-)
 
If you don't need to send the SACK, then you don't do it...
 
    (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.
[Arias-Rodriguez Ivan (NRC/Helsinki)] You are completely rigth. Don't bundle any SACK chunk then...
 
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.
 
[Arias-Rodriguez Ivan (NRC/Helsinki)] In this case the receiver would surely check that the Cum TSN ACk does not acknowledge anything, and would drop the packet...
 
Maybe the problem is that you think that you should always include a SACK, but that's not true. In TCP you always send the acknowledgement number, but in SCTP this is not the case...
 
Bye!
 
BR Iván Arias Rodríguez
 
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] 

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

---

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

SIGTRAN had advised last week that a SACK may be sent at any time, due to
its multiple purposes. I am CUT-PASTING brian's view on this matter, from
last week:
----------------------------------------------------------------------------
----------------------------------------------
"... RFC 2960 provides for the bundling of SACK in _any_ message where DATA
exists.  SACK may be sent _at_any_time_ that DATA may be sent, because a
peer is always allowed to send SACK to update rwnd.  A number of
implementations at the last interop sent SACK initially with the first DATA
chunk.  Our implementation even sent SACK bundled with DATA in the COOKIE
ACK (which is also legal)."
----------------------------------------------------------------------------
----------------------------------------------

Jacques Rajchgod

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 1:27 PM
To: [email-masked]; [email-masked]
Subject: RE: [Sigtran] Issues with SCTP TSN and Cum TSN

Hi Jacques!

Let's see...

-----Original Message-----
From: ext Jacques Rajchgod [mailto:[email-masked]]
Sent: 13. February 2002 21:08
To: Sigtran
Subject: [Sigtran] Issues with SCTP TSN and Cum TSN

Hi, SIGTRAN...

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)

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 -------->

1) A CUM_TSN is supposed to be sent only AFTER having received data - not
before.

[Arias-Rodriguez Ivan (NRC/Helsinki)] If you haven't received data yet, why
sending a SACK chunk at all? I don't get the point...

     (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).
[Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, a SACK MUST contain a Cum TSN
ACK... But, there isn't any place were it says something like "a datagram
MUST have a SACK" :-)

    (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.
[Arias-Rodriguez Ivan (NRC/Helsinki)] You are completely rigth. Don't bundle
any SACK chunk then...

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.

[Arias-Rodriguez Ivan (NRC/Helsinki)] In this case the receiver would surely
check that the Cum TSN ACk does not acknowledge anything, and would drop the
packet...

Maybe the problem is that you think that you should always include a SACK,
but that's not true. In TCP you always send the acknowledgement number, but
in SCTP this is not the case...

Bye!

BR Iván Arias Rodríguez

Jacques Rajchgod
MCI Worldcom

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 14 Feb 2002 00:08:24 +0100

Dear all,

the message flow shows:

MGC->SG: INIT(Initial_TSN=X)
SG->MGC: INIT-ACK(Initial_TSN=Y)
MGC->SG: SACK(Cumualative_TSN_Ack=X); DATA(TSN=Y-1)

The third line describes the first DATA Chunk send using the association.

In my understanding this is wrong. The Initial_TSN in the INIT or 
INIT-ACK chunk
is the first TSN used in a DATA chunk by the SENDER of the INIT or 
INIT-ACK chunk.
So the DATA chunk in the third line must have TSN=X.
If an SCTP endpoint wants to send a SACK chunk it must fill in the 
Cumulative_TSN_Ack
field. That value is initialized to the Initial_TSN of the peer minus 
one. So
the SACK chunk in line three should contain Cumualative_TSN_Ack=Y-1.

The correct message flow would be:

MGC->SG: INIT(Initial_TSN=X)
SG->MGC: INIT-ACK(Initial_TSN=Y)
MGC->SG: SACK(Cumualative_TSN_Ack=Y-1); DATA(TSN=X)

The SCTP implementation of the MGC is free to bundle the SACK chunk or 
not.

Best regards
Michael

On Wednesday, February 13, 2002, at 08:27 PM, Ivan.Arias-
[email-masked] wrote:

> [Arias-Rodriguez Ivan (NRC/Helsinki)] If you haven't received data yet, 
> why sending a SACK chunk at all? I don't get the point...
>
>      (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).
> [Arias-Rodriguez Ivan (NRC/Helsinki)] Yes, a SACK MUST contain a Cum 
> TSN ACK... But, there isn't any place were it says something like "a 
> datagram MUST have a SACK" :-)
>
> described in above scenario, there is no business having a CUM_TSN 
> present in the SCTP pack
> for PAYLOAD.
> [Arias-Rodriguez Ivan (NRC/Helsinki)] In this case the receiver would 
> surely check that the Cum TSN ACk does not acknowledge anything, and 
> would drop the packet...
>
> Maybe the problem is that you think that you should always include a 
> SACK, but that's not true. In TCP you always send the acknowledgement 
> number, but in SCTP this is not the case...
>
> Bye!
>
> BR Iván Arias Rodríguez
>
[email-masked]

---

From: Jacques Rajchgod <[email-masked]>
Date: Wed, 13 Feb 2002 17:33:28 -0600

CUM_TSN's are used to ACK DATA that has been exchanged.
At Y-1, there hasn't been any data exchanged by anyone yet - neither the MGC
nor the SG.

INIT, INIT_ACK's, COOKIEs, COOKIE_ACKs - are NOT DATA...These are CONTROL
messages. Only DATA payloads may use SACK's - not Control messages.
That's why the "Y-1" is wrong at that point.

Personally, though, I would have preferred to have seen any of the three
following options being implemented at the IETF for subject scenario:

1) That the (Y-1) is somehow SCTP-rejected since its existence indicates
that its sender wished to ACK (non-existing) data - an illogical action...
2) That a SACK not ACKING DATA - do not use a CUM_TSN at all...since the
CUM_TSN is not designed for non-data usage...
3) That a SACK not ACKING DATA - be used with a CUM_TSN=All-Zero, so to be
understood as "Not_Used".

Jacques Rajchgod
MCI Worldcom

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]]
Sent: Wednesday, February 13, 2002 5:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] Issues with SCTP TSN and Cum TSN

Dear all,

the message flow shows:

Best regards
Michael