hi Karen, Thanks for the comments and review! Commentcomments inline, anything not remarked on is accepted into -08 as-is.
> On 28 Oct 2015, at 13:16, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > 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]. It does seem to me that CC algorithms as deployed in the Internet are somewhat orthogonal to the mechanics of the underyling transport protocol, so this is probably not a bad idea... I'll have a look at how this could be easily refactored out of the document, probably into a new section 4 (before the present section 4)... > 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 ? I've never seen it treated as one; to my knowledge inconsistent treatment has led to PSH being largely ignored/ignorable, but there are probably people with more thorough knowledge on this list... > The urgent flag is not recommended ... so does it belong here ? It does provide a (not very functional) out of order delivery mechanism, though its deprecation should be referenced here here. Will do so in -08. > Section 4.1: Section 4.1 has been removed, in the interests of getting the document out the door. The hierarchical list in Section 4 replaces it. > I wonder if SCTP Reliability could be Full/Partial/None This is captured in the present (GitHub) revision of the list. > I wonder if unordered delivery should be added as a row. Unordered delivery is an entry in the list. > I am not sure if ECN for SCTP should be marked as TBD. Applicability of > RFC3168 to SCTP is described in RFC4960. We don't have a line item for ECN in the list yet, perhaps we should. > I personally don’t know of any deployment of this. By "no deployment" you mean "no implementation" or "it's not turned on"? Thanks again, cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
