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

[Joe Touch <[e-mail]>]

On 4/6/2016 9:39 AM, [e-mail] 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