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

From: Suresh Krishnan <[email-masked]>
Date: Tue, 17 Mar 2020 22:34:26 +0000

Hi all,
  IANA received an IP protocol number allocation request from Jon Maloy <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Ji Qin <[email-masked]<mailto:[email-masked]>>
Wei Yongjun <[email-masked]<mailto:[email-masked]>>
<[email-masked]<mailto:[email-masked]>>
Yue Haibing <[email-masked]<mailto:[email-masked]>>
Junwei Hu <[email-masked]<mailto:[email-masked]>>
Jie Liu <[email-masked]<mailto:[email-masked]>>
Qiang Ning <[email-masked]<mailto:[email-masked]>>
Zhiqiang Liu <[email-masked]<mailto:[email-masked]>>
Miaohe Lin <[email-masked]<mailto:[email-masked]>>
Wang Wang <[email-masked]<mailto:[email-masked]>>
Kang Zhou <[email-masked]<mailto:[email-masked]>>
Suanming Mou <[email-masked]<mailto:[email-masked]>>

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

Nokia:
Tommi Rantala <[email-masked]<mailto:[email-masked]>>

Verizon:
Amar Nv <[email-masked]<mailto:[email-masked]>>
Jayaraj Wilson, <[email-masked]<mailto:[email-masked]>>

Hewlett Packard Enterprise:
<[email-masked]<mailto:[email-masked]>>

WindRiver:
Ying Xue <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>

Redhat:
The person contacting me to have TIPC integrated and maintained in RHEL-8.0 was
Sirius Rayner-Karlsson <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]>
Krzysztof Rybak <[email-masked]>

Ericsson:
All (dozens of) applications based on the TSP and Core Middleware/Components Based Architecture (CMW/CBA) platforms is per definition based on TIPC. They have not yet started to use TIPC on their Kubernetes based ADP platform, but there is work ongoing on this.

I also see numerous other people being active, from small (I believe) companies, universities and private contributors. E.g.,
Innovsys Inc  http://www.innovsys.com/innovsys/
Allied Telesis https://www.alliedtelesis.com/
Telaverge Communications http://www.telaverge.com/
Ivan Serdyuk <[email-masked]> (seems to be responsible for the ZeroMQ port of TIPC)
John Hopkins University / Fast LTA, Munich <[email-masked]>
Just to mention a few...

TIPC is currently maintained jointly by Ericsson, WindRiver, Redhat, and the Australian consulting company DEK Technologies https://www.dektech.com.au/

Thanks
Suresh

---

From: Joseph Touch <[email-masked]>
Date: Tue, 17 Mar 2020 21:04:27 -0700

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 <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 <[email-masked]> wrote:
> 
> Hi all,
>   IANA received an IP protocol number allocation request from Jon Maloy <[email-masked] <mailto:[email-masked]>> 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.
> 
> You can find more info about this at http://tipc.io <http://tipc.io/>
> 
> Dmitry Kolmakov <[email-masked] <mailto:[email-masked]>>
> Ji Qin <[email-masked] <mailto:[email-masked]>>
> Wei Yongjun <[email-masked] <mailto:[email-masked]>>
> <[email-masked] <mailto:[email-masked]>>
> Yue Haibing <[email-masked] <mailto:[email-masked]>>
> Junwei Hu <[email-masked] <mailto:[email-masked]>>
> Jie Liu <[email-masked] <mailto:[email-masked]>>
> Qiang Ning <[email-masked] <mailto:[email-masked]>>
> Zhiqiang Liu <[email-masked] <mailto:[email-masked]>>
> Miaohe Lin <[email-masked] <mailto:[email-masked]>>
> Wang Wang <[email-masked] <mailto:[email-masked]>>
> Kang Zhou <[email-masked] <mailto:[email-masked]>>
> Suanming Mou <[email-masked] <mailto:[email-masked]>>
> 
> Tommi Rantala <[email-masked] <mailto:[email-masked]>>
> 
> Verizon:
> Amar Nv <amar.nv@in..verizon.com <mailto:[email-masked]>> 
> Jayaraj Wilson, <[email-masked] <mailto:[email-masked]>>
> 
> <[email-masked] <mailto:[email-masked]>>
> 
> WindRiver:
> Ying Xue <[email-masked] <mailto:[email-masked]>>
> Christophe JAILLET <[email-masked] <mailto:[email-masked]>>
> 
> Redhat:
> Sirius Rayner-Karlsson <[email-masked] <mailto:[email-masked]>>
> https://new.abb.com/pl <https://new.abb.com/pl>
> TIPC is currently maintained jointly by Ericsson, WindRiver, Redhat, and the Australian consulting company DEK Technologies https://www.dektech.com.au/ <https://www.dektech.com.au/>
> 
> Thanks
> Suresh
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Jon Maloy <[email-masked]>
Date: Thu, 19 Mar 2020 18:11:24 -0400

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

>
> 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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>   IANA received an IP protocol number allocation request from Jon 
>> Maloy <[email-masked] <mailto:[email-masked]>> 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:
>>
>> 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.
>>
>> This would give a 128-bit value range for both 'type', 'instance' and 
>> 'node', and opens up for new opportunities:
>> - 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 API extension they need a new IPPROTO_TIPC socket type which 
>> can be registered and instantiated independently from the traditional 
>> AF_TIPC socket type.
>>
>> 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.
>> Mikolaj K. Chojnacki <[email-masked] 
>> <mailto:[email-masked]>>
>> Krzysztof Rybak <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> Ericsson:
>> All (dozens of) applications based on the TSP and Core 
>> Middleware/Components Based Architecture (CMW/CBA) platforms is per 
>> definition based on TIPC. They have not yet started to use TIPC on 
>> their Kubernetes based ADP platform, but there is work ongoing on this.
>>
>> I also see numerous other people being active, from small (I believe) 
>> companies, universities and private contributors. E.g.,
>> Ivan Serdyuk <[email-masked] 
>> <mailto:[email-masked]>> (seems to be responsible for 
>> the ZeroMQ port of TIPC)
>> John Hopkins University / Fast LTA, Munich 
>> <[email-masked] <mailto:[email-masked]>>
>> Just to mention a few...
>>
>> TIPC is currently maintained jointly by Ericsson, WindRiver, Redhat, 
>> and the Australian consulting company DEK Technologies 
>> https://www.dektech.com.au/
>>
>> Thanks
>> Suresh
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 Mar 2020 16:03:23 -0700

On Thu, Mar 19, 2020 at 3:43 PM Jon Maloy <[email-masked]> wrote:
> 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

> 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.
> 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
> 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
> 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
> 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
> 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
>
>
>   IANA received an IP protocol number allocation request from Jon Maloy <[email-masked]> 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.
>
> Dmitry Kolmakov <[email-masked]>
> Ji Qin <[email-masked]>
> Wei Yongjun <[email-masked]>
> <[email-masked]>
> Yue Haibing <[email-masked]>
> Junwei Hu <[email-masked]>
> Jie Liu <[email-masked]>
> Qiang Ning <[email-masked]>
> Zhiqiang Liu <[email-masked]>
> Miaohe Lin <[email-masked]>
> Wang Wang <[email-masked]>
> Kang Zhou <[email-masked]>
> Suanming Mou <[email-masked]>
>
> Tommi Rantala <[email-masked]>
>
> Verizon:
> Amar Nv <amar.nv@in..verizon..com>
> Jayaraj Wilson, <[email-masked]>
>
> <[email-masked]>
> Ying Xue <[email-masked]>
> Christophe JAILLET <[email-masked]>
>
> Redhat:
> Sirius Rayner-Karlsson <[email-masked]>

---

From: Joseph Touch <[email-masked]>
Date: Thu, 19 Mar 2020 16:31:50 -0700

> On Mar 19, 2020, at 3:11 PM, Jon Maloy <[email-masked]> wrote:
> 
                                          ^^^^^^^^^^^^^
> specifically (e.g., regarding segmentation) per carried protocol. That is just a fact, and not 

How is that not exactly an implementation issue?

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

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

Joe

---

From: Jon Maloy <[email-masked]>
Date: Thu, 19 Mar 2020 19:32:45 -0400

> don't see any requirement for a protocol to need its own IP protocol
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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 Mar 2020 17:07:36 -0700

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

---

From: Jon Maloy <[email-masked]>
Date: Thu, 19 Mar 2020 20:20:09 -0400

> explict kernel support for QUIC).
Hi Tom,
I´ll take a look at this. Thank you for the tip.
///jon

---

From: Jon Maloy <[email-masked]>
Date: Fri, 20 Mar 2020 10:09:15 -0400

Adding cc to [email-masked], 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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> 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

---

From: Joseph Touch <[email-masked]>
Date: Fri, 20 Mar 2020 08:04:40 -0700

> On Mar 20, 2020, at 7:09 AM, Jon Maloy <[email-masked]> wrote:
> 
> Adding cc to [email-masked] <mailto:[email-masked]>, since I forgot that in my original response.
>  
> 
>>> On Mar 19, 2020, at 4:46 PM, Jon Maloy <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> 	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.

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

---

From: Jon Maloy <[email-masked]>
Date: Mon, 23 Mar 2020 10:31:17 -0400

On 3/20/20 11:04 AM, Joseph Touch wrote:
>
>
>> On Mar 20, 2020, at 7:09 AM, Jon Maloy <[email-masked] 
>> Adding cc [email-masked], since I forgot that in my original 
>> response.
>>
>>
>>>>> address. They do not indicate a location any more than an IP 
>>>>> address does or does not.
>> 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 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.
>>> 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 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 

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 23 Mar 2020 08:38:54 -0700

On Mon, Mar 23, 2020 at 7:32 AM Jon Maloy <[email-masked]> wrote:
> On Mar 19, 2020, at 4:46 PM, Jon Maloy <[email-masked]> wrote:
>
> Type in www.google.com
> 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.
>
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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.
> 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
>     - 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
> 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.)

I don't understand why you think you need to rewrite GSO, there has
been an enormous amount of work to make this usable and extensible. I
suggest you take this up on the netdev list since this is about
implementation. I'd also point out that having a separate protocol
number is hardly a guarantee of acceptance in Linux, we would still be
asking for a justification and why wasn't this done in UDP.

>   Terminating sockets in kernel space comes at a cost.

And what exactly is the performance difference that do your measurements show?

>   to a (compatible) TIPC v3 protocol.

A new socket type does not require a new protocol number. There are
many examples of that. AF_KCM for instance.

>   family, controlled by IETF, like most other protocols.

Well "most other protocols" nowadays are being defined over UDP-- e.g.
QUIC, all the various encapsulation protocols. The reasons for this
are: 1) there's only 256 IP protocol number, but 65536 port numbers,
hence it's obviously going to be easier to get a port number
assignment as opposed to a protocol number. 2) Network devices
notoriously don't handle new protocols well. If a protocol number is
assigned for TIPC and a packet is sent with the number, somewhere and
sometime an intermediate device will drop the packet. 3) UDP is really
cheap wire overhead (eight bytes) and we've put a lot of effort into
optimizing it in implementation at least in Linux (like all the
aforementioned GSO/GRO work).

Tom

---

From: Joseph Touch <[email-masked]>
Date: Mon, 23 Mar 2020 08:41:37 -0700

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.

> 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 alon…

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

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

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

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

Please explain what a node number is...

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.

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 “change on the fly” too?

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

You don’t need an IP protocol number for that….

> UDP (at the link level) has only one service type in this case: “TIPC"

That’s an identifier for your service - you can easily add whatever additional identifiers you want inside that and demux to support dozens or even billions of different sub-services.

> 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, we could use VxLAN or Geneve or whatever. But that always comes to a cost both in performance and maintenance.

I can’t speak for IP protocol numbers, but Internet transport port numbers are not assigned or performance reasons. 

> We want TIPC to be both performant and really simple to use.

You seem to have a lot of competing goals. You should consider the rule of home contractors - fast, cheap, good - pick two. The same applies to nearly all systems design decisions.

>       well-known address for TIPC. At least not for the purpose of 

What you want, IMO, is a field t the front of a UDP TIPC port packet. YOUR service IDs are not the Internet transport port services; they’re components of what the Internet architecture considers “the application layer’ (which is merely whatever runs over UDP/TCP/SCTP/DCCP).

>       will never be lost or disordered.

Raw UDP isn’t what you seek, so do what you want *over* UDP. Nothing stops you and nothing makes your protocol only offer only what UDP has. E.g., see QUIC.

>     address type. There is no way you can get that with UDP.

See my response to #2.

> In that respect this is only an implementation issue, as you say, but it is not a TIPC only one. 

Perhaps, but you’re the only one asking for a new IP protocol number to solve it.

> 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 TI…

So let me get this straight:

- you want an IP protocol number, a limited resource of the entire global Internet
- because you’re concerned that Linux won’t take your code?

I strongly suggest trying that first and if it fails, then perhaps make your own Linux release or patch.

I.e., this is not an Internet protocol problem.

>   Terminating sockets in kernel space comes at a cost.

That’s an implementation issue...

>   to a (compatible) TIPC v3 protocol.

That’s another implementation issue.

>   family, controlled by IETF, like most other protocols.

It already is, but it’s recognized for what it is to the Internet protocol family - a service, not a transport. 

Also, FWIW, making it be its own transport will only ensure it won’t get through most firewalls.

Joe

---

From: Jon Maloy <[email-masked]>
Date: Mon, 23 Mar 2020 13:47:06 -0400

> asking for a justification and why wasn't this done in UDP.
I find it hard to beleive they would refuse an IP number assigned by IETF.
But maybe I am wrong...
> And what exactly is the performance difference that do your measurements show?
It isn't much, admittedly. I made a quick prototype of this a few months 
and observed a difference of 1-4% in comparison to UDP.
Unfortunately I cannot find the log from this now (I changed job 
recently), but I know I sent a mail to Suresh with an example run some 
weeks ago.

> many examples of that. AF_KCM for instance.
Sure. We already have AF_TIPC, and we could define a new AF_TIPCv3 or 
similar.
But I would prefer to avoid that, and have TIPC recognized as in IP 
protocol instead.
> sometime an intermediate device will drop the packet.

I am aware of that risk. In our experience TIPC is almost never set up 
to pass through routers. If you mean this could be a problem even inside 
clusters on the same LAN then that would be more serious problem, of course.

Regards
///jon

> 3) UDP is really

---

From: Jon Maloy <[email-masked]>
Date: Mon, 23 Mar 2020 14:40:37 -0400

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

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

>> When I am talking about location independence I am always talking 
>> about what the socket programmer/user 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.

> Please clarify - do you want to hard-code anything? Or have the user 

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

>> dependent ditto in order to transmit the packets to the right node 
>> and socket. Be it MAC, IPc4, IPv6 or anything else.
>>
> 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 |

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.

> That’s how Internet protocols already work...

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

> 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 theoretically 
have a new IP address, but normally not. Anyway, this is a detail has 
nothing to do with our request.

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

Another design decision which has nothing to do with our application. In 
some cases it is practical and more efficient to use this address type 
when setting up a connections.

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

Service addresses.

>> 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 “change on the fly” too?

???

>>> Anycast gives you location independent addresses at the cost of 
>>> doing discovery “inside the network layer”.
>>
>> discovery/translation has to be blistering fast, and that is also 
>> what we do.
>

I never said that. But you were originally questioning our use of an 
internal lookup service, that I why I mentioned this.
>
>>
>>>
>>> However, even if you have those addresses, you still need to 
>>> identify the service types (which is what we use ports for).
>>
> That’s an identifier for your service - you can easily add whatever 
> additional identifiers you want inside that and demux to support 
> dozens or even billions of different sub-services.

That is exactly what we are doing.

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

>> Yes, we could use VxLAN or Geneve or whatever. But that always comes 
>> to a cost both in performance and maintenance.
>
> I can’t speak for IP protocol numbers, but Internet transport port 
> numbers are not assigned or performance reasons.
>
> You seem to have a lot of competing goals. You should consider the 
> rule of home contractors - fast, cheap, good - pick two. The same 
> applies to nearly all systems design decisions.

True. This has always been a conflict, and still I think we have, after 
a lot of effort, succeeded quite well in combining all three.

>> 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:
>>
> What you want, IMO, is a field t the front of a UDP TIPC port packet. 
> YOUR service IDs are not the Internet transport port services; they’re 
> components of what the Internet architecture considers “the 
> application layer’ (which is merely whatever runs over UDP/TCP/SCTP/DCCP).
Why not UDP/TCP/SCTP/DCCP/TIPC?
> Raw UDP isn’t what you seek, so do what you want *over* UDP. Nothing 
> stops you and nothing makes your protocol only offer only what UDP 
> has. E.g., see QUIC.

Functionally there is no showstopper.  But we want TIPC to be comparable 
or better than TCP even regarding performance.

>>> 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.
>>
So be it.
>> 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.)
>
> It already is, but it’s recognized for what it is to the Internet 
> protocol family - a service, not a transport.
>

See my response to Tom regarding this.

///jon

---

From: Joseph Touch <[email-masked]>
Date: Mon, 23 Mar 2020 12:23:39 -0700

> On Mar 23, 2020, at 11:40 AM, Jon Maloy <[email-masked]> wrote:
> 

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 25 Mar 2020 19:32:23 +0000

Hi all,
 Thanks a lot to everyone who commented, both on list and in private, on this protocol number allocation request. They were extremely valuable. Given the new information that has come up regarding the potential for improvements in the Linux kernel for better UDP performance, I think allocating a protocol number for this is premature. I have discussed this with the submitter and he agrees with my assessment. I will share my conclusion with the IESG and send a recommendation to IANA to close this request without allocating a protocol number.

Thanks
Suresh

On Mar 17, 2020, at 6:34 PM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

1)  Performance

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

Huawei:

Nokia:

Verizon:
Amar Nv <amar.nv@in..verizon.com<mailto:[email-masked]>>
Jayaraj Wilson, <[email-masked]<mailto:[email-masked]>>

WindRiver:

Orange:

Redhat:

ABB:
https://new.abb.com/pl
Mikolaj K. Chojnacki <[email-masked]<mailto:[email-masked]>>
Krzysztof Rybak <[email-masked]<mailto:[email-masked]>>

Ericsson:

I also see numerous other people being active, from small (I believe) companies, universities and private contributors. E.g.,
Innovsys Inc  http://www.innovsys.com/innovsys/
Allied Telesis https://www.alliedtelesis.com/
Telaverge Communications http://www.telaverge.com/
Ivan Serdyuk <[email-masked]<mailto:[email-masked]>> (seems to be responsible for the ZeroMQ port of TIPC)
John Hopkins University / Fast LTA, Munich <[email-masked]<mailto:[email-masked]>>
Just to mention a few...

Thanks
Suresh

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area