Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

[Joseph Touch <[e-mail]>]

> On Mar 20, 2020, at 7:09 AM, Jon Maloy <[e-mail]> wrote:
> 
> Adding cc to [e-mail] <mailto:[e-mail]>, 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 <[e-mail] <mailto:[e-mail]>> 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.

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

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

However, even if you have those addresses, you still need to identify the service types (which is what we use ports for).

——

I’m still stuck at why you want to run direct over IP. If you want Ethernet that bridges across routers, GRE does that. If you want loc-independent addresses for services, UDP over IP using anycast does that.

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.

Joe