Subject: [Tsvwg] [Fwd: comments on:draft-ietf-sigtran-usctp-00.txt]

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 19 Feb 2001 15:59:20 -0600

Fwd to tsvwg list :)

R
-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

Subject: Re: comments on:draft-ietf-sigtran-usctp-00.txt
From: "Randall R. Stewart" <[email-masked]>
To: Qiaobing Xie <[email-masked]>
Cc: [email-masked], [email-masked], Qiaobing Xie <[email-masked]>
Date: Mon, 19 Feb 2001 15:56:51 -0600

Qiaobing Xie wrote:

> I believe you are thinking of the lost FORWARD TSN case. Yes, this rule
> was originally in there, but somehow got edited out when Randy and I
> were playing with the wording of the SACK handling procedures.
> 
> I have streamlined the SACK processing procedures in v01. Basically, you
> first process the SACK using the standard steps in RFC2960. Then you try
> a "local advancement of Peer.Cumulative.TSN", and send a F-TSN either a)
> if you did make a local advancement of Peer.Cumulative.TSN, or b) you
> find the SACK is good but the Cumulative TSN it carries is older than
> your local Peer.Cumulative.TSN.
> 
> So we need to add:
> 
>  The data sender MUST always send a F-TSN containing its latest
>  "Peer.Cumulative.TSN" to the data receiver whenever the sender receives
>  a SACK which is not out-of-order and carries a Cumulative TSN earlier
>  than the current "Peer.Cumulative.TSN".

Hmm, the only way you can:

A) Recognize a SACK which is NOT out-of-order 

<AND>

B) carries a Cumulative TSN earlier than the current
"Peer.Cumulative.TSN"

is to keep two variables the Peer.Cumulative.TSN and a 
Estimated.Peer.Cumulative.TSN. 

However when you say "local advancement of the Peer.Cumulative.TSN" you
imply you are increasing the Peer.Cumulative.TSN. This becomes very
confusing I think. Since if one WERE to advance it, it WOULD make
all future SACK's out of order (as defined by RFC2960). For the quest
of NOT having an additional variable codified you are leaving a very
very subtle twist in the spec that, if one does not read closely AND
really think about, will lead implementors to just blindly update
the Peer.Cumulative.TSN and not think about what that will do to
out-of-order SACK detection.

I am pretty much convinced we need to add this other variable for
clearity otherwise you leave a AWFUL hole in the spec IMO...

I think we must add back a Estimated.Peer.Cumulative.TSN to make
this clear...

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)