-
Notifications
You must be signed in to change notification settings - Fork 42
FAQ
XIA is a (meta) network architecture whose the central goal is an evolvable and secure Internet architecture. By evolvable, XIA means having an explicit, well defined, incremental path to introduce changes to its network protocol, which is called the eXpressive Internet Protocol (XIP). These changes are introduced and removed in units; each of these units is a principal. By secure, XIA means providing the capabilities to deliver security guarantees to applications. XIA's main vehicles to carry evolution and enable security guarantees are, its expressive network addresses and the intrinsic security found at its network identifiers, respectively. A short presentation of XIA is available on XIA 101 page.
What do you really mean by enabling a crowdsourced future Internet? Does Linux XIA only target network researchers?
The efforts to explore what the future Internet will look like is mostly restricted to the research community nowadays. Thus, one may perceive Linux XIA as just helping the research community, but the truth is that if a broad community of kernel developers, researchers, application developers, users, entrepreneurs, and who else is interested get together on a single platform to explore new network architectures, implement code to address applications' needs, report bugs and suggestions, and make a business over this exploratory network, we believe that we all will make progress faster, and current siloed knowledge will circulate openly.
It is worth pointing that while some members of the "crowd" will be very informed, none of them may know what the future Internet will look like. Still, they, as a group, may figure this out thanks to the principal interoperability built into Linux XIA. In fact, "magic" combinations of principals may come from people that did not conceived or implemented the combined principals.
This community would be an alternative to the slow, open cycle: the researcher community comes up with an idea that get everyone excited, a few more years are spent drafting standards, and even more years afterwards to persuade everyone else that implementing the new standards is worth their time. Applications developers, users, and entrepreneurs will only join the effort way later, if at all.
Finally, if all that Linux XIA ever accomplishes is to bring the community together to explore the future Internet that we all want, it would easily be our most important contribution.
A group of researchers, not linked to the XIA project, has designed a service-centric architecture called Serval that, among other use cases, enables one to move the partitioning knowledge of memcached from the client applications to the network. See section 6.2 of their paper for details.
The example above shows how the network can leverage knowledge that once was only available in the applications. Moreover, it points out that application developers should be able to explore network architectures that best fit their applications rather than being always forced to fit their applications to IP.
Like the Serval example, one could conceive moving Ceph's CRUSH into the network. This hasn't been done, so we don't know if this would improve Ceph's performance, or be that useful at all. But it could well make CRUSH useful for other applications.
As in the first days of TCP/IP, we barely have any application available. They'll only come when Linux XIA becomes mature. Having said that, we have some members looking on ways to port TCP/IP applications, but it's early to describe their work.
If a bus hits we all and the community around Linux XIA is not strong enough to survive the hit then, we expect and will work to keep it true as much as possible that dropping Linux XIA of the Linux kernel will require a little or no more than removing folder net/xia and headers files include/net/xia_*.h from the kernel's tree.
The Home page of this wiki provides a thorough overview of the project and how to get involved. We suggest starting there.
The format of TCP/IP packets is not a problem per se, but the fact that every packet must have the IP header. If you have reproduced or studied the zFilter principal experiment, you will notice that one can construct addresses with no XIDs of principals analog to IP. The point here is that evolution is not only about adding new features, but also being able to deprecate features as well.
You state in the previous answer that the evolution problem of TCP/IP is that the IP header is always present in TCP/IP packets, but isn't it also the case for XIP header in XIA packets?
The key difference between IP and XIP is that XIP does not define any class of identifiers. The XIA principals define the classes of identifiers that can go into an XIP address, whereas IP only defines IP addresses. In order to highlight this difference, consider that someone tells you that a router is about to route an IP packet. Even if you are not told anything else, you can still have a good idea of how the router will proceed. If, instead, you were told that a router is about to route an XIP packet, you would need to know the XIP address of that packet to know what the router could do; or another equivalent information such as the set of principals the router supports.
The difference cited above as well as its side effects are deeper than it may look like at first. Further reflection on these details and their interrelations led us to the definitions of network factors, network architectures, and meta network architectures. See Section 1.1 of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture for those definitions, examples, and the reasoning behind them.
There are two complementary approaches to answer this question: going through a pointwise comparison of the designs, and observing what the designs ultimately accomplish from a bird's-eye view. The former approach only requires an understanding of the designs, whereas the latter also requires a higher level of abstraction to see the forest for the trees.
A salient difference between XIA and FreeBSD's netgraph, or XIA and Click Modular Router, is when the connections among their components is established. The components of XIA are principals, and principals are arranged together in each network address. That is, each network packet can require a different arrangement of principals. The components of netgraph are nodes and they are arranged in order to process streams of packets; typically done during the initialization of a system. Click works similarly to netgraph, but calls its components elements. One can find other differences exploring other features of the designs.
In order to reach a bird's-eye view of the designs, we evoke the definitions present in Section 1.1 of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture as well as the taxonomy of meta architectures present in Section 1.4 of the same PhD thesis. From this vantage point, netgraph and Click are slicing meta architectures, so once multiple network architectures are instantiated in them, applications are solely responsible for all the necessary work to leverage the implemented architectures. On the other hand, XIA, as explained in Section 1.4, is an interoperable meta architecture.
No, Linux XIA is not about userspace networking. Principals are implemented as kernel modules.
While network evolution is a driving force throughout our work, one thing that became clearer as we made progress is the possibility of interoperating the designs integrated in XIA. This capability is so unique that we are not aware of another meta architecture that supports this feature. Section 1.4 of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture adds to this statement, and page An exemplifying demo highlights interoperability in action.
Linux XIA's codebase is very young and we haven't had the chance to work on the performance front as much as we want. Nevertheless, Chapter 5 of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture shows that the current performance is good enough for experimentation. Once new principals and applications are developed, we expect that usage patterns will become clear, and we' will be able to fit faster data structures.
Van Jacobson presented netchannels as a way to reorganize network code to improve performance. Thus, one could pursue an implementation of TCP/IP or XIA using netchannels. In other words, netchannel is orthogonal to Linux XIA.
It is important to keep the DST table up-to-date amid updates to the routing table. Otherwise, stale cache entries may be used and incorrect routing behavior will result. Naive solutions to this problem include flushing the entire DST table every time the routing table is updated, or walking down the DST table to find which entries need to be updated. Both of these solutions are very expensive.
Instead, Linux XIA uses a dependency forest to anchor DST table entries on routing table entries, so that when a routing table entry is updated the cache remains valid. The low-level details of this data structure are outside the scope of this FAQ, but more information can be found in section 3.3 of the PhD thesis Linux XIA: An Interoperable Meta Network Architecture.
These wiki provides information about the high-level concepts of Linux XIA. For more information about the low-level details of the implementation, such as descriptions of functions, see the XIA header files in the kernel source tree, which all match the regular expression include/net/xia_*.h.
The string format used to print out DAGs is documented at Human readable XIP address format. From that page, one reads the following: The prefix "!" indicates that the address is invalid. Any index greater than 35 (i.e. 'z') is represented by '+', and an empty edge by '*'.
The function that tests if an address is valid or not checks many things as one can verify in the source code, for example, that the DAG is a single component, that there is no edge after an empty edge, the DAG is in topological order, etc.
This function assumes that addresses come from userland, so they cannot have chosen edges, and that is the reason most destination addresses in packets on a wire will be invalid. One may want to have a special version of this function for Wireshark, but nobody has worked on it yet.
Once an address is deemed invalid, all edges are printed out, including empty edges, in order to help with debugging cases like "-2**9", that is, an edge after an empty edge.
This question can arise when considering addresses like the following:
u4id-0a024702c3d70000000000000000000000000000-21: zf-0110000000000000000000000000000000000000-2: xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b-210
It appears as if the edges coming out of the last node of the DAG (the XDP) are directed toward the previous nodes, such as 0 (the U4ID), 1 (the zF), or 2 (the XDP itself). However, the last node of a DAG is always a sink, so the last node does not have any outgoing edges. The edges of the last node represent the edges of the entry node.
This example can be found on the page An exemplifying demo, which includes an image of the DAG that may help you to understand what the textual representation above is trying to show. More information about the address grammar can be found on the page Human readable XIP address format.
In some cases, the source address DAG is the inverse of the destination address DAG, but this is not necessarily true. To new users of XIA, it is perhaps tempting to think of the DAGs as path specifications through the network, so it would only be natural to follow the reverse path back to the source. However, the DAG does not specify a path. The DAG is used to express an intent to the network, and typically the destination intent cannot be expressed in the same way as the source intent.
Consider this simple example, a client wants to send a request to a server, and uses the destination DAG <math>\bullet\rightarrow AD_1\rightarrow HID_1\rightarrow XDP_1</math> to do so. <math>AD_1</math> identifies the server's administrative domain, <math>HID_1</math> identifies the server, and <math>XDP_1</math> identifies a socket listening on the server. When the server receives the request and goes to respond to it, notice that it would not make sense to send data back to the client through the reverse DAG <math>\bullet\rightarrow XDP_1\rightarrow HID_1\rightarrow AD_1</math>, since none of this information is related to the client. Of course, the client could be located in the same administrative domain <math>AD_1</math> and be on the same machine <math>HID_1</math> that the server is, but even in this case, server and client could not share the same XDP XID, and the address would still not be in reverse order: <math>\bullet\rightarrow AD_1\rightarrow HID_1\rightarrow XDP_2</math>.
The original reasoning behind having such a large identifier space was two-fold. First, having a large address space would reduce the possibility of address space depletion. Since XIA must be able to address very large sets of entities, such as identifying globally-unique pieces of content, the address space must be quite large. Second, XIDs typically are cryptographically secure identifiers, and a longer identifier is more secure than a shorter identifier.
It has also been discovered that XIDs can serve as data structures. For example, the zFilter principal uses the XID field as a Bloom filter. It has proven beneficial to have ample space to store information for these kinds of principals.
Currently, XIP addresses must be manually generated by the user using the Human readable XIP address format. There is a project on our Roadmap that will create functionality that simplifies the construction of DAGs, but that project has not yet been claimed.
The format of the XIP header is presented in Section 3.3.1 of the paper XIA: Efficient support for evolvable internetworking.
The previous answer points to where one finds documentation of the XIP header. For details on how to encode DAG addresses, one can study function xia_pton() that converts a string according to Human readable XIP address format to the DAG format used in the header. Function xia_pton() is available here.
All grants that have generously supported the development of Linux XIA are listed on our Funding page.