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

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Apr 2016 11:19:53 -0400

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.

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.

In section 3.1 is:

   SET_IPV6_UNICAST_HOPS:  The SET_IPV6_UNICAST_HOPS function sets the
      hop limit field to be used in the field of an IPv4 header of a
      packet that carries an UDP datagram.  For IPv6 unicast datagrams,
      this is functionally equivalent to the SET_TTL IPv4 function.

   GET_IPV6_UNICAST_HOPS:  The GET_IPV6_UNICAST_HOPS function reads the
      value from the hop count field in the IPv6 header of a received
      UDP datagram.  For IPv6 unicast datagrams, this is functionally
      equivalent to GET_TTL IPv4 function.

I might be wrong, but it looks like "IPv4" and "IPv6" are mistaken for
each other in three places in these items.

How does the application get notified that a packet has arrived?  The
only event that is defined is ERROR_REPORT.  The RECEIVE primitive is
called by the application, but application has to first know that there
is a packet to receive.

Dale

---

From: [email-masked]
Date: Wed, 6 Apr 2016 17:39:05 +0100

Thanks - appreciated.

> on a socket before the receiver has done a CONNECT.
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

> the framework for this draft.  At the least, the use of listening ports
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.

> each other in three places in these items.
Indeed. We will fix this.

> called by the application, but application has to first know that there
One contribution in the parallel TAPS meeting suggested the WG could use a
call-back API - that may be worth exploring.

> Dale
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>
Thanks Dale,

Gorry

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Apr 2016 10:53:43 -0700

On 4/6/2016 9:39 AM, [email-masked] wrote:
...
>> 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

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 07 Apr 2016 14:42:06 -0400

[email-masked] writes:
> [...]

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

	Create socket
	Bind socket to listening address
	Activate listening

			Create socket
			Connect

	Incoming connection event
	Accept connection

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
and send their initial packets within one RTT of each other, so I don't
know if that possibility is ever used in practice.  Or whether the
Berkeley sockets API supports it.

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

The process for UDP is not much simpler.  My memory is:

	Passive		Active
	Endpoint	Endpoint

	Create socket
	Bind socket to listening address

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

	Incoming connection event
	Connect (in the TAPS paradigm)
	Incoming packet event
	Receive packet

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 07 Apr 2016 14:44:51 -0400

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

Dale

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Apr 2016 12:11:59 -0700

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

> to assume that both ends can do a "connect" before they exchange any

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

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Apr 2016 12:23:15 -0700

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

> 			Create socket

optionally bind to local address

> 	Incoming connection event

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

> 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

> know if that possibility is ever used in practice. 

It happens routinely if you end up calling yourself.

> Or whether the

It should, as per above.

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

It had better, IMO.

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

> 			Send-to -or- Connect, then Send

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

> 	Connect (in the TAPS paradigm)

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

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