HI, Please accept the following comments. Use them as/if you see fit. (Given my wretched, non-twistable, arms you are allowed not to take them too seriously)
Section 3.1.1: 6'th paragraph: " In addition, a congestion control mechanism may react to changes in delay as an early indication for congestion." I think one will need to give a reference to this as it is not covered by the reference to RFC5681. Possibly this statement is better given in the context of the next paragraph referring to extensions. [I am aware that I have given this comment before. The reason that this continues to be an issue for me is that delay based CC alg's also are applicable to, e.g., SCTP (and have been applied there, though I don't know much about real deployment of them for SCTP). I am not sure if the solution to this is to have a special common section about congestion control algorithms - referring possibly to that these special CC als mostly are in deployment for TCP]. 9'th paragraph: Reference to push flag: The sentence: "TCP provides a push and a urgent function to enable data to be directly accessed by the receiver without having to wait for in-order delivery of the data." Should be revised I think. It is not very clear what the push flag contribute with in this sentence. The PUSH flag helps to release a "tail" packet from a TSO/GRO function/temporary packet buffering function. This feature of TCP might be significantly enough to describe the PUSH flag function as an implicit and internal protocol implementation optimization making TCP "push" tails through intermediate buffering functions. But the PUSH function is not really a "function" that TCP stacks provide to the ULP today (even if this is described as an optional possibility in RFC1122) - Or is it ? The urgent flag is not recommended ... so does it belong here ? Section 3.3: 1'st Paragraph: I propose to remove the sentence: "It also optionally supports path failover to provide resilience to path failures." There is no optionality about it and I think it is covered in the sentence before on supporting MH to handle path failures. In sentence: "An SCTP association has multiple unidirectional streams in each direction and provides in- sequence delivery of user messages only within each stream." ^^^ I propose to remove the word "only". I suggest to add the following sentence: "SCTP supports multiple stream scheduling schemes controlling the multiplexing of the streams into the transmission channel. Including priority as well as fair weighting schemes." Section 3.3.1: I propose to add the following sentence in the end of the paragraph on multi-homing below the bulleted list: "[I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation reducing the latency of the failover". Inserted before the last sentence as follows: "If a remote address becomes unreachable, the traffic is switched over to a reachable one, if one exists. [I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation reducing he latency of the failover. Each SCTP end-point supervises continuously the reachability of all peer addresses using a heartbeat mechanism." Section 3.3.2: First bullet: "In case of send failures that application .. " --> propose to replace with "In case of send failures, including drop of messages sent unreliably, the application " Third last paragraph: snet --> sent Section 3.3.3. Suggest to replace: fully reliable or partially reliable delivery --> with --> fully reliable, partially reliable and unreliable delivery Section 4.1: I wonder if SCTP Reliability could be Full/Partial/None I wonder if unordered delivery should be added as a row. I am not sure if ECN for SCTP should be marked as TBD. Applicability of RFC3168 to SCTP is described in RFC4960. I personally don’t know of any deployment of this. BR, Karen > -----Original Message----- > From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of internet- > dra...@ietf.org > Sent: 7. oktober 2015 12:43 > To: i-d-annou...@ietf.org > Cc: taps@ietf.org > Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.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-07.txt > Pages : 53 > Date : 2015-10-07 > > 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: > https://tools.ietf.org/html/draft-ietf-taps-transports-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-07 > > > 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 > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
