Subject: RE: [Tsvwg] Comments about the PR-SCTP extension

From: [email-masked]
Date: Thu, 27 Nov 2003 12:24:21 +0200

Hi all!

	See my comments inline...

> >	- Section 3.4, page 12, rule C5: Hmm... I think that a 
> very common situation will be that we have some TSNs 
> unacknowledged, and then the T3-rtx timer expires (the only 
> one that was running), and then you decide to abandon all the 
> unacknowledged TSNs and send the FORWARD TSN. There is no 
> T3-rtx running, so, C5 says that we "MUST assure that at 
> least one T3-rtx timer is running", so, should be restart it? 
> but, which one?
> >  
> >
> 
> I don't think that it matters. The point of having  the T3 
> timer running 
> is that if it is NOT running (as you
> illustrate above) and the FWD-TSN is lost.. then you have a kind of 
> deadlock scenario.. not really
> a dead lock.. but until the sender of the FWD-TSN sends some 
> new data it 
> will never know to resend
> the FWD-TSN. Thus the receiver will possibly be stuck with some 
> out-of-order data on queue and
> never send it up to the upper layer until new data is sent... 
> not really 
> what you want I think... So, as
> long as one tiemr is running the job will get done i.e. it 
> will go off 
> and then cause you to resend
> the FWD-TSN.
> 
> I suppose we could add a Implementation note like:
> "
> IMPLEMENTATION NOTE: Any destination's timer may be used for the
> purposes of rule C5.
> "

	Yeah, you are completely right... In fact, the point of this comment (and the next one) was that I was thinking that, since the FWD-TSN is acknowledged as the DATA chunks are, you were also performing that retransmission counter reset when the SACK arrives, or an increase plus cwnd shrink and RTO doubling and so on...

	But since that's not the case (by the way, which is the reason not to do so?), then I agree that the destination doesn't really matter (however, I think that any implementer will try to send the FWD-TSN to a different address than the previously used)...

> >	Another thing that is not so clear for me is which 
> address should we use for sending the FORWARD TSN... Should 
> we kind of follow the same criterion than when retransmitting 
> the TSNs themselves? However, the abandoned TSNs might have 
> been sent to different addresses, so, which one should be 
> use? Maybe I'm just mistaken but I would say that this is not 
> clearly stated in the draft... :-/
> >
> >  
> >
> 
> I think again it does not really matter, as long as the address is 
> "confirmed" (see the I-Gv10 which was
> sent in during the IETF)...
> 
> So maybe a note after C3 stating:
> <t>
> IMPLEMENTATION NOTE: It is an implemenation decision as to which
> destination address is to be sent to, the only restriction
> being that the address MUST be one that is CONFIRMED.
> </t>

	Same comment also applies here. The NOTE sounds good for me, but mind that "implemenation" typo ;-)

> >	- Section 3.4, page 12, rule A5: As it is written I 
> think it is a little bit confusing... I suppose that what you 
> want to mean is that after a T3 expiration you check whether 
> you have to abandon or not any TSN, and after that you try to 
> advance the Advanced.Peer.Ack.Point, right? But that 
> procedure of advancing that variable is stated only in C2... 
> The others are mostly related with the arrival of a SACK... :-/
> >
> >  
> >
> Hmm in looking at the rules I must disagree and agree :->
> 
> Rule C1 has to do with a SACK...

	Yes...

> Rule C2 has to do with how you figure out if you have
> an advance peer ack point.

	I agree...

> Rule C3 tells you that you must send a FWD-TSN (possibly)

	Yes but here there is a comment about the received SACK... In fact, thinking about it, since you firstly process normally the SACK, I don't think you even have to mention the SACK at all, since the value of the "Cumulative TSN Ack Point" must have been already updated at this stage, being equal to the "Cumulative TSN ACK carried in the received SACK"...

	Hmm... now that I see it, A4) mentions the normal processing procedure for SACKs as stated in 6.2.1, but that section basically deals with the rwnd only... Weird that 6.2.1 in the RFC doesn't give any pointer to sections 7.2.1 and 7.2.2, which depict the "real" steps you take when receiving a SACK, and only mentions 7.2.4... :-/ Well, also 8.1 and 8.2 are very important sections regarding SACK processing...

	I hadn't taken a look to the section 6.2.1 when I firstly read the draft, but now that I have gone through it, it makes me feel kind of uncomfortable (not for the draft, but for the RFC itself)... :-/

> Rule C4 tells you that you must back it down if you have some 
> data that
> is not partially reliable between the last sack point and the advance 
> peer ack point.

	Yes.

> Rule C5 tells you that you must maintain your timer..

	Exactly.

> So really A5 should use the procedures outlined in C2-5 not C1-5..

	Yes, you are right... Only that the C3 is also SACK-related as it is written...

> So I guess we can consider these IETF-Last-Call comments aka..
> 
> 1) Fix typos.
> 
> 2) add two implementation notes
> 
> 3) correct sequecne range in A5 to C2-C5 instead of C1-C5
> 
> 
> Does this sound ok to you Ivan?

	It does!

	Thanks!

	BR Iván Arias Rodríguez

> R

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg