BTW, My personal opinion is that this document, in this version, is very good and serves well the purpose of providing a comprehensive survey of the services provided with a number of the IETF transport protocols.
I do note, however, that the title of the document puts bigger emphasis on congestion control than the document content as such. I further, personally, consider the document draft-welzl-taps-transport as a good, and necessary, supplement going more into the details of the existing transport service interface(s). Thanks. BR, Karen > -----Original Message----- > From: Karen Elisabeth Egede Nielsen [mailto:[email protected]] > Sent: 28. oktober 2015 13:16 > To: '[email protected]'; 'Brian Trammell'; 'Mirja Kühlewind'; Michael Tuexen > ([email protected]) > Subject: RE: [Taps] I-D Action: draft-ietf-taps-transports-07.txt > > 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:[email protected]] On Behalf Of internet- > > [email protected] > > Sent: 7. oktober 2015 12:43 > > To: [email protected] > > Cc: [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
