Subject: [Tsvwg] Comments about prsctp-03.txt (and latest changes)

From: [email-masked]
Date: Thu, 8 May 2003 15:36:08 +0300

Hi all!

	I have just read the version 03 of the document and I have the next comments and several small typos:

	- First of all: Why the diff document at www.sctp.org is done taking as the basis the version 02? :-/ just curious...

	- Section 1.1, 2): I suppose that "Data chunks" should be "DATA chunks"...

	- Section 1.2, first paragraph, last words: Instead of "... send the message to receiver." might be "... send the message to the receiver."

	- Section 3.2, definitions of Stream-N and Stream Sequence-N: It speaks about "skipped streams" here... I think I understand what it means but it is ambiguous for me... Is it something like "streams to which were directed one or more of the abandoned DATA chunks reported in this FORWARD TSN chunk"? Uff, too long... maybe "skipped" is still better... :-)

	And what about the meaning of Stream Sequence-N? What I understand is that it is the previous to the next SSN that could be delivered to the upper user, i.e., all the SSNs earlier to this number can already be delivered even though there are earlier SSNs that have not yet arrived... Am I right?

	By the way, the graphic at the beginning of the page shows "*Steam* Sequence-1"...

	- Section 3.3.3, beginning of 10th page: Forgive me for this comment but, what about gracefully closing the association? Later in this section, in 2) there is a typo: "reliablilty".

	- Section 3.4, A2): It doesn't say here anything about updating the Advanced.Peer.Ack.Point, should it?

	- Section 3.4, C4): It says "drop's" here, I guess it could be... "abandonings"? There are another two "drop"s in section 4.1 TR3) and TR4).

	- Section 3.6, first paragraph: Should the "end point" written here be "endpoint" instead?

	- Section 3.6, page 14: There is here a rule to treat a FORWARD TSN as out-of-date and discard it, but I'm not convinced it is right...

	Imagine the sender has sent TSNs 101, 102 and 103. TSN 103 arrived normally, 102 was lost in the network, and 101 was delayed enough time to make the T3 timer expire and send the FORWARD TSN chunk before the SACK reached the data sender.

	If the sender has not received yet the SACK for TSN 101, and in case 102 is abandoned at this point (but 101 is not), the "New Cumulative TSN" of the FORWARD TSN chunk will be set to 100, however, the Cumulative TSN at the receiver is already 101, and the information carried in the FORWARD TSN chunk would help the data receiver advance its Cumulative TSN to at least 103...

	Hmm... I don't think this rule is valid... :-/

	- Section 4.3, beginning of page 18: Typo. "...) than those additional..." should be "...) then those additional..."

	- Section 6: I guess there is a period missing at the end, between "security" and "further"...

	I think this is enough this time :-)

	Thanks!

	BR Iván Arias Rodríguez
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 08 May 2003 09:22:47 -0500

[email-masked] wrote:
> - First of all: Why the diff document at www.sctp.org is done taking
> as the basis the version 02? :-/ just curious...
Opps.. because I fat fingered the diff.. I will redo it :>

> - Section 1.1, 2): I suppose that "Data chunks" should be "DATA

ok
> - Section 1.2, first paragraph, last words: Instead of "... send the
> message to receiver." might be "... send the message to the
> receiver."
> 

good cach.

> - Section 3.2, definitions of Stream-N and Stream Sequence-N: It
> speaks about "skipped streams" here... I think I understand what it
> means but it is ambiguous for me... Is it something like "streams to
> which were directed one or more of the abandoned DATA chunks reported
> in this FORWARD TSN chunk"? Uff, too long... maybe "skipped" is still
> better... :-)

You have it right.. but it is a bit hard to put down.. without being
very long :-0.. Of course so far these suggestions you have
made have nothing to do with the new changes.. but thats ok :>

Don't know how to define 3.2 better.. It does specify:
"

    Stream-N: 16 bit u_int

    This field holds a stream number that was skipped by this FWD-TSN.

    Stream Sequence-N: 16 bit u_int

    This field holds the sequence number associated with the stream
    that was skipped. The receiver of the FWD-TSN's can use the Stream-N
    and Stream Sequence-N fields to enable delivery of any stranded TSN's
    that remain on the stream re-ordering queues.
"

Which if you read all together I think is clear...

> 
> And what about the meaning of Stream Sequence-N? What I understand is
> that it is the previous to the next SSN that could be delivered to
> the upper user, i.e., all the SSNs earlier to this number can already
> be delivered even though there are earlier SSNs that have not yet
> arrived... Am I right?
> 

Yep... its the highest stream sequence in this stream number
that can be skiped... so if you do

abandon (TSN=888 STR=1 SEQ=5
and
abandon (TSN=889 STR=1 SEQ=6)

Then your FWD-TSN would
have

STREAM- 1  SEQUENCE-6

In its report.

> By the way, the graphic at the beginning of the page shows "*Steam*

Yes.. and it is labeld

Stream Sequence-N

and so the graphic shows
Stream Sequence-1

Is this not what one would expect... if we want to kill the word
stream thats ok.. I just don't understand why you need to.. it is
after all a "stream sequence" number...

> 
> - Section 3.3.3, beginning of 10th page: Forgive me for this comment
> but, what about gracefully closing the association? Later in this
> section, in 2) there is a typo: "reliablilty".

Got the reliablity...but if you are just starting the association
I.e. have either sent the INIT or received it... there is NO
association to gracefully close.. so one would abort it not
close it..

Otherwise one would need to finish the 4-way handshake and THEN
shut it down.. which makes no sense to me...am I missing something?
> 
> - Section 3.4, A2): It doesn't say here anything about updating the
> Advanced.Peer.Ack.Point, should 

Good point.. you should try to advance the ack point if possible
as well as resend a new fwd-tsn.

> 
> - Section 3.4, C4): It says "drop's" here, I guess it could be...
> "abandonings"? There are another two "drop"s in section 4.1 TR3) and
> TR4).
> 
Ok, got them.. even though I think abandonings is a bit strange.. I
can't think of any other way to word it :>

> - Section 3.6, first paragraph: Should the "end point" written here
Yep thats a typo.

> - Section 3.6, page 14: There is here a rule to treat a FORWARD TSN
> as out-of-date and discard it, but I'm not convinced it is right...
> 
> Imagine the sender has sent TSNs 101, 102 and 103. TSN 103 arrived
> normally, 102 was lost in the network, and 101 was delayed enough
> time to make the T3 timer expire and send the FORWARD TSN chunk
> before the SACK reached the data sender.
So let me get this right

CUM-ACK=100

I send

---TSN101--->Xdelayed
---TSN102--->Xlost
---TSN103-------------------------->
<-------------SACK(100, got103-103)---
Now t3-rxt goes off on 101 so I

----FORWARD-TSN(101)-------->

> 
> If the sender has not received yet the SACK for TSN 101, and in case
> 102 is abandoned at this point (but 101 is not), 

Now wait... no I mis-understand your diagram.. you are not
skipping 101, but 102...

So at the point the T3-Timer goes off you have

101-- still good need resend
102-- mark to abandon
103-- Acked with gap-acks

In this case your advanced peer ack point will still be
at 100 (the same as the cum-ack) so you can NOT send
a fwd-tsn..

Not until the SACK(101) comes back and then your adv-peer-ack-point
will be advanced.

Note rule C2) and also note rule C3).. so in the first
case C2 prevents you from moving a-p-a since 101 is still
outstanding and is not marked to skip.. and C3) blocks
you from sending a FWD-TSN since the a-p-a is equal to
your Cum-Ack.

In the second case (after SACK(101) arrives) you then
can, by C2) set a-p-a to 102 and thus send a fwd-tsn..

I think there is nothing wrong with discarding
old FWD-TSN's .. you may want to handle them the
same way you would duplcaite data though.. and send a
SACK()..

the "New Cumulative
> TSN" of the FORWARD TSN chunk will be set to 100, 

and won't be sent (see above)

however, the
> Cumulative TSN at the receiver is already 101, and the information
> carried in the FORWARD TSN chunk would help the data receiver advance
> its Cumulative TSN to at least 103...
> 

Please restate your example... if I missed something... I think
its ok..

> 
> - Section 4.3, beginning of page 18: Typo. "...) than those
> additional..." should be "...) then those additional..."

got it.

> I think this is enough this time :-)

I will put a new diff (against -03 up with your new changes in :>)

R

> 
> Thanks!
> 
> BR Iván Arias Rodríguez 
> _______________________________________________ tsvwg mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 08 May 2003 09:43:12 -0500

Ivan/All:

I have re-compared the -03 to -04 version.. this
time with the right documents.. plus Ivan's changes
and all comments that have been made so far.

Please have a look at

http://www.sctp.org

under the rfc tab..

Note if anyone has problems with the site please contact me
and I will either get things working or send a copy of the
comparison doc.

Thanks

R