Hi Joe,
I reply to the TCP part in this mail... see below.
On 19.12.2014 00:39, 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.
Yes, but this is handled by IP and not by the transport. Therefore I believe
that does not need to be mention here...?
PathMTU discovery is supported by TCP but may be inhibited
by network conditions (ICMP blocking); PLMTUD is supposed
to be supported as well.
I added PLMTUD separately as well as the respective RFCs for both. However, I'm
not sure if we actually need to distinguish which mechanism is used than rather
just saying TCP supports path MTU discovery. (The notation in the draft current
is PathMTU discovery which references to a specific mechanism but that be
changes...).
3.1.2
TCP's API is mostly specified in RFC793.
What's missing are how options and parameters are managed.
Thanks, changed this.
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).
Yes but it is still something that TCP implements as a component. The discussion
if this component should be revealed to the application as a transport feature
should follow in the next paragraphs (which are not there yet...)
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)
Done. Somehow just forgot this...
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.
Added one sentence in section 3.1.1. and extended the connection setup up point
to
"connection setup with feature negotiation and application-to-port
mapping"
Does that make sense to you?
Mirja
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
--
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland
Room ETZ G93
phone: +41 44 63 26932
email: [email protected]
------------------------------------------
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
