Hi Karen, thank you very much for the review. See my comments in-line.
Best regards Michael > On 20 Mar 2015, at 05:29, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > 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. So what about: Transport services may be provided directly by these transport protocols, or layered on top of them using protocols such as WebSockets (which runs over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS over UDP or TCP). > > #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. What about: SCTP offers a message-based service providing full or partial reliability and allowing to minimize the head of line blocking due to the support of unordered and unordered message delivery within multiple streams, ... > > #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 ? I wouldn't say that it is typically implemented with an override timer... My point was that SCTP has specific mechanisms for supporting small messages efficiently and also large messages. > Further I think that it is important to distinguish this from bundling > delay from the standard bundling of immediately available messages for > efficiency reasons. Hmm. The section describes the protocol. So I don't want to go into too much detail. So what about adding the following sentence: For example, this bundling may be done by delaying user messages at the sender side similar to the Nagle algorithm used by TCP. > > #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]. What about: ICMP-based path MTU discovery as specified for IPv4 in {{RFC1191}} and for IPv6 in {{RFC1981}} as well as packetization layer path MTU discovery as specified in {{RFC4821}} with probe packets using the padding chunks defined the {{RFC4820}} are supported. > > > #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. I'm not sure this is really guaranteed by the specs. I think unordered messages can be delivered in the order they arrive, but don't have to be. So what about changing it to User messages can be sent un-ordered or ordered upon request by the upper layer. Un-ordered messages can be delivered as soon as they are completely received. Only all ordered messages sent on the same stream ... > > #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. What about {{I-D.ietf-tsvwg-sctp-ndata}} overcomes this limitation. Furthermore, {{I-D.ietf-tsvwg-sctp-ndata}} specifies multiple algorithms for the sender side selection of which streams to send data from supporting a variety of scheduling algorithms including priority based ones. > > #8: section 3.3.1 second last paragraph: > > I note that native NAT traversal is not mentioned even though this is a wg > document. > - ? Good point. I missed that one. So what about adding at the beginning of the paragraph: {{I-D.ietf-tsvwg-ietf-tsvwg-natsupp}} defines a methods for end-hosts and middleboxes to provide for NAT support for SCTP over IPv4. > > #9: Should SCTP AUTH not be described in an individual paragraph of > section 3.3.1 ? The TCP MD-5 option is not discussed, so I thought describing SCTP-AUTH as a service might not be worth. It is used in combination with DTLS and dynamic address reconfiguration. Do you see a relevant use case for SCTP-AUTH on its own? > > #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. Well, multihoming-support is not related to the socket style. This is covered by an extra paragraph. > > #11: Section 3.3.3: > > . Perhaps one should extend the "reliable or partially reliable > delivery" to "reliable, partially reliable or un-reliable delivery" I don't use un-reliable, since I don't know what it is. What is the difference between un-reliable and partial-reliable. Bot are versions of not being reliable. > . 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. Well, this is my understanding: A sender selects * an outgoing stream * whether the message is sent ordered or unordered Both is presented in the API to the receiver. So I think the text is appropriate. > . 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 ? That is correct. Maybe Strong error detection (CRC32C) to emphasis that it is not "just" the normal checksum. > . Should SCTP Auth not be mentioned ? Depends on the point above... > . Is think flow control should simply be "flow control" (no > reference to slow receiver). Correct. > . 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 OK. > . I would replace "application PDU" with "message" Changed to user message. Thanks a lot for you comments. They help to improve the SCTP test substantially! > > > 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
