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

From: [email-masked]
Date: Fri, 21 Nov 2003 18:20:46 +0200

Hi all!

	I have read the PR-SCTP extension draft, and I have seen some typos (which I hate to comment, but since I saw them anyway...) and also I have couple of comments:

	- Section 1.2, page 4, second paragraph, a duplicated word: "... IETF so that *that* the designers..."

	- Section 3.1, "Length" definition: "Indicate the size...", shouldn't it be "Indicates the size..."?

	- Section 3.2, page 8, "Stream Sequence-N" definition: "... report TSN's co*or*esponding to..."

	- Section 3.3.1, title of the section (also in the index): This is kind of silly, but, shouldn't be that "param" be "parameter" instead?

	- Section 3.3.2, second paragraph: There is a mistaken reference to RFC2960 as [4] instead of [5]...

	- Section 3.3.3, page 9: "... COOKIE or as a** unrecognized...", I would say that "a" should be "an"... :-/

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

	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... :-/

	- 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... :-/

	Ok, that's all this time!

	Have a nice weekend!

	BR Iván Arias Rodríguez

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

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Wed, 26 Nov 2003 12:37:30 -0600

>	- Section 3.3.3, page 9: "... COOKIE or as a** unrecognized...", I would say that "a" should be "an"... :-/

Thanks for the typos.. I found them all ;-> 

Now to your other questions...

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

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

>	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? How…

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>

>	- 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…
Hmm in looking at the rules I must disagree and agree :->

Rule C1 has to do with a SACK...
Rule C2 has to do with how you figure out if you have
an advance peer ack point.
Rule C3 tells you that you must send a FWD-TSN (possibly)
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.
Rule C5 tells you that you must maintain your timer..

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

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?

R

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)