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

2020-03-23 Thread Joseph Touch 


> On Mar 23, 2020, at 11:40 AM, Jon Maloy  wrote:
> 
>>> 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.
>> 
>> That, IMO, is an ID that belongs *inside* UDP port TIPC. That is YOUR 
>> service type/instance, not the Internet’s. The Internet should consider this 
>> all a single TIPC service.
> 
> Yes. That why we are asking for a protocol number.

That’s what the Internet calls a UDP port number, not an IP protocol number.

There’s no reason why running over UDP should affect your performance per se.

Finally, if you want to be able to switch IP addresses in the middle of things, 
you should consider MP-TCP - whether you run over it or emulate how it works.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2020-03-23 Thread Jon Maloy 



On 3/23/20 11:41 AM, Joseph Touch wrote:

Jon,

First, if you’re going to come to the IETF asking for something as 
core as an IP protocol number, you need to be able to explain your 
system to us in our terms.


That means explaining things below in the following terms:
UDP/TCP and nearly anything over IP = transport
IP = network
Ethernet = link

UDP/IP isn’t a link layer to us;


It isn't for us either. It is a transport for our own link layer, just 
like VxLAN and some other protoctols are using it.


what you’re really asking for, FWIW, is to be a *transport protocol*, 
but that’s not quite what you want either (see below).


Second, if you want an IP protocol number, your system has to “buy-in” 
to the IP model in which IP unicast addresses are endpoints, not 
logical identifiers.



...
Type in 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.


Please be more specific in what you’re seeking then.


Once more: location transparency at the user/socket level.






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.


IP isn’t about that. It’s about what the network sees.


True. But that is IP.
*TIPC* is about location independence at the socket level. This exists, 
and will continue to exist independent of whether we are using IP or 
something else.




We don't want him to handle IP addresses, and we probably don't want 
him to hard code DNS names either.


Please clarify - do you want to hard-code anything? Or have the user 
type it in?


Programmers typically hard code the service type, while the service 
instance more typically is configured or calculated based on 
configuration data.




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}


The Internet uses service names for that (e.g., HTTP, HTTPS, etc).

If service name lookup over the Internet using DNS is too slow, then 
replace it with a different lookup mechanism or implementation.


That is what we have done.


But it’s still DNS and DNS SRV records equivalent at that point.


-- | A
v |
TIPC Binding Table:  {port number, node 
number}   |


Please explain what a node number is...


- | |
v |
TIPC Link Layer:    {UDP port, IP 
address}   {UDP port, IP address}
--- or {MAC 
address}    or {MAC address}


How is a UDP port different from your port?


It is the endpoint for the node-to-node transport, only. There is one or 
two of those per node pair.
The TIPC port is a 32-bit endpoint identifying the socket that 
terminates a service, bound by a {service type, service instance} tuplet.


How is a node number different fro your number?


A node number is just a 32 bit identifier for a node. It could nowadays 
be mapped to an IPv4 address, if any such is available, but since we are 
also running directly on Ethernet, that is not the way it is done now.




The {UDP port, IP address} tuple (or MAC address) at the link layer 
are never visible to the user,


That’s how Internet protocols already work...


Then I guess you see this as a correct level of abstraction, just like I do..




and may change on-the-fly without him ever noticing.


That’s where you lose me. You want IP, but this isn’t IP. This is 
Ethernet, at least as I uses it.


It is a transport for our link layer. If we have two transport channels 
between two nodes, and one of them fail, the remaining one will take 
over all traffic. When the lost channel comes back, it may theor

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

2020-03-23 Thread Jon Maloy 



On 3/23/20 11:38 AM, Tom Herbert wrote:

On Mon, Mar 23, 2020 at 7:32 AM Jon Maloy  wrote:



On 3/20/20 11:04 AM, Joseph Touch wrote:



On Mar 20, 2020, at 7:09 AM, Jon Maloy  wrote:

Adding cc to int-area@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  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

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.

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

2020-03-23 Thread Joseph Touch 
Jon,

First, if you’re going to come to the IETF asking for something as core as an 
IP protocol number, you need to be able to explain your system to us in our 
terms.

That means explaining things below in the following terms:
UDP/TCP and nearly anything over IP = transport
IP = network
Ethernet = link

UDP/IP isn’t a link layer to us; what you’re really asking for, FWIW, is to be 
a *transport protocol*, but that’s not quite what you want either (see below).

Second, if you want an IP protocol number, your system has to “buy-in” to the 
IP model in which IP unicast addresses are endpoints, not logical identifiers.

>> ...
>> Type in 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.

Please be more specific in what you’re seeking then.

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

IP isn’t about that. It’s about what the network sees.

> We don't want him to handle IP addresses, and we probably don't want him to 
> hard code DNS names either.

Please clarify - do you want to hard-code anything? Or have the user type it in?

> 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}

The Internet uses service names for that (e.g., HTTP, HTTPS, etc).

If service name lookup over the Internet using DNS is too slow, then replace it 
with a different lookup mechanism or implementation. But it’s still DNS and DNS 
SRV records equivalent at that point.

> --  | 
>  A
>v  
> |
> TIPC Binding Table:  {port number, node number}   
> |

Please explain what a node number is...

> -  |  
> |
>v  
> |
> TIPC Link Layer:{UDP port, IP address}   {UDP 
> port, IP address} 
> --- or {MAC address}  
>   or {MAC address}

How is a UDP port different from your port?

How is a node number different fro your number?

> The {UDP port, IP address} tuple (or MAC address) at the link layer are never 
> visible to the user,

That’s how Internet protocols already work...

> and may change on-the-fly without him ever noticing. 

That’s where you lose me. You want IP, but this isn’t IP. This is Ethernet, at 
least as I uses it.

> The same is true for the {port number, node number} tuple,

Why?

If everything in your system changes on the fly, what stays the same?

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

My point is that you’re not showing us how this helps. You simply want 
something - I understand that. But you have to show you NEED it. Everything 
you’re saying are reasons why you actually don’t want or need it.

Further, let’s say you get an IP protocol number. Why wouldn’t that be among 
the many things here that needs to

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

2020-03-23 Thread Tom Herbert 
On Mon, Mar 23, 2020 at 7:32 AM Jon Maloy  wrote:
>
>
>
> On 3/20/20 11:04 AM, Joseph Touch wrote:
>
>
>
> On Mar 20, 2020, at 7:09 AM, Jon Maloy  wrote:
>
> Adding cc to int-area@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  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
>
> 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

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

2020-03-23 Thread Jon Maloy 



On 3/20/20 11:04 AM, Joseph Touch wrote:



On Mar 20, 2020, at 7:09 AM, Jon Maloy > 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 > 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 

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 3

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

2020-03-20 Thread Joseph Touch 


> On Mar 20, 2020, at 7:09 AM, Jon Maloy  wrote:
> 
> Adding cc to int-area@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 >> > 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 

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2020-03-20 Thread Jon Maloy 

Adding cc to int-area@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 > 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.


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



I don't know how much you have studied the rest of the tipc.io web site, 
but you should be aware that there are significant differences between 
what is described in the protocol description and what is current reality:


1) There is no zone/cluster/node hierarchy any more. A TIPC network 
consists of a cluster of more or less (normally full-mesh, but that is 
not a requirement) interconnected nodes. That is all.
2) Nodes are currently identified by a flat, unstructured 128-bit 
identifier field, which may or may not be based on a MAC address, an 
IPv6/v4 address, a string (e.g., host name) , a UUID, or something else.
3) Clusters may scale up to 1000 fully-meshed nodes, still with 
second-speed peer failure discovery. This is thanks to the 
patent-pending hierarchical neighbor monitoring algorithm.
4) We have added the concept of "communication groups" (also 
patent-pending), which caters for high-speed, loss free, flow controlled 
unicast, anycast, multicast and broadcast inside very large groups of 
sockets. All of those using the location independent addressing scheme 
we provide in TIPC, of course. To achieve anything like that using DNS 
is very hard to imagine for me.

5) And much more.

In short, an Informational RFC for TIPC would be a significant upgrade 
from the draft version I handed over to Suresh yesterday. That one is 
the base for the current protocol description at our web page, which 
hence also needs an update.


Regards
 ///jon



Joe


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2020-03-19 Thread Jon Maloy 



On 3/19/20 8:07 PM, Tom Herbert wrote:

On Thu, Mar 19, 2020 at 4:33 PM Jon Maloy  wrote:



On 3/19/20 7:03 PM, Tom Herbert wrote:

On Thu, Mar 19, 2020 at 3:43 PM Jon Maloy  wrote:


On 3/18/20 12:04 AM, Joseph Touch wrote:

Hi all,

I’m quite confused by this request.

It seems like they either have an implementation issue (in Linux).

Linux "passthru" GSO is implemented so that any IP based protocol which wants 
to benefit
from it needs its own IP protocol number. Doing this generically through the 
already existing
UDP protocol number is not possible, because GSO on a host must be implemented
specifically (e.g., regarding segmentation) per carried protocol. That is just 
a fact, and not
an implementation issue.

Jon,

I'm not sure I understand your point. Linux already supports GSO, and
GRO for that matter, for several protocols encapsulated over UDP. I
don't see any requirement for a protocol to need its own IP protocol
number in this regard.

Tom

Yes, but this is not about guest GSO. What we need is something more
similar to TCP TSO, where we can send full-size buffers down to the
host OS, and only do segmentation (or in our case, a TIPC specific
fragmentation where each fragment gets an individually numbered header)
when we find that the destination is off-host.
Basically we want to transport full-size messages between VMs when those
are located in the same host. So far, I haven´t found any way to
do this on the host by looking at the inner protocol carried over UDP.
But I may of course be wrong at this point, I know you are the expert.


Jon,

You might want to look at Willem's work in UDP GSO
(http://vger.kernel.org/lpc_net2018_talks/willemdebruijn-lpc2018-udpgso-presentation-20181104.pdf).
That might be useful as a generic method assuming the proper APIs are
supported (this is exactly how QUIC GSO was solved without needing
explict kernel support for QUIC).

Tom

Hi Tom,
I´ll take a look at this. Thank you for the tip.
///jon



///jon


I checked their documentation, which includes smoothing that looks a little 
like an Internet Draft:
http://tipc.io/protocol.html
but it’s quite confusing. Taken at face value, they make their own argument 
that IP addresses won’t work - at which point running raw over IP serves no 
utility (sec 3.1.1),

That is not a correct interpretation of the text. There is nowhere stated that 
IP addresses won't work for TIPC,
neither in sec. 3.1.1 or anywhere else. Of course they work, *for transport 
purposes*, just like they have been
doing for many years already when running TIPC over UDP. What we state 
elsewhere in the document is that
IP addresses are no good in the *user API*, because they are location bound.
That is also why DNS was invented, I  believe.

We also state that using IP addresses is less optimal than omitting the IP 
layer altogether
and using MAC addresses, but that doesn't mean the former are useless, -it just 
makes
IP the only viable alternative in the cases when a network owner doesn't allow 
non-IP
protocols though their back planes, or when routing gets involved.

even though most of those claims are debatable (DNS-SD is too static? And 
expensive?? How so?). Then they reinvent the DNS in Section 6.

There is no doubt that DNS is not the best choice for the type of environments 
(tight clusters) where
we use TIPC. All DNS implementations I know run in user land, and doing a 
service discovery typically
means at least one, and often several inter-process and potentially inter-node 
hops. Even if there is
a process local lookup cache in each sender, that cache has to be populated 
before it is of any use.
Instead, TIPC uses a tailor-made kernel resident translation service which 
normally contains a complete
copy of the the lookup database, so there are no unnecessary hops and no cache 
misses.

This would have been of less importance if TIPC were only a connection oriented 
TCP-like service where
service lookup is only needed at connection setup. But a just as important 
feature of TIPC is its reliable
connectionless transport mode. Here, the lookup service is not primarily about 
service discovery
(although that is also important), but about efficient on-the-fly translation 
between user level service
addresses (aka "port names") and location bound socket addresses (aka "port 
identities"). This
translation has to be performed per message, not per connection, since the 
destination may change
between each message.

If we were to make an analogy with the IP world, we could imagine that we use 
UDP to send high
volume traffic to many different destinations, each having its own domain name. 
Making a
separate DNS lookup for each sent message would certainly work, but it would 
not by far be as
performant as having a tailor made "always cache resident" translation table, 
shared between
all processes, like we do in TIPC.

Furthermore, when the connectionless service is used, sockets might be 
created/deleted and
bound/unbound at extremely high

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

2020-03-19 Thread Tom Herbert 
On Thu, Mar 19, 2020 at 4:33 PM Jon Maloy  wrote:
>
>
>
> On 3/19/20 7:03 PM, Tom Herbert wrote:
> > On Thu, Mar 19, 2020 at 3:43 PM Jon Maloy  wrote:
> >>
> >>
> >> On 3/18/20 12:04 AM, Joseph Touch wrote:
> >>
> >> Hi all,
> >>
> >> I’m quite confused by this request.
> >>
> >> It seems like they either have an implementation issue (in Linux).
> >>
> >> Linux "passthru" GSO is implemented so that any IP based protocol which 
> >> wants to benefit
> >> from it needs its own IP protocol number. Doing this generically through 
> >> the already existing
> >> UDP protocol number is not possible, because GSO on a host must be 
> >> implemented
> >> specifically (e.g., regarding segmentation) per carried protocol. That is 
> >> just a fact, and not
> >> an implementation issue.
> > Jon,
> >
> > I'm not sure I understand your point. Linux already supports GSO, and
> > GRO for that matter, for several protocols encapsulated over UDP. I
> > don't see any requirement for a protocol to need its own IP protocol
> > number in this regard.
> >
> > Tom
> Yes, but this is not about guest GSO. What we need is something more
> similar to TCP TSO, where we can send full-size buffers down to the
> host OS, and only do segmentation (or in our case, a TIPC specific
> fragmentation where each fragment gets an individually numbered header)
> when we find that the destination is off-host.
> Basically we want to transport full-size messages between VMs when those
> are located in the same host. So far, I haven´t found any way to
> do this on the host by looking at the inner protocol carried over UDP.
> But I may of course be wrong at this point, I know you are the expert.
>

Jon,

You might want to look at Willem's work in UDP GSO
(http://vger.kernel.org/lpc_net2018_talks/willemdebruijn-lpc2018-udpgso-presentation-20181104.pdf).
That might be useful as a generic method assuming the proper APIs are
supported (this is exactly how QUIC GSO was solved without needing
explict kernel support for QUIC).

Tom

> ///jon
>
> >
> >>
> >> I checked their documentation, which includes smoothing that looks a 
> >> little like an Internet Draft:
> >> http://tipc.io/protocol.html
> >> but it’s quite confusing. Taken at face value, they make their own 
> >> argument that IP addresses won’t work - at which point running raw over IP 
> >> serves no utility (sec 3.1.1),
> >>
> >> That is not a correct interpretation of the text. There is nowhere stated 
> >> that IP addresses won't work for TIPC,
> >> neither in sec. 3.1.1 or anywhere else. Of course they work, *for 
> >> transport purposes*, just like they have been
> >> doing for many years already when running TIPC over UDP. What we state 
> >> elsewhere in the document is that
> >> IP addresses are no good in the *user API*, because they are location 
> >> bound.
> >> That is also why DNS was invented, I  believe.
> >>
> >> We also state that using IP addresses is less optimal than omitting the IP 
> >> layer altogether
> >> and using MAC addresses, but that doesn't mean the former are useless, -it 
> >> just makes
> >> IP the only viable alternative in the cases when a network owner doesn't 
> >> allow non-IP
> >> protocols though their back planes, or when routing gets involved.
> >>
> >> even though most of those claims are debatable (DNS-SD is too static? And 
> >> expensive?? How so?). Then they reinvent the DNS in Section 6.
> >>
> >> There is no doubt that DNS is not the best choice for the type of 
> >> environments (tight clusters) where
> >> we use TIPC. All DNS implementations I know run in user land, and doing a 
> >> service discovery typically
> >> means at least one, and often several inter-process and potentially 
> >> inter-node hops. Even if there is
> >> a process local lookup cache in each sender, that cache has to be 
> >> populated before it is of any use.
> >> Instead, TIPC uses a tailor-made kernel resident translation service which 
> >> normally contains a complete
> >> copy of the the lookup database, so there are no unnecessary hops and no 
> >> cache misses.
> >>
> >> This would have been of less importance if TIPC were only a connection 
> >> oriented TCP-like service where
> >> service lookup is only needed at connection setup. But a just as important 
> >> feature of TIPC is its reliable
> >> connectionless transport mode. Here, the lookup service is not primarily 
> >> about service discovery
> >> (although that is also important), but about efficient on-the-fly 
> >> translation between user level service
> >> addresses (aka "port names") and location bound socket addresses (aka 
> >> "port identities"). This
> >> translation has to be performed per message, not per connection, since the 
> >> destination may change
> >> between each message.
> >>
> >> If we were to make an analogy with the IP world, we could imagine that we 
> >> use UDP to send high
> >> volume traffic to many different destinations, each having its own domain 
> >> name. Making a
> >> separate

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

2020-03-19 Thread Jon Maloy 



On 3/19/20 7:03 PM, Tom Herbert wrote:

On Thu, Mar 19, 2020 at 3:43 PM Jon Maloy  wrote:



On 3/18/20 12:04 AM, Joseph Touch wrote:

Hi all,

I’m quite confused by this request.

It seems like they either have an implementation issue (in Linux).

Linux "passthru" GSO is implemented so that any IP based protocol which wants 
to benefit
from it needs its own IP protocol number. Doing this generically through the 
already existing
UDP protocol number is not possible, because GSO on a host must be implemented
specifically (e.g., regarding segmentation) per carried protocol. That is just 
a fact, and not
an implementation issue.

Jon,

I'm not sure I understand your point. Linux already supports GSO, and
GRO for that matter, for several protocols encapsulated over UDP. I
don't see any requirement for a protocol to need its own IP protocol
number in this regard.

Tom
Yes, but this is not about guest GSO. What we need is something more 
similar to TCP TSO, where we can send full-size buffers down to the
host OS, and only do segmentation (or in our case, a TIPC specific 
fragmentation where each fragment gets an individually numbered header) 
when we find that the destination is off-host.
Basically we want to transport full-size messages between VMs when those 
are located in the same host. So far, I haven´t found any way to

do this on the host by looking at the inner protocol carried over UDP.
But I may of course be wrong at this point, I know you are the expert.

///jon





I checked their documentation, which includes smoothing that looks a little 
like an Internet Draft:
http://tipc.io/protocol.html
but it’s quite confusing. Taken at face value, they make their own argument 
that IP addresses won’t work - at which point running raw over IP serves no 
utility (sec 3.1.1),

That is not a correct interpretation of the text. There is nowhere stated that 
IP addresses won't work for TIPC,
neither in sec. 3.1.1 or anywhere else. Of course they work, *for transport 
purposes*, just like they have been
doing for many years already when running TIPC over UDP. What we state 
elsewhere in the document is that
IP addresses are no good in the *user API*, because they are location bound.
That is also why DNS was invented, I  believe.

We also state that using IP addresses is less optimal than omitting the IP 
layer altogether
and using MAC addresses, but that doesn't mean the former are useless, -it just 
makes
IP the only viable alternative in the cases when a network owner doesn't allow 
non-IP
protocols though their back planes, or when routing gets involved.

even though most of those claims are debatable (DNS-SD is too static? And 
expensive?? How so?). Then they reinvent the DNS in Section 6.

There is no doubt that DNS is not the best choice for the type of environments 
(tight clusters) where
we use TIPC. All DNS implementations I know run in user land, and doing a 
service discovery typically
means at least one, and often several inter-process and potentially inter-node 
hops. Even if there is
a process local lookup cache in each sender, that cache has to be populated 
before it is of any use.
Instead, TIPC uses a tailor-made kernel resident translation service which 
normally contains a complete
copy of the the lookup database, so there are no unnecessary hops and no cache 
misses.

This would have been of less importance if TIPC were only a connection oriented 
TCP-like service where
service lookup is only needed at connection setup. But a just as important 
feature of TIPC is its reliable
connectionless transport mode. Here, the lookup service is not primarily about 
service discovery
(although that is also important), but about efficient on-the-fly translation 
between user level service
addresses (aka "port names") and location bound socket addresses (aka "port 
identities"). This
translation has to be performed per message, not per connection, since the 
destination may change
between each message.

If we were to make an analogy with the IP world, we could imagine that we use 
UDP to send high
volume traffic to many different destinations, each having its own domain name. 
Making a
separate DNS lookup for each sent message would certainly work, but it would 
not by far be as
performant as having a tailor made "always cache resident" translation table, 
shared between
all processes, like we do in TIPC.

Furthermore, when the connectionless service is used, sockets might be 
created/deleted and
bound/unbound at extremely high rates, much higher than DNS with its 
hierarchical updates
is meant to deal with. This is what we mean with DNS being too "static". It is 
not saying that
DNS is bad, it is just stating that it is not designed for the very high 
performance requirements
and dynamism we have in TIPC.

There is no doubt that a few things in TIPC could have been done differently,  
but the decision
to design our own topology/lookup service is not among those. This request is 
an attempt to
open up for

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

2020-03-19 Thread Joseph Touch 


> On Mar 19, 2020, at 3:11 PM, Jon Maloy  wrote:
> 
> On 3/18/20 12:04 AM, Joseph Touch wrote:
>> Hi all,
>> 
>> I’m quite confused by this request.
>> 
>> It seems like they either have an implementation issue (in Linux). 
> Linux "passthru" GSO is implemented so that any IP based protocol which wants 
> to benefit 
  ^
> from it needs its own IP protocol number. Doing this generically through the 
> already existing 
> UDP protocol number is not possible, because GSO on a host must be 
> implemented 
> specifically (e.g., regarding segmentation) per carried protocol. That is 
> just a fact, and not 
> an implementation issue.  

How is that not exactly an implementation issue?


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

…
> Whatever the viewpoints, TIPC is currently what it is,

As is IP...

> and rather than focusing on the motivation
> for certain implementation choices and how they work, I think IETF should 
> consider the fact
> that this is a well-established service used by dozens of small and big 
> companies, running high-volume
> traffic at hundreds of telco sites around the globe. They should also 
> consider that TIPC has 
> existed as a stable and well-maintained implementation in all major Linux 
> distros for many years.

I won’t focus on the bad decisions in TIPC if you won’t ask for a protocol 
number -deal?

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2020-03-19 Thread Tom Herbert 
On Thu, Mar 19, 2020 at 3:43 PM Jon Maloy  wrote:
>
>
>
> On 3/18/20 12:04 AM, Joseph Touch wrote:
>
> Hi all,
>
> I’m quite confused by this request.
>
> It seems like they either have an implementation issue (in Linux).
>
> Linux "passthru" GSO is implemented so that any IP based protocol which wants 
> to benefit
> from it needs its own IP protocol number. Doing this generically through the 
> already existing
> UDP protocol number is not possible, because GSO on a host must be implemented
> specifically (e.g., regarding segmentation) per carried protocol. That is 
> just a fact, and not
> an implementation issue.

Jon,

I'm not sure I understand your point. Linux already supports GSO, and
GRO for that matter, for several protocols encapsulated over UDP. I
don't see any requirement for a protocol to need its own IP protocol
number in this regard.

Tom

>
>
> I checked their documentation, which includes smoothing that looks a little 
> like an Internet Draft:
> http://tipc.io/protocol.html
> but it’s quite confusing. Taken at face value, they make their own argument 
> that IP addresses won’t work - at which point running raw over IP serves no 
> utility (sec 3.1.1),
>
> That is not a correct interpretation of the text. There is nowhere stated 
> that IP addresses won't work for TIPC,
> neither in sec. 3.1.1 or anywhere else. Of course they work, *for transport 
> purposes*, just like they have been
> doing for many years already when running TIPC over UDP. What we state 
> elsewhere in the document is that
> IP addresses are no good in the *user API*, because they are location bound.
> That is also why DNS was invented, I  believe.
>
> We also state that using IP addresses is less optimal than omitting the IP 
> layer altogether
> and using MAC addresses, but that doesn't mean the former are useless, -it 
> just makes
> IP the only viable alternative in the cases when a network owner doesn't 
> allow non-IP
> protocols though their back planes, or when routing gets involved.
>
> even though most of those claims are debatable (DNS-SD is too static? And 
> expensive?? How so?). Then they reinvent the DNS in Section 6.
>
> There is no doubt that DNS is not the best choice for the type of 
> environments (tight clusters) where
> we use TIPC. All DNS implementations I know run in user land, and doing a 
> service discovery typically
> means at least one, and often several inter-process and potentially 
> inter-node hops. Even if there is
> a process local lookup cache in each sender, that cache has to be populated 
> before it is of any use.
> Instead, TIPC uses a tailor-made kernel resident translation service which 
> normally contains a complete
> copy of the the lookup database, so there are no unnecessary hops and no 
> cache misses.
>
> This would have been of less importance if TIPC were only a connection 
> oriented TCP-like service where
> service lookup is only needed at connection setup. But a just as important 
> feature of TIPC is its reliable
> connectionless transport mode. Here, the lookup service is not primarily 
> about service discovery
> (although that is also important), but about efficient on-the-fly translation 
> between user level service
> addresses (aka "port names") and location bound socket addresses (aka "port 
> identities"). This
> translation has to be performed per message, not per connection, since the 
> destination may change
> between each message.
>
> If we were to make an analogy with the IP world, we could imagine that we use 
> UDP to send high
> volume traffic to many different destinations, each having its own domain 
> name. Making a
> separate DNS lookup for each sent message would certainly work, but it would 
> not by far be as
> performant as having a tailor made "always cache resident" translation table, 
> shared between
> all processes, like we do in TIPC.
>
> Furthermore, when the connectionless service is used, sockets might be 
> created/deleted and
> bound/unbound at extremely high rates, much higher than DNS with its 
> hierarchical updates
> is meant to deal with. This is what we mean with DNS being too "static". It 
> is not saying that
> DNS is bad, it is just stating that it is not designed for the very high 
> performance requirements
> and dynamism we have in TIPC.
>
> There is no doubt that a few things in TIPC could have been done differently, 
>  but the decision
> to design our own topology/lookup service is not among those. This request is 
> an attempt to
> open up for moving beyond some current limitations, e.g., by enabling 
> introduction of a more
> versatile 128-bit  service addressing concept.  Along with this request we 
> are aiming at having
> an updated version of the protocol description adopted as an informational 
> RFC, so that
> TIPC can be regarded as an IETF supported protocol in its own right.
>
> Whatever the viewpoints, TIPC is currently what it is, and rather than 
> focusing on the motivation
> for certain implementa

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

2020-03-19 Thread Jon Maloy 



On 3/18/20 12:04 AM, Joseph Touch wrote:

Hi all,

I’m quite confused by this request.

It seems like they either have an implementation issue (in Linux).
Linux "passthru" GSO is implemented so that any IP based protocol which 
wants to benefit
from it needs its own IP protocol number. Doing this generically through 
the already existing
UDP protocol number is not possible, because GSO on a host must be 
implemented
specifically (e.g., regarding segmentation) per carried protocol. That 
is just a fact, and not

an implementation issue.


I checked their documentation, which includes smoothing that looks a 
little like an Internet Draft:

http://tipc.io/protocol.html
but it’s quite confusing. Taken at face value, they make their own 
argument that IP addresses won’t work - at which point running raw 
over IP serves no utility (sec 3.1.1),
That is not a correct interpretation of the text. There is nowhere 
stated that IP addresses won't work for TIPC,
neither in sec. 3.1.1 or anywhere else. Of course they work, *for 
transport purposes*, just like they have been
doing for many years already when running TIPC over UDP. What we state 
elsewhere in the document is that
IP addresses are no good in the *user API*, because they are location 
bound.

That is also why DNS was invented, I  believe.

We also state that using IP addresses is less optimal than omitting the 
IP layer altogether
and using MAC addresses, but that doesn't mean the former are useless, 
-it just makes
IP the only viable alternative in the cases when a network owner doesn't 
allow non-IP

protocols though their back planes, or when routing gets involved.

even though most of those claims are debatable (DNS-SD is too static? 
And expensive?? How so?). Then they reinvent the DNS in Section 6.
There is no doubt that DNS is not the best choice for the type of 
environments (tight clusters) where
we use TIPC. All DNS implementations I know run in user land, and doing 
a service discovery typically
means at least one, and often several inter-process and potentially 
inter-node hops. Even if there is
a process local lookup cache in each sender, that cache has to be 
populated before it is of any use.
Instead, TIPC uses a tailor-made kernel resident translation service 
which normally contains a complete
copy of the the lookup database, so there are no unnecessary hops and no 
cache misses.


This would have been of less importance if TIPC were only a connection 
oriented TCP-like service where
service lookup is only needed at connection setup. But a just as 
important feature of TIPC is its reliable
connectionless transport mode. Here, the lookup service is not primarily 
about service discovery
(although that is also important), but about efficient on-the-fly 
translation between user level service
addresses (aka "port names") and location bound socket addresses (aka 
"port identities"). This
translation has to be performed per message, not per connection, since 
the destination may change

between each message.

If we were to make an analogy with the IP world, we could imagine that 
we use UDP to send high
volume traffic to many different destinations, each having its own 
domain name. Making a
separate DNS lookup for each sent message would certainly work, but it 
would not by far be as
performant as having a tailor made "always cache resident" translation 
table, shared between

all processes, like we do in TIPC.

Furthermore, when the connectionless service is used, sockets might be 
created/deleted and
bound/unbound at extremely high rates, much higher than DNS with its 
hierarchical updates
is meant to deal with. This is what we mean with DNS being too "static". 
It is not saying that
DNS is bad, it is just stating that it is not designed for the very high 
performance requirements

and dynamism we have in TIPC.

There is no doubt that a few things in TIPC could have been done 
differently,  but the decision
to design our own topology/lookup service is not among those. This 
request is an attempt to
open up for moving beyond some current limitations, e.g., by enabling 
introduction of a more
versatile 128-bit  service addressing concept.  Along with this request 
we are aiming at having
an updated version of the protocol description adopted as an 
informational RFC, so that

TIPC can be regarded as an IETF supported protocol in its own right.

Whatever the viewpoints, TIPC is currently what it is, and rather than 
focusing on the motivation
for certain implementation choices and how they work, I think IETF 
should consider the fact
that this is a well-established service used by dozens of small and big 
companies, running high-volume
traffic at hundreds of telco sites around the globe. They should also 
consider that TIPC has
existed as a stable and well-maintained implementation in all major 
Linux distros for many years.


IETF now has a genuine chance to help us making TIPC even more useful 
for existing and new users.


BR
Jon Maloy

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

2020-03-17 Thread Joseph Touch 
Hi all,

I’m quite confused by this request.

It seems like they either have an implementation issue (in Linux). 

I checked their documentation, which includes smoothing that looks a little 
like an Internet Draft:
http://tipc.io/protocol.html 
but it’s quite confusing. Taken at face value, they make their own argument 
that IP addresses won’t work - at which point running raw over IP serves no 
utility (sec 3.1.1), even though most of those claims are debatable (DNS-SD is 
too static? And expensive?? How so?). Then they reinvent the DNS in Section 6.

Frankly, IMO this would probably have a difficult time arguing for a transport 
protocol port number, much less an IP protocol number.

Joe


> On Mar 17, 2020, at 3:34 PM, Suresh Krishnan  wrote:
> 
> Hi all,
>   IANA received an IP protocol number allocation request from Jon Maloy 
> mailto:jma...@redhat.com>> for the Transparent Inter 
> Process Communication (TIPC) protocol. I picked up this request as Internet 
> AD as the registration procedure requires IESG Approval. I had provided the 
> information below to the IESG and discussed this with a favorable view of 
> this request. I am recommending allocation of an IP protocol number for this. 
> If you have any concerns that you think I might have overlooked, please let 
> me know by end of day March 24 2020.
> 
> After several round trips of back and forth probing I had collected the 
> following information regarding the protocol number request for TIPC. There 
> were two main questions I had for him:
> 
> * Q1: Why did they want an IP protocol number?
> * Q2: Is the protocol implemented and deployed widely?
> 
> Q1: Why did they want an IP protocol number?
> 
> 
> There are two main reasons why they want to reserve an IP protocol number:
> 
> 1)  Performance
> They are currently working on adding GSO support to TIPC, including a 
> TSO-like "full-size buffer pass-thru" though virtio and the host OS tap 
> interface. They have experimentally implemented GSO across UDP tunnels, but 
> performance is not good because of the way the tunnel GSO is implemented, and 
> there is no 'pass-thru' support for this in Linux. They have even done the 
> same at the pure L2 level, but L2 transport is sometimes not accepted by the 
> cloud maintainers or the telco operators, and hence they need an alternative. 
> The best alternative, both from a performance and acceptability viewpoint 
> would be to establish TIPC as a full-fledged IP protocol, apart from the 
> traditional L2 bearer many users are still using.
> 
> 2) Currently TIPC has two user address types:
> 
> struct tipc_service_addr{
> uint32_t type;
> uint32_t instance;
> uint32_t node;
> };
> struct tipc_service_addr{
> uint32_t port;
> uint32_t node;
> };
> 
> They want to complement this  with a new API where we have a unified address 
> type:
> struct tipc_addr{
>u8 type[16];
>u8 instance[16];
>u8 node[16];
> };
> 
> This would give a 128-bit value range for both 'type', 'instance' and 'node', 
> and opens up for new opportunities:
> - Users will never need to coordinate 'type' values since there will no risk 
> of collisions.
> - Users can put whatever they want into the fields, e.g., an IPv6 address, a 
> Kubernetes or Docker container id, a LUKS disk UUID or just a plain string.
> For the 'node' id this has already been implemented and released, but it is 
> not reflected in the API yet.
> 
> For the API extension they need a new IPPROTO_TIPC socket type which can be 
> registered and instantiated independently from the traditional AF_TIPC socket 
> type.
> 
> You can find more info about this at http://tipc.io 
> 
> Q2: Is the protocol implemented and deployed widely?
> ==
> 
> The requester provided the following information when I asked about who was 
> currently using TIPC (pretty much about adoption and deployment):
> 
> I can give you a list of current or recently active code contributors and 
> companies/people who have been asking for support:
> 
> Huawei:
> For natural reasons I don't know any details about them, I can only name 
> persons I have seen contributing to netdev or being active on our mailing 
> lists. Huawei people sometimes use gmail addresses when posting questions and 
> patches, so there are more persons than I have listed here.
> Dmitry Kolmakov  >
> Ji Qin mailto:jiqin...@huawei.com>>
> Wei Yongjun mailto:weiyongj...@huawei.com>>
> mailto:songshuaishu...@huawei.com>>
> Yue Haibing mailto:yuehaib...@huawei.com>>
> Junwei Hu mailto:hujunw...@huawei.com>>
> Jie Liu mailto:liujie...@huawei.com>>
> Qiang Ning mailto:ningqia...@huawei.com>>
> Zhiqiang Liu mailto:liuzhiqian...@huawei.com>>
> Miaohe Lin mailto:linmia...@huawei.com>>
> Wang Wang mailto:wangwa...@huawei.com>>
> Kang Zhou mailto:zhouka...@huawei.com>>
> Suanming Mou mailto:mousu

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

2020-03-17 Thread Suresh Krishnan 
Hi all,
  IANA received an IP protocol number allocation request from Jon Maloy 
mailto:jma...@redhat.com>> for the Transparent Inter Process 
Communication (TIPC) protocol. I picked up this request as Internet AD as the 
registration procedure requires IESG Approval. I had provided the information 
below to the IESG and discussed this with a favorable view of this request. I 
am recommending allocation of an IP protocol number for this. If you have any 
concerns that you think I might have overlooked, please let me know by end of 
day March 24 2020.

After several round trips of back and forth probing I had collected the 
following information regarding the protocol number request for TIPC. There 
were two main questions I had for him:

* Q1: Why did they want an IP protocol number?
* Q2: Is the protocol implemented and deployed widely?

Q1: Why did they want an IP protocol number?


There are two main reasons why they want to reserve an IP protocol number:

1)  Performance
They are currently working on adding GSO support to TIPC, including a TSO-like 
"full-size buffer pass-thru" though virtio and the host OS tap interface. They 
have experimentally implemented GSO across UDP tunnels, but performance is not 
good because of the way the tunnel GSO is implemented, and there is no 
'pass-thru' support for this in Linux. They have even done the same at the pure 
L2 level, but L2 transport is sometimes not accepted by the cloud maintainers 
or the telco operators, and hence they need an alternative. The best 
alternative, both from a performance and acceptability viewpoint would be to 
establish TIPC as a full-fledged IP protocol, apart from the traditional L2 
bearer many users are still using.

2) Currently TIPC has two user address types:

struct tipc_service_addr{
uint32_t type;
uint32_t instance;
uint32_t node;
};
struct tipc_service_addr{
uint32_t port;
uint32_t node;
};

They want to complement this  with a new API where we have a unified address 
type:
struct tipc_addr{
   u8 type[16];
   u8 instance[16];
   u8 node[16];
};

This would give a 128-bit value range for both 'type', 'instance' and 'node', 
and opens up for new opportunities:
- Users will never need to coordinate 'type' values since there will no risk of 
collisions.
- Users can put whatever they want into the fields, e.g., an IPv6 address, a 
Kubernetes or Docker container id, a LUKS disk UUID or just a plain string.
For the 'node' id this has already been implemented and released, but it is not 
reflected in the API yet.

For the API extension they need a new IPPROTO_TIPC socket type which can be 
registered and instantiated independently from the traditional AF_TIPC socket 
type.

You can find more info about this at http://tipc.io

Q2: Is the protocol implemented and deployed widely?
==

The requester provided the following information when I asked about who was 
currently using TIPC (pretty much about adoption and deployment):

I can give you a list of current or recently active code contributors and 
companies/people who have been asking for support:

Huawei:
For natural reasons I don't know any details about them, I can only name 
persons I have seen contributing to netdev or being active on our mailing 
lists. Huawei people sometimes use gmail addresses when posting questions and 
patches, so there are more persons than I have listed here.
Dmitry Kolmakov 
mailto:kolmakov.dmit...@huawei..com>>
Ji Qin mailto:jiqin...@huawei.com>>
Wei Yongjun mailto:weiyongj...@huawei.com>>
mailto:songshuaishu...@huawei.com>>
Yue Haibing mailto:yuehaib...@huawei.com>>
Junwei Hu mailto:hujunw...@huawei.com>>
Jie Liu mailto:liujie...@huawei.com>>
Qiang Ning mailto:ningqia...@huawei.com>>
Zhiqiang Liu mailto:liuzhiqian...@huawei.com>>
Miaohe Lin mailto:linmia...@huawei.com>>
Wang Wang mailto:wangwa...@huawei.com>>
Kang Zhou mailto:zhouka...@huawei.com>>
Suanming Mou mailto:mousuanm...@huawei.com>>

Hu Junwei is the one I see most active at the moment.

Nokia:
Tommi Rantala mailto:tommi.t.rant...@nokia.com>>

Verizon:
Amar Nv mailto:amar...@in.verizon.com>>
Jayaraj Wilson, 
mailto:jayaraj.wil...@in.verizon.com>>

Hewlett Packard Enterprise:
mailto:jonas.ar...@hpe.com>>

WindRiver:
Ying Xue mailto:ying@windriver.com>>
He is my co-maintainer at netdev ans sourcefoge.
Windriver has several products in the field based on TIPC, e.g. control system 
for Sikorsky helicopters.

Orange:
Christophe JAILLET 
mailto:christophe.jail...@wanadoo.fr>>

Redhat:
The person contacting me to have TIPC integrated and maintained in RHEL-8.0 was
Sirius Rayner-Karlsson mailto:akarls...@redhat.com>>
He motivated it with a request from "a telco vendor", but I don't know which 
one.
Hence, TIPC is now integrated in and officially supported from RHEL 8.1

ABB:
https://new.abb.com/pl
Mikolaj K. Chojnacki 
Krzysztof Rybak 

Ericsson:
All (dozens of) applications based on the TSP and Co