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

From: Aaron Falk <[email-masked]>
Date: Sat, 2 Apr 2016 14:33:09 -0300

Couple of minor comments on the draft
<https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-01>:

   - No mention of ECN in phase 2.  Am I missing something?
   - You had asked about what app-oriented IETF groups might be able to
   review the API.  It's a good question for draft-ietf-taps-transports-usage
   as well.  Wonder if the wg has any suggestions?  Perhaps we should raise
   the question in APPSAWG although they don't seem to be meeting this IETF...

--aaron

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 2 Apr 2016 15:17:58 -0300

Hi, Aaron and Gorry,

>    the question in APPSAWG although they don't seem to be meeting this IETF...
If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at the
welcome reception, you might ask if Dispatch is the right place to ask
about these drafts - now that APP is part of ART, Dispatch has a broader
scope than just RAI, and they are meeting this time (on Monday morning, so
ask fast) ...

Spencer

---

From: Aaron Falk <[email-masked]>
Date: Sat, 2 Apr 2016 15:20:33 -0300

> scope than just RAI, and they are meeting this time (on Monday morning, so

So, is DISPATCH the new APPSAWG?  If so, we need to add it to our conflict
avoid list (esp since we conflict with it this week).

--aaron

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 2 Apr 2016 15:42:18 -0300

Hi, Aaron,

On Sat, Apr 2, 2016 at 3:20 PM, Aaron Falk <[email-masked]> wrote:

>> If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at
>> the welcome reception, you might ask if Dispatch is the right place to ask

I'm not entirely clear on that, but I think it's kinda turning into the ART
Open Area Meeting (APPSAWG actually works on stuff that doesn't have its
own working group, like TSVWG). So, DISPATCH is more like TSVAREA than
TSVWG.

In related news, I just talked to Cullen, and he said Dispatch puts up
advertisements for drafts all the time. Is all you/Gorry want to do is get
a slide into the chair slide deck that says "these drafts in TSV could use
ART clue and attention", that should be fine (but putting together a slide
that says whatever you want to ask is the key action).

I hope that helps,

Spencer

---

From: Aaron Falk <[email-masked]>
Date: Sat, 2 Apr 2016 16:49:02 -0300

On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> Is all you/Gorry want to do is get a slide into the chair slide deck that
> says "these drafts in TSV could use ART clue and attention", that should be
> fine (but putting together a slide that says whatever you want to ask is
> the key action).
>
>
To me the key question is whether it is premature.  It might be useful to
get a few more protocols beyond TCP, SCTP, and UDP to better illustrate the
range of features.  Interested in other opinions.

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Sat, 2 Apr 2016 19:23:10 -0300

> On 2. apr. 2016, at 16.49, Aaron Falk <[email-masked]> wrote:
> 
> On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
> Is all you/Gorry want to do is get a slide into the chair slide deck that says "these drafts in TSV could use ART clue and attention", that should be fine (but putting together a slide that says whatever you want to ask is the key action).
> 
> 
> To me the key question is whether it is premature.  It might be useful to get a few more protocols beyond TCP, SCTP, and UDP to better illustrate the range of features.  Interested in other opinions.

As an author of the -usage document, this being premature is indeed also my concern. I’d feel more comfortable doing this with the next version, at the next IETF.

Cheers,
Michael

---

From: [email-masked]
Date: Sun, 3 Apr 2016 12:54:06 +0100

When someone talks about using TCP or SCTP then they are typically using
an API to the transport that hides a lot of details. My present draft is
only about the Datagram aspects of the API. For UDP applications, many
times you need require options or IP-level functions along with UDP. I'd
personally love to get helpful review inputs the ART area people
(applications/real-time) to figure this out.

I was hoping we could put the text in the WG draft after we got this
input. But maybe, this can't happen soon... and we need a different plan?
I'll maybe see you people today perhaps to decide how best to present
this?

Gorry

>> On Sat, Apr 2, 2016 at 3:42 PM, Spencer Dawkins at IETF
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>> Is all you/Gorry want to do is get a slide into the chair slide deck
>> that says "these drafts in TSV could use ART clue and attention", that
>> should be fine (but putting together a slide that says whatever you want
>> to ask is the key action).
>>
>>
>> To me the key question is whether it is premature.  It might be useful
>> to get a few more protocols beyond TCP, SCTP, and UDP to better
>> illustrate the range of features.  Interested in other opinions.
>
> As an author of the -usage document, this being premature is indeed also
> my concern. I’d feel more comfortable doing this with the next version,
> at the next IETF.
>
> Cheers,
> Michael
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: Michael Welzl <[email-masked]>
Date: Sun, 3 Apr 2016 10:15:11 -0300

Sent from my iPhone

> On 3. apr. 2016, at 08.54, <[email-masked]> <[email-masked]> wrote:
> 

it sounds good to me; when i said premature i was thinking of my own doc, not this udp one

> I'll maybe see you people today perhaps to decide how best to present

jfyi not me, not going to be at reception

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 3 Apr 2016 17:20:58 -0700

1. Steps 1 and 2 look to me like "inside sausage factory", aka:
   trying to reverse engineer the justification for some sane service descriptions
   from past IETF work and real implementation knowledge on the side. I think
   it would be lovely if Step 3 could end up as a separte document thats used
   going forward, and 1.1 are for folks in historic interest (aka: separate them out).

   But i am sure there is all type of important IETF/TAPS reasoning why this is
   not desirable ;-)

2. Unless i am overlooking something, pass 2 and 3 do not define weell enough how
   the transport service endpoints work (aka: what we call sockets in BSD, but
   that really work the same logically in all OS, even those that tried not to call them
   sockets). And it would make the transport service description pretty useless if
   that was not made clearer.

    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.
    
    If you really mean to say destination (remote) transport address, then
    this is not the listen() of the socket API, and i would not know how this
    listen would work, eg: what would happen if multiple parallel calls to this
    are made by competing apps on the same host. 

    Demultiplexing protocol (UDP) packes is obviously the key part of the transport service.

One approach would be to define a transport service endpoint as a packet
signature that is "owned" by this transport service endpoint:

  (LocalIP,LocalPort,Porto,DstIP,DstPort)

A "server" transport service endpoint owns (LocalIP,LocalPort,Proto*,*). This
is what you get when you do socket(Proto), bind(LocalIP,LocalPort). This could
be represented in the API as BIND(LocalAddr,LocalPort). Details here include:

- LocalAddr can be one explicit address or ANY{-AF}
  ANY{-AF} is lready quite egregious in existing socket APIs, 0.0.0.0 indicates
  only AF=IPv4 ANY, whereas :: indicates IPv4 and IPv6 ANY (AFAIK).

- LocalPort = ANY means you do get an allocation of a "free" port. Which means
  that you need some API call OR a return value showing the actually LocalPort.

  Indeed, if we wanted to define a good API, wee wanted to have some
  ANY-Range{MIN..MAX} parameter option given how we (IETF) have defined UDP
  port ranges with specific semantics.

So, The BIND API call has success/failure critera that can also be detailled.

I can do SEND/RECEIVE on this communications endpoint, this is probably what
we'd call the "unconnected" mode.

Of course there is the CONNECT paradigm for connected sockets. IMHO, it is
also crucial to worry about the local port in the API. In your writeup it looks
like you only consider that the local port is automatically assigned implicit
by CONNECT. Which is fine in many cases, but not if you want some upfront signaling
like ICE. In those cases, you do a BIND first to know your local port and then
do some signaling... And maybe later you do a CONNECT .

In another mail thread you asked about reraching out to ART. IMHO, a crucial aspect
for the application folks is the demultiplexing model. Without defining what
packets a transport endpoint has ownership of, all bets are off. Eg: If i
just had a 5-tuple ownership model, i do not own a local port, so i would have
to potentially redo a signaling that expects local port ownership for every
connection, because i could not necessarily get to every remote site with my
local port, because some other app may have it.

3. Having lamented on the above: The socket APIs are pretty good with all of the
above, i am just worried about making sure we actually capture it in our IETF
specs. BUT: The socket APIs IMHO do quite well suck on doing the same for IP
multicast. Aka: For unicast, the packet signature is well embodied in the socket,
aka: a socket has the right options of packet ownerships (non-connected, connected).
For IP multicast, that concept does not exist well, and it would be lovely if
we could have an API definition that introduces the same level of ownership.

Eg: Socket ownership is always around local port or 5-tuple connection. Which
is just the granularity useful in unicast. In IP multicast it does not make
sense. If i am application A with eg: (S,G) traffic over Port P1, i do certainly
not want some other application B to also use (S,G) traffic over port P2: In
the network, we would now get traffic for A go to all receivers of B and vice
versa. Aka: its an attack vector, albeit in most cases not intentional but by
stupidity of address selection.

So, for IP multicast, you really want to BIND (own) to (RemoteAddr) - not
Port, not Proto - for ASM, and to (LocalAddr,RemoteAddr) for SSM. And of course
in IPv6 the permissible binding could be derived from RemoteAddr (indicates ASM or SSM).

Now, of course, this does not help me for App B on another host to mess up
my multicast traffic trees, but the whole point is about creating a transport
service definition that is IMHO as good and logical as possible for the service
as we can make it, and right now, the APIs are really 30 years developed and
pretty good for unicast, but multicast is just an afterthought, and quite illogical
by just following the unicast API model and adding some *yuck* setsockopts.

Cheers
    toerless

---

From: Michael Welzl <[email-masked]>
Date: Sun, 3 Apr 2016 22:18:35 -0300

Hi,

I don’t want to go into specifics about this draft, that should be up to its authors… just a general point:

> On 3. apr. 2016, at 21.20, Toerless Eckert <[email-masked]> wrote:
> 

Step 2 is a better practical basis for developing an API than step 3.
I’d agree about step 1; this only exists to systematically arrive at steps 2 and 3.

The reasoning behind the three steps is explained in draft-ietf-taps-transports-usage

Cheers,
Michael

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 4 Apr 2016 13:20:35 -0300

The process stuff is I think in the WG draft. The questions on port usage of UDP and the implications on the service model - these are things I would like to explore. 

Let's see if we can find some additional text on this for the next rev.

Gorry

> On 3 Apr 2016, at 22:18, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 10:31:55 -0700

>           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

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 10:36:08 -0700

> 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

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 10:44:51 -0700

On 4/3/2016 4:54 AM, [email-masked] wrote:
> 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

---

From: [email-masked]
Date: Mon, 4 Apr 2016 18:55:04 +0100

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.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 11:06:23 -0700

Hi, Gorry,

> 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

---

From: [email-masked]
Date: Mon, 4 Apr 2016 19:24:02 +0100

Hi Joe,

We don't seem to be agreeing.

> The TCP API needs a way to set any flags in the TCP header, either
Agree

> instrumentation purposes, but not for regular operation.
Agree.

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

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

Gorry

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 11:30:32 -0700

> We don't seem to be agreeing.

Not yet at least ;-)

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

> 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

---

From: [email-masked]
Date: Mon, 4 Apr 2016 20:49:44 +0100

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

> I do agree this needs to be per message, not per endpoint.
That sounds a lot like you are thinking about a concrete API. And I agree,
to implement this, you can do exactly that and provide additional data per
datagram buffer to communicate the DSCP, ECN, TTL ...

Gorry

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 13:24:49 -0700

On 4/4/2016 12:49 PM, [email-masked] wrote:
...
> this is not necessarily an IP setting for all packets, it can be a per UDP

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

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

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

---

From: [email-masked]
Date: Mon, 4 Apr 2016 23:31:28 +0100

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

> We shouldn't need to update the UDP API whenever IP or other layers
That's a good goal.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Apr 2016 15:41:21 -0700

> 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