Hi, Gorry, On 12/22/2014 8:53 AM, [email protected] wrote: > I can see the merits of discussing PUSH, but if this advice is for usage > in the future, I think RFC 6093 says SHOULD NOT use, due to the range of > TCP implementations that process TCP urgent indications differently. That > makes me think it may be wise to note this perhaps, rather than just > include it as if there were not issues.
IMO, you need to explain what you're doing before you jump into recommendations for the future. The current reality is that PUSH is defined for TCP, required in implementations, and can be used by applications (SHOULD NOT != MUST NOT). As far as APIs go, though - TCP has a fairly detailed one. It's in RFC793, and it should be summarized in its entirety (including updated current recommendations) if you're going to talk about transport APIs. Joe > > Gorry > >> One additional point: >> >> TCP services described in 3.1.3 should also include PUSH and URG >> capabilities. >> >> FWIW, the specific section of RFC793 that defines the TCP interfaces - >> above and below - is 3.8. >> >> Joe >> >> On 12/18/2014 3:39 PM, Joe Touch wrote: >>> Some feedback below. Although I focus on some TCP and UDP specifics, >>> some observations apply to other transports as well. >>> >>> Joe >>> >>> ----- >>> >>> 3.1.1 >>> TCP segments fit into IP packets, but those packets are not >>> necessarily constrained to fit into a lower-layer frame. >>> They can be source fragmented. >>> >>> PathMTU discovery is supported by TCP but may be inhibited >>> by network conditions (ICMP blocking); PLMTUD is supposed >>> to be supported as well. >>> >>> 3.1.2 >>> TCP's API is mostly specified in RFC793. >>> >>> What's missing are how options and parameters are managed. >>> >>> 3.1.3 >>> TCP provides a byte-ordered reliable stream. How that >>> is delivered - e.g., by segments - is irrelevant, if only >>> because TCP can change those segment boundaries during >>> operation (e.g., with path MTU updates). >>> >>> this section should also mention flow control - TCP >>> doesn't dump data on the floor if the receiver >>> can't process it fast enough (vs. UDP) >>> >>> additionally, the ports ought to be discussed in more detail. >>> ports in the SYN have a different meaning that ports in other >>> segments. The SYN destination port indicates the receiving >>> ` service, which typically involves BOTH demuxing to a process >>> within a host AND indicating the format of the stream. Ports >>> there and in all other segments are only demultiplexing >>> indicators. >>> >>> 3.4.1 >>> UDP doesn't fragment packets into IP packets; it maps to >>> a single IP packet, which itself may be fragmented. The >>> IP fragments are what are limited by the lower-layer >>> frames. >>> >>> Because UDP is connectionless, if you're going to talk >>> about properties of sequences of messages, you need to >>> explain what that sequence is - i.e., you need to >>> define what it means to have a UDP flow, and only >>> such flows are subject to flow/congestion control, >>> PMTUD, etc. >>> >>> >>> 3.4.2 >>> RFC768 describes an API for UDP. As with TCP, >>> it leaves out options and parameters. >>> >>> 3.4.3 >>> should include port demuxing here too, with the same >>> caveats as noted above for TCP (i.e., ports for >>> messages have multiple meanings) >>> >>> ---- >>> >>> >>> On 12/18/2014 6:44 AM, Brian Trammell wrote: >>>> Greetings, all, >>>> >>>> We've posted a -01 rev of the TAPS transports document. We believe that >>>> the format and level of detail for the TCP section is about what we're >>>> targeting for each of the other sections, but this is still open to >>>> discussion. The document also includes at least a little text on most >>>> of the transport protocols identified in the -00 revision. Welcome also >>>> to Mirja Kühlewind, added as an additional editor. >>>> >>>> If there are any additional transport protocols we're missing, or other >>>> comments on document structure, please send them to the list. >>>> >>>> Document source is available (with a kramdown-rfc2629-based workflow) >>>> at https://github.com/britram/taps-transports. Feel free to send pull >>>> requests against the markdown, or XML/text diffs to the editors, for >>>> contributions to sections of the document. >>>> >>>> Cheers, and merry Christmas, >>>> >>>> Brian >>>> >>>>> On 18 Dec 2014, at 15:06, [email protected] wrote: >>>>> >>>>> >>>>> 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-01.txt >>>>> Pages : 15 >>>>> Date : 2014-12-18 >>>>> >>>>> 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-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 >>>>> >>>>> >>>>> 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 >>>> >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
