Subject: [Tsvwg] Comments about prsctp-00

From: [email-masked]
Date: Mon, 20 May 2002 02:04:35 +0300

Hi all!

	After reading the draft, I have the following comments...

	- Section 3.2, page 7: Wouldn't it be better to express the Chunk Type as 0xC0 (using hexadecimal numbers, as normally done)? Or at least leave clear that we are using binary numbers (i.e., it is not eleven million :->)

	- Section 3.2, page 8: The Chunk Length field appears already set to its fixed value of 8. Somehow I would like it more if "Chunk Length = 8" would appear there, as done with the Forward-TSN-Supported Parameter... But this is, of course, just a matter of style... :-0

	- Section 3.3.2, first paragraph, page 8: Here it says that if the receiver of the INIT chunk containing the new parameter does not understand it, it should report it in an ERROR chunk... However, the normal way of doing this is including an Unrecognized Parameters parameter in the INIT ACK chunk...

	In fact, now that I think about it, the RFC allows to send the answer back either inside an ERROR or an INIT ACK chunk. But, as the INIT ACK chunk cannot be bundled with any other chunk, does this really make sense?... :-/ Maybe if you decide not to establish the association and you don't send the INIT ACK, then you would just send the ERROR chunk... However, this (not sending the INIT ACK at all) would make more sense in the "01" case, not the "11"... :-/

	This first paragraph could be included at the end of the section with the only modification of changing "INIT" for "INIT ACK". This is because the section does not cover the situation where the INIT sender does not support the extension and the INIT ACK sender includes the new parameter... You can always bundle the ERROR chunk right AFTER the COOKIE ECHO chunk... :-/

	- Section 3.3.3, page 9: The previous comment affects to this section as well... You would either receive an Unrecognized Parameters parameter in the INIT ACK, or an ERROR chunk after receiving the COOKIE ECHO, most probably bundled with it (otherwise, if the COOKIE ECHO and ERROR Chunks are reordered, the ERROR would be treated as an OOTB datagram).

	In the first case, 1) and 2) in section 3.3.3 make sense (only changing "operational error" for "INIT ACK with the Unrecognized Parameters parameter" would be required). In the later case, the peer will have already processed the COOKIE ECHO, and thus it will be already in the ESTABLISHED state at the time of processing the ERROR Chunk (and then it makes no sense to "end/continue the initiation process", because the association is already established).

	- Section 3.6, middle of page 13: "Whenever an unreliable DATA chunk arrives...". How does the data receiver know that the DATA chunk is unreliable? :-) Most probably you could omit "unreliable" here...

	- Next paragraph in section 3.6: "... any messages that carry a TSN earlier than or equal to the new cumulative TSN point.". I'm not sure if this paragraph makes the assumption that the messages are smaller than or equal to one MTU and thus every SSN corresponds with a single TSN... :-/

	Maybe, "... any fully received messages whose last fragment has a TSN earlier than or equal to the new cumulative TSN point." would be better... But this is not really exact either... Let's make an example. If these have been the last chunks sent:

	- (TSN: 100, Stream: 0, SSN: 10, Flags: B) RECEIVED (and all the previous ones)
	- (TSN: 101, Stream: 0, SSN: 10, Flags: E) LOST
	- (TSN: 102, Stream: 1, SSN: 20, Flags: B) LOST
	- (TSN: 103, Stream: 1, SSN: 20, Flags: E) RECEIVED
	- (TSN: 104, Stream: 0, SSN: 11, Flags: BE) RECEIVED

	Then, so far, the cumulative TSN is 100. If SSN 10 of Stream 0 must be dropped, then the new Advanced.Peer.Ack.Point would be 101. However, SSN 11 of Stream 0 can be now delivered to the upper user (even though it is not covered by the new cumulative TSN point).

	The actions that must be taken upon receipt of a FORWARD TSN are quite obvious, the hard thing is to express them... :-)

	- Section 4.1, TR3), page 16: Maybe instead of saying that the lifetime parameter is set to "zero", it could be said that it is set to "SCTP_LIFETIME_RELIABLE", as previously defined...

	- Section 4.2, Note, page 17: The word "the" appears between square brackets... I don't know if this is a typo or what... Little bit below, we can read "[default]", not sure if the square brackets should be normal ones here or not... :-/

	- A final comment about the shape of the new FORWARD TSN chunk. Have you thought about including gaps in this chunk? probably yes. It is not a TSN what becomes stale, but the whole SSN, so a list of (Stream ID, Dropped SSN) could be useful as well. But this doesn't apply to unordered messages... :-/ Maybe a simple list of TSNs that have been dropped and that are not acknowledged in the received SACK would be also useful... Probably the best way would be the one used in the SACK chunks...

	In any case, the idea is that if these were the last chunks sent:

	- (TSN: 100, Stream: 0, SSN: 10, Flags: B) RECEIVED (and all the previous ones)
	- (TSN: 101, Stream: 0, SSN: 10, Flags: E) LOST
	- (TSN: 102, Stream: 1, SSN: 20, Flags: B) LOST
	- (TSN: 103, Stream: 1, SSN: 20, Flags: E) RECEIVED
	- (TSN: 104, Stream: 0, SSN: 11, Flags: B) RECEIVED
	- (TSN: 105, Stream: 0, SSN: 11, Flags: E) LOST
	- (TSN: 106, Stream: 0, SSN: 12, Flags: BE) RECEIVED

	At this point we receive the SACK [100: (3, 4); (6, 6)] and we realize that SSNs 10 and 11 of Stream 0 have become stale. Following the draft, one should send a FORWARD TSN [101], and then nothing could be delivered to the upper user. However, if we include gaps as done in the SACKs and we send a FORWARD TSN [101: (3, 4)] (note that we include in the gaps of the FORWARD TSN only the dropped TSNs that the peer has not acknowledged), the receiver would know that TSN 105 has also been dropped and thus it can already deliver SSN 12 of Stream 0 to the upper user...

	If this makes the processing harder, one could always choose not to send/process gaps... :-0

	And now, some typos:

	- Abstract, page 2: "... (2) one example partially reliable service...". I imagine that it should be "... (2) one example *of a* partially reliable service..."

	- Section 3.1, last sentence, page 7: "Indicate the size...". Shouldn't it be "Indicates the size..."

	- Section 3.5, A2), last paragraph, page 10: "... and the MUST NOT advance the cwnd...". Maybe "... and *it* MUST NOT advance the cwnd..." or "... and the *sender* MUST NOT advance the cwnd..." would be better...

	- Section 4, last paragraph, page 14: "implementers"... I'm not sure at all about this... Shouldn't it be "implementors"? Google does not help that much here... "Implementer" also appears twice in the last paragraph of section 4.1.

	- Section 4.1, E3), page 15: "A send exactly once" message...". There is a " missing... It should be "A *"*send exactly once" message..."

	- Section 4.3, first paragraph, page 17: "... than those additional PR-SCTP services...", should be "... *then* those additional PR-SCTP services...".

	That's all! 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: Fri, 24 May 2002 12:01:38 -0500

Ivan:

Once again I will get the document XML up and 
go though this with your changes....

see below...

>         - Section 3.2, page 7: Wouldn't it be better to express the Chunk Type as 0xC0 (using hexadecimal numbers, as normally done)? Or at least leave clear that we are using binary numbers (i.e.,…

ok.. done..

>         - Section 3.2, page 8: The Chunk Length field appears already set to its fixed value of 8. Somehow I would like it more if "Chunk Length = 8" would appear there, as done with the Forward-TS…

I agree it now shows:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = 0xC0 |  Flags = 0x00 |        Length = 0x0008        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      New Cumulative TSN                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>         - Section 3.3.2, first paragraph, page 8: Here it says that if the receiver of the INIT chunk containing the new parameter does not understand it, it should report it in an ERROR chunk... H…

Yep.. I will change this to the unrecog param in the INIT-ACK... and I
will fix the reference to 3.3.3 as it should be..

>         In fact, now that I think about it, the RFC allows to send the answer back either inside an ERROR or an INIT ACK chunk. But, as the INIT ACK chunk cannot be bundled with any other chunk, do…

I think we will just leave it to point to 3.3.3 and bundle back
the unrecog parameter... this is how it SHOULD be... since we
are discussing a peer that does not recognize the PR-SCTP parameter and
in theory with the bit set like that they do not refuse to setup
the assoc unless there is some other reason.... and they are
supposed to send back the unrecog-param's...

>         This first paragraph could be included at the end of the section with the only modification of changing "INIT" for "INIT ACK". This is because the section does not cover the situation where…

I am confused by this comment.. what text do you want where? :> (maybe
it is just me... I have changed the 3.3.2 to read:
"
3.3.2 Receipt of Forward-TSN-Supported param in INIT

   When a receiver of an INIT detects a Forward-TSN-Supported parameter,
   and does not support the Forward-TSN chunk type, the receiver SHOULD
   treat this parameter as an invalid or unrecognized parameter and
   respond to the data sender with an unrecognized paramater in the
   INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
   [4].
"

What else do you want changed?

>         - Section 3.3.3, page 9: The previous comment affects to this section as well... You would either receive an Unrecognized Parameters parameter in the INIT ACK, or an ERROR chunk after recei…

Ok .. how about this:

"
3.3.3 Receipt of Op. Error for Forward-TSN-Supported Param

   When an SCTP endpoint that desires to use the FORWARD TSN chunk
   feature for partially reliable data transfer receives an operational
   error from the remote endpoint (either bundled with the COOKIE or as
   a unrecognized parameter in the INIT-ACK), indicating that the remote
   endpoint does not recognize the Forward-TSN-Supported parameter, the
   local endpoint SHOULD inform its upper layer of the remote endpoint's
   inability to support partially reliable data transfer.

   The local endpoint may then choose to either:
"

I think this capture the fact that you can get an error from one of
the two sources aka INIT-ACK or bundled seperately with the COOKIE.

>         In the first case, 1) and 2) in section 3.3.3 make sense (only changing "operational error" for "INIT ACK with the Unrecognized Parameters parameter" would be required). In the later case,…

I think no matter which way the peer sends you the error you must
turn off the feature... 

>         - Section 3.6, middle of page 13: "Whenever an unreliable DATA chunk arrives...". How does the data receiver know that the DATA chunk is unreliable? :-) Most probably you could omit "unreli…
yep.. this is an oversight from the last version :> in fact
I had already caught it in my conversion to XML....

>         - Next paragraph in section 3.6: "... any messages that carry a TSN earlier than or equal to the new cumulative TSN point.". I'm not sure if this paragraph makes the assumption that the mes…

No it does not make this assumption. pr-sctp procedures are on a
TSN basis. This is ok when one thinks about it... consider
a fragmented message

---Msg 3k----TSN 7 BE=10/ TSN 8 BE=01

Now when it is time to retransmit one of a number things will
be happening:

A) 7 needs retransmitting and 8 is received
B) 7 and 8 need retransmitting
C) 8 needs retransmitting.

If we are A.. .then when you advance everything according to the
procedures your new FWD-TSN will be 8. Now this means that 
when processing the FWD-TSN the sender must be careful to
update its re-ordering queues very carefully... removing
stray fluf that is hanging. It must examine the cum-ack point
carefully and leave any unknown/undetermined things pending until
it can look backwards and see the BE=10 and it knows it has
everything...

If we are B then BOTH should expire at the same time...

If we are C then FWD-TSN is 8 and 7 should get purged..

I don't see any problems here...

>         Then, so far, the cumulative TSN is 100. If SSN 10 of Stream 0 must be dropped, then the new Advanced.Peer.Ack.Point would be 101. However, SSN 11 of Stream 0 can be now delivered to the up…

this is why the peer must wait for the sender to tell it what to fwd-tsn
to
only paying attention to the TSN number...  

In your example if we are skipping the message represented by
TSN100/101 then the FWD-TSN will say 101.. this will leave
102 outstanding yet...

If both messages have expired then the FWD-TSN will be marked with 104.
Things in the reassembly queue would be purged to anything that was
unknown. but the 104 would be released to read...

>         The actions that must be taken upon receipt of a FORWARD TSN are quite obvious, the hard thing is to express them... :-)

Yep.. This is why the receiver must only pay attention to the TSN and
not
pay attention to the BE bits.. 

>         - Section 4.1, TR3), page 16: Maybe instead of saying that the lifetime parameter is set to "zero", it could be said that it is set to "SCTP_LIFETIME_RELIABLE", as previously defined...
hmm I don't see that TR3) says anything about 0:
"
   TR3) Before assigning a TSN to any message, the SCTP sender MUST
      evaluate the lifetime of that message.  If it is expired, the SCTP
      sender MUST NOT assign a TSN to that message, but instead, SHOULD
      issue a notification to the upper layer and drop the message.
"

do you mean TR1? And I would think TR2 has the same issue... Qiaobing
is proposing to the authors to make this more generic anyway... I think
this will show up in the next pass...still waiting for inter-author
comment
though..

>         - Section 4.2, Note, page 17: The word "the" appears between square brackets... I don't know if this is a typo or what... Little bit below, we can read "[default]", not sure if the square b…

don't know why.l. I will take it out... for the [the]

>         - A final comment about the shape of the new FORWARD TSN chunk. Have you thought about including gaps in this chunk? probably yes. It is not a TSN what becomes stale, but the whole SSN, so…

Qiaobing and I have debated this.. and after a lenghty bit of
conversation we came to the conclusion that it was un-needed. One
simply keeps what streams are pending re-ordering and that way
you have a quick way to find all the ones that the TSN is smaller
than the FWD-TSN point.

>         At this point we receive the SACK [100: (3, 4); (6, 6)] and we realize that SSNs 10 and 11 of Stream 0 have become stale. Following the draft, one should send a FORWARD TSN [101], and then…

I see what you mean but this would make the implementation quite
a bit more complex.. we were attempting to go for simplicity... I don't
think the gain is worth it.. because you will either get the ones
inbetween
or another fwd-tsn skipping... I would rather not have GAP-FWD-TSN's

R

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 24 May 2002 17:08:37 -0500

.....
> What else do you want changed?

I see Ivan's point here. Maybe we should do something like:

change the section titile to:
"
3.3.2 Receipt of Forward-TSN-Supported param in INIT or INIT-ACK
"

and add the following to the end of the section:

"
   When a receiver of an INIT-ACK detects a Forward-TSN-Supported
parameter,
   and does not support the Forward-TSN chunk type, the receiver SHOULD
   treat this parameter as an invalid or unrecognized parameter and
   respond to the data sender with an unrecognized paramater error, 
   following the rules defined in Section 3.3.3 of RFC2960 [4]. This
error 
   SHOULD be reported in an ERROR chunk bundled with the COOKIE-ECHO.
"

> you have a quick way to find all the ones that the TSN is smaller

Yes, agree with Randy here. To report gaps or a full list of "dropped"
TSNs in FORWARD TSN chunk will not be that useful because the gaps from
sender's view is not always the same as that from the receiver's view
and what really matters is what the receiver sees (this is fundamentally
different from a SACK where what is reported in a SACK is the receiver's
view). 

For example, when the sender reports a list of "dropped" TNSs, some of
the "dropped" TSNs might have already been correctly received and passed
on to the UPL. So whether the receiver will find the additional gap
information useful is unclear.

regards,
-Qiaobing