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

From: Qiaobing Xie <[email-masked]>
Date: Mon, 19 Feb 2001 17:04:42 -0600

Randy,

Please see my comments below...

-Qiaobing

"Randall R. Stewart" wrote:
> 
> 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

For this, you compare the cmTSN of the new SACK with the cmTSN of the
*last good SACK* you processed.

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

If the new SACK is good (i.e., it passed A test above), you then compare
its cmTSN with your "Peer.Cumulative.TSN". And if the cmTSN in the SACK
is behind, you need to send a FORWARD TSN. This is the issue John was
looking at.

My argument is we don't need to codify how the test A) above is
implemented. You can do it by keeping a copy of the last good SACK you
received, or use an internal variable to record the cmTSN carried in the
last good SACK. I don't feel we need to elevate this internal variable
to a protocol variable.

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

NO, this won't happen. Peer.Cumulative.TSN is NOT meant to be used for
out-of-order SACK detection! As I've commented above, you must compare
the cmTSN of the new SACK against the cmTSN of the *last good SACK* you
received for out-of-order detection.

In other words, Peer.Cumulative.TSN is a new sender side proto variable
added for u-sctp to manage the sender's out-queue. It is not meant to
help detecting out-of-order SACKs. Maybe the name of the variable is a
little confusing. If that is the case, I can change it to something
else.

This is all made very clear in v01 now.

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

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 19 Feb 2001 17:13:40 -0600

Q:

You make my point.. .see below..

> *last good SACK* you processed.

And the *last good SACK* is EXACTLY what the Peer.Cumulative.TSN is
in the current RFC2960!! 

> last good SACK. I don't feel we need to elevate this internal variable

I understand your argument...

> received for out-of-order detection.

See here is my EXACT point. In RFC2960 the Peer.Cumulative.TSN IS the
last good SACK value. This IS used to figure out if you have an
OUT-OF-ORDER SACK. Now with this draft you are CHANGING THE MEANING
in a very subtle way of the Peer.Cumulative.TSN and creating a variable
(that you don't want to codify) that WAS the Peer.Cumulative.TSN while
changing the meaning of the Peer.Cumulative.TSN. This is my fundamental
problem... As such you are creating confusion for implementors by
twisting the meaning of a current variable. In RFC2960 it is called
the 'Cumulative TSN Ack Point'  and is used to detect out of order
SACK's. This IS the Peer.Cumulative.TSN variable and you are making
subtle changes to it by changing its meaning.. VERY BAD in my opinion.

> little confusing. If that is the case, I can change it to something

The above statement is in complete conflict with the statement in the
draft

" A1) The sender maintains a "Peer.Cumulative.TSN" for each peer so as
     to track the latest cumulative TSN point of the peer (Note, this
     variable may already exist in a classic SCTP implementation for
     outqueue management and for detecting out-of-order SACKs). 
"

You are saying to reuse the Peer.Cumulative.TSN which IS implied to
be the same variable. If you want to fix this then you will need to
say something like:

"
 A1) The sender maintains a "Peer.Cumulative.TSN" for each peer so as
     to track the latest cumulative TSN point of the peer (Note, this
     variable is NOT the same has a classic SCTP implementations
     'Cumulative TSN Ack Point' and it a new protocol variable).
"

Which then means you have exactly what I have been trying to get
you to put into this spec i.e

Peer.Cumulative.TSN = the "Estimated Cumulative.TSN"
Cumulative TSN Ack Point (From RFC2960) = The place the Peer is at...

You have the two variables, you have just been blurring the two
together (at least for me) with your wording in A1...

R

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 19 Feb 2001 17:47:06 -0600

hmm... I see your point, the text you cited below is indeed broken and
confusing.

>      'Cumulative TSN Ack Point' and it a new protocol variable).

How about:

"
 A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer to
     track a theoretical cumulative TSN point of the peer (Note, this 
     is a new protocol variable and its value is NOT necessarily the 
     same as the classic SCTP Cumulative TSN Ack Point as defined in 
     [RFC2960]).
"

-Q

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 19 Feb 2001 17:49:11 -0600

Q:

Yes!! this is what I have wanted all along :)

I knew we were in violent agreement I just had to
figure out how to get you up to speed with me :/

Your wording below is fine..

R