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

Reply via email to