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

[Joe Touch <[e-mail]>]

On 4/7/2016 11:42 AM, Dale R. Worley wrote:
> [e-mail] 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
> 	Endpoint	Endpoint
> 
> 	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
> 	Endpoint	Endpoint
> 
> 	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.