Subject: Re: PR-SCTP question (reneging)

From: Gavin Shearer <[email-masked]>
Date: Thu, 8 May 2003 13:44:40 +0100 (BST)

Ronnie said:

  One further question.  Does the advanced.peer.ack.point get moved backwards
  if acked data that it relies on is reneged ?  This doesn't seem to be
  mentioned in the draft.

Randall said:

	Hmm.. I am lost on this one..

To explain for Ronnie, say we at first have:

---1--------->	ABANDONED
---2--------->  ACKED
---3--------->  ABANDONED

The Advanced Peer Ack Point is therefore moved onto 3, while the Cumulative
Peer Ack Point is still at 0.

Now the peer renegs on 2, so we have:

---1--------->	ABANDONED
---2--------->  RENEGED (so no longer acked)
---3--------->  ABANDONED

Therefore the Advanced Peer Ack Point needs moved back to 1, as there is
now a gap (number 2).

So you could do something like the following when a chunk is reneged:

	if (Advanced.Peer.Ack.Point >= SackCumAck)
	{
		Advanced.Peer.Ack.Point = "TSN of reneged chunk" - 1
	}

Of course, this would probably only have an effect if delaying the F-TSN
or resending when the first one was lost (and a reneg arrived in the meantime).

	Gavin
---
Gavin Shearer,                        Suite 4,              [email-masked]
Project Leader,                       2 Anderson Place,     +44 131 475 7017
Artesyn Communication Products        Edinburgh, EH6 5NP

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 08 May 2003 09:53:31 -0500

>The Advanced Peer Ack Point is therefore moved onto 3, while the Cumulative

Nope... you have an error in your logic.

C2 says that your APAP is set a 1 NOT 3...

"
      C2) Try to further advance the "Advanced.Peer.Ack.Point" locally,
         that is, to move "Advanced.Peer.Ack.Point" up as long as the
         chunk next in the out-queue space is marked as "abandoned" as
         shown in the following example:
"

2 is NOT marked as abandoned so you would stop at 1.

This is how you get away from the reneg issue...

And as to your T3-rxt issue... Anytime a T3 goes off (no matter what
destination it was for) I go ahead and:

1) Mark anything new that needs to be marked.
2) update the APAP if needed.
3) Send a FWD-TSN if needed.

The reason I took this logic is that you are trying to move
forward the cum-ack over skipped data.. you may end up
sending the FWD-TSN twice.. but this is ok.. since duplicates
are ignored and this will be a very infrequent occurance..

One could send it only on one address. .but I don't think it
matters.. as the idea is to get things moved forward..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

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

Gavin Shearer wrote:

>On Thu, 8 May 2003, Randall Stewart (cisco) wrote:
>
>  
>
>Thanks, I see that now! I guess I thought you would try and abandon
>as many as possible and so would not stop at acked packets.
>
>  
>
>OK. It would be nice if the draft did not prevent doing it the
>way I said, i.e. the strictness of sentence "... the sender MUST
>NOT stop the rtx-timer" would prevent you stopping one T3-timer
>and starting another one if sending to a different address.
>Also the new paragraph "Any time the T3-rtx timer expires ... MUST
>be sent to the peer" would force a send on any T3 timer expiring.
>
>	Gavin
>
>
>  
>
Have a peak at the updated text ... and then see
if you still object..

R

---

From: Gavin Shearer <[email-masked]>
Date: Thu, 8 May 2003 17:22:21 +0100 (BST)

Gavin

---

From: Gavin Shearer <[email-masked]>
Date: Thu, 8 May 2003 18:50:57 +0100 (BST)

> Have a peak at the updated text ... and then see

It looks OK now that it has a "should" for resending whenever any T3 timer
expires, which would allow you not to do it if you deem it unnecessary.

However, is the following any better, to show the choice and also ensure
that the FORWARD TSN is retransmitted?

	C5) If a FORWARD TSN is sent the sender MUST start the T3-rtx
	timer ** for the destination address of the FORWARD TSN ** if
	it is not already running.

	A4) When the T3-rtx timer of the destination address sent the
	FORWARD TSN expires, the sender MUST try to advance the
	"Advanced.Peer.Ack.Point" by following the procedures outlined
	in C1 - C5. These procedures MAY also be followed when the
	T3-rtx timers expire for other destination addresses.

My suggestion for C5) can be ignored, if you do not want to insist the
T3-rtx timer be run on the dest address, if it is already running on
another address.

BTW in your C5) and A4) you have your favorite typo
of "rxt" instead of "rtx" :-)

Thanks,
	Gavin

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 08 May 2003 13:58:58 -0500

>	it is not already running.
How about instead
                  C5) If a FORWARD TSN is sent, the sender MUST assure that
                   at least one T3-rtx timer is running.

This way you can start one or not... as long as one is running somewhere...
and then one can based on this carefully maintain only where the
FWD-TSN is sent.. or not... depending...

And I think the SHOULD in the current A4) makes it loose enough
that one can do the alternate aka track things closely  OR just
do the FWD-TSN bit on all T3's

>	T3-rtx timers expire for other destination addresses.
And

>of "rxt" instead of "rtx" :-)

got it.. must be how fast my fingers repsond in the wrong sync :-0

R

---

From: Gavin Shearer <[email-masked]>
Date: Fri, 9 May 2003 09:46:26 +0100 (BST)

>                    at least one T3-rtx timer is running.

That sounds fine.

> do the FWD-TSN bit on all T3's

This seems OK. Is there a concern that being a "should" in A4 would allow
someone not to retransmit the FORWARD TSN at all?

	Gavin
---