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

From: [email-masked]
Date: Thu, 8 May 2003 17:46:41 +0300

... snip...

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

	Ok, now is even clearer...

> > By the way, the graphic at the beginning of the page shows "*Steam*
> > Sequence-1"...
> 
> 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...

	The point is that there is an "r" missing. It says "Steam" instead of "Stream"...

	I guess that steam was going out of your head trying to figure out what I was meaning... ;-)

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

	Yes, in that case. But it says that the "... initiation process have already ended..."

	But it is a little silly comment from mine anyway... :-0

	BTW, shouldn't it say "... initiation process *has* already ended..."?

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

	Well... read above...

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

	Yep... Well, it is you whose mother tongue is English, so... :-)

> can't think of any other way to word it :>
> 
> > - Section 3.6, first paragraph: Should the "end point" written here
> > be "endpoint" instead?
> > 
> 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..

	Yes, you are right... I had the idea that you could also report abandoned TSNs which are earlier than the Cumulative TSN ACK... Some kind of abandoned TSNs Gaps as in the SACK or so...

	I'm mistaken here... However, does it make any sense having such "gaps"? Probably not, since in this case you directly send a DATA, not a FORWARD 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.

	Yep... For a moment I was thinking about those Stream Numbers as specifying the SSNs that were abandoned... even past the Cumulative TSN 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)

	Yes...

> 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... :-/
> 
> Please restate your example... if I missed something... I think
> its ok..

	No, you got it right, I was mistaken...

> > - Section 4.3, beginning of page 18: Typo. "...) than those
> > additional..." should be "...) then those additional..."
> 
> got it.
> 
> > 
> > - Section 6: I guess there is a period missing at the end, between
> > "security" and "further"...
> 
> 
> > 
> > I think this is enough this time :-)
> 
> I will put a new diff (against -03 up with your new changes in :>)

	Thanks!

	BR Iván Arias Rodríguez

> 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)
> 
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 08 May 2003 10:37:08 -0500

[email-masked] wrote:
> 
>>> By the way, the graphic at the beginning of the page shows
>>> "*Steam* Sequence-1"...
>> 
>> Yes.. and it is labeld
>> 
>> Stream Sequence-N
>> 
>> and so the graphic shows Stream Sequence-1
>> 

Ahh..I missed the R a second time :> either that or
I was thinking of trains :>

> 
>>> - 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".
>> 
>> association to gracefully close.. so one would abort it not close
>> it..
> 
> 

Yep.. but maybe the whole statment in () should be killed...
don't know why I said already finished...because it
could not have :>

>>> - 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.
>> 
>> 
>> 
>>>  "abandonings"? There are another two "drop"s in section 4.1 TR3)
>>> and TR4).
>>> 
>> 

Well, that is something that as always haunted me.. but there is
nothing I can do about it but muddle through :D

>>> - Section 3.6, first paragraph: Should the "end point" written
>>> here be "endpoint" instead?
>>> 
>> 
>> 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
>> 
>>> 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...
>> 
>> 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..
> 
> 
> Yes, you are right... I had the idea that you could also report
> abandoned TSNs which are earlier than the Cumulative TSN ACK... Some
> kind of abandoned TSNs Gaps as in the SACK or so...

Not sure why one wuuld need this.. since once the cum-ack is
passed it is done...

> 
> I'm mistaken here... However, does it make any sense having such
> "gaps"? Probably not, since in this case you directly send a DATA,
> not a FORWARD TSN... :-/

I don't think you need them...
>> 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.
> 
> 
> Yep... For a moment I was thinking about those Stream Numbers as
> specifying the SSNs that were abandoned... even past the Cumulative
> TSN ACK...

ok
> 
> 
>> 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
>> 
>>> Cumulative TSN at the receiver is already 101, and the
>>> information carried in the FORWARD TSN chunk would help the data
>>> 
>> 
>> receiver advance
>> 
>> Please restate your example... if I missed something... I think its
>> ok..
> 
> 

A bit of steam got in the way here too :-D

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

I will fix the steam but I will not put an updated change on the
web site..

Let me know if you have trouble accessing it.. you shoudl be ok
but one never knows :>

R

> 
> BR Iván Arias Rodríguez
> 
> 
>> 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)
>> 
>> 
> 
> 
> 
>