Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
RFC 3758
Yes
(Allison Mankin)
(Jon Peterson)
No Objection
(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Harald Alvestrand)
(Margaret Cullen)
(Ned Freed)
(Russ Housley)
Note: This ballot was opened for revision 03 and is now closed.
Allison Mankin Former IESG member
Yes
Yes
()
Unknown
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Thomas Narten Former IESG member
(was Discuss)
Yes
Yes
(2003-12-18)
Unknown
Nits: > Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > protocol extended as defined in this document. Spell out "partially reliable" above so folk make the connection with PR. > Comparisons and arithmetic on TSNs are governed by the rules in > Section 1.6 of RFC2960 [3]. expand TSN on first usage. > services as required. Each such service may be proposed as a > separate new informational RFC. Better to drop "informational". Point is to publish each one as separate document. The exact type of document doesn't need to be specified here, though I suspect info will be the normal case. But it isn't a requirement. same comment applies elsewhere in document. > Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s s/.s/s./ > 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 parameter in the > INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960 > [3]. > > 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 > parameter error, following the rules defined in Section 3.3.3 of > RFC2960 [3]. This error SHOULD be reported in an ERROR chunk bundled > with the COOKIE-ECHO. Seems odd for this document to seem to be saying what to do if you don't understand the new extensions (that is what I intepret when I see MUST langague like the above). I suspect the text that is here is just being copied verbatim from the base SCTP spec. It would be better to make to make it clear that this is already the required behavior per 2960, and either quote the text (for info) or just point to the other document.
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
(2003-12-18)
Unknown
From OPS Directorate (Pekka) Nits Abstract This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [3] that allows an SCTP endpoint to signal to ==> remove the refs from the abstract. [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. ==> this can be removed, isn't even being used. 8. IANA Considerations One new chunk type is added to SCTP (192) by this document. One new parameter type code is defined by this document to be added to SCTP (49152). ==> well, technically, IANA is registering these codes and types, not you guys :-). So these should be reworded to be like: "IANA is requested to assign a new chunk type to SCTP; using "192" is recommended". But I'm not sure if this is really needed :-) Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s ==> s/.s/s./
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Steven Bellovin Former IESG member
No Objection
No Objection
(2004-02-19)
Unknown
-
Ted Hardie Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2003-12-16)
Unknown
Section 3.6 says: Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating ordered delivery) and is out of order, the receiver must hold the chunk for reordering. Since it is possible with PR-SCTP that a DATA chunk being waited upon will not be retransmitted, special actions will need to be taken upon the arrival of a FORWARD TSN. In particular, during processing of a FORWARD TSN, the receiver MUST use the stream sequence information to examine all of the listed stream reordering queues, and immediately make available for delivery stream sequence numbers earlier than or equal to the stream sequence number listed inside the FORWARD TSN. Does the U bit here have a secondary expectation that when ordering is requested, eventual delivery will be better than a drop? If so, is there any way to indicate that what you want is ordered delivery, but drop CHUNKS not yet delivered if the FORWARD TSN is received? In Section 4, can I suggest "standardized in an informational RFC." be replaced with "documented in an Informational RFC?" (By the way, would we object to someone asking for standards track to one that had been specified in a WG?) Lastly, the document seems to make the design choice that using something liked "timed reliability" is something that the sender decides based on the availability of Forward TSN as a primitive, and that there is no sense in which the receiver ought to decide whether to support Forward TSN based on which of these PR-SCTP services it would be used with. Fair enough, but if there is motivational text laying about that could describe that design decision process, it would be valuable to add it. It's probably not worth the sweat of cooking up, though, if it is not available already.