Subject: Regarding Cumulative TSN Ack in the SACK after peer re-start

From: Padmalochan Moharana <[email-masked]>
Date: Mon, 23 May 2011 16:17:07 +0530

Hi ,

I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK
message after restart of the peer.

what should be the value of the "Cumulative TSN Ack" in SACK message for the
DATA message received before

peer re-started.

Please find the call flow for the scenario for more information.

Thanks,
Padmalochan

---

From: sandeep kandula <[email-masked]>
Date: Mon, 23 May 2011 18:47:05 +0530

Hi,

When peer restart happens and same identified at SCTP EndPoint B, all the
queued data will be deleted at SCTP EndPoint B. This is as good as tearing
down the association and re-establishing association again. So, SCTP
EndPoint B will not send any SACK for old data that received before peer
restart.

Thanks,

V Sandeep Kandula.

On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana <[email-masked]>wrote:

> what should be the value of the "Cumulative TSN Ack" in SACK message for
> the DATA message received before
>
> peer re-started.
>

-- 

*Regards,
V Sandeep Kandula.*

---

From: Padmalochan Moharana <[email-masked]>
Date: Mon, 23 May 2011 19:06:15 +0530

Thanks for the response.

On Mon, May 23, 2011 at 6:47 PM, sandeep kandula <[email-masked]
> wrote:

---

From: Padmalochan Moharana <[email-masked]>
Date: Mon, 23 May 2011 19:04:51 +0530

Hi Randy,

Thanks for the response. In this case ENDPOINT A send INIT after sending one
DATA with TSN 100 to peer. So should end point B send SACK for the received
message after sending INIT ACK to endpoint A. Or Endpoint should not send
any SACK for the DATA received before restart of endpoint A.

Thanks,
Padmalochan

On Mon, May 23, 2011 at 6:30 PM, Randy Stewart <[email-masked]> wrote:

> Padmalochan:
>
> I see the restart occur, but in your picture
> I see no data sent... Until data is sent after
> the restart you would not see a sack..
>
> A restart is like a new association. After all the
> other side most likely crashed and started back up again.
>
> So IF your restarted endpoint had sent:
>
> -----DATA:TSN=200----->
>
> Which it would have since thats the initial TSN it declared in its INIT
>
> You would get back
>
> <--------SACK:200
>
> But only after a data message had been sent.
>
> R
>
>
> On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote:
>
> > Hi ,
> >
> > I have a doubt regarding the value of the "Cumulative TSN Ack" in the
> SACK message after restart of the peer.
> >
> -----
> Randall Stewart
> [email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Mon, 23 May 2011 10:10:20 -0400

On May 23, 2011, at 9:34 AM, Padmalochan Moharana wrote:

> Hi Randy,
> 
> Thanks for the response. In this case ENDPOINT A send INIT after sending one DATA with TSN 100 to peer. So should end point B send SACK for the received message after sending INIT ACK to endpoint A. Or Endpoint should not send any SACK for the DATA received before restart of endpoint A.

When the new INIT is sent it is the same as a brand new association. Endpoint B
will NOT SACK about 100.. its the same as Endpoint B receiving an ABORT and then
a new INIT.

In fact it is very very difficult to get Endpoint B NOT to receive an ABORT.

In your scenario, what you would more likely see is

-----DATA(TSN=100)---------------->
<crash/restart>
  <---------SACK(TSN=100)---------
------ABORT(NO-TCB FLAG)---------->
------INIT---------------->

In past interop's the only way to get the restart to occur is to unplug
the endpoint that you restart so it won't get a Heartbeat or a SACK to
cause it to generate an ABORT..

R

> > I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer.
> >
> > what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before
> >
> > peer re-started.
> >

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Mon, 23 May 2011 09:00:40 -0400

Padmalochan:

-----DATA:TSN=200----->

You would get back

<--------SACK:200

R

-----
Randall Stewart
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 23 May 2011 20:12:14 +0200

> what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before 
When B processes the INIT, it does not change its state.
I can only assume that the SACK is sent, for example,
based on the SACK timeout or a window update. So cum_tsn
would be 100.

Please note that due to a vtag mismatch, endpoint A will
silently discard the SACK.

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 23 May 2011 20:16:37 +0200

> will NOT SACK about 100.. its the same as Endpoint B receiving an ABORT and then
If B receives an INIT, it will not change its state. The SACK might be sent, because
due to the reception of the DATA chunk (TSN 100) a T2 timer was started. So
the SACK would have cum_tsn = 100.
> In fact it is very very difficult to get Endpoint B NOT to receive an ABORT.
Really?
If A is restarting (using the same port number as before), it would receive
a SACK with incorrect v-tag, but there is an association. So it would be
silently discarded. Or am I missing something?
> ------INIT---------------->
Correct. But if the INIT was sent before the SACK was received, the SACK is
silently discarded.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Mon, 23 May 2011 15:44:55 -0400

> the SACK would have cum_tsn = 100.
Ahhh.. you are right here..

I was thinking of after the cookie... my bad ;-)

> silently discarded. Or am I missing something?

I was thinking of when we tried to get restart to occur in the 
interops.. we always had to pull the cable in order to get
a HB or some other fun not coming in and causing an abort..

> Correct. But if the INIT was sent before the SACK was received, the SACK is

Sure..

But the above scenario... actually more like:

<crash>
<-----Heartbeat()
----ABORT(no tcb)---->

Is what we commonly saw at interops .. sometimes planned (sometimes not :-D)

R

-----
Randall Stewart
[email-masked]

---

From: Wei Yongjun <[email-masked]>
Date: Wed, 25 May 2011 14:32:26 +0800

Hi,

> Hi,
>
>
> When peer restart happens and same identified at SCTP EndPoint B, all the queued data will be deleted at SCTP EndPoint B.
>

It also means we need to stop the SACK and T3-rtx timer when
peer restart? If T3-rtx not been deleted, no data will be sent
after the T3-rtx expire, but the cwnd will be set to PMTU.
And also the T4-rto timer running for asconf, and all queued
asconf check should be deleted?

RFC does not describe about the timers when peer restart.

> This is as good as tearing down the association and re-establishing association again. So, SCTP EndPoint B will not send any SACK for old data that received before peer restart.
>
>
> Thanks,
>
> V Sandeep Kandula.   
>
>
>
> On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi ,
>

---

From: Wei Yongjun <[email-masked]>
Date: Wed, 25 May 2011 14:38:09 +0800

> And also the T4-rto timer running for asconf, and all queued
-----------------------
> asconf check should be deleted?
sorry, 'asconf check'- I want to say 'asconf chunks'
-----------------------

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 25 May 2011 13:51:46 +0200

> RFC does not describe about the timers when peer restart.
It is basically taking an assoc down and up... So all timers have to be cleared.
All retransmission counters also, and so on...

Best regards
Michael