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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
