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

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

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

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

---

From: [email-masked]
Date: Thu, 14 Feb 2002 18:08:47 +0200

Hi again,

	First of all, I'll use tsvwg and not sigtran as SCTP is discussed in the tsvwg since quite long ago...

> -----Original Message-----
> From: ext Jacques Rajchgod [mailto:[email-masked]]
> Sent: 14. February 2002 17:49
> 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.

	Why? You have just stated which is your a_rwnd inside the INIT/INIT ACK and few time later you changed it?... In any case this does not really matter... Let's continue...

> At such time:
> 
> 1) The INIT sender "a" has just received an INIT_ACK from "b".

	Yes, in the normal case it received just one INIT ACK and the COOKIE ACK...

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

	:-/ Why? What has to do the receiving window of one peer with the other's one? I don't think you should adjust your rwnd once you know your peer's... why is the reason to do this? What am I missing?

> 3) "a" would send a SACK smack immediately to "b" to notify 
> "b" of its ("a")
> new a_rwnd size.

	Well... yes, if for some reason you have changed it, then it is nice to send a SACK to indicate it... But not compulsorily...

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

	I don't know that much about M3UA or how it can affect to SCTP's rwnd... But in any case, I wouldn't say that it would "frequently" happen. I would rather say that it would be a very rare event... Please, tell me why you would modify rwnd right after knowing the rwnd of your peer...

> 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 

	I didn't know this happened... ok then. Somewhere in RFC I think it says that should not shrink your receiver window, but let's say then that it would be a normal situation.

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

	Yes... 

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

	But, again, could you tell me what the Cum TSN ACK is doing wrong? I mean, what is the bad thing about receiving it?

> 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 

	A very bad implementation I would say... A "normal" one should have a variable such as "next TSN to send"... When the SACK is processed, you check if the received Cum TSN ACK is bigger, smaller or equal:

	- If it is smaller, you simply drop the SACK (it is an old one).
	- If it is equal, you check if there is any Gap ACK Block, and then you process them.
	- If it is bigger, the peer is acknowledging TSNs that you should erase from your memory and some other things.

	Also you use the a_rwnd to update your rwnd value...

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

	One of the two of us is not getting the point. You never tear down an association because a SACK does not acknowledge anything new... I don't see if there is any other problem... Excuse me but I fail to see the problem... The implementation behaviour you have described is wrong... That shouldn't happen...

	Thanks!

	BR Iván Arias Rodríguez

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