Thanks Joe, This is very much a first attempt to quickly put a little substance on the framework, to see if it can work and gather thoughts. Your read through is helpful
I'll reply just to the UDP feedback below: > Some feedback below. Although I focus on some TCP and UDP specifics, > some observations apply to other transports as well. > > Joe > > ----- <snip --- TCP part to be discussed in a separate thread> > > 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. > Sure, that's a better way to say this, > 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. > I get it, we can say that applications send a sequence of messages and that these constitute a UDP flow, that can then implement these mechanisms as an upper layer protocol. > > 3.4.2 > RFC768 describes an API for UDP. As with TCP, > it leaves out options and parameters. > I'd say "describes" is perhaps over stating this - but I accept we do need to acknowledge this REF, and probably also refer to other standards -- do you have ideas of what specific ones we should cite?, For UDP, I thought of also adding: Many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports [RFC5405]. > 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) > Yes. I'm not sure how this relates to TAPS, are you thinking that we should say "choice of port" has a bearing on whether a packet is transmitted along an end to end path by the network? Gorry > ---- > > > 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
