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

From: Tuexen Michael <[email-masked]>
Date: Thu, 14 Feb 2002 17:34:34 +0100

Dear Jacques,

the Cumulative_TSN_Ack is part of any SACK. I do not see
why this isn't good. And you must have a rule what to use
as an inital value because you must be able to handle the
case where the first packtet containing DATA chunks is
lost and the second arrives. You have to acknowledge them but
you must use the initial value as the cumulative_TSN_Ack.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Jacques Rajchgod [SMTP:[email-masked]]
> Sent:	Thursday, February 14, 2002 4:49 PM
> To:	[email-masked]
> Subject:	RE: [Sigtran] Issues with SCTP TSN and Cum TSN
> 
> 
> Per Brian's past mail on the matter (and Sec 6.2 of RFC 2960, 3rd parag),
> SACKs can be simply sent to adjust a_rwnd values dynamically. Thus, a SACK
> can be used for that control purpose, in addition to the purpose of ACK'ing
> received data. When there is no data to ACK, SACKs would be used to adjust
> the a_rwnd value dynamically.
> The time when that situation is likely to occur is - immediately at the
> conclusion of the INIT sequence, just before data might have begun to flow.
> At such time:
> 
> 1) The INIT sender "a" has just received an INIT_ACK from "b".
> 2) "a" has studied the returned values in the INIT_ACK from "b" and may
> decide to re-adjust its ("a") RX buffer size to adapt to b's just-advertised
> values.
> 3) "a" would send a SACK smack immediately to "b" to notify "b" of its ("a")
> new a_rwnd size.
> 
> That is why one may frequently see a SACK at the beginning smack after an
> INIT, even though no M3UA PAYLOAD has yet been exchanged.
> 
> In the scenario I was investigating, the MGC ("s") had INIT'ed with
> a_rwnd=32,768K. Then after having received the INIT_ACK from the SG ("b")
> and having studied "b's" advertised capabilities, "a" decided to re-adjust
> its a-rwnd and re-advertise it to "b". So it chose to do such by bundling a
> SACK with an ASP_UP Request (data payload) - a very efficent traffic usage
> (spares bandwidth). The SACK was now advertising 8K for a_rwnd on "a". Note
> that this is a dynamic way of re-adjusting window sizes.
> 
> The only issue I have with using SACKs as a_rwnd adjusters, is the CUM_TSN
> param present in them. It would have made great sense to dictate that when a
> SACK is used strictly as an a_rwnd adjuster, that no CUM_TSN be present in
> it as it serves no purpose at that moment. Some manufacturers hick-up on
> that:
> They see a CUM_TSN and start checking to see what data it is that the
> CUM_TSN is ACK'ing at the time. Since there has been no data sent yet, they
> get lost on that computation...Therefore, to prevent such UNWARRANTED (<---
> note the CAPS) causes for hangs, it would have meant good thinking to
> dictate that when a SACK is used strictly as an a_rwnd adjuster, that NO
> CUM_TSN be present at that specific time for that specific use.
> 
> Tks.
> 
> Jacques Rajchgod
> MCI Worldcom
> Next Generation System Evaluation
> Tel: [972] 729-7180
> E-mail: [email-masked]
> 
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 3:49 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] Issues with SCTP TSN and Cum TSN
> 
> 
> 	Hi again Jacques,
> 
> > CUM_TSN's are used to ACK DATA that has been exchanged.
> 
> 	Well... SACK are used to ack data exchanged... If there has not been data
> exchanged, why then sending any SACK at all? It is like if you don't have
> any data to send to your peer, so, why would you like to send a DATA chunk
> then?
> 
> 	I still continue not getting the point...
> 
> > 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.
> 
> 	So, don't use SACKs... :-)
> 
> > That's why the "Y-1" is wrong at that point.
> 
> 	Michael is right... But I guess that it was just a simply mistake when
> writing your example (as I did when reading it, I saw the X and Y-1 and I
> thought they were right)... As he said
> 
> > MGC->SG: INIT(Initial_TSN=X)
> > SG->MGC: INIT-ACK(Initial_TSN=Y)
> > MGC->SG: SACK(Cumualative_TSN_Ack=Y-1); DATA(TSN=X)
> 
> is the right example.
> 
> > 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...
> 
> 	Well... The SACK is not acknowledging anything, but it still has some other
> valuable information such as the a_rwnd. But as I have said, if you need a
> SACK at all, you are not pushed to send it at all... It is an option, not
> any mandatory thing...
> 
> > 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...
> 
> 	:-S
> 
> 	I don't know what you want... The SACK has its structure and it should be
> like that... If you don't need the SACK, don't send it...
> 
> > 3) That a SACK not ACKING DATA - be used with a
> > CUM_TSN=All-Zero, so to be
> > understood as "Not_Used".
> 
> 	What is the point of this? The field is there, so... If you tell me that
> your first DATA chunk will carry the TSN X, then it is right to include a
> Cumulative TSN ACK set to X-1 inside a SACK that (for some reason) you send
> to the "not yet data sender". If you do it so that you haven't send anything
> and the Cum TSN ACK is set to any other value than X-1, then there is a bug
> at the SACK sender...
> 
> 	In any case, could you explain me what is the problem about having a
> (right) Cum TSN ACK even if you don't use it?
> 
> 	Thanks!
> 
> 	BR Iván Arias Rodríguez
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 14 Feb 2002 12:13:13 -0600

OK. Here it is:

1) a SENDS to b:	 -------------- INIT ---------------->
2) a RECEIVES from b	<------------ INI_ACK ------------
3) a SENDS to b	-------------- COOKIE ---------->
4) a RECEIVES from b	<------------ COOKIE_ACK ------------
3) a SENDS to b	--------------SCTP pack:  SACK (CUM_TSN=x) bundled with
ASP_UP ---------->

- What's the "CUM_TSN=x" pointing to? Which DATA chunk is it ACK'ing
CUMULATIVELY??
- There hasn't been any DATA exchanged anywhere yet, to ack!
- A CUM_TSN is only used to ack CUMULATIVELY - DATA chunks. There are no
DATA chunks exchanged at INIT time. The DATA may come only after the INIT.
- The INIT consists only of CONTROL chunks.
- So, what is a Receiver of that CUM_TSN=x ("b") supposed to look for? "b"
hasn't sent any data to be ACK'ed cumulatively yet!
- Take a look at Section 1.4, page 11, the 5th bullet down - CUM_TSN...

Brian recommended yesterday that the recipient of such SACK ignore that SACK
and just update a_rwnd. Here is the statement:

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

Jacques Rajchgod
MCI Worldcom

-----Original Message-----
From: Tuexen Michael [mailto:[email-masked]]
Sent: Thursday, February 14, 2002 10:35 AM
To: 'Jacques Rajchgod'; [email-masked]; [email-masked]'
Subject: RE: [Sigtran] Issues with SCTP TSN and Cum TSN

Dear Jacques,

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 14 Feb 2002 19:25:56 +0100

Dear Jacques,
see my comments below.
Best regards
Michael

> - What's the "CUM_TSN=x" pointing to? Which DATA chunk is it ACK'ing
The value will be (Initial_TSN of the INIT_ACK chunk from b) - 1
> - There hasn't been any DATA exchanged anywhere yet, to ack!
It doesn't matter.
> DATA chunks exchanged at INIT time. The DATA may come only after the 
It is just the rule. b knows it and understands that nothing is 
acknowledged.
- The INIT consists only of CONTROL chunks.
It is a control chunk.
> hasn't sent any data to be ACK'ed cumulatively yet!
B is looking for  (Initial_TSN of the INIT_ACK chunk from b) - 1, he 
knows the rule.
> - Take a look at Section 1.4, page 11, the 5th bullet down - CUM_TSN...
In general that is true. But in case of the initialization it is NOT 
true.
That field is in each SACK chunk, so you have to put a value in it, so 
you
have to define an initialization value.
If you do not have anything to acknowledge you do not have to send a 
SACK. But
if the first packets containing DATA chunks are lost and you have to 
acknowledge
the first one you have to tell the peer that the first packets are lost. 
So you
will also use the initialization value for the Cumulative_TSN_Ack.
>> its a-rwnd and re-advertise it to "b". So it chose to do such by 
>> bundling
> a
>> param present in them. It would have made great sense to dictate that 
>> when
> a
[email-masked]

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 14 Feb 2002 13:48:10 -0600

Thanks, Michael...I'll run with that.

Still, some questions:

Your first mail on the topic contained the following comment:

"...If an SCTP endpoint wants to send a SACK chunk (from JR: i.e, after an
INIT) it must fill in the
Cumulative_TSN_Ack field. That value is initialized to the Initial_TSN of
the peer minus
one..."

Where does the "minus-1" come from?
Section "3.3.4" (SACK) 3rd parag states "Less-than or equal..."

Please kindky advise...

Jacques Rajchgod
MCI Worldcom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Michael Tuexen
Sent: Thursday, February 14, 2002 12:26 PM
To: Jacques Rajchgod
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] Issues with SCTP TSN and Cum TSN

Dear Jacques,
see my comments below.
Best regards
Michael

It doesn't matter.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Feb 2002 14:15:45 -0600

Jacques,

Section 3.3.4:

   The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver
   Window Credit (a_rwnd) parameters.

   By definition, the value of the Cumulative TSN Ack parameter is the
   last TSN received before a break in the sequence of received TSNs
   occurs; the next TSN value following this one has not yet been
   received at the endpoint sending the SACK.  This parameter therefore
   acknowledges receipt of all TSNs less than or equal to its value.

That's where the minus-1 comes from.  The value of the Cummulative
TSN in the SACK is the next expected TSN minus one.

--brian

Jacques Rajchgod wrote:                                   (Thu, 14 Feb 2002 13:48:10)

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

---

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

Dear Jacques,
see my comments below.
Best regards
Michael

> Thanks, Michael...I'll run with that.
That's fine.
> Section "3.3.4" (SACK) 3rd parag states "Less-than or equal..."
12.2. says

    Last Rcvd   : This is the last TSN received in sequence.  This value
    TSN         : is set initially by taking the peer's Initial TSN,
                : received in the INIT or INIT ACK chunk, and
                : subtracting one from it.

and the but-last paragraph of section 5.1 says

    When the TCB is created, each endpoint MUST set its internal
    Cumulative TSN Ack Point to the value of its transmitted Initial TSN
    minus one.

This value will be used to fill the field Cumulative_TSN_Ack in SACK 
chunks.

This is 'indicated' by the text in 3.3.4 (which doesn't describe the 
initialization)

It is not as clear as it could be but that is the way it is written in 
RFC 2960.

---

From: Randall Stewart <[email-masked]>
Date: Sat, 16 Feb 2002 09:31:10 -0600

Jacques:

Right before section 5.1.1 on Page 54 (in RFC2960) we read:

"
"

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)