Subject: [Tsvwg] Re: PR-SCTP question (T3 timers)

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 8 May 2003 04:36:30 -0600

Gavin,

That's what I did too.  It makes sense.  However, if a new FWD TSN
is sent (because new TSNs are dropped pushing the advanced ack point),
I also cancel the fact that a previous FWD TSN was outstanding against
the destination to which the previous FWD TSN was sent.

We might now consider that FWD TSNs need not be delayed for bundling by
200 to 500 ms.  In fact if the TSNs are marked dropped and an FWD TSN
is to be transmitted on t3-rtx timeout, we might as well only wait for
the normal t3-rtx timeout (even if it is greater than 500ms) before
sending the FWD TSN.  This would have the effect of bundling the FWD TSN
with unexpired retransmitted TSNs, or at worst only retransmitting the
FWD TSN once an RTO and would back off sending of FWD TSNs during periods
of congestion rather than sending every 200-500 ms without data (no back
off).

Is the 200-500ms still in the new draft?

--brian

On Thu, 08 May 2003, Gavin Shearer wrote:

> I have some queries/suggestions about handling the T3 timer(s) with
> PR-SCTP.
> 
> As each destination address has a T3 timer, there can be multiple T3
> timers running if you are sending to different destination addresses of
> the peer.  Therefore, as the draft/updates are worded, it is unclear
> which T3 timer is stopped and the expiry of which causes sending again
> of a F-TSN.  (If it was all T3 timers which caused sending again, you
> may send the F-TSN more than once even if you do not need to.)
> 
> Therefore, carrying on with the theme of treating the packet as summary
> of data, I would think it makes sense for the F-TSN to be treated like
> the bundling of the abandoned chunks being retransmitted to a
> particular address.  Therefore the T3 timer handling would be handled
> in the same way.
> 
> This means you would start the T3 timer for the destination address of
> the F-TSN if not already running.  So, when a T3 timer expires you
> would only send the F-TSN again if the T3 timer expired for the address
> sent the F-TSN. (This could be implemented by checking that this is the
> address at least one abandoned chunk was last "sent" to, if you note
> the address a chunk is sent to in the same way as (re)transmitting
> a chunk).
> 
> Of course, if you re-send the F-TSN to an alternative address, then the
> F-TSN will be noted as outstanding on that address, in the same manner
> as you would treat retransmitting DATA to an alternative address.
> 
> I think this would change the wording of:
> 
> 	A2) You would not say that the T3-rtx timer is not stopped - i.e.
> 	remove that line.
> 
> 	[I think this would be the case, as when retransmitting you
> 	do not stop the T3 timer of an earlier address when
> 	retransmitting on an alternative address, see RFC2960 6.3.3 F1).]
> 
> 	For the new paragraph covering sending due to the T3 expiring
> 	you would put in an additional condition of the T3-rtx timer
> 	expiring for the destination address sent the F-TSN.
> 
> 
> 	C3) You would say that sending the F-TSN is treated like
> 	retransmission of the abandoned chunks when handling the T3-timers.
> 	You may want to emphasize that the T3 timer for the
> 	destination address should be started if not already running.
> 
> 		Gavin
> ---
> Gavin Shearer,                        Suite 4,              [email-masked]
> Project Leader,                       2 Anderson Place,     +44 131 475 7017
> Artesyn Communication Products        Edinburgh, EH6 5NP

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