Re: [Taps] Stream vs. packet

[Joe Touch]

On Jun 30, 2014, at 2:53 PM, Michael Welzl  wrote:

> 
> On 30. juni 2014, at 19:03, Joe Hildebrand (jhildebr)  
> wrote:
> 
>> On 6/27/14, 8:45 AM, "Michael Welzl"  wrote:
>> 
>>> Can we try to make a simple decision here, as a group, to never even
>>> really consider streams at all?
>>> 
>>> 
>>> It seems to me to be straightforward to provide a stream-based transport
>>> over a message-based transport, so this is something that can simply
>>> always be done. Thus, can we just write a disclaimer in one of our
>>> documents, recommending that any TAPS-supporting
>>> systems can provide stream-based transport on top of the message based
>>> transport too, but that its users must be aware of limitations that arise
>>> from streams (such as HOL blocking delay, no ALF, ..)?
>> 
>> Maybe, if we also have:
>> 
>> - retransmission
>> - order preservation
>> - optional nagle-ish grouping
>> - optional FEC
>> - whatever else I'm missing
>> 
>> At which point it might be straightforward to build a stream, but we still
>> might want to suggest how to combine the characteristics together into a
>> larger bit of functionality.
> 
> Sure; you can do all these things with messages, but it's harder or in some 
> cases impossible with streams. You can turn much into a stream but not vice 
> versa. Case in point: Minion - by merely introducing a marker in the byte 
> stream that separates messages, all kinds of good things become possible.

Messages can be turned into streams and streams can be turned into messages, 
but there's an efficiency cost when the application data model doesn't match 
the network data model.

However, there's a lot more to life than just messages or streams, i.e., that's 
only 2 of many alternatives.

Joe
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Stream vs. packet

[Joe Touch]

On 7/11/2014 7:53 AM, Fred Baker (fred) wrote:

This discussion is as old as TCP. One can build a message interface on a
stream interface (RFCs 1006 and 2126) and a stream interface on a packet
interface.


Except for efficiency. A messages on streams can induce delays for 
reordering and error recovery that the messages might be able to tolerate.


I.e., that's why we have DCCP and SCTP alternatives.

> When I want to send a large message, such as a file, the

difference between the two is difficult to discern: either way one
slices that cookie, one has a lot of transport PDUs being sent; the only
real difference is at the receiving end, which might want to receive the
stream as it arrives or the message when it has completely arrived.


Even when you send a file, there is a difference depending on the errors 
and reordering in the stream. If the source is stable (not ephemeral) 
and has no cost to the order of access, the most efficient way is to 
send the entire file and go back to fill in the holes as you go. Other 
ways induce stalls to ensure that the window 'in memory' is small, which 
made sense when RAM was costly.


I.e., there are a LOT of trade-offs in the overall system, and it 
depends on way the *entire* system is being used as a whole.



IMHO, the API will do well to let the client advise it regarding what
type of interface it wants, and go with it.


+1

Joe




On Jun 27, 2014, at 7:45 AM, Michael Welzl mailto:mich...@ifi.uio.no>> wrote:


Hi,

I changed the subject because this is not about the chartering
discussion anymore - it's beginning our work   :-)


Toby, in his last email, raised the following question:

On 27. juni 2014, at 16:21, Toby Moncaster
mailto:toby.moncas...@cl.cam.ac.uk>> wrote:

[snip]



- message atomicity


What's that? That multiple messages are not combined into one
packet? This plays a role for an application only when there is
significant loss (I think). Wouldn't it be nice to have a system
that provides atomicity only when needed and otherwise saves header
overhead? I would vote against exposing that. Either way, I vote it
off the list that goes in the charter, it's not an obvious service
to me.


To some extent I agree here. But is there any way we can correctly
express the differences between stream and packet oriented transports?


Can we try to make a simple decision here, as a group, to never even
really consider streams at all?

It seems to me to be straightforward to provide a stream-based
transport over a message-based transport, so this is something that
can simply always be done. Thus, can we just write a disclaimer in one
of our documents, recommending that any TAPS-supporting systems can
provide stream-based transport on top of the message based transport
too, but that its users must be aware of limitations that arise from
streams (such as HOL blocking delay, no ALF, ..)?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org 
https://www.ietf.org/mailman/listinfo/taps




___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps



___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

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, internet-dra...@ietf.org 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
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
> 

___

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

[Joe Touch]

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

On 12/18/2014 3:39 PM, 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.
> 
>   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, internet-dra...@ietf.org 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.
>>&

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

[Joe Touch]

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

Hi, Gorry,

On 12/22/2014 8:53 AM, go...@erg.abdn.ac.uk wrote:
> 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.

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


> 
> Gorry
> 
>> 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
>>
>> On 12/18/2014 3:39 PM, 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.
>>>
>>> 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
>>>>

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

[Joe Touch]

Hi, Mirja,

On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:

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


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



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


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


...

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.


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.


...

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?


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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 1/30/2015 7:20 AM, Wolfgang Beck wrote:

Would it make sense to include statements about latency?


Yes, but I'm not sure what at this point.

Latency is a multidimensional property; it depends on the interaction of 
a variety of factors, so even if you wanted to have the application say 
"I want low latency", that's not well-defined.



We recently had a discussion with one of our suppliers about application
layer timeouts that fired while the request was still stuck in the send
queue.

There were statements like 'UDP never queues' or 'we can't control the
TCP send buffer size'.


UDP doesn't queue, but UDP implementations do. The interface between 
applications and UDP does too.



Maybe some general discussion of the interactions between application
layer timers and transport layer retransmission strategies (like Nagle)
would be useful.


That's a really good example of how poorly understood this problem is.

Nagle should be off for multi-byte transaction protocols using TCP, but 
TCP isn't a low-latency protocol to start with. Nagle is as much about 
minimizing short packets as it is about the effect on transaction 
interaction delay.


However, it's also well-understood that Nagle should be off for 
transactions involving multiple bytes - whether that's because the 
transaction itself is larger (e.g., web transactions) or because the 
character encoding is larger (e.g., telnet using Unicode rather than 
ASCII). (J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance 
of HTTP Over Several Transport Protocols,” IEEE/ACM Transactions on 
Networking, V5, N5, Oct. 1997, pp.616-630.)


The fact that TCP doesn't have a way for the application to signal a 
transaction boundary (it's a byte stream model) means that the entire 
issue of latency of transactions over TCP is questionable.


--

So, in summary, yes, an API from transport to the service layer should 
have an indication of latency, but this is a very complex, 
*bidirectional* interface. So other than saying that this should be 
addressed in the future, anything said now will be at best woefully 
incomplete, and at worst, wrong.


Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 2/2/2015 12:48 PM, Michael Welzl wrote:

So, in summary, yes, an API from transport to the service layer
should have an indication of latency, but this is a very
complex,*bidirectional*  interface. So other than saying that this
should be addressed in the future, anything said now will be at
best woefully incomplete, and at worst, wrong.

>

I’m for keeping this first document correct and complete.


In that case, I suggest that latency issues be listed under "TBD". The 
only way to deal with them currently is via interfaces that describe HOW 
an existing mechanism is to be configured, not WHAT the goal of that 
configuration is.


Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

Hi, Mirja,

On 2/4/2015 8:59 AM, Mirja Kühlewind wrote:
> Hi Joe.
> 
> see below...
> 
> On 30.01.2015 20:23, Joe Touch wrote:
>> Hi, Mirja,
>>
>> On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
>>> 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...?
>>
>> 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).
> 
> Okay, I've just removed the second part of the sentence to avoid
> confusion because it is actually not important in this doc. That's okay
> for you?

Sure.

>>>>  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...).
>>
>> "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.
> 
> K. Done.
> 
>>
>> ...
>>>> 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.
>>
>> 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.
> 
> I think this is again a terminology problem. We agreed that a (transport
> protocol) component is something that a transport protocol implements. I
> don't think there are any TCP implementations that do not implement
> segmentation...? So it's a component.

TAPS describes the services that transports provide to applications (as
per the charter).

The details of how that service is implemented internally are not
relevant because they're not exported as part of that service interface.

Although TCP uses segments to talk to other TCPs, TCP is not required to
export or import the segment boundary to the application.

> A transport feature is something that you would reveal to the
> application.

A transport feature is something you *can* reveal to the application.
The spec for TCP allows implementations to segment data in different
ways and still interconnect just fine.

> This is currently not the case and will probably also in
> future not be the case for segmentation. (However if you would want to
> reveal it, the fu

Re: [Taps] agenda topic: application - transport abstractions

[Joe Touch]

On 2/4/2015 2:55 PM, Marie-Jose Montpetit wrote:

Well one reason I started being interested in TAPS was because of the
video and of course the multisource version (video for example combining
streaming, download, multimedia and social networking). For these use
cases you need to be able to specify delay, loss (to avoid or minimize
buffering events)


For a streaming source, delay can be described (time offset, time offset 
variation). That is simple only for real-time streaming live, 
bidirectional content.


When you start including the size of the message - whether as a single 
bulk transfer, or the ability to buffer large amounts of it (for 
recorded content), then the size of the message is inherent in the 
notion of latency. You can't ask the network how long something will 
take if you don't tell it how big it is.



I could think in extreme cases even path (or
multipath).


I've said this before in MPTCP, but please don't confuse endpoint with 
path here. Same endpoints can mean different path, and using multiple 
endpoints is no guarantee of independent paths.


> So a way to abstract the services that could be summarized

into “give me the best video now” would be very useful for all new
video-based apps out there.


What would "give me the best video now" mean to the transport layer?

Completely different things for Netflix, Vine, and Skype.

In summary, we need a better way to describe the services we want before 
we'll ever be able to expect the transport to handle them properly.


Joe


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt

[Joe Touch]

On 3/4/2015 6:10 PM, Simone Ferlin-Oliveira wrote:
> Greetings,
> 
> Sections 3.2 and 3.3 in draft-03 remind us that there are
> commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They
> could be further summarised, perhaps in a dedicated session to
> “multi-path features”, abstracting what both protocols provide to
> applications. It could be, for example, inside section 4 as
> subsection.

These are multi-endpoint features. Despite the name of MPTCP and the
fact that this has been pointed out repeatedly to them, let's please not
continue to mislabel this as multi-path.

Joe

> 
> If the group agrees with that, we would like to take it (Section 4) as
> contributors.
> 
> Thanks,
> Simone Ferlin and Olivier Mehani
> 
> On 27 February 2015 at 23:58, Brian Trammell  wrote:
>> Greetings, all,
>>
>> We've posted rev -03 of the taps-transports document; this includes a new 
>> Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP by Kevin 
>> Fall; thanks Michael and Kevin!
>>
>> Comments on the new sections or the structure thereof (i.e., as input to 
>> future transport protocol sections), or indeed on anything else in the 
>> document, are very welcome. :)
>>
>> Thanks, cheers,
>>
>> Brian
>>
>>> Begin forwarded message:
>>>
>>> From: internet-dra...@ietf.org
>>> To: "Gorry Fairhurst" , "Mirja Kuehlewind" 
>>> , "Brian Trammell" , 
>>> "Mirja Kuehlewind" , "Godred Fairhurst" 
>>> , "Brian Trammell" 
>>> Subject: New Version Notification for draft-ietf-taps-transports-03.txt
>>> Date: 27 Feb 2015 13:52:23 CET
>>>
>>>
>>> A new version of I-D, draft-ietf-taps-transports-03.txt
>>> has been successfully submitted by Brian Trammell and posted to the
>>> IETF repository.
>>>
>>> Name: draft-ietf-taps-transports
>>> Revision: 03
>>> Title:Services provided by IETF transport protocols and 
>>> congestion control mechanisms
>>> Document date:2015-02-27
>>> Group:taps
>>> Pages:25
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-03.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/
>>> Htmlized:   http://tools.ietf.org/html/draft-ietf-taps-transports-03
>>> Diff:   
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> The IETF Secretariat
>>>
>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Comments on draft-ietf-taps-transports-03

[Joe Touch]

On 3/22/2015 7:34 AM, Michael Welzl wrote:
> Major:
> - I do think that the terminology actually needs to clarify about
> what a "service" is. Following the chain of dependencies here, it is found in
> "Transport Service", where it says "... which provides a complete
> service to an application."
> 
> The reason I think we need to define this is that we should (IMO)
> explicitly exclude protocol functions that can improve the performance
> of the protocol *only* depending on environment characteristics but
> *irrespective* of the application. For example, things like ECN, SACK
> etc. shouldn't be regarded as a "service" in my opinion.

IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities
within a service.

The difference is simple: a service is the smallest set of capabilities
that can be used independent of all others.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Comments on draft-ietf-taps-transports-03

[Joe Touch]

On 3/23/2015 11:06 AM, Michael Welzl wrote:
> 
>> On 23. mar. 2015, at 11.34, Joe Touch  wrote:
>>
>>
>>
>> On 3/22/2015 7:34 AM, Michael Welzl wrote:
>>> Major:
>>> - I do think that the terminology actually needs to clarify about
>>> what a "service" is. Following the chain of dependencies here, it is found 
>>> in
>>> "Transport Service", where it says "... which provides a complete
>>> service to an application."
>>>
>>> The reason I think we need to define this is that we should (IMO)
>>> explicitly exclude protocol functions that can improve the performance
>>> of the protocol *only* depending on environment characteristics but
>>> *irrespective* of the application. For example, things like ECN, SACK
>>> etc. shouldn't be regarded as a "service" in my opinion.
>>
>> IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities
>> within a service.
>>
>> The difference is simple: a service is the smallest set of capabilities
>> that can be used independent of all others.
> 
> I completely agree and apologize, that was slopping writing on my
> side: I should have said "service component". Anyway my point was that
> ECN, SACK etc. shouldn't be any of that.

ECN and SACK are "how" a service achieves a capability, but they're not
capabilities.

Just like "Nagle" isn't a capability either.

These items are activated to achieve a capability. The closest for Nagle
would be "efficient transfer allowing delay".

YMMV, and I don't have a suggestion for the others.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

Hi, Brian (et al.),

On 5/26/2015 6:25 AM, Brian Trammell wrote:
...
> (3) frontmatter in Section 4 normalizing and categorizing the
> transport protocol components; please review this and suggest necessary
> or useful changes for using this as background for selecting taps features.

I like the definitions but IMO the protocol descriptions don't follow
the definitions.

I.e., I agree that a transport protocol service (TPS) is a feature or
capability made available to the app, and that a transport protocol
component (TPC) is an implementation of such a feature.

I realize I sound like a broken record, but the descriptions of the
protocols herein still does not match the definition of TPS or TPC.

E.g., for TCP, none of the following is exposed to the user:
- segmentation
- flow control
- congestion control
- error detection
At best, the effects of the above are exposed to the user in very
indirect fashion, certainly not as a "service" that can be used.

In addition, TCP provides all of the following services (the latter two
depending on being supported), which are not listed:
- PUSH
- URG
- authentication (via TCP-AO or legacy TCP MD5)
- control over user timeout (UTO option)

This continues to be a pervasive issue in this doc, i.e., not just for
this protocol.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
> Hi Joe,
> 
> I agree. This is a working document and we are still in the phase of
> collecting data while the next step is to discuss which things that are
> currently listed must/should be listed or not and also which of the
> things must/should be exposed to the app.

To be clear, can you clarify the focus?:

- what IS/IS NOT (i.e., current requirements)

- what WILL BE/WILL NOT BE (i.e., future goals)

AFAICT, this is about IS/IS NOT. With that in mind, it should not be
necessary to "collect data" and then decide later what is exposed or not.

> However, I think we are on the write track for the TSC because these
> are thing that are implemented independent of the question if these
> things should be exposed to the app or not.

There seems to be ample confusion about:

- upper layer interface (abstract "API"): services to the user

- lower layer interface: services needed from the next protocol layer

- the protocol itself (as an abstract specification: i.e., the finite
state machine rules that relate commands and responses to the ULI, calls
and returns to the LLI, and internal state and events (e.g., timers)

- the *implementation* of any of the above, e.g.:
- Unix sockets API
- interface to IPv4
- Differences that include Reno vs. Cubic..., MTU algs, etc.

> However, features in
> contrast should really only be the things that should be exposed.

IMO, implementation issues should be fully out of scope.

> The
> list in section 4 currently copies everything from above and we need to
> have the discuss now what should stay there and what not.

Frankly, RFC 793 specified exactly what is needed here (it may need to
be augmented with options and later extensions), but that needs to be a
*starting point* for these discussions.

And the current doc doesn't come close to what's in 793.

If we're not starting there, there's little point in starting IMO.

Joe


> Mirja
> 
> 
>> Am 27.05.2015 um 00:36 schrieb Joe Touch :
>>
>> Hi, Brian (et al.),
>>
>> On 5/26/2015 6:25 AM, Brian Trammell wrote:
>> ...
>>> (3) frontmatter in Section 4 normalizing and categorizing the
>>> transport protocol components; please review this and suggest necessary
>>> or useful changes for using this as background for selecting taps features.
>>
>> I like the definitions but IMO the protocol descriptions don't follow
>> the definitions.
>>
>> I.e., I agree that a transport protocol service (TPS) is a feature or
>> capability made available to the app, and that a transport protocol
>> component (TPC) is an implementation of such a feature.
>>
>> I realize I sound like a broken record, but the descriptions of the
>> protocols herein still does not match the definition of TPS or TPC.
>>
>> E.g., for TCP, none of the following is exposed to the user:
>>  - segmentation
>>  - flow control
>>  - congestion control
>>  - error detection
>> At best, the effects of the above are exposed to the user in very
>> indirect fashion, certainly not as a "service" that can be used.
>>
>> In addition, TCP provides all of the following services (the latter two
>> depending on being supported), which are not listed:
>>  - PUSH
>>  - URG
>>  - authentication (via TCP-AO or legacy TCP MD5)
>>  - control over user timeout (UTO option)
>>
>> This continues to be a pervasive issue in this doc, i.e., not just for
>> this protocol.
>>
>> Joe
>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 5/28/2015 1:49 AM, Mirja Kühlewind wrote:
> Hi Joe,
> 
> see below...
> 
> 
>> Am 27.05.2015 um 19:20 schrieb Joe Touch :
>>
>>
>> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
>>> Hi Joe,
>>>
>>> I agree. This is a working document and we are still in the phase of
>>> collecting data while the next step is to discuss which things that are
>>> currently listed must/should be listed or not and also which of the
>>> things must/should be exposed to the app.
>>
>> To be clear, can you clarify the focus?:
>>
>>  - what IS/IS NOT (i.e., current requirements)
>>
>>  - what WILL BE/WILL NOT BE (i.e., future goals)
>>
>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be
>> necessary to "collect data" and then decide later what is exposed or not.
> 
> It’s about IS/IS NOT. However, currently there is very little (explicitly) 
> exposed to the app.

That's contradictory.

What IS/IS NOT exposed as per the specs is easy to determine.

Anything not exposed is either not part of a spec or an incomplete
implementation. Other stuff - like congestion control alg - is
absolutely NOT part of any current TCP spec to expose to the API.

> So the question is actually what should be exposed from the
> transport service components that are currently implemented in the then 
> different
> existing transport protocols.

That's WILL BE, and a completely different issue IMO. If we don't
clearly document the current requirements, it's very difficult to move
forward with deciding how to extend that API.

>>> However, I think we are on the write track for the TSC because these
>>> are thing that are implemented independent of the question if these
>>> things should be exposed to the app or not.
>>
>> There seems to be ample confusion about:
>>
>> - upper layer interface (abstract "API"): services to the user
>>
>> - lower layer interface: services needed from the next protocol layer
>>
>> - the protocol itself (as an abstract specification: i.e., the finite
>> state machine rules that relate commands and responses to the ULI, calls
>> and returns to the LLI, and internal state and events (e.g., timers)
>>
>> - the *implementation* of any of the above, e.g.:
>>  - Unix sockets API
>>  - interface to IPv4
>>  - Differences that include Reno vs. Cubic..., MTU algs, etc.
>>
>>> However, features in
>>> contrast should really only be the things that should be exposed.
>>
>> IMO, implementation issues should be fully out of scope.
> 
> It’s not about implementation issues but it’s not always absolutely
> clear which level of detail must be exposed to the app.

It's absolutely clear in RFC 793 at least.

> Is it enough to
> only have an interface where you can choose to use congestion control or
> not,

That's not part of any current spec, so you're back to "tomorrowland"
thinking.

> or do you need to choose between delay-based and lost-based
> congestion control, or foreground and background congestion control, or
> one specify algorithm, or just specify one specify detail of the
> algorithm e.g. don’t increase fast than one packet per RTT…?

Potentially useful, but that's diving very deep into HOW TCP operates,
rather than user-level issues.

This is revisiting the old QOS debate: do you open the entire set of QOS
parameters to the user, or merely provide the user with a set of
user-visible goals and allow the protocol to decide how best to support
them? In QOS, this ended up picking a very few types of service classes.
The same goal might be useful here.

But, again, that's a goal for the future. It's difficult to get there if
there's no clear indication of the current APIs.

> So the approach for the current document is to summarize what’s
> already there.

The doc needs to differentiate between "already required per
specification" and "available in some implementations". The former sets
the baseline. The latter is fodder for discussion of how to standardize
API extensions.

> We had some discussions about the level of detail of this
> document, and I believe we currently have a good compromise where we
> give some implementation details but also try to not make this document
> unnecessary long.

IMO, the problem is that there's no clear distinction between what's
currently required vs. available in some instances.

>>> The
>>> list in section 4 currently copies everything from above and we need to
>>> have the discuss now what should stay there and what not.
>>
>> Frankly, RFC 7

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

[Joe Touch]

On 5/28/2015 11:05 AM, Mirja Kühlewind wrote:
> Hi Joe,
> 
> here is where the confusion comes from: this doc is not about APIs,
> it’s about transport services, or to say it even more concrete,
> transport services components and features.

Such services are either inherent to the transport (e.g., in-order,
reliable delivery) or exposed as a control to the user (by the API).

I.e., APIs are necessary but not sufficient to describe transport services.

> We do have a section on
> interfaces for each protocol but that just an add-on which might or
> might not be useful to have in this document, but the core of the
> document is to describe the components that are currently implemented
> independent of the current provided (app-layer) interface and then add
> some discuss of which of these components are useful to expose to the
> app as transport services feature (and which level of detail/degree of
> decision freedom for each feature).

But then isn't it critical to also know what's already exposed, e.g., in
the existing API?

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

First, I think this discussion would benefit from a clarification of
what "API" means, or at least to stop using that term in isolation.

There are three distinct concepts:

A- abstract protocol "upper layer interface"
e.g., OPEN, CLOSE, ABORT, as per RFC 793

B- programmer API
e.g., Linux C/C++ TCP socket interface

C- instance of a programmer API
e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface

IMO, this document MUST discuss A, and can be address potential
extensions to A based on examining variants of B and C.

There are also the protocol features, which are the properties of the
protocol that:
- can be explicitly configured and monitored
these are *exactly* A, B, and/or C above

- can be implicitly detected
some are based on the definition of the protocol,
such as reliable, byte sequence delivery

some are an artifact of the implementation,
such as specific delays due to burst losses

However, *none* of this is a rat-hole IF TAPS is intended to explain the
service interface to the user. IMO, B and C above should be secondary
considerations after A is clearly documented, but this draft is a long
way from that.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 6/1/2015 9:45 AM, Michael Welzl wrote:
> 
>> On 1. jun. 2015, at 16.32, Mirja Kühlewind  
>> wrote:
>>
>> Hi Joe, hi Michael,
>>
>> I completely welcome to add more text to the Interface description section 
>> (3.1.2). Currently this section is very short and says regarding the (higher 
>> layer) interface described in FRC793:
>>
>> "A User/TCP Interface is defined in [RFC0793] providing six user
>>   commands: Open, Send, Receive, Close, Status.  This interface does
>>   not describe configuration of TCP options or parameters beside use of
>>   the PUSH and URGENT flags.“
>>
>> This text was already added based on Joe’s input. Please provide more text 
>> if you think this is not sufficient. 
>>
>> Probably we should at least add one more sentence describing the TCP-to-User 
>> interface (as it is called in RFC 793) like this:
>>
>> „Further the TCP-to-User interface is described providing information on the 
>> local connection name, the response string, the send and received buffer 
>> addresses, the Byte count (which counts bytes received) as well as the PUSH 
>> flag and URGENT flag.“
> 
> I agree

My concern is that there is no clear relation between 3.1.2 and 3.1.3.

In fact, many of the properties of 3.1.3 are the result of the interface
mentioned in 3.1.2. Also, a few aspects of the 3.1.2 interface aren't
considered in 3.1.3.

So what's the point of 3.1.3?

>From the definition:
   Transport Protocol Component:  an implementation of a transport
  service feature within a protocol.

Unfortunately, the items in 3.1.3 aren't implementations; they're
general properties. An implementation would be Reno or CUBIC.

In addition, API isn't defined (e.g., see my previous 3 descriptions),
so it's never clear what should be in 3.1.2 (or the corresponding
sections of other protocols).

As a result, I do not understand the purpose of either section of this
document, or this document as a whole.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 6/1/2015 11:38 AM, Mirja Kühlewind wrote:
> Hi Joe
>>
>> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
> 
> Yes, that’s actually true. Initially there was no section 3.1.2 as
> this doc is not on interfaces. However it seems to be incomplete without
> mentioning interfaces at all. If we keep this section, you are right,
> the relation should be there.

Interfaces *define* services:

We use the term "Transport
Service" to mean an end-to-end facility provided by the
transport layer. That service can only be provided correctly if
information is supplied from the application.

The API defines the information supplied from (and to) the application.

Thus, if TAPS doesn't include the API in its flagship document, then I
have no idea what you're all doing.

>> In fact, many of the properties of 3.1.3 are the result of the interface
>> mentioned in 3.1.2.
> 
> Really? Can you give an example? I would rather hope that we can
> describe the transport components independent of the currently/any
> interface.

Your own charter indicates why that is not possible.

(Again, I mean "abstract API", not the C or Linux implementations of these).

Properties:

- stateful
result of OPEN and CLOSE commands

- active calling party
result active/passive OPEN commands
i.e., one party needs to actively call the other

- byte-oriented, in order
result of SEND/RECEIVE calls in order
that input/output blocks of bytes in linear
sequence

- independent of the application data boundaries
result of the semantics fo the SEND/RECEIVE
calls, which input/output blocks of bytes
where the call data boundaries are defined as NOT
corresponding to TCP segment boundaries or events

- OOB signaling
result of PUSH and URG interface

>> Also, a few aspects of the 3.1.2 interface aren't
>> considered in 3.1.3.
> 
> To complete 3.1.3, looking at interface is probably useful. Can you list 
> what’s missing?

I've done this multiple times already.

>> So what's the point of 3.1.3?
> 
> I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a
> list of components as basis for discuss which features should/must be
> exposed to the app-layer.

The list of "components" doesn't fit the definition within this doc, so
I disagree with this.

>>> From the definition:
>>   Transport Protocol Component:  an implementation of a transport
>>  service feature within a protocol.
>>
>> Unfortunately, the items in 3.1.3 aren't implementations; they're
>> general properties. An implementation would be Reno or CUBIC.
> 
> I agree that what’s currently listed is not on the right level of
> detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on
> the right level either. Maybe it’s delay/loos-based or
> foreground/background or AIMD, but congestion control is especially
> complicated I’d say. That’s what we have to figure out now.

You need to update your definitions first if that's the case.

>> In addition, API isn't defined (e.g., see my previous 3 descriptions),
>> so it's never clear what should be in 3.1.2 (or the corresponding
>> sections of other protocols).
> 
> I don’t know either what should be in 3.1.2 right now. Anything that is
> useful for 3.1.3 or 4 should be mentioned; everything else will be
> removed at the end (potentially even the whole section).

The expectations for what are in each section should be defined in this
document.

Again, if we all don't know what's being written, writing is premature.


>> As a result, I do not understand the purpose of either section of this
>> document, or this document as a whole.
> 
> That’s to bad. Maybe we should state this more explicitly in the
> intro…? According to our charter, while taps itself is chartered to
> describe "an (abstract) interface for applications
> to make use of Transport Services“,

That is an API - more specifically, it's a future, desired abstract API.

> this first document is only used to "identifying the
> [components] provided by existing IETF protocols“ as a starting
> point.

IMO, you need to start by defining the current abstract API, then the
internal capabilities (independent of implementation) that might be exposed.

I don't see how to do that with this "shopping-list" of issues.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 6/1/2015 12:23 PM, Michael Welzl wrote:
> I'll try addressing another detail, maybe that helps get us aligned:
> 
> 
>> On 1. jun. 2015, at 21.38, Mirja Kühlewind  
>> wrote:
>>
>> Hi Joe
>>>
>>> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
>>
>> Yes, that’s actually true. Initially there was no section 3.1.2 as this doc 
>> is not on interfaces. However it seems to be incomplete without mentioning 
>> interfaces at all. If we keep this section, you are right, the relation 
>> should be there.
> 
> The document is about services. These are provided via interfaces - so the 
> document should very much be about interfaces.
> 3.1.3 describes TCP, it lists all the things you get with TCP - nothing that 
> the application can configure, but what you get with it anyway.
> 
> The complete service provided by TCP consists of everything TCP is AND the 
> what the application can configure about it.

Yes.

> It gives you segmentation, congestion control,  AND it lets you use PUSH 
> and an URGENT pointer and ...

Segmentation is HOW TCP gives you a reliable byte-sequence service over
a packet service.

It is absolutely NOT something provided to the user or under user
control. Users can set MTU values on *some systems*, but that's not part
of the TCP API (to the application) nor does MTU necessarily correspond
to actual data boundaries (TCP is allowed to do a lot of things).

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 6/1/2015 1:34 PM, Michael Welzl wrote:

>> Segmentation is HOW TCP gives you a reliable byte-sequence service over
>> a packet service.
>>
>> It is absolutely NOT something provided to the user or under user
>> control. Users can set MTU values on *some systems*, but that's not part
>> of the TCP API (to the application) nor does MTU necessarily correspond
>> to actual data boundaries (TCP is allowed to do a lot of things).
> 
> Yes, I didn't mean that segmentation is under user control. Let me rephrase 
> my above sentence:
> 
>>> It gives you, via its non-configurable static behavior:
>>> segmentation, congestion control,  AND it lets you control some
>>> things: PUSH and an URGENT pointer and ...

But it doesn't "give" you segmentation. It uses segmentation to provide
a reliable byte stream over a packetized service. If we wanted, we could
arguably export a TCP service over a circuit that did NOT need to rely
on segmentation.

This discussion really needs to distinguish between WHAT TCP exports and
HOW TCP makes that happen - the latter may or may not ever be visible to
the user.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote:
...
> Does it make sense for the TAPS transports draft to add ICMP?

ICMP is not a transport protocol.

The ways in which transport protocols either terminate or pass-through
ICMP messages is part of the transport protocol abstract API.

E.g., for UDP and TCP see RFC1122.

UDP passes all ICMP messages to the app.

TCP passes only dest unreachable types 0, 1, and 5, time exceeded and
parameter problem. All others it interprets or ignores internally and
it's not clear it should pass up to the app.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
> 
>> On 04 Jun 2015, at 17:43, Joe Touch > <mailto:to...@isi.edu>> wrote:
>>
>>
>>
>> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote:
>> ...
>>> Does it make sense for the TAPS transports draft to add ICMP?
>>
>> ICMP is not a transport protocol.
> 
> Sure. And I agree. But it has the potential to influence how the various
> transport protocols behave. That interaction might be nice to have
> described in the transports draft.

Abstract APIs need to be described. These are part of that description.

>> The ways in which transport protocols either terminate or pass-through
>> ICMP messages is part of the transport protocol abstract API.
>>
>> E.g., for UDP and TCP see RFC1122.
>>
>> UDP passes all ICMP messages to the app.
>>
> No. Not unless the application specifically listens for it.

UDP passes all ICMP messages to the app. If the app doesn't listen for
it, that's the app's decision.

> Unfortunately how to do this varies from OS to OS:
> See 
> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 for
> examples.

You are confusing the OS and language-dependent implementation of the
API with the abstract API.

RFC1122 requires that UDP implementations make the ICMP signals
available to the application. It does not indicate by what mechanism.

> Listening for port unreachable can be nice to avoid spamming a host or
> application that recently crashed. Detecting fragmentation or max MTU is
> also a nice feature especially VoIP applications sending video can
> utilise to optimise their packet sizes. 

UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122.

>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded and
>> parameter problem. All others it interprets or ignores internally and
>> it’s not clear it should pass up to the app.
> 
> That is exactly that kind of information I would find useful in the
> transports draft.

Well, yes - IMO, that's because it's part of the abstract API.

> Any pitfalls with ICMP when doing SCTP?

In many ways, SCTP subsumes similar requirements as TCP, but that's
probably buried in the SCTP docs.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/4/2015 3:34 AM, Mirja Kühlewind wrote:
> It's in the doc:
> 
> "Application:  an entity that uses the transport layer for end-to-end
>   delivery data across the network (this may also be an upper layer
>   protocol or tunnel encapsulation)."

"End to end" is *defined* as the endpoints of the transport association.

So, basically:

"Application:  an entity that uses the transport layer for delivery of
data between the transport endpoints."

However, *every* protocol is trivially defined as:

A mechanism between two or more parties to exchange data
(information) between those parties.

I.e., as a result, an app is defined EXACTLY and ONLY by the following:

Application: an entity that *uses* a transport layer.

Every other part of the definition is irrelevant, IMO.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
...
>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>> it, that’s the app's decision.
>>
> Then there is a lot UDP application developers out there that does not care. 
> 
> Ill guess what I am asking if we should make life easier for them.

Again, FIRST this doc needs to explain the current abstract APIs for
transport protocols.

THEN we can decide whether that set either needs to be augmented,
diminished, or translated to be more useful for "applications".

>>> Unfortunately how to do this varies from OS to OS:
>>> See 
>>> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 
>>> for
>>> examples.
>>
>> You are confusing the OS and language-dependent implementation of the
>> API with the abstract API.
>>
> On purpose. I hate it when a feature should work because it says so 
> in a RFC, but the implementations of it is so vastly different that
> it is not possible to get the thing to work so the app developer just
> chose to ignore it.

The IETF standardizes protocols and abstract APIs.

If you are concerned with differences in the implementations of those
abstract APIs, you need to address them in other organizations (e.g.,
POSIX, etc.).

...
>> RFC1122 requires that UDP implementations make the ICMP signals
>> available to the application. It does not indicate by what mechanism.
>>
>>> Listening for port unreachable can be nice to avoid spamming a host or
>>> application that recently crashed. Detecting fragmentation or max MTU is
>>> also a nice feature especially VoIP applications sending video can
>>> utilise to optimise their packet sizes. 
>>
>> UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122.
> 
> That is another problem. An app using port  will receive all
> ICMP messages also generated by other apps running on other ports.

That's an incorrect implementation. See RFC1122 Section 4.1.3.3.

...
> So this boils down better education of the app developers?

No, in that case you have a bug. The only thing the UDP app has to worry
about are ICMPs from other apps using the same port.

 TCP passes only dest unreachable types 0, 1, and 5, time exceeded and
 parameter problem. All others it interprets or ignores internally and
 it’s not clear it should pass up to the app.
>>>
>>> That is exactly that kind of information I would find useful in the
>>> transports draft.
>>
>> Well, yes - IMO, that’s because it's part of the abstract API.
>>
> Can they at least cite RFC 1122 then?

I would hope so.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
> 
>> On 04 Jun 2015, at 21:17, Joe Touch  wrote:
>>
>>
>>
>> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
>> ...
>>>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>>>> it, that’s the app's decision.
>>>>
>>> Then there is a lot UDP application developers out there that does not 
>>> care. 
>>>
>>> Ill guess what I am asking if we should make life easier for them.
>>
>> Again, FIRST this doc needs to explain the current abstract APIs for
>> transport protocols.
>>
>> THEN we can decide whether that set either needs to be augmented,
>> diminished, or translated to be more useful for “applications".
> 
> Heh.. I still do not get that..
> 
>>From the Abstract:
> This document describes services provided by existing IETF protocols
> and congestion control mechanisms.

*existing*

That means we need to document WHAT IS before deciding to pursue WHAT
SHOULD BE.

> It is designed to help
> application and network stack programmers and to inform the work of
> the IETF TAPS Working Group.
> 
> 
> Having a description of how ICMP works. Both in theory (abstract
> APIs) and in practice would help app developers.

In theory, it behaves like RFC 792 and RFC 1122 specify.

In practice, we can measure whether those capabilities are supported or
not (but that's not particularly the scope of TAPS).

However, that does not necessarily require documenting the Java
interface to TCP on Linux CentOS v7. That what man pages are for.

>>>>> Unfortunately how to do this varies from OS to OS:
>>>>> See 
>>>>> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2
>>>>>  for
>>>>> examples.
>>>>
>>>> You are confusing the OS and language-dependent implementation of the
>>>> API with the abstract API.
>>>>
>>> On purpose. I hate it when a feature should work because it says so 
>>> in a RFC, but the implementations of it is so vastly different that
>>> it is not possible to get the thing to work so the app developer just
>>> chose to ignore it.
>>
>> The IETF standardizes protocols and abstract APIs.
>>
>> If you are concerned with differences in the implementations of those
>> abstract APIs, you need to address them in other organizations (e.g.,
>> POSIX, etc.).
>>
> 
> That seems like a fun task.. (So who is on the list: Apple,
> Microsoft, Google(android), Linux, BSD…)

POSIX is maintained by the IEEE, and defines the common API across
various OS implementations - and yes, some of those orgs participate.

That's far outside the scope of the IETF, though.

>> ...
>>>> RFC1122 requires that UDP implementations make the ICMP signals
>>>> available to the application. It does not indicate by what mechanism.
>>>>
>>>>> Listening for port unreachable can be nice to avoid spamming a host or
>>>>> application that recently crashed. Detecting fragmentation or max MTU is
>>>>> also a nice feature especially VoIP applications sending video can
>>>>> utilise to optimise their packet sizes. 
>>>>
>>>> UDP is required to pass ALL ICMP messages to the app layer, as per RFC 
>>>> 1122.
>>>
>>> That is another problem. An app using port  will receive all
>>> ICMP messages also generated by other apps running on other ports.
>>
>> That's an incorrect implementation. See RFC1122 Section 4.1.3.3.
>>
> The section says:
> UDP MUST pass to the application layer all ICMP error
> messages that it receives from the IP layer.  Conceptually
> at least, this may be accomplished with an upcall to the
> ERROR_REPORT routine (see 
> Section 4.2.4.1).
> 
> Looks like none the implementers do send any ICMP messages to the
> UDP layer.

Here's an example of how an app can get errors in response to a call:
http://stackoverflow.com/questions/4888285/send-an-udp-packet-and-receive-an-icmp-response-from-router-in-c

The app can get async errors (i.e., not in response to a given sendmsg
or recvmsg call) by using a connect() to the socket - i.e., creating a
handle by which the OS can signal the app.

See the book excerpt here:
https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA249&lpg=PA249&dq=socket+errors+icmp&source=bl&ots=Ks3APlbjQs&sig=aBvReFfOYShEGtJtvEheG-8HpnI&hl=en&sa=X&ei=lLpwVdLHJZSZoQSxtYKwCw&ved=0CDMQ6AEwAg#v=onepage&q=socket%20errors%20icmp&f=false

AFAICT, this is widely supported.

>> ...
>>> So this boils down better education of the app developers?
>>
>> No, in that case you have a bug. The only thing the UDP app has to worry
>> about are ICMPs from other apps using the same port.
> 
> Do you have any real code to show that this actually work as described on any 
> platform?

See above.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> I think that speaking specifically about any protocol in this document
> will not be in the sens of an "abstract" interface for the Transport
> layer, because abstraction means that application will no longer be
> aware of who or what Transport services are really offered.

We need to be more clear in what we are discussing.

E.g., an "abstract API" (as I've been calling it) is described as in RFC
793:

OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS

That's abstract only in the sense that it does NOT specify an
implementation in Linux, for example. It is not so abstract that it
applies to all transports - it's indicated for TCP only.

What you're proposing is a "universal interface", whether abstract
(described as above, using words to describe app-level actions and
events) or instantiated (e.g., using Unix socket(), connect(), accept(),
listen(), etc.).

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote:
> In my presentation in Dallas I had suggested adding RTP (and even
> HTTP) because as both Mirja and Christian mention some 'applications'
> are requesting functionalities that are got given elsewhere.

The core of this issue is "what is a transport protocol".

To the user, "transport" is the entire stack between their program and
the network (IP) layer - sometimes even including that (e.g., IPsec).

To typical transport protocols (e.g., UDP, TCP), everything that
accesses a transport protocol is the "application" layer.

>From the document:
   Transport Service:  a set of transport service features, without an
  association to any given framing protocol, which provides a
  complete service to an application.

   Transport Protocol:  an implementation that provides one or more
  different transport services using a specific framing and header
  format on the wire.

By those definitions, EVERYTHING between the user program and the link
layer is arguably part of the services an app sees, which include "shim"
services and layers such as: IPsec, TLS, and RTP.

I would argue that HTTP is the application that uses TCP (or TLS/TCP),
but not a separate service, but that's true only for conventional web
service.

There are many services built on top of HTTP, at which point HTTP is
just another part of what this document calls a "transport service".

As a result, unless you'll be describing every possible stack between
the user program and the link layer, this document cannot proceed with
the current definitions.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote:
> 
>> On 04 Jun 2015, at 22:56, Joe Touch > <mailto:to...@isi.edu>> wrote:
>>
>>
>>
>> On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
>>>
>>>> On 04 Jun 2015, at 21:17, Joe Touch >>> <mailto:to...@isi.edu>> wrote:
>>>>
>>>>
>>>>
>>>> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
>>>> ...
>>>>>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>>>>>> it, that’s the app's decision.
>>>>>>
>>>>> Then there is a lot UDP application developers out there that does
>>>>> not care. 
>>>>>
>>>>> Ill guess what I am asking if we should make life easier for them.
>>>>
>>>> Again, FIRST this doc needs to explain the current abstract APIs for
>>>> transport protocols.
>>>>
>>>> THEN we can decide whether that set either needs to be augmented,
>>>> diminished, or translated to be more useful for “applications".
>>>
>>> Heh.. I still do not get that..
>>>
>>>> From the Abstract:
>>> This document describes services provided by existing IETF protocols
>>> and congestion control mechanisms.
>>
>> *existing*
>>
>> That means we need to document WHAT IS before deciding to pursue WHAT
>> SHOULD BE.
>>
> ICMP is an *existing* protocol. Not a transport protocol, but a
> service(?) that affects how the other protocols behaves.

And it is part of the service provided by a transport - i.e., when an
ICMP message is absorbed and acted on by TCP, it's a service *to* TCP,
but when TCP relays ICMP messages to the application they become part of
the TCP API.

> All I am observing is that this is something app developers rarely cares
> about, and having sections in the TAPS transports draft describing it
> might help. Why are there sections describing TCP, they could just read
> RFC 793?

More like RFC1122, which already does for TCP and UDP basically what
this doc is attempting to do.

>>> It is designed to help
>>> application and network stack programmers and to inform the work of
>>> the IETF TAPS Working Group.
>>>
>>>
>>> Having a description of how ICMP works. Both in theory (abstract
>>> APIs) and in practice would help app developers.
>>
>> In theory, it behaves like RFC 792 and RFC 1122 specify.
>>
>> In practice, we can measure whether those capabilities are supported or
>> not (but that's not particularly the scope of TAPS).
>>
>> However, that does not necessarily require documenting the Java
>> interface to TCP on Linux CentOS v7. That what man pages are for.
>>
> 
> No, but pointing out that there are differences out there and app
> developers should take care and investigate is a useful hint. 

One line:

Implementations vary.

What else is there to say? And do we really need to say that?

>>>>>>> Unfortunately how to do this varies from OS to OS:
>>>>>>> See 
>>>>>>> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2
>>>>>>>  for
>>>>>>> examples.
>>>>>>
>>>>>> You are confusing the OS and language-dependent implementation of the
>>>>>> API with the abstract API.
>>>>>>
>>>>> On purpose. I hate it when a feature should work because it says so 
>>>>> in a RFC, but the implementations of it is so vastly different that
>>>>> it is not possible to get the thing to work so the app developer just
>>>>> chose to ignore it.
>>>>
>>>> The IETF standardizes protocols and abstract APIs.
>>>>
>>>> If you are concerned with differences in the implementations of those
>>>> abstract APIs, you need to address them in other organizations (e.g.,
>>>> POSIX, etc.).
>>>>
>>>
>>> That seems like a fun task.. (So who is on the list: Apple,
>>> Microsoft, Google(android), Linux, BSD…)
>>
>> POSIX is maintained by the IEEE, and defines the common API across
>> various OS implementations - and yes, some of those orgs participate.
>>
>> That’s far outside the scope of the IETF, though.
> 
> 
> That I agree on. The discussion is probably better had over a beer. I do
> feel that it is important that IETF do take into account what is
> actually used in the wil

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

[Joe Touch]

On 6/5/2015 4:29 AM, Mirja Kühlewind wrote:
> I do have the feeling that parts of what Joe wants to discuss should
> however be in the third doc. And therefore I think that the current
> first doc is not the taps flagship doc because for me a flagship doc
> (and we probably need to define this term ;-) ) is the doc that you
> point people to as the first thing to read after the work was finished...?

Perhaps "flagship" isn't a useful word for either doc.

IMO, this is a "foundation" doc, and as such needs to set the groundwork
for other docs.

As to what doc we'll point people at when this is done, that could be a
BCP, it could be a new protocol (experimental, presumably), etc.

But we're nowhere near understanding what that last doc will be if we
can't agree on what a protocol or API is.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/5/2015 5:11 AM, Helge Backhaus wrote:
> Am 04.06.2015 um 23:20 schrieb Joe Touch:
...
>> There are many services built on top of HTTP, at which point HTTP is just
>> another part of what this document calls a "transport service".
>>
>> As a result, unless you'll be describing every possible stack between the
>> user program and the link layer,
> 
> Shouldn't this ideally be the (long-term) goal of TAPS?

This would require an exponential number of service descriptions.

IMO, it's better to describe them as a linear number of composable
components and declare the composition rules.

(that's not novel; that's what we do throughout the IETF)

>> this document cannot proceed with the current definitions.
> 
> So could a possible way forward be to leave the definitions as they are
> and add a description of the considered stack(s) to the document? For
> now "just" TCP, UDP, SCTP, ... over IPv4/6 etc.

If you ignore the deficiency of the definitions, then it's impossible to
move together on the remainder of the doc.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
> 
> 
> On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  <mailto:to...@isi.edu>> wrote:
> 
> 
> 
> On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> > I think that speaking specifically about any protocol in this document
> > will not be in the sens of an "abstract" interface for the Transport
> > layer, because abstraction means that application will no longer be
> > aware of who or what Transport services are really offered.
> 
> We need to be more clear in what we are discussing.
> 
> E.g., an "abstract API" (as I've been calling it) is described as in RFC
> 793:
> 
> OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS
> 
> That's abstract only in the sense that it does NOT specify an
> implementation in Linux, for example. It is not so abstract that it
> applies to all transports - it's indicated for TCP only.
> 
> This definition of 'abstract interface" is specific for a given
> protocol, but the aim in TAPS is a higher level (services). In other
> words, if this is the définition of an abstract interface, and is
> already defined in RFC 793, what will be the contribution of TAPS by
> defining its abstract interface?

The first step towards a universal abstract interface is to understand
the current specific abstract interfaces. That's what the current
document is focused on.

> The objective of TAPS is to change the traditional way to use the
> Transport layer. In fact, traditionally, applications select the
> appropriate transport service by selecting a given transport protocol.
> The TAPS vision is to change this, so as applications will request only
> their desired services, via this abstract interface, and it is to the
> Transport layer to choose the appropriate protocol according to the
> application request. It is this level of abstraction that is aimed by
> TAPS. (see the charter, point 3 especially)

In order to unify or further abstract the API, the current API needs to
be understood - but the discussion on the list indicates a lot of
disagreement on this.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/8/2015 1:19 AM, Mirja Kühlewind wrote:
> Hi Joe,
> 
> the document defines one more term:
> 
> Transport Service Instance:  an arrangement of transport protocols
>   with a selected set of features and configuration parameters that
>   implements a single transport service, e.g. a protocol stack (RTP
>   over UDP).
> 
> This is to describe also a stack of protocols which an application
> might use to get a certain transport service. (we might need to re-write
> this maybe, because I now have the feeling that this is hard to understand).

If that's what it means, it certainly needs to be rewritten. A substack
of protocols isn't "an arrangement of transport protocols". The former
is vertical and involves functional composition; the latter is
horizontal ("peers" in the ISO stack at L4) and involves the union of
capabilities of the peers.

> Currently we are not using this term in this document because we try
> to describe components of anything that might/could provide a transport
> service feature of all protocols that that might be part of a protocol
> stack that can be accessed by an application.

I don't understand that either.

I really think that the definitions need to decouple the concept of
service interface to the upper layer from mechanisms that provide those
services.

> That’s what we had in mind when we came up with this terminology and
> I think think it covers the case where HTTP over TCP is used as a
> transport ‚substitute‘.

HTTP isn't a transport protocol. I don't know anyone who would call it
that or be able to use it as a substitute for TCP.

Joe

> Mirja
> 
> 
> 
>> Am 04.06.2015 um 23:20 schrieb Joe Touch :
>>
>>
>>
>> On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote:
>>> In my presentation in Dallas I had suggested adding RTP (and even
>>> HTTP) because as both Mirja and Christian mention some 'applications'
>>> are requesting functionalities that are got given elsewhere.
>>
>> The core of this issue is "what is a transport protocol".
>>
>> To the user, "transport" is the entire stack between their program and
>> the network (IP) layer - sometimes even including that (e.g., IPsec).
>>
>> To typical transport protocols (e.g., UDP, TCP), everything that
>> accesses a transport protocol is the "application" layer.
>>
>>> From the document:
>>   Transport Service:  a set of transport service features, without an
>>  association to any given framing protocol, which provides a
>>  complete service to an application.
>>
>>   Transport Protocol:  an implementation that provides one or more
>>  different transport services using a specific framing and header
>>  format on the wire.
>>
>> By those definitions, EVERYTHING between the user program and the link
>> layer is arguably part of the services an app sees, which include "shim"
>> services and layers such as: IPsec, TLS, and RTP.
>>
>> I would argue that HTTP is the application that uses TCP (or TLS/TCP),
>> but not a separate service, but that's true only for conventional web
>> service.
>>
>> There are many services built on top of HTTP, at which point HTTP is
>> just another part of what this document calls a "transport service".
>>
>> As a result, unless you'll be describing every possible stack between
>> the user program and the link layer, this document cannot proceed with
>> the current definitions.
>>
>> Joe
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/11/2015 5:30 AM, go...@erg.abdn.ac.uk wrote:
...
>> - Port multiplexing, with application-to-port mapping during connection
>> setup:
> 
> GF: Thinking on this, is application-to-port mapping really a TCP
> function? port-mapping is similar in other transports, and doesn't really
> have any different support in TCP (contrast to the Service Code in DCCP)

The assumption of app-to-port mapping is part of how assigned ports are,
well, assigned.

>>  Note that in the presence of network address and port translation 
>> (NAPT),
>> TCP
>> ports are
>>  in effect part of the endpoint address for forwarding purposes.
>>
> GF: This is the case only for those middle boxes that do NAPT,
> load-ballancing etc, saying they are part of the endpoint address is to me
> confusing forwarding by middle boxes from forwarding by routers - I'd
> prefer to be more careful here.

Ports are part of the connection identifier, in conjunction with the
endpoint address.

The fact that NATs or any other devices remap, translate, or overload
that function (i.e., using it for forwarding decisions) is not relevant
to TCP's view of these values or to the service TCP provides, IMO.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/17/2015 1:44 AM, Michael Welzl wrote:
> I think that this discussion with Joe maybe suffered from focusing on
> TCP. 

To be fair, TCP has a simpler abstract API.

> SCTP is perhaps a better starting point because it supports
> almost everything. 

IMO, that makes it very hard as a starting point, and I also think that
TCP's variant of an API description is much better as an example.

E.g., Section 10 of RFC4960 claims it defines an abstract API
(ULP-to_SCTP), but it begins by describing a call to initialize a data
structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
generic description of an implementation issue.

IMO, if we don't understand the difference between the API in RFC793 vs.
that in RFC4960 (and why 793 is a better example), then this is going to
be a very bumpy road.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

+1

On 6/18/2015 9:44 AM, Michael Welzl wrote:

*My*  goal is, and has always been, to provide a simpler, general API
that is protocol independent. Note that this is not only for
simplicity for ease of use BUT also for the sake of being able to
automatize. After all the major goal is to remove the strict binding
between applications and a specific protocol choice.

To be able to do this (documents 2 and 3), we first need a list of
the existing services - our toolbox, if you wish (document 1).
Figuring out what's missing / wrong about today's APIs (except that
they are bound to a specific protocol) has never been*my*  major
intention, and I certainly don't see that as the goal of this
document. I'd be surprised if that's what the charter suggests?! But
of course my opinion is only what it is, the charter reflects the
consensus...


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 7:15 AM, Mirja Kühlewind wrote:
> Cool! I think that the alternative approach Brian just proposed:
> Start with the feature we think/know we want to have and the compare
> them with what we have in the first document.

-1

If you don't know what you already have, it's hard to figure out why
what you need isn't there.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 6:22 AM, Michael Welzl wrote:
>
> On 19 Jun 2015, at 14:03, Mirja Kühlewind  
> wrote:
>> So there current API is always bound to a specify protocol which
>> already provides you a certain set of service feature. At least in
>> TCP there is not much choice left and there the current API does
>> not give us a good indication which services are actually provided
>> by TCP. Therefore from my point of view the only way to identify
>> these services is to look at the protocol itself and not only the
>> API. In SCTP it’s different and we definitely have to and will
>> discuss the existing API in the document.
>
> Exactly that's why I thought starting with TCP's API 
> (even when it's the abstract one) is not very helpful.
>
> Joe, Aaron: what is it you were expecting us to take away from 
> reading section 3.8 of RFC 793?

No. IMO, the current description of that API fails to indicate the
controls *already* available to TCP.

I don't agree that the TCP API doesn't indicate the service TCP provides
- it's just implicit. E.g.:

OPEN call
indicates TCP is connection oriented

SEND/RECEIVE calls
indicates TCP is an ordered byte stream,
that the user-level byte boundaries are NOT
related to message boundaries, etc.

Yes, there's some "reading between the lines" to do here.

> ( I can see it highlighting the need
> to discuss communication patterns (or decide for a specific one) in
> document #2, but not really contributing much to the list in document
> #1 ? )

I believe the opposite is true.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote:


Of course, no one use a protocol without knowing the service it offers.
When the application requests a TCP connection, it really request a
reliable and ordered connection oriented service. The protocols
primitives are used to each one to offer a part of this service.


My point is that the API primitives do define the service offered in 
this case. You can't use TCP without using OPEN; OPEN exists only 
because TCP is connection-oriented.


Similarly, SEND/RECEIVE are handled in-order and the byte order within 
each call is preserved - which indicates that this is a byte stream 
service. The lack of boundary marking within the SEND/RECEIVE calls - 
and the indication that SEND/RECEIVE block boundaries are not preserved 
- indicates that this is a byte stream service with no internal boundaries.


All of this can be gleaned from the API in section 3.8 of RFC 793.

> The

difficulty occurs when several protocols are available, with mainly a
certain service overlapping.


You're getting far ahead of the conversation, IMO. This document needs 
to start by explaining the services we already have before jumping into 
a "service of services" model.


I don't disagree with the goal, but it's impractical to develop a 
meta-interface when the base interface has not been described.


Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:



On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch mailto:to...@isi.edu>> wrote:


You're getting far ahead of the conversation, IMO. This document
needs to start by explaining the services we already have before
jumping into a "service of services" model.

I don't disagree with the goal, but it's impractical to develop a
meta-interface when the base interface has not been described.


It is just to say that TCP already defines its services, and the goal is
not to give another definition of these services, but only to change the
way they are exposed to applications. So the services definition already
exists, but implicitly.


It's explicit - see section 3.8 of RFC 793. The issue with that variant 
is that it captures the state of TCP in 1981; it has evolved quite a bit 
since then. Although we do have a 793-bis in the works, the update of 
that section hasn't been tackled yet.


Let's put it this way:

- if the goal of TAPS is to unify existing APIs,
then those APIs need to be summarized together in one place


- if TAPS is indeed focused solely on an alternate API,
then it should NOT try to 'restate' the existing TCP API
in a TAPS doc

"Do, or do not; there is no try."
- Yoda

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

Michael,

On 6/20/2015 1:35 AM, Michael Welzl wrote:



On 20. jun. 2015, at 00.55, Joe Touch  wrote:

On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:

...

Let's put it this way:

- if the goal of TAPS is to unify existing APIs,
then those APIs need to be summarized together in one place


- if TAPS is indeed focused solely on an alternate API,
then it should NOT try to 'restate' the existing TCP API
in a TAPS doc

"Do, or do not; there is no try."
- Yoda


TAPS is focused on an alternate API that it's based on existing
transports. As a way of analyzing existing transports and creating
a foundation for this API, document #1 is written. I think this
discussion is about the approach taken to write document #1.

So now I wonder what you're complaining about,


I'm trying to get Mohamed (and perhaps others) on the same page as you 
and I.


Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen wrote:
> Hi,
> 
> Please find a very few comments to the document. Nothing major. Please use
> if you see fit and only then :-)
> 
> Section 1: End First Paragraph:
> 
> Here it is said that a transport service feature may be minimal latency.
> Opposed to the other features listed here,
> like e.g. in-order or reliable delivery, then minimal latency seems a more
> delicate obtainable feature; How one best obtain it
> within the services provided by a certain transport protocol, may depend
> quite heavily on the application traffic pattern (unless CPU and network
> resources are unlimited).
> Also minimal latency is not a feature which any of the protocols described
> in the document has within its list of features (I think) or
> are you thinking minimal latency and best effort transport service (like
> UDP) - Or are you thinking some smart protocol of the future which will
> deduce how to best
> provide a minimal latency service for a particular application flow over a
> specific E-to-E path ?

FWIW, UDP doesn't minimize latency; it (arguably) minimizes the latency
created by the transport layer at the expense of ordered, reliable
delivery and congestion control.

So there are several levels of the latency issue:

- minimize the latency ADDED by the transport layer
- reduce the latency seen by the app
(which can involve more active interaction with the network
layer, anticipation, etc.)

Note also that latency is not a single metric nor a meaningful
standalone metric:

1. latency between two parties is a property *of a message*,
i.e., it requires knowing the message size

2. latency includes both basic and higher order effects;
the basic is "delay", the higher order include "jitter" etc.
Many common delay-sensitive use cases are really mostly
jitter sensitive.

...
> I am not sure if Connection oriented  and Feature negotiation should be
> split into two features ?

If you don't share state (i.e., what we tend to call a "connection"),
what is the meaning of feature negotiation?

...
> Disabling Nagle does not always give the lowest latency and further then I
> think that we are missing the good side of Nagle in the present text.

Nagle reduces the number of small packets at the expense of introducing
transport delay. Turning it off increases the number of small packets
and reduces the transport delay.

Although it's theoretically possible for the larger number of packets to
cause delays larger than those that Nagle aggregation would induce, in
practice the Nagle delays are several orders of magnitude larger.

Using byte-based congestion control, the larger number of packets would
have no effect. Using packet-based congestion control, the larger number
of packets would reduce latency (by opening up the window faster,
keeping it open longer, etc.) unless the increased number of packets
itself is the bottleneck.

So the general assumption that turning off Nagle will reduce latency
should be reasonable. Do you have a counterexample seen in the wild?

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote:
> HI Mirja, All
> 
> Sorry for jumping late into this discussion.
...
> I really do not think that it makes much sense to look into outdated and
> deprecated APIs
> as specified in RFC793 and RFC4960 when we have better material available.

What portion of RFC793's API do you consider outdated?

AFAICT, it's exactly what most sockets try to support (I can't speak
about SCTP, as I haven't used it much).

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote:
...
 Any pitfalls with ICMP when doing SCTP?
>>>
>>> In many ways, SCTP subsumes similar requirements as TCP, but that's
>>> probably buried in the SCTP docs.
>> It is. See
>> https://tools.ietf.org/html/rfc4960#appendix-C
>>
> 
> [Karen ] In this context then it is noteworthy to observe that SCTP defacto
> API (spec or implementations, I know)
> does not prescribe for that the SCTP transport passes information of
> received ICMP messages (any kind/type/code) up to SCTP User.
> Here SCTP is significantly different from UDP and TCP defacto APIs.
> 
> For security reasons SCTP  demands for hard reaction to receipt of protocol
> unreachable,
> but that is a protocol feature not an api issue.

Agreed, however the other ways that SCTP doesn't pass validated ICMPs to
the user seems like a mistake to me.

In particular, destination unreachables can cause the SCTP connection to
go into a dead state (mark the dest unreachable or increment the path
error counter) without indicating anything to the user.

This seems incorrect to me, given the number of other ways in which SCTP
can shut down a connection (heartbeat failure, retransmission failre)
and is supposed to pass that info to the user.

So, IMO, this is a great example of why studying these APIs as
abstractions is important and would have prevented this (IMO) oversight.

Or can someone in the SCTP team explain why shutting connections down
due to other reasons is a user signal but validated ICMP signals are not?

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

Hi, Karen,

On 7/16/2015 12:27 AM, Karen Elisabeth Egede Nielsen wrote:
...
>> So there are several levels of the latency issue:
>>
>>  - minimize the latency ADDED by the transport layer
>>  - reduce the latency seen by the app
>>  (which can involve more active interaction with the network
>>  layer, anticipation, etc.)
>>
>> Note also that latency is not a single metric nor a meaningful standalone
>> metric:
>>
>>  1. latency between two parties is a property *of a message*,
>>  i.e., it requires knowing the message size
>>
>>  2. latency includes both basic and higher order effects;
>>  the basic is "delay", the higher order include "jitter" etc.
>>  Many common delay-sensitive use cases are really mostly
>>  jitter sensitive.
>>
>> ...
> [Karen ] I agree so what do we mean in this document when we say that
> a transport service feature can be to provide minimal latency ?

There should probably be two levels:

- minimize what you add at the transport layer

- reduce even further

> Are we thinking about Nagle OFF ?

That is how TCP might react to a request to minimizing added latency,
but I don't expect a TAPS API should expose the specific knob of "Nagle".

>>> I am not sure if Connection oriented  and Feature negotiation should
>>> be split into two features ?
>>
>> If you don't share state (i.e., what we tend to call a "connection"),
> what is the
>> meaning of feature negotiation?
>>
> [Karen ] Yes, but does connection oriented necessarily means that you can
> negotiate features ?

Absolutely. Connection oriented means there is state that persists
between messages. To be useful, that state needs to be controllable.
Negotiating features *is* controlling that state.

...
>> So the general assumption that turning off Nagle will reduce latency
> should be
>> reasonable.
> [Karen ] I agree with this as a general assumption.
> But when I read the paragraph in the doc it almost sounds as if turning
> Nagle off comes with no price.

I would think that should be clarified.

>  Do you have a counterexample seen in the wild?
>
> [Karen ] Yes we have examples with NO Nagle where the number of packets
> then becomes the bottleneck.
> In the local ends (CPU) as well as in the infrastructure elements. I am
> not sure how much of this information I can share.
> I can try to find out. That is why I was saying that how to provide
> minimal latency may depend on the application traffic.

Because latency depends on the sizes of the messages, it should not be a
surprise that latency can't be minimized without that context.

> How to solve also depends on whether it is the average latency that needs
> to be minimal or whether the latency for some particular application
> "messages" should be kept as low as possible.

This is difficult for TCP to handle, because TCP thinks of the input
stream as an ordered sequence of bytes, and the issue of latency is
related to message boundaries within the TCP stream that are NOT part of
the TCP API (there's no way for an application to indicate those
boundaries to TCP - and no, the SEND boundaries are explicitly NOT those
markers).

> For SCTP we allow for that Nagle is disabled on some streams (streams with
> high scheduling priority) and not on others. This is done exactly for this
> purpose.

Sure, but that's also why it doesn't make sense for TCP.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 7/16/2015 12:01 AM, Karen Elisabeth Egede Nielsen wrote:
> HI Joe,
> 
> I generally agree with your comments, but the situations is not
> necessarily as bad as you say.
> Please see below.
...
>> Agreed, however the other ways that SCTP doesn't pass validated ICMPs to
>> the user seems like a mistake to me.
>>
> [Karen ] I agree and we have for our SW recently discussed as to whether
> we should implement such notification following
> the UDP and TCP semantics. But at present none of our applications has the
> need (on why that is, see below).

IMO, the spec is what is deficient, in not requiring that this
information be available to the application. It is always the
application's prerogative to ignore such signals.

>> In particular, destination unreachables can cause the SCTP connection to
> go
> [Karen ] MAY force. And this MAY of the RFC I  (and we) believe is
> questionable.  We believe that
> for an implementation to support this MAY the implementation MUST
> implement dormant state handling as
> described (right now) in the SCTP Failover draft = SCTP continues to
> transmit data also when the destinations are considered unreachable.

But the spec doesn't require that behavior. IMO, if the unreachable ends
up causing the connection to close, the application should be able to
figure out why.

...
> [Karen ] I agree that  when the association is closed as a direct result
> of receipt of ICMPs then this should be communicated to the Users.
> The envisaged approach (from our side) is to define a new error code for
> the sac_error of the SCTP_ASSOC_CHANGE (the notification of comm_LOST):
> 
>sac_error:  If the state was reached due to an error condition (e.g.,
>   SCTP_COMM_LOST), any relevant error information is available in
>   this field.  This corresponds to the protocol error codes defined
>   in [RFC4960].

Right - the issue is that COMMUNICATION LOST as described in RFC4960,
Sec 10.2, item "E", needs to include ICMP errors as a cause that
generates this error message. The current description covers only lost
heartbeats or aborts -- and while the ICMP could end up resulting in a
lost heartbeat, that's a different type of error to report as context.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 7/16/2015 2:40 AM, Michael Tuexen wrote:
>> [Karen ] We provide information about received destination unreachable
>> > ICMPs to users via socket api.
>> > The same we do for (connected) UDP.
>> > 
>> > This we could also do for SCTP, but as said we don't do it (yet).
>
> OK. FreeBSD does this. So it is not an issue with the specification,
> but an implementation issue.

IMO, it's a hole in the specification. It should be required by the
specification.

Yes, an implementation can exceed the specification, but that's
irrelevant to the discussion here, IMO.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 7/16/2015 3:26 AM, Karen Elisabeth Egede Nielsen wrote:
> I think that one could say that RFC4960 Appendix C prescriptions for how
> to handle soft icmps  could relate to that this can make the assocs enter
> dormant state fast and that dormant state implementation
> need to relate to this fact if the MAYs are followed.

Although that may be true for an implementation, the specification needs
to cover both sides of a MAY (i.e., what happens if the MAY is followed
and what happens when it is not).

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TAPS Transports and ICMP

[Joe Touch]

On 7/16/2015 1:56 AM, Michael Tuexen wrote:
>> > So, IMO, this is a great example of why studying these APIs as
>> > abstractions is important and would have prevented this (IMO) oversight.
>
> Can you say specifically, what has been missed?
> 
> My understanding is that SCTP and TCP are similar in respect to ICMP 
> processing
> with the difference that
> (a) SCTP ignore ICMP destination unreachable, port unreachable

When it MUST ignore those signals, that's fine.

> (b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP
> destination unreachable, protocol unreachable similar to an SCTP ABORT.

And this is the problem - when it acts on these signals, it never sends
any information to the user.

Further, ICMPs not otherwise defined are not required to be passed to
the application, as is required for TCP. That's a HUGE problem for ICMP
extensibility.

> The reason is that there are no legacy SCTP stacks sending ICMP destination 
> unreachable,
> port unreachable, so (a) is appropriate. (b) is for protecting hosts that 
> don't
> support SCTP.
> 
> The "handle like an ABORT" includes notifying the application.
> 
> The handling of ICMP Destination unreachable (host or network unreachable)
> is similar to the TCP case. If there is an SCTP state change, the user
> will be notified if requested.

That's not strictly required by the spec.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

Hi, Karen,

On 7/16/2015 12:57 AM, Karen Elisabeth Egede Nielsen wrote:
>> What portion of RFC793's API do you consider outdated?

> HI,
> 
> I was thinking about the PUSH flag mainly.
> 
> In our socket api implementation we do not allow for set of PUSH in send
> calls nor do we provide the PUSH flag indication upwards on the receiver
> side.

That's consistent with RFC1122, which updates RFC793.

> I think that after RFC793 it has been clarified that TCP MAY allow for set
> of PUSH flag in send() and MAY OPTIONALLY provide this information upwards
> on the receiver side.

Yes.

> I think that it would be questionable to follow RFC793 wording here on
> PUSH.

Sure; I was being broad in my reference back to RFC793; updates need to
be chased down too, so to the extent that the updates make RFC793
outdated, you're correct. However, the bulk of RFC793's API remains in
effect.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

Hi, Kasren,

[Michael]:
>>> For SCTP we allow for that Nagle is disabled on some streams (streams
>>> with high scheduling priority) and not on others. This is done exactly
>>> for this purpose.

[Joe]:
>> Sure, but that's also why it doesn't make sense for TCP.

> [Karen ] Yes and then also why Nagle off for TCP may give undesired and
> contra-productive results from a latency perspective.
> But then TCP applications may not typically have the application traffic
> patterns that gives these undesired latency effects of disabling Nagle.

The one thing we should have learned about TCP is to not make
assumptions about traffic patterns:

- (paraphrasing) after going idle, we need to decide whether to slam
CWND down or keep it open, and we need a "time since last sent"; we
don't have that timer, but because TCP traffic is mostly symmetric,
let's use "time since last received" (VJ88)
Result: burst the entire CWND on the next HTTP request

- TCP congestion control can assume infinite sources
Result: good performance for elephants but bad for mice
or transaction sequences (web)

- TCP should not send large amounts of small packets because they create
congestion, e.g., Telnet (Nagle)
Result: very bad delays on protocols where multibyte
messages can straddle packet boundaries, e.g.,
Telnet with Unicode, Web, etc.

i.e., Nagle fails exactly for the kinds of uses
it was intended

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

[Joe Touch]

+1

I have read this version in detail (and provided feedback), and think it
is a useful document.

Joe

On 10/5/2015 12:49 PM, Brian Trammell wrote:
> In transit, please excuse the brevity.
> 
> Broadly I appreciate the effort to do the decomposition in a less
> arbitrary way. I'm not convinced it's actually less arbitrary, but this
> is largely irrelevant: it's a *different* way to do the decomposition,
> so points of agreement (of which, at least on TCP and SCTP, there are
> many) reinforce confidence that we're doing this right. I tend to agree
> with Gorry's suggestion on the way forward.
> 
> Cheers, Brian
> 
> Sent from my iPhone
> 
> On 05 Oct 2015, at 11:42, Aaron Falk  > wrote:
> 
>> Have others read this draft yet?   It is clearly aimed at addressing
>> charter deliverable #1.  Do other folks have an opinion on how well it
>> helps the group achieve the goals in our charter?  Should we use this
>> document in some way? I'm looking for more input from the working
>> group on how we should proceed. 
>>
>> My opinion: I am very mindful (& appreciative) of the significant
>> effort by Mirja and Brian and the other contributors on
>> draft-ietf-taps-transports.The discussion around this doc has been
>> very useful for clarifying (to me) how difficult it can be to pull
>> useful common abstractions out of the 30+ years of transport
>> technologies.  Having been down this path for over a year, I
>> appreciate the fairly narrow approach draft-welzl-taps-transports and
>> think it may be the best chance for TAPS to succeed.  
>>
>> Please share your views.
>>
>> --aaron
>>
>>
>> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl > > wrote:
>>
>> +1
>>
>> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit
>> mailto:ma...@mjmontpetit.com>> wrote:
>> >
>> > Makes sense.
>> >
>> >> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk
>>  wrote:
>> >>
>> >> We seem to have two documents in a space where we started with
>> one. These
>> >> are different, to me this is OK. Both seem close to charter
>> milestone 1. I
>> >> don't see much overlap between the contents of the descriptive
>> language
>> >> and the API-focussed analysis, and any overlap could be eliminated.
>> >>
>> >> To me, doc 1 (current chartered item) can evolve to provide
>> background and
>> >> missing documentation for anyone in the IETF, and should compare
>> >> transports in a broad way and draw out the idea that they provide
>> >> services. This appears to be harder to get right than I for one
>> had hoped,
>> >> and still has a wide scope. Not a bad thing. I suggest it will
>> provide a
>> >> reference to stop us rat-holing when people ask what is "this"
>> and explain
>> >> how all these transports stack-up against one another (good
>> pun?). We can
>> >> (I suggest) finish this doc in this way.
>> >>
>> >> I do like the idea of a second document focussed ONLY on the
>> Transport API
>> >> (I'd call this 1a). In this we can avoid this"discussion of
>> what are
>> >> transports"  and move to  a  more focussed  process in doc 1b, 
>> Most of
>> >> that troublesome descriptive  text can go into 1, and ensure we
>> keep that
>> >> one readable to anyone in the  IETF.
>> >>
>> >> Could  I suggest the two docs against the first milestone will
>> help us
>> >> make  progress towards the next milestone faster. (Assuming we
>> can keep
>> >> the two aligned, which seems quite doable). I can see also how
>> the  docs
>> >> are useful to different people. I'd like to see both mature and
>> provide
>> >> inputs to move forward.
>> >>
>> >> Gorry
>> >>
>> >>
>> >>> Interesting and inline to getting transport API(s)
>> >>>
>> >>> Marie-José Montpetit
>> >>> ma...@mjmontpetit.com 
>> >>> mari...@mit.edu 
>> >>>
>>  On Sep 21, 2015, at 04:44, Michael Welzl > > wrote:
>> 
>>  Dear all,
>> 
>>  In my presentation in Prague, I proposed an approach to
>> identify the
>>  services that transport protocols provide. At the end of the
>> ensuing
>>  discussion, I said that I (with co-authors) would write a
>> draft that
>>  explains the proposal by applying the proposed method to TCP
>> and SCTP.
>> 
>>  We just submitted this document - see below;  I hope that
>> this will lead
>>  to some discussion on the list...
>> 
>>  Cheers,
>>  Michael
>> 
>> 
>> > Begin forwarded message:
>> >
>> > From: > >
>> > Subject: New Version Notification for
>> 

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Joe Touch]

On 11/3/2015 5:33 AM, go...@erg.abdn.ac.uk wrote:
> GF: From a TSVWG Chair perspective, beware here...  *ALL* more recent IETF
> SCTP API work from TSVWG is INFO.  Each SCTP RFC is expected to have an
> informative section that describes the API together with the normative
> protocol spec. That is not because there are expected to be alternatives
> to choose from:  It's because, as I understand, the IETF is not the formal
> standards body for specification of such normative APIs.

That has been a serious misinterpretation of how a protocol definition
works, which the IETF has propagated over the years.

The abstract APIs - above and below - of a protocol are a key part of a
protocol specification. More directly, a protocol definition is a FSM
that consists of:

- a finite state machine
- upper layer events (in/out)
i.e., the upper layer abstract API
the services that a protocol "creates"
- lower layer events (out/in)
i.e., the services on which the protocol relies
- time events
- rules that relate the items above

The way in which an abstract API is implemented as Unix sockets might be
informative to the IETF (but not, e.g., to the POSIX community), but the
abstract API cannot be. It has to be a normative part of the definition
of the protocol.

Otherwise, you end up with a protocol with no upper layer events or
actions, i.e., a tree falling in the woods with nobody to hear.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Joe Touch]

On 11/3/2015 10:37 PM, Karen Elisabeth Egede Nielsen wrote:
> HI Joe,
> 
> Yes I agree. But still there are finer features and BCP for api
> and protocol implementations that have appeared from the api's defined
> outside of the IETF and for which one need to look outside of RFC docs.

Oh, I was certainly not claiming that IETF specifications are always
complete. The key is to derive the abstract API requirement from the
implementation extensions (and update the spec, ultimately).

> Or for PUSH bit one can also look at RFC1122 which describes it as
> optional.

RFC1122 is a standards track doc that clearly updates RFC793, even
though that sort of marking was not part of IETF process when it was issued.

Joe

> 
> BR, Karen
> 
>> -Original Message-
>> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Joe Touch
>> Sent: 4. november 2015 02:44
>> To: go...@erg.abdn.ac.uk; Michael Welzl 
>> Cc: taps WG ; to...@isi.edu
>> Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
>>
>>
>>
>> On 11/3/2015 5:33 AM, go...@erg.abdn.ac.uk wrote:
>>> GF: From a TSVWG Chair perspective, beware here...  *ALL* more recent
>>> IETF SCTP API work from TSVWG is INFO.  Each SCTP RFC is expected to
>>> have an informative section that describes the API together with the
>>> normative protocol spec. That is not because there are expected to be
>>> alternatives to choose from:  It's because, as I understand, the IETF
>>> is not the formal standards body for specification of such normative
> APIs.
>>
>> That has been a serious misinterpretation of how a protocol definition
> works,
>> which the IETF has propagated over the years.
>>
>> The abstract APIs - above and below - of a protocol are a key part of a
>> protocol specification. More directly, a protocol definition is a FSM
> that
>> consists of:
>>
>>  - a finite state machine
>>  - upper layer events (in/out)
>>  i.e., the upper layer abstract API
>>  the services that a protocol "creates"
>>  - lower layer events (out/in)
>>  i.e., the services on which the protocol relies
>>  - time events
>>  - rules that relate the items above
>>
>> The way in which an abstract API is implemented as Unix sockets might be
>> informative to the IETF (but not, e.g., to the POSIX community), but the
>> abstract API cannot be. It has to be a normative part of the definition
> of the
>> protocol.
>>
>> Otherwise, you end up with a protocol with no upper layer events or
> actions,
>> i.e., a tree falling in the woods with nobody to hear.
>>
>> Joe
>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

[Joe Touch]

On 11/3/2015 5:27 PM, Karen Elisabeth Egede Nielsen wrote:
> HI,
> 
> As a general comment then I believe that when describing what is supported
> by TCP/SCTP (or UDP) as standard then it does not suffice to look into
> IETF RFCs.
> One need at least to relate to the *basic functions* of the POSIX/Berkeley
> socket api standard.
> 
> My understanding of the TCP API, for example, is that while RFC793 did
> specify an abstract API for TCP, then
> the true defacto standard for the socket api is the Berkeley socket api
> from .?. around 1990.
> Not saying the different socket api standards don't differ and that there
> is *one* standard to look at.
> But making is be RFC793 rather then what emerged as defacto in the 1990's
> seems a "bit odd" to me.

There are implementations of TCP that do not use the Berkeley sockets
model. Note, though, that the concept of a socket for communications
itself comes from RFC793, not Unix.

> Especially since we have RFCs RFC1122 dating back to 1989 already
> clarifying part of RFC793 (namely the PUSH bit)
> And one, much more recent, RFC6093, clarifying the urgent bit.

When we talk about TCP, we certainly mean more than just RFC793 - we
include all updates to that spec, which include these documents. In some
cases, the updates came from implementation experience; in other cases,
they came from the standards community because of more fundamental concerns.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] What about draft-moncaster-tsvwg-transport-services ?

[Joe Touch]

This might be a useful document, but it seems like it overlooks a few
"elephants in the room":

1) lots of services use TCP or UDP because they want to work through NATs

2) lots of services do just fine with the services provided by TCP or UDP

It would be useful to address those issues head-on. Otherwise, this
really looks like a group that's looking under its own lamppost for
solutions.

Joe

On 1/30/2016 12:40 AM, Michael Welzl wrote:
> Hi everyone,
> 
> Looking at the current charter items, when TAPS is over, folks will see
> RFCs describing services of transports, an overview of what a TAPS
> system should provide, and how it could be implemented - but they do
> lack background unless they read stuff elsewhere: why is a TAPS system
> even needed? What is so important about it? What are its benefits,
> compared to simply building your own protocol?
> 
> I think it makes sense to provide these answers in an RFC. As part of
> the effort to motivate the need for TAPS, such text was written up in
> draft-moncaster-tsvwg-transport-services
> https://tools.ietf.org/html/draft-moncaster-tsvwg-transport-services-01
> 
> Is this group interested in taking this document further? What do y’all
> think?
> 
> Cheers,
> Michael
> 
> 
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] What about draft-moncaster-tsvwg-transport-services ?

[Joe Touch]

On 1/30/2016 11:59 PM, Michael Welzl wrote:
...
> The main question on the table is: provided that we'll incorporate
> such comments, should this be a product of the WG?

It's not clear it's a separate doc. It might be more useful as part of
the use case description of other docs, but there's no good reason to
force that decision now.

IMO, some of this justification clearly needs to be clarified, but I'm
not entirely sure where it best belongs.

I do disagree that this should happen when we're done; IMO, we need this
context to know whether we're all talking about the same kind of
problem. In fact, it looks a lot like a problem statement, which more
typically *precedes* other WG output.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/3/2016 5:20 PM, Toerless Eckert wrote:
> Eg: Consider someone used the transport service definitions of this drat 
> randomnly,
> there is no way to figure out which would or would not succeed, because 
> there is
> no definition how send/received packets are associated to transport 
> service endpoints.
> 
> Example: LISTEN.UDP:
>   Pass 1 primitive: 'receive'.
>   Parameters: 1 local IP address (optional); 1 destination transport 
> address.

It should be:

local IP address or ANY
it's not really "optional"; it's more like
ANY is the default until overridden

local port (selected explicitly or "let the OS pick")

remote IP address or ANY (same thing as above)

remote port or ANY

NOTE: any of these can be indicated for most existing implementations of
UDP. The local side is set using the BIND call and the remote side set
using the CONNECT call - which is a bit confusing because UDP is
connectionless.

That's why the CONNECT used here is confusing - it's used more like BIND
than CONNECT and ignores the existing CONNECT semantics.



Note that this should allow some cases that aren't really well
understood or implemented, e.g.:

two different OS endpoints listen as follows:
A on loc-IP ANY loc-port 80
B on loc-IP 10.0.0.1 loc-port 80

I.e., there's ambiguity as to whether ANY means EVERY or "any except
those more specifically bound".



Additionally, there's no such thing as CLOSE for UDP. CLOSE happens on
the OS endpoint, not the connection.

AFAIR, this is the difference between unix close() and shutdown(). The
former disconnects both the connection and the OS endpoint, whereas the
latter "undoes" the corresponding connect() but not the socket creation,
allowing half-open connections (I wonder - is shutdown() implemented for
UDP? does it clear out the remote IP/port expectations?)

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/4/2016 10:31 AM, Joe Touch wrote:
> AFAIR, this is the difference between unix close() and shutdown(). The
> former disconnects both the connection and the OS endpoint, whereas the
> latter "undoes" the corresponding connect() but not the socket creation,
> allowing half-open connections (I wonder - is shutdown() implemented for
> UDP? does it clear out the remote IP/port expectations?)

Just dug a bit deeper - seems like shutdown() [in man section 3] just
decouples the send and receive close of the unix socket, so it still
does both connection and OS endpoint operations but decouples send and
receive.

I have not found an operation that lets you specifically close a TCP
connection without affecting the unix socket (i.e., to issue a half
close but not disconnect the send side of the OS endpoint) - though that
might not have any useful meaning.

For UDP, I wonder what happens if you issue multiple connects...

(if I have time, I'll try this and check, but if others have experience,
let us know)

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/3/2016 4:54 AM, go...@erg.abdn.ac.uk wrote:
> When someone talks about using TCP or SCTP then they are typically using
> an API to the transport that hides a lot of details.

I'm not sure I agree with this.

IMO, TCP defines an API that is intended to provide a service capability
that it renders on top of less-capable underlying services.

UDP does this much less so, so that might be a simpler place to start,
but only because the level of service is simpler - not because of
"hiding a lot of details".

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

Hi, Gorry,

On 4/4/2016 10:55 AM, go...@erg.abdn.ac.uk wrote:
> I was thinking in terms of what we were trying to achieve within TAPS, and
> from that perspective things like: ECN-marks, Maximum datagram/segment
> size, etc. I do not think through the TCP API (for instance), since these
> concern the path and are only needed by CC or PMTUD algorithms within TCP.
>
> These same values do need to be accessed (visible) over the current UDP
> API so that apps can implement mechanisms that use these.

These are different things, IMO.

The TCP API needs a way to set any flags in the TCP header, either
directly or indirectly.

TCP does NOT require a way to set the MSS or segment size, IMO - that
ought to be something it figures out from the interface parameters, IP
settings, remote end, and path. It may be useful to set these things for
instrumentation purposes, but not for regular operation.

For MSS and segment size, the same ought to be true for UDP.

For ECN, UDP ought to be ignorant - as should its API. The only question
is whether the UDP API should have a "pass through" for signals from
lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the
UDP API; they're part of the OS endpoint API to these other protocols.

Joe

> 
> Gorry
> 
>> On 4/3/2016 4:54 AM, go...@erg.abdn.ac.uk wrote:
>>> When someone talks about using TCP or SCTP then they are typically using
>>> an API to the transport that hides a lot of details.
>>
>> I'm not sure I agree with this.
>>
>> IMO, TCP defines an API that is intended to provide a service capability
>> that it renders on top of less-capable underlying services.
>>
>> UDP does this much less so, so that might be a simpler place to start,
>> but only because the level of service is simpler - not because of
>> "hiding a lot of details".
>>
>> Joe
>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/4/2016 11:24 AM, go...@erg.abdn.ac.uk wrote:
> Hi Joe,
> 
> We don't seem to be agreeing.

Not yet at least ;-)

...
>> For MSS and segment size, the same ought to be true for UDP.
>>
> No. It's true that UDP needs to know this, but this info needs to arrive
> at the App, either from a primitive that returns the size or from a failed
> send call when probing for a maximum datagram size. The app also may need
> to control DF if it wants to do path probing of PMTU, whereas in TCP this
> is handed within the transport protocol..

Ahh - I see this now. However, IMO, that ought to be something it gets
from the IP layer, not from UDP. UDP has an MSS that's defined by the
protocol itself which is not all that useful to indicate to the app.

>> For ECN, UDP ought to be ignorant - as should its API. The only question
>> is whether the UDP API should have a "pass through" for signals from
>> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the
>> UDP API; they're part of the OS endpoint API to these other protocols.
>>
> I don't understand what you are saying about an "OS endpoint API to IP".
> To me the API has to signal per-datagram on send whether ECT(0) or ECT(1)
> or neither is to be set, the receive API needs to see the received ECN
> field for each datagram.
> 
> Do you see a different way to do this?

Here's the issue - when a message arrives, right now we think of it
being "from UDP" as part of the UDP API. However, there are no ECN
markings in UDP. It makes sense to forward the IP source/dest in the UDP
API because that part of the IP header is defined as part of UDP (as the
pseudoheader). However, it makes no sense to have that information
available as part of what UDP passes to the app per se.

So maybe each UDP message is allowed to forward a single opaque (to UDP)
structure that contains information from any of its underlying layers
(i.e., a pass-through signal mechanism). But I would consider that not
really integral to the API of UDP.

I do agree this needs to be per message, not per endpoint.

Joe



> 
> Gorry
> 
>> Joe
>>
>>>
>>> Gorry
>>>
 On 4/3/2016 4:54 AM, go...@erg.abdn.ac.uk wrote:
> When someone talks about using TCP or SCTP then they are typically
> using
> an API to the transport that hides a lot of details.

 I'm not sure I agree with this.

 IMO, TCP defines an API that is intended to provide a service
 capability
 that it renders on top of less-capable underlying services.

 UDP does this much less so, so that might be a simpler place to start,
 but only because the level of service is simpler - not because of
 "hiding a lot of details".

 Joe

 ___
 Taps mailing list
 Taps@ietf.org
 https://www.ietf.org/mailman/listinfo/taps

>>

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/4/2016 12:49 PM, go...@erg.abdn.ac.uk wrote:
...
>>> No. It's true that UDP needs to know this, but this info needs to arrive
>>> at the App, either from a primitive that returns the size or from a
>>> failed
>>> send call when probing for a maximum datagram size. The app also may
>>> need
>>> to control DF if it wants to do path probing of PMTU, whereas in TCP
>>> this
>>> is handed within the transport protocol..
>>
>> Ahh - I see this now. However, IMO, that ought to be something it gets
>> from the IP layer, not from UDP. UDP has an MSS that's defined by the
>> protocol itself which is not all that useful to indicate to the app.
>>
> I see what you are saying for reading the MTU less headers, but whatever
> the method, the APP needs to work out what to do with this. For setting DF
> this is not necessarily an IP setting for all packets, it can be a per UDP
> datagram choice.

Sure, but again that argues for a transparent supplement to the UDP API,
not for a UDP-specific API.

 For ECN, UDP ought to be ignorant - as should its API. The only
 question
 is whether the UDP API should have a "pass through" for signals from
 lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the
 UDP API; they're part of the OS endpoint API to these other protocols.

>>> I don't understand what you are saying about an "OS endpoint API to IP".
>>> To me the API has to signal per-datagram on send whether ECT(0) or
>>> ECT(1)
>>> or neither is to be set, the receive API needs to see the received ECN
>>> field for each datagram.
>>>
>>> Do you see a different way to do this?
>>
>> Here's the issue - when a message arrives, right now we think of it
>> being "from UDP" as part of the UDP API. However, there are no ECN
>> markings in UDP. It makes sense to forward the IP source/dest in the UDP
>> API because that part of the IP header is defined as part of UDP (as the
>> pseudoheader). However, it makes no sense to have that information
>> available as part of what UDP passes to the app per se.
>>
>> So maybe each UDP message is allowed to forward a single opaque (to UDP)
>> structure that contains information from any of its underlying layers
>> (i.e., a pass-through signal mechanism). But I would consider that not
>> really integral to the API of UDP.
>>
>> I do agree this needs to be per message, not per endpoint.
>>
> That sounds a lot like you are thinking about a concrete API.

Way more abstract. The issue is that these features are not inherent in
UDP - they are inherent in the IP over which UDP runs (and depend on
that IP version).

> And I agree,
> to implement this, you can do exactly that and provide additional data per
> datagram buffer to communicate the DSCP, ECN, TTL ...

My point is that - at the abstract level - UDP should not have an API
that talks about DSCP, ECN, or TTL - that ought to be something opaque
that UDP hands down underneath.

We shouldn't need to update the UDP API whenever IP or other layers change.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/4/2016 3:31 PM, go...@erg.abdn.ac.uk wrote:
>> My point is that - at the abstract level - UDP should not have an API
>> > that talks about DSCP, ECN, or TTL - that ought to be something opaque
>> > that UDP hands down underneath.
>> >
> And does this particular list of things vary between IPv4 or IPv6? - I
> suggest not really, apart from different naming of the TTL to HOP_COUNT?

IPv6 has a flow label.

They support different options, including:
IPv6 doesn't add an ID field unless fragmentation occurs.
IPv6 allows jumbograms.

Regardless, these are IP issues, though - they should be transparent at
the UDP API (though the UDP API could support passing this info opaquely
along in either direction).

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/6/2016 9:39 AM, go...@erg.abdn.ac.uk wrote:
...
>> I'm reading parts of draft-fairhurst-taps-transports-usage-udp-01
>> because it was presented in the Dispatch session of the meeting, so I
>> don't have all the context for this draft.  But a couple of comments
>> struck me:
>>
>> The description seems to be connection-oriented, in that it only
>> describes usages involving two endpoints establishing a connection and
>> then using it.  Indeed, even the process of establishing a listening
>> port based on which connections will be created is not described.  E.g.,
>> the description of the CONNECT primitive says "The CONNECT primitive
>> allows the association of source and port sets to a socket ...", but
>> doesn't describe where the socket comes from, or that packets can arrive
>> on a socket before the receiver has done a CONNECT.

For connection-oriented protocols, this should never happen.

For connectionless protocols, "CONNECT" is often the basic primitive by
which a user indicates the socket pair (address/port) of the remote end.

It would be useful to separate these two concepts:

- pinning parameters of the remote socket pair
- establishing pairwise state

...
>> Perhaps these concepts are discussed in the document that establishes
>> the framework for this draft.  At the least, the use of listening ports
>> needs to be formalized.
>>
> I probably need help - I think there are different many ways in which UDP
> uses ports. Offers from anyone on how to get started would be great.

See below.

I'm glad to help with this further if useful - some additional notes below:

Joe

Pass1:

First, it would be useful to introduce the idea of a communication
endpoint as seen from inside a program (or the OS). Unix uses the term
"socket" for this (which is awful because we use the term "socket pair"
to mean something different).

I'd suggest using the term "CHANNEL" at least for now.

So the primitives needed, *assuming an OS primitive to create a new,
blank CHANNEL*, are:

SET_LOCAL_SOCKETPAIR CHANNEL IP? PORTNUM?
nail down specific local IP address and/or port numbers
as associated with a CHANNEL object

corresponds to bind() in Unix...

SET_REMOTE_SOCKETPAIR CHANNEL IP? PORTNUM?
nail down specific remote IP address and/or port numbers
as associated with a CHANNEL object

corresponds to connect() in Unix (yes, for UDP, even
though it is connectionless)

SEND CHANNEL MESSAGE (IP PORTNUM)? PARAMS?
emit a UDP message with the indicated contents
over the indicated channel
if the CHANNEL does not have a set remote socket
pair, then also requires the remote socketpair

RECEIVE CHANNEL PARAMS?
obtain a UDP message from the indicated CHANNEL
returns the message and its remote socketpair

Send and receive may have per-message parameters that are optional, as
indicated above.

Note that I've deliberately avoided a few terms and reused others. I
can't find better words for send/receive than those, but I would never
think of "listen" as something that necessarily returns a message (it
might return an indicator that a message is available, in the manner of
the select() call)

I don't think it makes sense to talk about CLOSE in any way for UDP
connections. At best, we would talk about discarding the CHANNEL object.

And yes, I don't think you can talk about any of this without a model
for the process/OS side of the communication entity.

Joe



___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/7/2016 11:44 AM, Dale R. Worley wrote:
> Joe Touch  writes:
>> For connectionless protocols, "CONNECT" is often the basic primitive by
>> which a user indicates the socket pair (address/port) of the remote end.
> 
> The trouble I see is that the concept of "listening" is not covered.

It depends on what you mean by "listen".

If you mean "wait for a message", that's a "read"

If you mean "coordinate state with the other end", that is not part of
UDP semantics.

> The passive or listening endpoint doesn't initiate a "connect" operation
> to indicate the address/port of the remote end, that is indicated by the
> arrival of a packet from the remote end.  As I read the draft, it seems
> to assume that both ends can do a "connect" before they exchange any
> packets at all.

IMO that's a failure of the current text to match UDP semantics.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01

[Joe Touch]

On 4/7/2016 11:42 AM, Dale R. Worley wrote:
> go...@erg.abdn.ac.uk writes:
>> I agree - the current format from the text comes from the existing text 
>> for TCP and SCTP in another draft. and I think we  may need to work out
>> how to handle
>> [...]
>> I probably need help - I think there are different many ways in which UDP
>> uses ports. Offers from anyone on how to get started would be great.
> 
> Even in TCP, the semantics of connection setup is more complicated that
> you'd think at first.  If I have it correctly, it runs:
> 
>   Passive Active
>   EndpointEndpoint
> 
>   Create socket
>   Bind socket to listening address

There's a step here where you get to set the limit on how many pending
connection requests can be allowed (the listen() call), but that's an
OS-ism IMO, not a protocol or API issue.

>   Activate listening
> 
>   Create socket

optionally bind to local address

>   Connect
> 
>   Incoming connection event
>   Accept connection

an optional parameter to this accept call involves whether the remote
socket pair is specified or not.

> At least in the protocol, it's possible for both endpoints to be active,
> but they have to have prior agreement regarding the addresses and ports

almost - they only need to agree on the port one one side exactly; in
both cases, the addresses need to reach each other but could be one of
any number of addresses on the machine.

E.g.:

A calls B.alpha using dest port 80
while
B calls A.omega using source port 80

> and send their initial packets within one RTT of each other, so I don't
> know if that possibility is ever used in practice. 

It happens routinely if you end up calling yourself.

> Or whether the
> Berkeley sockets API supports it.

It should, as per above.

> OTOH, the TAPS work might not be attempting to capture the semantics of
> connection setup.

It had better, IMO.

> The process for UDP is not much simpler.  My memory is:
> 
>   Passive Active
>   EndpointEndpoint
> 
>   Create socket
>   Bind socket to listening address
you only need to bind to a port; the address can float

you can optionally also lock the remote address using the "connect"
call, even though it doesn't issue a connection.

>   Create socket
>   Send-to -or- Connect, then Send

or bind too. Same reasons - you can pin the local or remote socket pair.


>   Incoming connection event
>   Connect (in the TAPS paradigm)

IMO, this should be removed. There can't be state associated with UDP.

>   Incoming packet event
>   Receive packet

The receive packet for UDP passes more information than for TCP; in UDP,
you need to indicate where the message came from too.

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] About old APIs from RFCs, and TAPS' real goal

[Joe Touch]

On 4/27/2016 1:16 AM, Michael Welzl wrote:
> Thinking about Toerless' general point of using more modern APIs made
> me think of the bigger picture again. For example, one cool recent
> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows
> better control of the sender buffer. Not including it in an API
> document "sucks" and it IS nice to include it in a description of an
> API.

This is an interesting example. It affects how a user-level process
interacts with the protocol implementation inside the OS but has NOTHING
to do with TCP.

I'm not sure where I would put that. It clearly isn't part of the TCP
API. Nor, e.g., would be the "nice" level of the process that's feeding
data to TCP -- yet both could affect performance between two applications.

It seems like there's a gap here you could drive a truck through that
needs to be addressed. I'm not sure where, though - i.e., whether this
is part of TAPS or not.

Joe



___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] About old APIs from RFCs, and TAPS' real goal

[Joe Touch]

On 6/6/2016 1:17 AM, Michael Welzl wrote:
>> On 27 Apr 2016, at 23:25, Joe Touch  wrote:
>>
>>
>>
>> On 4/27/2016 1:16 AM, Michael Welzl wrote:
>>> Thinking about Toerless' general point of using more modern APIs made
>>> me think of the bigger picture again. For example, one cool recent
>>> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows
>>> better control of the sender buffer. Not including it in an API
>>> document "sucks" and it IS nice to include it in a description of an
>>> API.
>> This is an interesting example. It affects how a user-level process
>> interacts with the protocol implementation inside the OS but has NOTHING
>> to do with TCP.
>>
>> I'm not sure where I would put that. It clearly isn't part of the TCP
>> API. Nor, e.g., would be the "nice" level of the process that's feeding
>> data to TCP -- yet both could affect performance between two applications.
>>
>> It seems like there's a gap here you could drive a truck through that
>> needs to be addressed. I'm not sure where, though - i.e., whether this
>> is part of TAPS or not.
> Not part of TAPS I think, because it's not related to automatizing the use of 
> protocols other than TCP or UDP.

Please explain why you think that's true.

AFAICT, it's fundamental to how any protocol interacts with the OS.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] About old APIs from RFCs, and TAPS' real goal

[Joe Touch]

On 6/6/2016 11:20 AM, Michael Welzl wrote:
>> On 6. jun. 2016, at 19.15, Joe Touch  wrote:
>>
>>
>>
>> On 6/6/2016 1:17 AM, Michael Welzl wrote:
>>>> On 27 Apr 2016, at 23:25, Joe Touch  wrote:
>>>>
>>>>
>>>>
>>>> On 4/27/2016 1:16 AM, Michael Welzl wrote:
>>>>> Thinking about Toerless' general point of using more modern APIs made
>>>>> me think of the bigger picture again. For example, one cool recent
>>>>> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows
>>>>> better control of the sender buffer. Not including it in an API
>>>>> document "sucks" and it IS nice to include it in a description of an
>>>>> API.
>>>> This is an interesting example. It affects how a user-level process
>>>> interacts with the protocol implementation inside the OS but has NOTHING
>>>> to do with TCP.
>>>>
>>>> I'm not sure where I would put that. It clearly isn't part of the TCP
>>>> API. Nor, e.g., would be the "nice" level of the process that's feeding
>>>> data to TCP -- yet both could affect performance between two applications.
>>>>
>>>> It seems like there's a gap here you could drive a truck through that
>>>> needs to be addressed. I'm not sure where, though - i.e., whether this
>>>> is part of TAPS or not.
>>> Not part of TAPS I think, because it's not related to automatizing the use 
>>> of protocols other than TCP or UDP.
>> Please explain why you think that's true.
>>
>> AFAICT, it's fundamental to how any protocol interacts with the OS.
> Yes it is, but it’s also orthogonal to the choice of protocol - as you said, 
> it really has nothing to do with TCP.
Yes, but configuration of the OS interface isn't orthogonal to that choice.

I.e., constraints of the OS interface may play into the decision of
which transport to use, and which transport is chosen may affect the
configuration of that OS interface.

> Using my typical example again: you can’t use an SCTP mechanism like e.g. 
> unordered message delivery without knowing that the application wants it, or 
> else you’ll break the semantics of the application data stream.
> It's is a mechanism of SCTP that simply cannot be used unless it’s chosen via 
> an API.
>
> Can you say the same about this SO_SNDLOWAT stuff?  As far as I’m concerned 
> such send buffer management is an implementation detail - you could implement 
> this very well or extremely badly for every protocol

The way the OS relays  information to the transport IS a protocol - just
not one that involves communication on the wire. It significantly
affects the way in which the transport operates.
>  - but even an implementation that gives you almost no choice of what goes on 
> in the buffer does not prohibit you from using a mechanism that a protocol 
> provides. 
Sure, but if you're trying to set TCP to very low latency and use a huge
socket buffer, you could easily be creating huge delays and jitter in
the interaction between the process scheduling to fill the buffer and
the transfer of info into TCP.
> It’s a different matter, because the semantics stay unaltered: if you set the 
> buffer very small with SO_SNDLOWAT, TCP will just fail on you. It’s not going 
> to lose any packets, it stays reliable. If you could make it lose packets by 
> changing SO_SNDLOWAT, that would be a different matter I think...
It might not affect TCP, but it could affect a protocol that can choose
between ARQ and FEC and use ARQ only where the latency budget permits.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Joe Touch]

On 7/19/2016 5:27 AM, Michael Welzl wrote:
> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS 
> is the day after, which fits nicely.
>
> Note, I phrased this controversial on purpose to generate a bit of list 
> discussion: “abstracting away” something like usage of multiple paths should 
> get some people to disagree?! Regarding the primitives we have so far, there 
> doesn’t seem to be a compelling need for a TAPS system to expose them to an 
> application I think.  (again, such abstraction always comes with loss of some 
> control - at one end of this, you want to be in control of which transport 
> protocol is used, which we don’t want here). Decisions need to be made...
>
>
> Multi-streaming seems to me to be an easier case: I can’t see any reason why 
> an application would need to be in control of this. Mapping communication 
> channels between the same end hosts onto the same transport connection 
> (whatever protocol provides it) should always be beneficial.

I'm not sure I understand how an app can/should know about any of this.
It strikes me as involving the app deep in "how" things are done in
other layers, rather than indicating a preference on behavior it sees
(it really shouldn't "see" any of this directly, IMO).

I.e., this would be a good place to take a lesson from QoS - the key is
to indicate a preference to the net based on "application visible
behavior", not to try to map things so directly based on semantics.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Joe Touch]

On 7/19/2016 8:49 AM, Michael Welzl wrote:
>> On 19. jul. 2016, at 17.40, Joe Touch  wrote:
>>
>>
>>
>> On 7/19/2016 5:27 AM, Michael Welzl wrote:
>>> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS 
>>> is the day after, which fits nicely.
>>>
>>> Note, I phrased this controversial on purpose to generate a bit of list 
>>> discussion: “abstracting away” something like usage of multiple paths 
>>> should get some people to disagree?! Regarding the primitives we have so 
>>> far, there doesn’t seem to be a compelling need for a TAPS system to expose 
>>> them to an application I think.  (again, such abstraction always comes with 
>>> loss of some control - at one end of this, you want to be in control of 
>>> which transport protocol is used, which we don’t want here). Decisions need 
>>> to be made...
>>>
>>>
>>> Multi-streaming seems to me to be an easier case: I can’t see any reason 
>>> why an application would need to be in control of this. Mapping 
>>> communication channels between the same end hosts onto the same transport 
>>> connection (whatever protocol provides it) should always be beneficial.
>> I'm not sure I understand how an app can/should know about any of this.
>> It strikes me as involving the app deep in "how" things are done in
>> other layers, rather than indicating a preference on behavior it sees
>> (it really shouldn't "see" any of this directly, IMO).
>>
>> I.e., this would be a good place to take a lesson from QoS - the key is
>> to indicate a preference to the net based on "application visible
>> behavior", not to try to map things so directly based on semantics.
> This sounds like a misunderstanding, maybe I didn’t make myself clear enough 
> - because I think we agree:
> an application can / should not know about any of this, IMO. It should just 
> see a communication channel.
>
> So mapping these channels onto a transport connection is what I thought a 
> TAPS system underneath the application could do, and the application won’t 
> need to be bothered.
 I was speaking to the broader point of this thread and generalizing
your point about multi-streaming to the multiple path case as well.

(I didn't know if you felt that both cases should be handled the same
way or whether you were using multi-streaming as an easier case to argue)

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Joe Touch]

On 7/19/2016 9:05 AM, Mirja Kühlewind wrote:
> Hi,
>
> for multicast there is the simple example where one access network is more 
> expensive to use than the other (in the sense where the user gets a bill at 
> the end). In this case the user would potentially rather except a disconnect 
> for a short time than sending data unnecessary over the expensive links (and 
> the link should only be used if no other one is available).

That's a great example - expense is the application criteria. That
criteria is enough for the net to make a decision without needing the
app to be involved.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-fairhurst-taps-transports-usage-udp-03.txt

[Joe Touch]

On 10/10/2016 3:15 AM, Gorry (erg) wrote:
> ... There is no document in the RFC series that document UDP API - this may 
> be helpful roadmap to find this info. Two documents are easier to maintain 
> and cite than one.

RFC1122 defines one in Section 4.1.4, but it basically points off to a
definition of the IP API in Section 3.4, which ignores the issue of
controlling source and destination ports.

The true UDP API ought to be defined in the same way the TCP API is
defined in RFC793, FWIW.

I've proposed a way forward for UDP options; as a result, I'd be glad to
take a shot at a draft UDP API doc if useful.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-fairhurst-taps-transports-usage-udp-03.txt

[Joe Touch]

Hi, Gorry (et al.),

On 10/10/2016 9:56 AM, go...@erg.abdn.ac.uk wrote:

> ...
> OK, so in the context of TAPS, the WG called for a list of UDP services.
> This is what is in the  ID. ...
>
> This ID clearly isn't an API spec.
>
> ...
> I don't personally know whether an API spec for UDP is useful or not, but
> suspect the list of services needed by UDP Apps is the thing the WG is
> presnetly looking for.

I have to admit I have no idea what you mean by "the list of services
needed by UDP Apps" if that doesn't basically start and end with the UDP
API.

Anything else needed by UDP apps isn't needed because they're UDP. And
having that list (of "things besides the UDP API") without a proper UDP
API wouldn't be very useful.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

FYI, there are two different "largest messages" at the transport layer:

1) the size of the message that CAN be delivered at all

2) the size of the message that can be delivered without network-layer
fragmentation (there are no guarantees about link-layer - see ATM or the
recent discussion on tunnel MTUs on INTAREA)

MTU generally refers to the *link payload*. At that point, transports
have to account for network headers, network options, transport headers,
and transport options too. See RFC6691.

MSS refers to the transport message size AFAICT. It is *sometimes* tuned
to MTU-headers but not always.

E.g., for IPv6, link MTU is required to be at least 1280, but the
src-dst transit MTU is required to be at least 1500. So a transport that
wants to match sizes and reduce fragmentation issues would pick
1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time.

Joe


On 12/7/2016 6:54 AM, Michael Welzl wrote:
> Hi all,
>
> I have a problem with one particular primitive, or lack of it, in UDP, 
> UDP-Lite and SCTP. It's something I just don't get.
>
> Consider this text from draft-fairhurst-taps-transports-usage-udp:
>
> "GET_INTERFACE_MTU:  The GET_INTERFACE_MTU function a network-layer
>   function that indicates the largest unfragmented IP packet that
>   may be sent."
>
> Indeed, this is a network-layer function. It's about the interface, not about 
> UDP. Does that mean that, to decide how many bytes fit in the payload of a 
> packet, the programmer needs to know if it's IPv4 or IPv6, with or without 
> options, and do the calculation?
> If so, isn't it extremely odd that UDP doesn't offer a primitive that 
> provides a more useful number: the available space in its payload, in bytes?
>
> I also have the same question for SCTP.  For TCP, it's obvious that the 
> application shouldn't bother, but not for UDP or SCTP.
> At the last meeting, knowing the MTU was mentioned as one of the needs that 
> latency-critical protocols have. I understand that - but I didn't include 
> this primitive in the last version of the usage draft because it is a 
> network-layer primitive... now I don't know how to approach this.
>
> Thoughts? Suggestions?
>
> Cheers,
> Michael
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 12:09 AM, Michael Welzl wrote:
>> On 07 Dec 2016, at 20:29, Joe Touch  wrote:
>>
>> FYI, there are two different "largest messages" at the transport layer:
>>
>> 1) the size of the message that CAN be delivered at all
> True... I wasn't thinking of that, but yes.
>
>
>> 2) the size of the message that can be delivered without network-layer
>> fragmentation (there are no guarantees about link-layer - see ATM or the
>> recent discussion on tunnel MTUs on INTAREA)
>>
>> MTU generally refers to the *link payload*. At that point, transports
>> have to account for network headers, network options, transport headers,
>> and transport options too. See RFC6691.
>>
>> MSS refers to the transport message size AFAICT. It is *sometimes* tuned
>> to MTU-headers but not always.
>>
>> E.g., for IPv6, link MTU is required to be at least 1280, but the
>> src-dst transit MTU is required to be at least 1500. So a transport that
>> wants to match sizes and reduce fragmentation issues would pick
>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time.
> So I'm getting the impression that the answer to my question really is that, 
> to figure out 2)  (which I was concerned with), an application programmer 
> needs to do the calculation her/himself.

To figure out 2), the transport layer needs to know the unfragmented
link MTU, the size of all of the network headers (including options),
and the sizes of its own headers and options.

It's also sometimes assumes that the transport can control the "DF" bit
(for IPv4).

However, this all breaks down if the app makes the wrong choice because
the net can (will, and should) source fragment if it gets a message that
turns out  to be too big for one fragment anyway.

> Not a big deal - and maybe some systems offer a function to give you the size 
> of a message that won't be fragmented.

Remember that - at best - you're optimizing for the next layer down
only. You can't know whether that net layer message is link fragmented
(e.g., as in ATM) or tunnel fragmented (as needs to be required or this
whole MTU concept breaks down).

>
> However: this calculation is transport protocol dependent, which we really 
> don't want to have in TAPS.

If you want to fix this, you need to change the API to the net layer to
provide immediate feedback. When transport hands a segment to network,
it has to get a "call failed" if the message is too big - and we really
do need transport layers to be able to pick between "too big for
non-fragmented net layer" and "too big for the net layer even with frag".

Merely handing info to the transport layer might not be enough, esp.
when net layer option lengths change.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 8:12 AM, Michael Welzl wrote:
>> On 09 Dec 2016, at 16:18, Joe Touch  wrote:
>>
>>
>>
>> On 12/9/2016 12:09 AM, Michael Welzl wrote:
>>>> On 07 Dec 2016, at 20:29, Joe Touch  wrote:
>>>>
>>>> FYI, there are two different "largest messages" at the transport layer:
>>>>
>>>> 1) the size of the message that CAN be delivered at all
>>> True... I wasn't thinking of that, but yes.
>>>
>>>
>>>> 2) the size of the message that can be delivered without network-layer
>>>> fragmentation (there are no guarantees about link-layer - see ATM or the
>>>> recent discussion on tunnel MTUs on INTAREA)
>>>>
>>>> MTU generally refers to the *link payload*. At that point, transports
>>>> have to account for network headers, network options, transport headers,
>>>> and transport options too. See RFC6691.
>>>>
>>>> MSS refers to the transport message size AFAICT. It is *sometimes* tuned
>>>> to MTU-headers but not always.
>>>>
>>>> E.g., for IPv6, link MTU is required to be at least 1280, but the
>>>> src-dst transit MTU is required to be at least 1500. So a transport that
>>>> wants to match sizes and reduce fragmentation issues would pick
>>>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
>>>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the 
>>>> time.
>>> So I'm getting the impression that the answer to my question really is 
>>> that, to figure out 2)  (which I was concerned with), an application 
>>> programmer needs to do the calculation her/himself.
>> To figure out 2), the transport layer needs to know the unfragmented
>> link MTU, the size of all of the network headers (including options),
>> and the sizes of its own headers and options.
>>
>> It's also sometimes assumes that the transport can control the "DF" bit
>> (for IPv4).
> Yes - but that hardly sounds worse to me than requiring the application 
> programmer to do this protocol-specific calculation by hand...

The app programmer needs to know what the transport can support, the
transport needs to know what net supports, etc.

Pushing the link MTU up the line and expecting all the other layers to
figure out what to do results in unnecessary complexity, never mind
undermining one of the key features of layering.

>
>> However, this all breaks down if the app makes the wrong choice because
>> the net can (will, and should) source fragment if it gets a message that
>> turns out  to be too big for one fragment anyway.
>>
>>> Not a big deal - and maybe some systems offer a function to give you the 
>>> size of a message that won't be fragmented.
>> Remember that - at best - you're optimizing for the next layer down
>> only. You can't know whether that net layer message is link fragmented
>> (e.g., as in ATM) or tunnel fragmented (as needs to be required or this
>> whole MTU concept breaks down).
> Sure - but that's something end systems just can't see. It's information up 
> to and including the IP layer that should be correctly handed over up the 
> stack, inside the host, with all the caveats this information comes with.
Why does that apply at the link layer but not other layers? If transport
can transfer and reassemble 1MB messages, then that's the "MTU" it needs
to tell the app layer. The same is true for net to tell transport, etc.

We've conflated the two between transport and net unnecessarily.

>
>>> However: this calculation is transport protocol dependent, which we really 
>>> don't want to have in TAPS.
>> If you want to fix this, you need to change the API to the net layer to
>> provide immediate feedback. When transport hands a segment to network,
>> it has to get a "call failed" if the message is too big - and we really
>> do need transport layers to be able to pick between "too big for
>> non-fragmented net layer" and "too big for the net layer even with frag".
>>
>> Merely handing info to the transport layer might not be enough, esp.
>> when net layer option lengths change.
> True if you want to cleanly fix it across the RFC-specified stack, but that's 
> beyond the concern of TAPS - it becomes a requirement from the TAPS WG. Does 
> that make sense?

Then this is part of the API requirements that TAPS should be
indicating, no?

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 12:56 AM, Michael Welzl wrote:
> These things can be achieved by only changing the implementation of 
> transports to locally provide some more of its internal information to a 
> system on top; they don't change anything on the wire...
FWIW, we really need to stop using that phrase ("on the wire").

A protocol is defined by:
- it's interface to the layer above
- its interface to the layer below
- the messages (the "on the wire" part)
- time
- it's state machine and how it reacts to the above 4 items

A protocol *implementation* can vary but still interoperate with other
protocols only when NONE of the above change.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 12:14 PM, Michael Tuexen wrote:
>> On 7 Dec 2016, at 15:54, Michael Welzl  wrote:
>>
>> Hi all,
>>
>> I have a problem with one particular primitive, or lack of it, in UDP, 
>> UDP-Lite and SCTP. It's something I just don't get.
>>
>> Consider this text from draft-fairhurst-taps-transports-usage-udp:
>>
>> "GET_INTERFACE_MTU:  The GET_INTERFACE_MTU function a network-layer
>>  function that indicates the largest unfragmented IP packet that
>>  may be sent."
>>
>> Indeed, this is a network-layer function. It's about the interface, not 
>> about UDP. Does that mean that, to decide how many bytes fit in the payload 
>> of a packet, the programmer needs to know if it's IPv4 or IPv6, with or 
>> without options, and do the calculation?
>> If so, isn't it extremely odd that UDP doesn't offer a primitive that 
>> provides a more useful number: the available space in its payload, in bytes?
>>
>> I also have the same question for SCTP.  For TCP, it's obvious that the 
>> application shouldn't bother, but not for UDP or SCTP.
> In the API description in https://tools.ietf.org/html/rfc6458 the MTU exposed 
> to the application
> via the API is "the number of bytes available in an SCTP packet for chunks." 
> I think this is the best
> we can do at that interface...
AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can send
without having SCTP coordinate frag/reassembly. That doesn't itself
indicate whether it's SCTP doing the rest or the network layer.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 12:28 PM, Michael Tuexen wrote:
>> ...
>>> In the API description in https://tools.ietf.org/html/rfc6458 the MTU 
>>> exposed to the application
>>> via the API is "the number of bytes available in an SCTP packet for 
>>> chunks." I think this is the best
>>> we can do at that interface...
>> AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can send
>> without having SCTP coordinate frag/reassembly. That doesn't itself
> You need to take the DATA or I-DATA chunk header into account...
> It is "the number of bytes in the packet for chunks", not "the number
> of bytes for the chunk value for DATA (or I-DATA) chunks".
Yes, but (see below).

>
>> indicate whether it's SCTP doing the rest or the network layer.
> As I said, that is what is exposed to the upper layer via the API.
> SCTP itself has procedures to detect the PMTU (of each path).
> It does PMTU discovery by interacting with the IP layer...

Yes, but it's possible that the chunksize the app sees from SCTP is
related to SCTP's reassembly limit, not IP's and not the PMTU.

At least that's how I read SCTP_MAXSEG.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 1:26 PM, Michael Tuexen wrote:
>
> Not sure what the reassembly limit is... SCTP handled arbitrary sized
> user messages a the receiver side by using partial delivery.
>
> The SCTP_MAXSEG allows a user to limit the size of DATA chunks without
> reducing the pmtu.
Yes, but that size can actually be larger than the PMTU, not just smaller.

>  Please note that this only affects DATA chunks, not
> the whole packet.
I was referring to the size the layer above SCTP deals with, not the
layer below.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/9/2016 1:38 PM, Michael Tuexen wrote:
>> On 9 Dec 2016, at 22:30, Joe Touch  wrote:
>>
>>
>>
>> On 12/9/2016 1:26 PM, Michael Tuexen wrote:
>>> Not sure what the reassembly limit is... SCTP handled arbitrary sized
>>> user messages a the receiver side by using partial delivery.
>>>
>>> The SCTP_MAXSEG allows a user to limit the size of DATA chunks without
>>> reducing the pmtu.
>> Yes, but that size can actually be larger than the PMTU, not just smaller.
> Hmm. https://tools.ietf.org/html/rfc6458#section-8.1.16 states:
>
>Note that the
>underlying SCTP implementation may fragment into smaller sized chunks
>when the PMTU of the underlying association is smaller than the value
>set by the user.
>
> So this means the user can not rely on this option to turn off SCTP
> fragmentation and let SCTP pass IP-packets down the stack to let
> the IP do the fragmentation.
>
> That is why I said, the user can use this option to ask the SCTP
> layer to use a smaller value than the one deduced from the PMTU.
> That is something you can do safely.

It seems like this setting is independent of PMTU. It could be larger
than PMTU, in which case SCTP *or* IP could do fragmentation (and I
don't see whether there's a way to know or force that decision).

Yes, you can set it smaller too.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/12/2016 1:31 AM, Michael Welzl wrote:
> Hi,
>
> Just trying to understand, so we're not talking past each other. Please note 
> that I'm not trying to argue in any direction with my comments below, just 
> asking for clarification:
Sure...
>
>> On 09 Dec 2016, at 18:32, Joe Touch  wrote:
>>
>>
>>
>> On 12/9/2016 8:12 AM, Michael Welzl wrote:
>>>> On 09 Dec 2016, at 16:18, Joe Touch  wrote:
>>>>
>>>>
>>>>
>>>> On 12/9/2016 12:09 AM, Michael Welzl wrote:
>>>>>> On 07 Dec 2016, at 20:29, Joe Touch  wrote:
>>>>>>
>>>>>> FYI, there are two different "largest messages" at the transport layer:
>>>>>>
>>>>>> 1) the size of the message that CAN be delivered at all
>>>>> True... I wasn't thinking of that, but yes.
>>>>>
>>>>>
>>>>>> 2) the size of the message that can be delivered without network-layer
>>>>>> fragmentation (there are no guarantees about link-layer - see ATM or the
>>>>>> recent discussion on tunnel MTUs on INTAREA)
>>>>>>
>>>>>> MTU generally refers to the *link payload*. At that point, transports
>>>>>> have to account for network headers, network options, transport headers,
>>>>>> and transport options too. See RFC6691.
>>>>>>
>>>>>> MSS refers to the transport message size AFAICT. It is *sometimes* tuned
>>>>>> to MTU-headers but not always.
>>>>>>
>>>>>> E.g., for IPv6, link MTU is required to be at least 1280, but the
>>>>>> src-dst transit MTU is required to be at least 1500. So a transport that
>>>>>> wants to match sizes and reduce fragmentation issues would pick
>>>>>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
>>>>>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the 
>>>>>> time.
>>>>> So I'm getting the impression that the answer to my question really is 
>>>>> that, to figure out 2)  (which I was concerned with), an application 
>>>>> programmer needs to do the calculation her/himself.
>>>> To figure out 2), the transport layer needs to know the unfragmented
>>>> link MTU, the size of all of the network headers (including options),
>>>> and the sizes of its own headers and options.
>>>>
>>>> It's also sometimes assumes that the transport can control the "DF" bit
>>>> (for IPv4).
>>> Yes - but that hardly sounds worse to me than requiring the application 
>>> programmer to do this protocol-specific calculation by hand...
>> The app programmer needs to know what the transport can support, the
>> transport needs to know what net supports, etc.
>>
>> Pushing the link MTU up the line and expecting all the other layers to
>> figure out what to do results in unnecessary complexity, never mind
>> undermining one of the key features of layering.
> Either we just agree here, or you're saying that your 2) above should not be 
> exposed? Or something else?

I'm saying that exposing 2) is a bad idea because it requires extra
information that can vary at other layers.


>>>> However, this all breaks down if the app makes the wrong choice because
>>>> the net can (will, and should) source fragment if it gets a message that
>>>> turns out  to be too big for one fragment anyway.
>>>>
>>>>> Not a big deal - and maybe some systems offer a function to give you the 
>>>>> size of a message that won't be fragmented.
>>>> Remember that - at best - you're optimizing for the next layer down
>>>> only. You can't know whether that net layer message is link fragmented
>>>> (e.g., as in ATM) or tunnel fragmented (as needs to be required or this
>>>> whole MTU concept breaks down).
>>> Sure - but that's something end systems just can't see. It's information up 
>>> to and including the IP layer that should be correctly handed over up the 
>>> stack, inside the host, with all the caveats this information comes with.
>> Why does that apply at the link layer but not other layers? If transport
>> can transfer and reassemble 1MB messages, then that's the "MTU" it needs
>> to tell the app layer. The same is true for net to tell transport, etc.
>>
>> We've conflated the

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/12/2016 3:45 AM, Gorry Fairhurst wrote:
>>
>> So what does that mean: that the API should contain a "don't
>> fragment" flag from the application?
>>
> Definitely.
>
> The use of DF in a datagram protocol is per-datagram decision -
> depending on what the app needs to happen.
>
> gorry

IMO, the app should never need to play with DF. It needs to know what it
thinks the transport can deliver - which might include transport
frag/reassembly and network frag/reassembly.

Joe


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:
>>
>> IMO, the app should never need to play with DF. It needs to know what it
>> thinks the transport can deliver - which might include transport
>> frag/reassembly and network frag/reassembly.
> How does the App handle probes for path MTU then in UDP?
>
> Gorry 
I think there needs to be two parts to the API:

- largest transmission size
- native transmission desired (true/false)

If the app says "YES" to native transmission size, then that would
suggest that UDP would do *nothing* and pass that same kind of flag down
to IP, where IP would not only set DF=1, but also not source fragment.

I.e., I don't think it's the app's job to know how to explicitly control
a mechanism two layers down, and DF isn't really what you want anyway.
DF isn't the same as "don't source fragment".

Joe
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

On 12/13/2016 5:34 AM, Gorry Fairhurst wrote:
> ...
>>>
>>> (1) I think we need a parameter returned to the App that is
>>> equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is
>>> useful to know how many bytes the app can send with reasonable
>>> chance of unfragmented delivery.

All we can know is whether it is unfragmented at the next layer down.

>>
>>> (2) It's helpful for Apps to be able to retrieve the upper size
>>> allowed with potential fragmentation - that could be useful in
>>> determinine probe sizes for an application.  Apps should know the
>>> hard limt, In DCCP this is called the current congestion control
>>> maximum packet size (CCMPS), the largest permitted by the stack
>>> using the current congestion control method. That's bound to be less
>>> than or equal to what is permitted for the local Interface MTU. This
>>> limit lets the App also take into consideration other size
>>> constraints in the stack below the API.
>>
Again, next layer down only. We're generally talking about existing
transports that try to pass the link MTU up through network and
transport transparently, but that need not be the case. Keep in mind
that the link MTU for ATM AAL5 isn't 48B, it's 9K - i.e., it is the
message that the link will deliver intact, not the native link size.
...
> (3) Apps need to be able to ask the stack to try hard to send
> datagrams larger than the current MPS - 

I disagree.

The app should see two values from transport:
   
A) how big a message can you deliver at all?
B) how big a message can you deliver "natively"?

Any probing happens between those two values.

> This is not expected as the default, the stack needs to be told to
> enable this use of source/router fragmentation and send IPv4 datagrams
> with DF=0 (For some IPv4 paths, the PMTU, and hence MPS can be very
> small).

I disagree.

DF=0 is a network flag that should never be exposed to the app. Even if
it is, this wouldn't be the control the app really wants. The app would
want to prevent source fragmentation. DF=0 applies to IPv4 only and only
affects *on path* fragmentation.

But that's not the transport's job.

Consider this:
- transport has max and native message sizes
- network has max and native message sizes
- link has max and native message sizes

Every layer has these. Sometimes they're the same (when a layer doesn't
support frag/ressembly , e.g., UDP, Ethernet), sometimes they're not
(IP, TCP). Somtimes they're unlimited (TCP has no max message size, AFAICT).

> (4) Apps need to be able to ask the stack to send datagrams larger
> than the current MPS, but NOT if this results in source fragmentation. 
Apps can control only transport fragmentation. They can't and shouldn't
see or control network or link fragmentation UNLESS transport lets that
pass through as a transport behavior.

> Such packets need to be sent with DF=1.  - This is not expected as the
> default, the stack needs to be told to enable this -  for UDP it would
> be needed to perform PMTUD. That's I think what has been just called
> "native transmission desired ".

The issue is that this is an interaction between the app and transport.
It has nothing to do with the network or link layers  - unless the
transport wants it to. It's up to the transport to decide whether to try
to "pass through" the native network size. It's up to the network layer
to decide whether to "pass through" the native link size.

E.g., for IPv6, the lowest values to the answers above are:
A) 1500B, including IP header and options
B) 1280B, including IP header and options

That necessarily means that IPv6 over IPv6 cannot truthfully answer (B)
- it HAS to require the lower IPv6 to fragment and reassemble. Otherwise
it would be reporting a value that would make it no longer compliant
with RFC2460.

So we need to be careful about this - there really aren't 4 values here.
There are only two - the max and "native" *as reported by* the next
layer down.

There never has been and never can be a way that an app can solely
manage PMTUD to match network *unless* the transport passes that
information through. There never has been and never can be a way an app
can match to a link layer native MTU (otherwise, we'd be spinning MTUs
down to 48B for ATM).

Joe


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

Hi, Gorry,

Let me see of I can explain my viewpoint.

I'll start by noting that there's a difference between "what transports
currently do" and what they "should" do. I agree with you that current
transports do have access to network MTUs and DF control, but don't
always pass all that to the user.

Here's what I think is currently required:

1122 indicates the interface between IP and transport as indicating the
max send and receive transport sizes - but for IPv6 that would be 1500 -
IPheaders, not 1280 - IP headers or even 1500 or 1280.

1122 also indicates that the transport - not the application - gets to
set DF in the SEND call to IP.

However, there does not appear to be any provision to limit source
fragmentation between transport and IP, nor any requirement for UDP to
pass that control to the app.



So 1122 is consistent with my view that:

- the application sees a transport MSS (I'm not sure whether to call
that max or native yet...)

- the transport sees the max network MSS (i.e., allowing source
fragmentation), not the native network MSS

I don't understand why 1122 requires transport control over DF, but UDP
is not required to pass that control to the user.

---

My conclusion is that the app-transport API *should* be required to give
the user control over whether to use the max or native transport MSS,
just as the transport-API should be required to give the transport
control over whether to use the max or native network MSS, and so forth
for the network-link API.

However, none of that implies that the user ever will be able to match
the link MTU. There's always the possibility that one of these layers
decides to never report a true native size, e.g., ATM (as a link layer)
never reports 48 to IP.

This means that apps can't ever really force a probe of much of
anything, too. Only transports can.

(FWIW, when I say that UDP doesn't support fragmentation, I mean that
UDP doesn't have UDP fragmentation. The fragmentation is at the IP
layer; UDP is ignorant of it).

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] MTU / equivalent at the transport layer

[Joe Touch]

One piece of potentially important information:

PMTUD and PLMTUD are intended to avoid the need for on-path
fragmentation. That's why there is control only over the DF bit, not
source fragmentation.

AFAICT, this points to a (AFAICT) a problem with IPv6 PMTUD as described
in RFC1981. That doc claims to try to optimize to the native link MTU,
but that doesn't appear to be possible given the way IPv4 and IPv6
interact with transports. There's no signal to IP that says "don't
source fragment".

Joe


On 12/14/2016 11:12 AM, Joe Touch wrote:
> Hi, Gorry,
>
> Let me see of I can explain my viewpoint.
>
> I'll start by noting that there's a difference between "what transports
> currently do" and what they "should" do. I agree with you that current
> transports do have access to network MTUs and DF control, but don't
> always pass all that to the user.
>
> Here's what I think is currently required:
>
> 1122 indicates the interface between IP and transport as indicating the
> max send and receive transport sizes - but for IPv6 that would be 1500 -
> IPheaders, not 1280 - IP headers or even 1500 or 1280.
>
> 1122 also indicates that the transport - not the application - gets to
> set DF in the SEND call to IP.
>
> However, there does not appear to be any provision to limit source
> fragmentation between transport and IP, nor any requirement for UDP to
> pass that control to the app.
>
> 
>
> So 1122 is consistent with my view that:
>
> - the application sees a transport MSS (I'm not sure whether to call
> that max or native yet...)
>
> - the transport sees the max network MSS (i.e., allowing source
> fragmentation), not the native network MSS
>
> I don't understand why 1122 requires transport control over DF, but UDP
> is not required to pass that control to the user.
>
> ---
>
> My conclusion is that the app-transport API *should* be required to give
> the user control over whether to use the max or native transport MSS,
> just as the transport-API should be required to give the transport
> control over whether to use the max or native network MSS, and so forth
> for the network-link API.
>
> However, none of that implies that the user ever will be able to match
> the link MTU. There's always the possibility that one of these layers
> decides to never report a true native size, e.g., ATM (as a link layer)
> never reports 48 to IP.
>
> This means that apps can't ever really force a probe of much of
> anything, too. Only transports can.
>
> (FWIW, when I say that UDP doesn't support fragmentation, I mean that
> UDP doesn't have UDP fragmentation. The fragmentation is at the IP
> layer; UDP is ignorant of it).
>
> Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Fwd: New Version Notification for draft-grinnemo-taps-he-02.txt

[Joe Touch]

Hi, all,

Some observations:

- HE-trans MUST NOT be used to try different combinations of options
within a given transport

- I'm wondering about the potential for problems when ports are reused
between different attempts, e.g., IPv6-TCP then IPv4-TCP

- the document works only for connection-orient transports that treat
failed connections as "no information"

if a connection fails for other reasons, the origin might receive an
ICMP message that prohibits further attempts, either to that transport,
port, or address

if a connection attempt is rejected but used as information, you
could end up with confusing results (e.g., as a covert channel)

in that case, you're not doing HE; IMO, HE requires that there be no
impact to failed attempts

Joe


On 3/14/2017 2:37 AM, Anna Brunstrom wrote:
>
> Hi all,
>
> The draft below on happy eyeballs was submitted last night. It is on
> the agenda for Chicago, but we are happy to hear any comments you may
> have also before then.
>
> Cheers,
> Anna
>
>  Forwarded Message 
> Subject:  New Version Notification for draft-grinnemo-taps-he-02.txt
> Date: Mon, 13 Mar 2017 11:18:59 -0700
> From: internet-dra...@ietf.org
> To:   Zdravko Bozakov , Zdravko Bozakov
> , Anna Brunstrom ,
> Per Hurtig , Karl-Johan Grinnemo
> , Naeem Khademi 
>
>
>
> A new version of I-D, draft-grinnemo-taps-he-02.txt
> has been successfully submitted by Karl-Johan Grinnemo and posted to the
> IETF repository.
>
> Name: draft-grinnemo-taps-he
> Revision: 02
> Title:Happy Eyeballs for Transport Selection
> Document date:2017-03-13
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt
> Status: https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/
> Htmlized:   https://tools.ietf.org/html/draft-grinnemo-taps-he-02
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02
>
> Abstract:
>Ideally, network applications should be able to select an appropriate
>transport solution from among available transport solutions.
>However, at present, there is no agreed-upon way to do this.  In
>fact, there is not even an agreed-upon way for a source end host to
>determine if there is support for a particular transport along a
>network path.  This draft addresses these issues, by proposing a
>Happy Eyeballs framework.  The proposed Happy Eyeballs framework
>enables the selection of a transport solution that according to
>application requirements, pre-set policies, and estimated network
>conditions is the most appropriate one.  Additionally, the proposed
>framework makes it possible for an application to find out whether a
>particular transport is supported along a network connection towards
>a specific destination or not.
>
>   
> 
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

On 4/5/2017 5:45 AM, Michael Welzl wrote:
> This is the minor change that I promised at the last meeting - mainly to 
> include TCP Authentication (RFC 5925).
There are bugs in the description. TCP-AO was careful to say "TCP SEND,
or a sequence of commands resulting in a SEND" (same for RECEIVE),
regarding setting or viewing received key IDs (current and next),
especially including ways to set/read these values even when a SEND or
RECEIVE isn't issued (e.g., to affect retransmissions or ACKs).

I didn't give a deep re-read and I don't recall from my earlier checks,
but is there a discussion of using other operations to interact with
connection parameters (socket options, ioctls), e.g., as part of the
required interface?

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

On 4/5/2017 12:12 PM, Michael Welzl wrote:
> Hi,
>
> Thanks a lot for checking this!
>
>
>> On Apr 5, 2017, at 8:01 PM, Joe Touch  wrote:
>>
>>
>>
>> On 4/5/2017 5:45 AM, Michael Welzl wrote:
>>> This is the minor change that I promised at the last meeting - mainly to 
>>> include TCP Authentication (RFC 5925).
>> There are bugs in the description. TCP-AO was careful to say "TCP SEND,
>> or a sequence of commands resulting in a SEND" (same for RECEIVE),
>> regarding setting or viewing received key IDs (current and next),
> Hm, I saw this but didn’t get it - what is “a sequence of commands resulting 
> in a SEND” (or RECEIVE) ?
> I just don’t get what that’s supposed to mean. E.g., what else than SEND will 
> send?

E.g., setting a socket option to set values then using SEND, or RECEIVE
then socket options to read.

The point was that the setting of those values can be asynchronous to
the SEND/RECEIVE calls.
>
>> especially including ways to set/read these values even when a SEND or
>> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs).
> I also saw this but didn’t see it as mandatory to provide (“It may be 
> useful…”, the text says). Is this really very useful?
You might want/need to change keys on a BGP session even when you aren't
yet ready to issue a SEND. You might want to check to see of the keys
have changed due to retransmissions or ACKs even when you didn't issue a
RECEIVE.

>
>> I didn't give a deep re-read and I don't recall from my earlier checks,
>> but is there a discussion of using other operations to interact with
>> connection parameters (socket options, ioctls), e.g., as part of the
>> required interface?
> Nothing that’s not in the RFCs… I did rephrase the authentication stuff for 
> TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating that 
> they’d be implemented using SEND and RECV. Not much else available…
>
> If you say it’s important it can be added, I guess, but I find it hard to 
> derive that from the text in RFC 5925. Well, empty send’s and receive’s are a 
> way out, I suppose.

It's not just RFC 5925. The issue is whether there are other mandatory
configurations or monitoring that is async to SEND/RECEIVE. If so, then
you can't simply assume they occur only during those calls.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

FWIW, the current setsockopt commands are an extension (IMO) of the
STATUS command of RFC 793, allowing it to not only read connection
information but also modify it.

IMO, we should think of it in those terms, not merely "setsockopt" or
"ioctl" or anything else.

Joe


On 4/5/2017 12:46 PM, Michael Welzl wrote:
>> On Apr 5, 2017, at 9:31 PM, Joe Touch  wrote:
>>
>>
>>
>> On 4/5/2017 12:12 PM, Michael Welzl wrote:
>>> Hi,
>>>
>>> Thanks a lot for checking this!
>>>
>>>
>>>> On Apr 5, 2017, at 8:01 PM, Joe Touch  wrote:
>>>>
>>>>
>>>>
>>>> On 4/5/2017 5:45 AM, Michael Welzl wrote:
>>>>> This is the minor change that I promised at the last meeting - mainly to 
>>>>> include TCP Authentication (RFC 5925).
>>>> There are bugs in the description. TCP-AO was careful to say "TCP SEND,
>>>> or a sequence of commands resulting in a SEND" (same for RECEIVE),
>>>> regarding setting or viewing received key IDs (current and next),
>>> Hm, I saw this but didn’t get it - what is “a sequence of commands 
>>> resulting in a SEND” (or RECEIVE) ?
>>> I just don’t get what that’s supposed to mean. E.g., what else than SEND 
>>> will send?
>> E.g., setting a socket option to set values then using SEND, or RECEIVE
>> then socket options to read.
>>
>> The point was that the setting of those values can be asynchronous to
>> the SEND/RECEIVE calls.
> Okay, got it; socket options don’t exist in RFC 793 language, or any of the 
> RFCs updating it, I think…
> maybe this RFC should have invented such a function call?  Anyway, I can do 
> this for you  :-)   to some degree, that’s the role of my draft. I can say 
> that RFC 5925 demands this functionality, and describe SET_AUTH and GET_AUTH 
> primitives that would map to that.
>
>
>>>> especially including ways to set/read these values even when a SEND or
>>>> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs).
>>> I also saw this but didn’t see it as mandatory to provide (“It may be 
>>> useful…”, the text says). Is this really very useful?
>> You might want/need to change keys on a BGP session even when you aren't
>> yet ready to issue a SEND. You might want to check to see of the keys
>> have changed due to retransmissions or ACKs even when you didn't issue a
>> RECEIVE.
> Okay…
>
>
>>>> I didn't give a deep re-read and I don't recall from my earlier checks,
>>>> but is there a discussion of using other operations to interact with
>>>> connection parameters (socket options, ioctls), e.g., as part of the
>>>> required interface?
>>> Nothing that’s not in the RFCs… I did rephrase the authentication stuff for 
>>> TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating 
>>> that they’d be implemented using SEND and RECV. Not much else available…
>>>
>>> If you say it’s important it can be added, I guess, but I find it hard to 
>>> derive that from the text in RFC 5925. Well, empty send’s and receive’s are 
>>> a way out, I suppose.
>> It's not just RFC 5925. The issue is whether there are other mandatory
>> configurations or monitoring that is async to SEND/RECEIVE. If so, then
>> you can't simply assume they occur only during those calls.
> There isn’t much; Nagle is an example - RFC 1122 just says that the 
> functionality to enable / disable must be there, without specifying via which 
> primitive that would happen.
> So, my draft says, in pass 2:
>
>o  DISABLE_NAGLE.TCP:
>   Pass 1 primitive / event: not specified
>
> Seems like I should do the same for set_auth and get_auth.
>
> Cheers,
> Michael
>

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

On 4/5/2017 12:46 PM, Michael Welzl wrote:
> There isn’t much; Nagle is an example - RFC 1122 just says that the 
> functionality to enable / disable must be there, without specifying via which 
> primitive that would happen.
> So, my draft says, in pass 2:
>
>o  DISABLE_NAGLE.TCP:
>   Pass 1 primitive / event: not specified
>
> Seems like I should do the same for set_auth and get_auth.
Set_auth and get_auth are either in the STATUS (as per my previous
message) or SEND/RECEIVE.

There may be other signals that need to be specified. E.g., RFC1122 has
a few items that need to be indicated, but isn't clear about them being
only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4).

Joe
   

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

Hi, Michael,


On 4/5/2017 1:10 PM, Michael Welzl wrote:
>> On Apr 5, 2017, at 9:55 PM, Joe Touch  wrote:
>> ...
>> Set_auth and get_auth are either in the STATUS (as per my previous
>> message) or SEND/RECEIVE.
> What’s the problem with defining new primitives for these things? It’s just 
> an abstract API anyway.
You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., it
does say that the management of these parameters can be via
SEND/RECEIVE, but doesn't have to be.

> I actually removed STATUS in my draft because of the following reasoning 
> (quoting my own draft):
>
> ***
> The 'status' primitive was not included because [RFC0793] describes this 
> primitive as
> "implementation dependent" and states that it "could be excluded without 
> adverse effect”.

That was true back when 793 was created, but hasn't been true
effectively since 1122.

>   Moreover, while a data block containing specific information is described, 
> it is also stated
>that not all of this information may always be available.
> ***
>
> Because a TAPS system should be able to rely on things that are available 
> pretty much everywhere,
> this draft doesn’t include things that are optional for an underlying 
> transport to implement.
Agreed - I'm saying that there MUST be a command by which some
parameters of a connection can be monitored and altered after the
connection is established but asynchronously from a SEND/RECEIVE call.

You might say that you could accomplish the result with a zero-byte SEND
or nonblocking RECEIVE, but that's ugly from an API viewpoint.

>
>> There may be other signals that need to be specified. E.g., RFC1122 has
>> a few items that need to be indicated, but isn't clear about them being
>> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4).
> Exactly my point - disabling Nagle is one of these things. So I gave them 
> names and call them primitives under “CONNECTION.MAINTENANCE”.
> Shouldn’t matter, as long as the functionality is there?

Oh, OK - then you would want to say that the keyID and nextkeyIDs fall
under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section.

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

On 4/5/2017 2:23 PM, Michael Welzl wrote:
>> On Apr 5, 2017, at 10:33 PM, Joe Touch  wrote:
>>
>> Hi, Michael,
>>
>>
>> On 4/5/2017 1:10 PM, Michael Welzl wrote:
>>>> On Apr 5, 2017, at 9:55 PM, Joe Touch  wrote:
>>>> ...
>>>> Set_auth and get_auth are either in the STATUS (as per my previous
>>>> message) or SEND/RECEIVE.
>>> What’s the problem with defining new primitives for these things? It’s just 
>>> an abstract API anyway.
>> You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., it
>> does say that the management of these parameters can be via
>> SEND/RECEIVE, but doesn't have to be.
> We seem to agree: see below -
>
>
>>> I actually removed STATUS in my draft because of the following reasoning 
>>> (quoting my own draft):
>>>
>>> ***
>>> The 'status' primitive was not included because [RFC0793] describes this 
>>> primitive as
>>> "implementation dependent" and states that it "could be excluded without 
>>> adverse effect”.
>> That was true back when 793 was created, but hasn't been true
>> effectively since 1122.
> Hmmm…. what about the whole block defined in RFC793? It tells you about rwnd, 
> snd wnd, and strange stuff like security/compartment… where to draw the line?
Having a "window" into what TCP is doing is nice, but not necessary.

Having a way to disable Nagle (or enable it, for that matter) is necessary.

I'd draw the line at "required" to make TCP work correctly.

> I guess by knowing what is actually happening in OS’es out there, for each of 
> these items. That’s the quest I wasn’t going to take - this draft is based on 
> the RFCs.

IMO, it's hard to scrub those RFCs for this info. There was a time when
the IETF decided that APIs were out of scope and a lot of the info you
need was ignored in RFCs, or at best pushed to "honorable mention".

> I’d also say that these things don’t matter much for a (minimal) TAPS system 
> - for many of these things, exposing them creates an unnecessary dependency 
> on the protocol.

I don't know what the requirements are for a minimal TCP system, so
there's no way to answer that.

We ought to understand that for every protocol we design, but we don't.

>>>  Moreover, while a data block containing specific information is described, 
>>> it is also stated
>>>   that not all of this information may always be available.
>>> ***
>>>
>>> Because a TAPS system should be able to rely on things that are available 
>>> pretty much everywhere,
>>> this draft doesn’t include things that are optional for an underlying 
>>> transport to implement.
>> Agreed - I'm saying that there MUST be a command by which some
>> parameters of a connection can be monitored and altered after the
>> connection is established but asynchronously from a SEND/RECEIVE call.
>>
>> You might say that you could accomplish the result with a zero-byte SEND
>> or nonblocking RECEIVE, but that's ugly from an API viewpoint.
> Agree to both -
>
>
>>>> There may be other signals that need to be specified. E.g., RFC1122 has
>>>> a few items that need to be indicated, but isn't clear about them being
>>>> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4).
>>> Exactly my point - disabling Nagle is one of these things. So I gave them 
>>> names and call them primitives under “CONNECTION.MAINTENANCE”.
>>> Shouldn’t matter, as long as the functionality is there?
>> Oh, OK - then you would want to say that the keyID and nextkeyIDs fall
>> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section.
> Exactly. Right now, the error is that the CONNECTION.MAINTENANCE primitive 
> description says that this uses ‘send’ or ‘receive’. It shouldn’t.  I’ll note 
> that for the next update (when I'll address more comments from WGLC), thanks!

AOK.
Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt

[Joe Touch]

Hi, Michael,

Sorry for the delay...


On 4/5/2017 11:54 PM, Michael Welzl wrote:
> BTW,
>
> Just a quick last question, to make sure I get this right:
>
> Oh, OK - then you would want to say that the keyID and nextkeyIDs fall
> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section.
> When handing over the keyID and nextkeyIDs on SEND, this just means that 
> these new values are valid from the time SEND was called, right? It's not 
> tied to the specific data block that's being handed over?
Correct. They're not tied to data the way the URG pointer is or SCTP
authentications are.

Joe

> (I'm asking because that's a difference to SCTP, where it's possible to 
> decide to authenticate a particular data chunk that's handed over. For TCP, 
> this would be pretty unusual, I think, but perhaps also implementable...)
>
> Cheers,
> Michael
>

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Joe Touch]

FWIW:


On 5/12/2017 5:31 AM, Michael Welzl wrote:
>> ---
>> Get Interface MTU is missing from pass 2 and 3:
>>
>> ADD to pass 2:
>>
>>  GET_INTERFACE_MTU.UDP:
>>  Pass 1 primitive: GET_INTERFACE_MTU
>>  Returns: Maximum datagram size (bytes)
> But this doesn’t exist!  It’s strictly an IP function and I couldn’t find it 
> described for UDP anywhere. I think we agreed on how a TAPS system should 
> handle this, and this is reflected in
> https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1
> … which may require a system to implement new local functionality, maybe 
> based on this MTU function - but to my understanding it’s just not something 
> that UDP offers.
IP is supposed to export MMS_S and MMS_R to the transport, which are
calculated from EMTU_S, EMTU_R, and the link MTU for the given source IP
address.. PMTUD exports PMTU to the transport. Both already take into
account the link MTU and other MTU information, where available.

In no cases does the transport actually ever need to see the link MTU.

Joe
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps