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

From: [email-masked]
Date: Thu, 18 Dec 2014 06:06:55 -0800

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/

---

From: Brian Trammell <[email-masked]>
Date: Thu, 18 Dec 2014 15:44:51 +0100

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

---

From: Michael Welzl <[email-masked]>
Date: Fri, 19 Dec 2014 08:37:32 +1100

Hi,

Thanks for this update!

A question:

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

Why is Nagle not a part of the protocol components and interface description? It’s mentioned in the protocol description above, and it’s something that an application decides.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Dec 2014 15:39:59 -0800

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)

----

---

From: [email-masked]
Date: Fri, 19 Dec 2014 07:06:33 -0000

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

> some observations apply to other transports as well.

<snip --- TCP part to be discussed in a separate thread>

> 	IP fragments are what are limited by the lower-layer
Sure, that's a better way to say this,

> 	such flows are subject to flow/congestion control,
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.

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

> 	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

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

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Dec 2014 10:05:23 +0100

> On 18 Dec 2014, at 22:37, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
> Thanks for this update!
> 
> A question:
> 

Simple omission.

Should we make an attempt to give this (as a component) a generic name? "Selectable sender side buffering"? Or can we just call it simply "Nagle"?

Thanks, cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 19 Dec 2014 20:29:52 +1100

> On 19. des. 2014, at 20.05, Brian Trammell <[email-masked]> wrote:
> 
> 

In http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf we took SCTP's term for the same function because we found it more meaningful than "Nagle": Application PDU Bundling.  I like that - it's also perhaps useful to folks to reuse terminology when we mean the exact same thing.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 19 Dec 2014 20:35:43 +1100

> On 19. des. 2014, at 20.29, Michael Welzl <[email-masked]> wrote:
> 
> 

Very sorry for writing a separate email! But having this open made me notice another one: "error detection" (or "integrity check", whatever you prefer). There's a checksum, it can't be disabled, it's covering the full data. Different from some other protocols.

And another: flow control. Mentioned in the text, but should be a component because the feature that it implements is meaningful to an application (if there's no flow control, you may have to take care of it yourself).

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Dec 2014 15:13:46 +0100

hi Michael,

> On 19 Dec 2014, at 10:29, Michael Welzl <[email-masked]> wrote:
> 
> 

So I'd argue that (1) this isn't *exactly* the same thing, as the interface to SOCK_SEQPACKET has application PDU preservation as an explicit part of the API contract, while SOCK_STREAM does not, but (2) that at the protocol level it might as well be, so "bundling" is exactly the right word. How about "sender segment bundling" for TCP?

Thanks, cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Dec 2014 15:14:44 +0100

> On 19 Dec 2014, at 10:35, Michael Welzl <[email-masked]> wrote:
> 
>> 

Yep, both excellent points. Will add to working -02.

Thanks, cheers,

Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Dec 2014 11:17:01 -0800

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

---

From: Michael Welzl <[email-masked]>
Date: Sat, 20 Dec 2014 09:08:43 +1100

> On 20. des. 2014, at 01.13, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 
> So I'd argue that (1) this isn't *exactly* the same thing, as the interface to SOCK_SEQPACKET has application PDU preservation as an explicit part of the API contract,

Ahh… let me see if I get this right: your point is, in terms of the actual function, the difference is:
SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out of which 3 may fit into a 1460-byte segment and get shipped together after an RTT, wasting space for 110 bytes.
TCP: app gives the same app PDUs into the send buffer, where they are treated as a byte stream and a segment of 1460 bytes can be exactly filled.

If that’s it, then I agree, that’s functionally different.

> while SOCK_STREAM does not, but (2) that at the protocol level it might as well be, so "bundling" is exactly the right word. How about "sender segment bundling" for TCP?

Ok by me, but we'll have to be careful later: when trying to unify access to these services across protocols, the two different names for SCTP and TCP may make it seem like they are entirely different in functionality when in fact they are not much different indeed: TCP’s Nagle operates on single bytes, SCTP’s app PDU bundling operates on potentially larger blocks of a given size?

What about: “data bundling (1 byte)”, as opposed to “data bundling (application PDU)”  for SCTP ?

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 19 Dec 2014 23:24:54 +0100

> SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out of which 3 may fit into a 1460-byte segment and get shipped together after an RTT, wasting space for 110 bytes.
I guess the 1460 are related to the IP and TCP header.
For SCTP it would be 
20 bytes for IPv4 header,
12 bytes for the SCTP common header,
16 bytes for the DATA chunk header,
450 byte payload
16 bytes for the DATA chunk header,
450 byte payload
16 bytes for the DATA chunk header,
450 byte payload
This gives 1430 bytes.
So 70 bytes are left. The SCTP implementation can just leave them unused or, and that is the point I want to make,
add
16 bytes for the DATA chunk header
54 bytes (the initial 54 bytes of the fourth 450 bytes user message)
Then the frame is completely used.
> What about: “data bundling (1 byte)”, as opposed to “data bundling (application PDU)”  for SCTP ?
I wouldn't object against using the term Nagle also for SCTP. It refers to delaying the initial
sending of user message in case of outstanding data. Bundling in SCTP might happen even when
Nagle is turned off, for example when you retransmit messages.

Best regards
Michael

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Dec 2014 23:24:30 +0100

> Ahh… let me see if I get this right: your point is, in terms of the actual function, the difference is:

I was trying to make a much less subtle point from the interface side: since SCTP actually _has_ a concept of application PDU, it can bundle them, while TCP has no such concept, so what it's bundling can't really be PDUs.

> SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out of which 3 may fit into a 1460-byte segment and get shipped together after an RTT, wasting space for 110 bytes.

sending app gives PDUS 1,2,3,4 via sendto(), receiver calls recvfrom() four times and gets four PDUs.

> TCP: app gives the same app PDUs into the send buffer, where they are treated as a byte stream and a segment of 1460 bytes can be exactly filled.

sending app writes PDUS 1,2,3,4 via write(), receiver gets some bytes from read(), and must either (1) know how large each PDU is in advance or (2) use some framing information in the byte stream to figure this out.

> What about: “data bundling (1 byte)”, as opposed to “data bundling (application PDU)”  for SCTP ?

"Data bundling" unqualified is just fine by me.

Cheers,

Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Dec 2014 14:40:20 -0800

On 12/19/2014 2:24 PM, Brian Trammell wrote:
...
> I was trying to make a much less subtle point from the interface side:
> since SCTP actually _has_ a concept of application PDU, it can bundle
> them, while TCP has no such concept, so what it's bundling can't really
> be PDUs.

TCP has three notions of application interaction regarding user data
boundaries:

	- a bytestream
		at which point the entire stream is the user API PDU
		(that's why CLOSE implies EOF; it's really
		"end of stream")

	- URG
		a one-bit flag that is an offset into the bytestream

	- PSH

Of these, only the first two provide user-level "PDU" information. The
last is essentially a flow-control signal.

However, because of how URG works, it's not useful as an intra-stream
marker (it is set for all segments between when activated and not).

So I wouldn't say that TCP has no concept of an application PDU. What it
lacks are internal PDU boundaries. The stream itself is the PDU.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Sat, 20 Dec 2014 10:14:42 +1100

> On 20. des. 2014, at 09.24, Michael Tuexen <[email-masked]> wrote:
> 
> On 19 Dec 2014, at 23:08, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 

Silly me, yes of course I was thinking of TCP while actually talking about SCTP  :)

> Then the frame is completely used.

Ah, ok. I wasn’t aware of that. Is that decision up to the application?

> Nagle is turned off, for example when you retransmit messages.

I like Brian’s proposal of unqualified “data bundling” - it is just a bit more meaningful than “Nagle” (despite the historic relevance of the latter).

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 20 Dec 2014 09:53:01 +0100

> Ah, ok. I wasn’t aware of that. Is that decision up to the application?
Not via the socket API as it is defined right now.
> I like Brian’s proposal of unqualified “data bundling” - it is just a bit more meaningful than “Nagle” (despite the historic relevance of the latter).
OK. Then in both cases the application can't turn it off. Using TCP_NODELAY or SCTP_NODELAY just
affects it.

Best regards
Michael

---

From: [email-masked]
Date: Mon, 22 Dec 2014 16:53:28 -0000

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.

Gorry

>>> 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.
>>>
>>> Document source is available (with a kramdown-rfc2629-based workflow)
>>> at https://github.com/britram/taps-transports. Feel free to send pull

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Dec 2014 12:13:13 -0800

Hi, Gorry,

> 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