Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 30 Jan 2015 12:46:39 +0100

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-masked] 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-masked]
>>> https://www.ietf.org/mailman/listinfo/taps
>>
>> _______________________________________________
>> Taps mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/taps
>>
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> 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-masked]
------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Jan 2015 11:23:02 -0800

Hi, Mirja,

On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
> Yes, but this is handled by IP and not by the transport. Therefore I
> believe that does not need to be mention here...?

The problem is in the first sentence:

    TCP partitions a continuous stream of bytes into segments, sized to
    fit in IP packets, constrained by the maximum size of lower layer
    frame.

The first part is true (TCP fits into IP), but the second is not (IP is 
NOT constrained by the max size of the lower-layer frame). IP is 
constrained only by the ability of IP (i.e., of L3 to reassemble at the 
destination).

> 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...).

"Path MTU discovery" is ambiguous; it can refer to any mechanism that 
allows the path MTU to be known, or it can refer to the specific 
mechanism by that name in RFC 1191.

If you mean the more general concept, it would be better to use a term 
that is unambiguous in referring to both (e.g., discovery of the path 
MTU). Once you tie the words together as "path MTU discovery", it could 
be misinterpreted as meaning only RFC 1191.

However, IMO, in this doc it would be better to be more clear and 
explicit by naming both mechanisms.

...
> Yes but it is still something that TCP implements as a component.

TCP definitely does not. There is no required correlation between SEND 
boundaries and segment boundaries.

Some TCP implementations do, but there is nothing to ensure that 
boundaries controlled by the sending application are exposed to the 
receiving application.

I don't think this doc should discuss how implementations go astray in 
this way.

...
> Does that make sense to you?

The sentence does, but that doesn't sufficiently (IMO) address the 
feedback I gave above.

TCP has two portions:
	- connection establishment
		feature negotiation
		service-to-port mapping
		connection identification

	- established connection data transfer
		which continues to use the connection identifier

Joe