HI, Please accept the following comments to the SCTP section.
Generally I think that the section is extremely well written and touches on the majority of significant SCTP transport service aspects. I have some minor nits for consideration for the next update: #1: Section 1, Second paragraph: In the context of web-sockets over TCP and RTP over UDP one might refer to RTCWEB data channel usage of SCTP, but I also recognize that this may not strike the right balance towards the other more widely used services. #2: Section 1, Third paragraph: One could reformulate: for instance, SCTP offers a message-based service that does not suffer head-of-line blocking when used with multiple stream, because it can accept blocks of data out of order, --> for instance, SCTP offers a reliable ordered message-based delivery service that, when used with multiple streams, mitigates the effects of head-of-line blocking, because head-of-line blocking is confined to the individual stream. One might even also, but not sure if this is equally important, rely to that SCTP offers the service of reliable un-ordered delivery: --> for instance, SCTP offers a reliable unordered message delivery which does not suffer from head-of-line blocking as well as a reliable ordered message-based delivery service that, when used with multiple streams, mitigates the effects of head-of-line blocking, because head-of-line blocking is confined to the individual stream. #3: Section 3.3.1: Fourth paragraph. Bundling: Would it be relevant to refer to that sender side bundling delay typically is (or may be) implemented as Nagle bundling with an override timer ? Further I think that it is important to distinguish this from bundling delay from the standard bundling of immediately available messages for efficiency reasons. #4: Section 3.3.1: Fourth paragraph. PMTUD: Should the text not refer also to RFC1191 and RFC1981. Possibly as: ICMP-based PathMTU discovery [RFC1191][RFC1981] as well as Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] are supported. [RFC4821] defines a method to perform packetization layer path MTU discovery for SCTP with probe packets using the padding chunks defined the [RFC4820]. #5: Section 3.3.1: 6th paragraph: Perhaps one could elaborate: Only all ordered messages sent on the same stream are delivered at the receiver in the same order as sent by the sender. --> Only ordered messages sent on the same stream are delivered at the receiver in the same order as sent by the sender. Un-ordered messages (any stream) are delivered at the receiver in the order they arrive, conditional to message reassembly having been performed. #6: Section 3.3.1: 6th paragraph: Schedular and prioritizations of streams. I think this could be a potential very important feature for SCTP (for signaling) and that it deserves to be mentioned in its own right. What about the following change: [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and also allows to specify a scheduler for the sender side streams selection. --> [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. [I-D.ietf-tsvwg-sctp-ndata] further allows to specify different stream schedulers for the sender side selection of which streams to transmit from, thereby allowing for various priority schemes for the sender side transmittal. #8: section 3.3.1 second last paragraph: I note that native NAT traversal is not mentioned even though this is a wg document. - ? #9: Should SCTP AUTH not be described in an individual paragraph of section 3.3.1 ? #10: Section 3.3.2: Perhaps reformulate: One-to-one style sockets are similar to TCP sockets, there is a 1:1 relationship between the sockets and the SCTP associations (except for listening sockets). One-to-many style SCTP sockets are similar to unconnected UDP sockets as there is a 1:n relationship between the sockets and the SCTP associations. --> One-to-one style sockets are similar to TCP sockets, there is a 1:1 relationship between the sockets and the SCTP associations (except for listening sockets). The major difference to TCP is that the SCTP associations can span multiple local and remote addresses. One-to-many style SCTP sockets have some similarity with unconnected UDP sockets as there is a 1:n relationship between the sockets and the SCTP associations endpoints. #11: Section 3.3.3: . Perhaps one should extend the "reliable or partially reliable delivery" to "reliable, partially reliable or un-reliable delivery" . I am a little unsure about the "unordered delivery within a stream" - I know that one can read the stream that an ordered messages was received from, but if that it enough to qualify for delivery "within a" stream I am not sure. . Integrity check refers to checksum. In the TCP Transport Protocol Components list this is listed as error detection. One should use aligned semantics - I think ? . Should SCTP Auth not be mentioned ? . Is think flow control should simply be "flow control" (no reference to slow receiver). . I think the support for multiple prioritized streams should be split into two bullets: o Support for multiple concurrent streams o Support for stream scheduling prioritization . I would replace "application PDU" with "message" BR, Karen >-----Original Message----- >From: Taps [mailto:[email protected]] On Behalf Of internet- >[email protected] >Sent: Friday, February 27, 2015 1:52 PM >To: [email protected] >Cc: [email protected] >Subject: [Taps] I-D Action: draft-ietf-taps-transports-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Services Working Group of the IETF. > > Title : Services provided by IETF transport protocols and congestion >control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-03.txt > Pages : 25 > Date : 2015-02-27 > >Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-taps-transports-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03 > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Taps mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
