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

From: [email-masked]
Date: Thu, 14 Feb 2002 11:49:01 +0200

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 14 Feb 2002 09:49:07 -0600

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?

> 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

is the right example.

> that its sender wished to ACK (non-existing) data - an

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

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

> 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

---

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

Jacques,

If you look closely at section 6.2.1. "Processing a Received SACK",
there is no excuse for this unwarranted behavior.

--brian

Jacques Rajchgod wrote:                        (Thu, 14 Feb 2002 09:49:07)

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