Subject: [Tsvwg] Re: PR-SCTP question.

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 May 2003 12:34:24 -0600

Randall,

If the FWD-TSN is treated in the same fashion as DATA is in the
base protocol with regard to the sending of SACK, in this case a
SACK would already be required by the base protocol would it
not?  So I don't think that there is a need for an alteration in
SACK processing.  IHO the problem appears to be (as you allude)
that for a normal DATA transmission there is a retransmit timer
running whereas for FWD-TSN there is not.  During normal data
transmission during the association, this is not problematic
because of the rules for sending subsequent FWD-TSN in receipt
of SACK.  It is only in this case where there is no further data
to send.

As this only appears to be a problem in this one situation (not
subsequent DATA to send and no SACKs forthcoming), it might be
possible to handle this with a SHUTDOWN rule such as follows:

Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state,
and there are only TSNs marked dropped for retransmission (for
which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the
sender enters the SHUTDOWN-SENT state.  (The same for
SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.)

Whenever the PR-SCTP receiver receives a SHUTDOWN or
SHUTDOWN-ACK and there are gaps in its received TSN sequence
(messages awaiting reordering before delivery to the user), it
will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward
TSN for all missing data chunks.

The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK)
chunk being sent waiting for acknowledgement of dropped TSNs
but to send it anyways with the knowledge that the receiver can
imply any missing TSNs as having been dropped.

I think this would better meet the intent of PR-SCTP (and in
particular timed-reliability) as it does not rely on a timer to
arrive at the implication of a missed FWD-TSN.  The receipt of a
SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN
for all outstanding data.

Under the base protocol, what happens if a sender sends a
SHUTDOWN chunk *before* all its sent data is acknowledged?  I
think an implementation could either complete the shutdown and
discard data awaiting reordering, or ABORT the association.  For
PR-SCTP, receiving SHUTDOWN early could be construed as cause to
mark as dropped all outstanding data, and move the cummulative
ack point to the "highest" received TSN and complete the
SHUTDOWN procedure.

Does that make sense?

So effectively the rules would be that a SHUTDOWN or
SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or
SHUTDOWN-RECEIVED states solely on the basis of unacknowledged
but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK
chunk that is otherwise valid should be construed by the
receiver to have the same effect as a FWD-TSN dropping all
outstanding TSNs.

Is that simpler than a timer?

--brian

Whenever the receiver receives

On Mon, 05 May 2003, Randall Stewart (cisco) wrote:

> Ronnie:
> 
> Nope, I don't think you are missing anything. I have been testing the
> internal Cisco-IOS implementation of PR-SCTP against the KAME stack
> and have reached the same conclusion. I think we need to require that the
> receiver of a FWD-TSN send a SACK in reponse to this. Otherwise
> you have this deadlock scenario.... I have made the KAME stack
> send the SACK.. but this then begs another question...
> 
> If the SACK in the return path was lost (I am testing at times with
> error rates set to 20%... so that happens a lot).. what do we do?
> 
> It almost sounds like we need not only to require a FWD-TSN get
> a SACK in response.. but that the sender of the FWD-TSN, if no
> other data is being sent, start a timer to retransmit the FWD-TSN
> if no SACK is received.. not sure if I worded that clear but I think
> it will be needed...
> 
> Co-authors.. what do you-all think?
> 
> R
> 
> 
> Sellar, Ronnie wrote:
> 
> >Hi,
> >
> >We have just started looking at PR-SCTP with a view to having a prototype
> >implementation ready for the next Interop in Delaware and have come up with
> >a question regarding the FORWARD-TSN chunk and how it could affect
> >association termination.
> >
> >Consider the following example.  Endpoint A has an association with endpoint
> >B in which all the data it sends is ordered and marked as 'unreliable' for
> >whatever reason.  Endpoint A has now sent all the data it wants to send to B
> >but can't yet close the association because B has not yet acknowledged one
> >of the TSNs.  Lets say that it has transmitted TSNs 1-100 but has not yet
> >received an acknowledgement of TSN 97 since B has not yet received that TSN.
> >
> >In this situation A cannot yet send the SHUTDOWN since not all data is acked
> >and B has three chunks it cannot deliver to it's user (98, 99 and 100) since
> >it has not received 97.  When A receives the last SACK it decides that it no
> >longer wants to retransmit chunk 97 and so issues a FORWARD-TSN chunk to
> >move the cumulative ack TSN on to 100.  How does A know that B received the
> >FORWARD-TSN chunk ?  There is no more data to send so B will not be sending
> >any more SACKs.  If B sends no more SACKs A's cumulative ack TSN will not
> >advance and so he will not be able to send the SHUTDOWN chunk.
> >
> >In B's case when he receives the FORWARD-TSN he will be happy, deliver
> >98-100 to the user and move his cumulative TSN forward.  But he is not
> >required to send a SACK to tell A he has done so.  Are we now in a stalemate
> >situation ?
> >
> >Also consider the case where B never receives the FORWARD-TSN.  He is now
> >stuck with 98-100 in his buffers which he cannot deliver since he doesn't
> >know that 97 is not coming.  Have we reached a similar stalemate ?
> >
> >Perhaps I'm missing something, but I do think there seems to be a problem if
> >a FORWARD-TSN chunk is the last chunk to be transmitted on an association.
> >Please feel free to correct me if I'm wrong.
> >
> >Cheers
> >
> >Ronnie 
> >
> >---
> >Ronnie Sellar			Artesyn Communications Products
> >Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
> >Fax: +44 131 475 7001		Edinburgh EH6 5NP
> >mailto:[email-masked]	http://www.artesyncp.com
> >
> >  
> >
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 05 May 2003 13:45:37 -0500

Brian:

Seems like a much better solution than having a timer..

so we end up with:

1) A note in PR-SCTP about the SHUTDOWN cases as you mention.

2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be
    treated as a DATA chunk in regard to sending SACK's ( I think
    this is needed since there is no mention to it in the document
    currently).

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 May 2003 13:39:30 -0600

Randall,

It would also be interesting to test this solution in Delaware.

--brian

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 05 May 2003 15:09:57 -0500

Randy,

I agree with you. The solution by Brian sounds good and has far less
overhead than adding timer and ack to each FWD-TSN. 

regards,
-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 May 2003 03:04:05 -0600

Michael,

Yes, I was thinking there might be a problem during transmission too.

However, as t3-rtx is never running in this circumstance, yet the sender
of the FWD-TSN can indeed expect a SACK within an RTO for the FWD-TSN.

So, it would be possible to borrow the t3-rtx timer (rather than adding
a new one) to solve this siutation as follows:

When the sender sends a FWD-TSN and there is no unacknowledged data
remaining, resulting from the dropped TSNs, that t3-rtx SHOULD NOT be
stopped.  This would be an alteration to rule A2).

In addition, when the t3-trx timer expires, normal base protocol
retransmission would occur and, in addition, if the cummulative TSN ack
point is less than the Advanced.Peer.Ack.Point that in addition to
normal retransmission a FWD-TSN be bundled with any retransmitted DATA
chunks indicating the Advanced.Peer.Ack.Point (again) to the receiver.
This would be an additional rule, say A4.

That is, one could make retransmission of the FWD-TSN subject to the
same rules as would have applied to the DATA had it not been dropped.

Coupled this with making the FWD-TSN at the receiver subject to the same
rules visa vi SACK as the received DATA would have been subject.  (This
would also be an addition as Randall notes.)

Then all cases of retransmission of FWD-TSN would be handled in the same
fashion as the base protocol and none of these problems can any longer
ensue.  Modifications to SHUTDOWN would then no longer be required.
Also, no additional timers would be required.

One can then think of the FWD-TSN as a compressed placeholder for the
DATA that was dropped.  If the place holder is subject to the same
retramission (t3-rtx) and acknowledgement (SACK) rules as the DATA it
represents, then the only variation from the base protocol is that the
data itself does not need to be retransmitted once expired, and the
place holders for a number of DATA chunks can be represented in a single
FWD-TSN.

I think the change would be minor in implementation (not stop T3-rtx
when only dropped data is outstanding and consider retransmission of
FWD-TSN when considering DATA for retransmission).

Note that the SHUTDOWN case is also handled (because now the FWD-TSN for
the dropped TSN 97 would be retransmitted on T3-rtx, and T3-rtx would be
restarted, retransmission pegs counted, ...  just as though the data for
TSN 97 were being retransmitted.)

How does that sound?

Is that a better and more complete solution proposal?

--brian

On Tue, 06 May 2003, Michael Tüxen wrote:

> Hi all,
> 
> Brians solution handles the case at the end of live of an association.
> 
> Consider this case:
> 
> A sends TSN 0,1,2 on stream 0, all ordered. TSN 0 gets dropped in the 
> network.
> TSN 1 and TSN 2 arrive and get SACKed. Now the sender drops (in the 
> sense of
> PR-SCTP)  TSN 0 and sends a FWD-TSN chunk which is dropped in the 
> network.
> The sender now has no timers running, the receiver waits for TSN 0 to 
> deliver
> TSN 1 and TSN 2 to the upper layer.
> 
> This situation is not changed until the Upper Layer on the sender side 
> decides
> to send more data or initiates the shutdown procedure.
> 
> Did I miss something?
> 
> Best regards
> Michael
> 
> On Monday, May 5, 2003, at 20:34 Europe/Berlin, Brian F. G. Bidulock 
> wrote:
> 
> > Randall,
> >

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 06 May 2003 06:50:36 -0500

Great idea.. we will have to see if we can squeeze in the test..

I think this time we have a lot more time to test so we should
get a bit futher :>

R

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 6 May 2003 09:54:51 +0200

Hi all,

Consider this case:

Did I miss something?

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 6 May 2003 14:19:29 +0200

Brian,

sending a FWD-TSN chunk is from a SACK point of view equivalent
to sending DATA chunks. That means that the timer handling should be
the same for FWD-TSN and for DATA.

In my example this would mean that you transmit the FWD-TSN chunk
due to a T3_RTX timer event and you have to restart it. You do not
need a new timer, but you have to start one and using T3_RTX is
the one with the already defined procedures. So you should use
that.

Best regards
Michael

On Tuesday, May 6, 2003, at 11:04 Europe/Berlin, Brian F. G. Bidulock 
wrote:

>>>> and have reached the same conclusion. I think we need to require 
>>>> that
>>>> the