On 3/20/20 11:04 AM, Joseph Touch wrote:
On Mar 20, 2020, at 7:09 AM, Jon Maloy <jma...@redhat.com
<mailto:jma...@redhat.com>> wrote:
Adding cc toint-a...@ietf.org, since I forgot that in my original
response.
On 3/19/20 9:18 PM, Joseph Touch wrote:
On Mar 19, 2020, at 4:46 PM, Jon Maloy <jma...@redhat.com
<mailto:jma...@redhat.com>> wrote:
IP addresses are no good in the *user API*, because they are
location bound.
That is also why DNS was invented, I believe.
DNS names are intended to be a human-rememberable alias to an IP
address. They do not indicate a location any more than an IP
address does or does not.
Exactly. Read what I wrote again.
IP addresses are no good in the USER API because they are location
bound.
False. DNS names are provided as an alternative for the user API
because they are easier for people to remember and type.
Then I should probably rephrase this so saying that "IP addresses AND
DNS names and are no good in the user API...", although I don't quite
agree with that. DNS names are of course much more convenient for a
user to deal with than IP addresses.
Type in www.google.com <http://www.google.com>
Now type in its IPv6 address.
Now see if you remember google’s website DNS or its IPv6 address.
That’s what the DNS was originally intended for.
Yes. But in this case also demonstrates that both DNS names and the IP
address may be location independent. We have no clue whether a call will
end up in a server farm in the US or Europe, let alone which server it
will be handled on. So, even though the original purpose of DNS may have
been something else, it has clearly followed the obvious path of
becoming a tool for location independence. This is good, but not good
enough for our purposes.
DNS names are no more or less location-independent than IP addresses.
This is also why DNS was invented...
False. The reason the DNS exists has nothing to do with location.
It’s simply string substitution for convenience, or at least was
ONLY that originally.
I think you just supported my case for a location independent
addressing scheme.
I am - but then I’m baffled why you want to run direct over IP.
Ethernet has location independent addresses; IP does not* (see next part)..
When I am talking about location independence I am always talking about
what the socket programmer/user sees. We don't want him to handle IP
addresses, and we probably don't want him to hard code DNS names either.
But, at some level further down in the stack we never get around
translating location independent addresses to some form of location
dependent ditto in order to transmit the packets to the right node and
socket. Be it MAC, IPc4, IPv6 or anything else.
This is what we do in TIPC :
Socket Layer: {service type, service
instance} {port number}
------------------
| A
v |
TIPC Binding Table: {port number, node
number} |
-------------------------
| |
v |
TIPC Link Layer: {UDP port, IP address}
{UDP port, IP address}
----------------------- or {MAC
address} or {MAC address}
| A
v |
+--------------------------------------------->+
The {UDP port, IP address} tuple (or MAC address) at the link layer are
never visible to the user, and may change on-the-fly without him ever
noticing.
The same is true for the {port number, node number} tuple, although the
user here has the option to use those directly, at the expense of
location transparency.
So, our request is simply about enabling us to use a third mapping at
the link layer, an IP address only. This does not in any way interfere
with the location transparency that is already provided at the socket level..
This was one of the original motivations for developing TIPC in the
first place. A programmer using TIPC can hard code his service
addresses if he wants to, ignoring the number of or location of the
corresponding endpoints, even as those move around or scale up/down
quite fast.
Anycast gives you location independent addresses at the cost of doing
discovery “inside the network layer”.
Yes, and that is what we do. But for this to be of any use, that
discovery/translation has to be blistering fast, and that is also what
we do.
However, even if you have those addresses, you still need to identify
the service types (which is what we use ports for).
UDP (at the link level) has only one service type in this case: "TIPC"
At the socket level we are using TIPC service addresses for this, i.e.,
a {service type, service instance} tuple, each element being a 32-bit
integer.
——
I’m still stuck at why you want to run direct over IP. If you want
Ethernet that bridges across routers, GRE does that.
Yes, we could use VxLAN or Geneve or whatever. But that always comes to
a cost both in performance and maintenance.
We want TIPC to be both performant and really simple to use.
If you want loc-independent addresses for services, UDP over IP using
anycast does that.
Again yes, but IP is normally not location independent inside clusters.
8.8.8.8 may be perceived as location independent, but 192.168.100.17 is
typically not. And UDP has well-known limitations:
1) - UDP has 16-bit port numbers, a number space which has to be
strictly managed.
- TIPC has a 32-bit+32-bit service address instead. This is what we
want
to extend to 128+128 bits, so that nobody ever needs to register a
well-known address for TIPC. At least not for the purpose of
avoiding collisions.
2) - UDP is best effort.
- Standard TIPC anycast is "better than best" effort, because
packets will
never be lost in transport. Due to lack of socket level flow
control, there
is still a risk of seeing messages being dropped, though.
- Group anycast DOES have end-to-end flow control, so such messages
will never be lost or disordered.
3) Furthermore, we have reliable multicast and broadcast using the same
address type. There is no way you can get that with UDP.
What is the specific gain of needing IP but not allowing a transport?
AFAICT, it’s all down to GSO - which is an implementation. If GSO
doesn’t do what you want, it would be useful to take your issues there
or edit the code yourself and submit the patches.
In that respect this is only an implementation issue, as you say, but it
is not a TIPC only one.
The slides referred to me by Tom Herbert describe GSO on large UDP
messages, but they don´t describe how we go one step further and do it
on the inner messages, or how we identify those as being TIPC in the
first place. Furthermore, we would have to re-write the host level GSO
support, which am highly uncertain that the Linux network community
would accept, given that everything needed already is there (i.e., if we
only have a proper protocol number.)
GSO is only one of the reasons for our request. There are more reasons:
- Performance. The difference is not dramatic, but clearly measurable.
Terminating sockets in kernel space comes at a cost.
- The need to be able to register a new socket type, which will map down
to a (compatible) TIPC v3 protocol.
- Acceptance. We want to have TIPC recognized as a part of the IP protocol
family, controlled by IETF, like most other protocols.
Regards
///jon
Joe
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
