Subject: RE: PR-SCTP question (T3 timers)

From: [email-masked]
Date: Thu, 8 May 2003 13:29:33 +0300

Hi!

	I imagine this is basically what Michael was thinking. I do support this idea as well.

	IMO it looks very "coherent" and would require less changes to an implementation adding the PR-SCTP functionality.

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Gavin Shearer [mailto:[email-masked]]
> Sent: Thursday, 08 May, 2003 12:15
> To: [email-masked]
> Subject: RE: PR-SCTP question (T3 timers)
> 
> 
> 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
> 
>