What is XTP
What is Linux
What is XTP-Linux
Current Status of XTP-Linux
Web Related Resources
XTP was initially designed as a "transfer" protocol, combining both
the transport and network layers into one single protocol. As of
version 4.0, XTP evolved exclusively into a transport level protocol.
XTP can run over any network protocol or network delivery mechanism like
IP and ATM. The XTP Specification is coordinated and maintained through
the XTP Forum. Implementations of XTP include a commercial product
from Mentat and a public domain object-oriented user-level implementation
from XTP Sandia. For other XTP implementations and related work visit
the XTP Sandia website.
....
The goal of the XTP-Linux implementation is to integrate seamlessly into the existing BSD API and to "hide" the complexity of XTP. Generally speaking applications, and therefore application programmers, are not network experts nor should they be. The application level should not be burdened with transport and network level issues such as flow control, reliable/unreliable transmission, congestion, etc. At most they should know what traffic "pattern" or traffic service the application will generate or require.
At the programming level this translates into creating an XTP socket via socket(AF_INET,XTP_SOCK,saddr,len) and optionally specifying a traffic service via setsockopt(mysock,XTP_TRAFFIC_SERVICE,HTTP_SERVICE,len), and that's it! The XTP code will take it from there and utilize a predetermined configuration of XTP's features. This allows each application to optimize the XTP transport layer for its own particular needs.
Possible traffic services may be:
FT_SERVICE : File Transfer
Service
SRR_SERIVCE : Simple Request Response Service
MRR_SERVICE : Multiple Request Response Service
UI_SERVICE : User Interactive
Service
HTTP_SERVICE : HTTP Service
DNS_SERVICE : DNS Service
Approaches for Implementing XTP-Linux
Initially I planned to pattern XTP after TCP since TCP is well proven and mature. I intended and partially implemented, TCP's algorithisms and mechanisms like slow start, congestion avoidance, etc., into XTP's framework. After several months it became evident that this approach is inappropriate. There are several reasons. Firstly, porting TCP's algorithms into XTP also ports TCP's problems and drawbacks and makes XTP, at best, no better than TCP. Secondly, this approach doesn't allow the full utilization of XTP's capabilites. So we end up using a feature rich, heavier protocol to mimic TCP--end result: lots of unnecessary protocol overhead and so-so performance. The insights from this experience however were worthwhile.
Now, the current approach is the following:
1 - Address Transport Protocol Issues strictly from XTP's point of
view. Thus allowing the use of XTP features. This means viewing
issues like flow control, rate control, data retransmission, etc. in an
IP environment differently from the current framework and therefore requiring
new and/or modified algorithms and mechanisms.
2 - Separate Transport Protocol Issues from TCP-Transport Protocol Issues.
It became apparent that many "transport" level issues are TCP based or
TCP induced problems which do not necessarily apply to other transport
level protocols. Case in point: TCP's Congestion Avoidance Algorithms.
Initially TCP had no slow start and congestion avoidance algorithms.
This proved problematic for TCP. Now, they are part of the TCP specification
and standard implementation. Note however, that while slow start
is a universal transport issue that applies to all IP-based transport protocols
(like UDP, TCP, and XTP), the congestion avoidance is strictly TCP related.
This is because TCP retransmits data automatically after a timeout.
In XTP, this automatic data retransmission does not occur.
XTP-Linux Design
In implementing the XTP Specification to run over IP and in the Linux
kernel, several arbitrary design decisions were made. Most are temporary
and meant to speed the development by reducing XTP's complexity.
Multicast
XTP's multicast features are not implemented in XTP-Linux and probably
will not be for the next forseable future. However, the implementation
can accomodate multicast if someone wishes to implement it later.
32-bit vs 64-bit
XTP-Linux runs only on Intel-based PCs (this is all I have). Since
Intel's Pentium chip is a 32-bit processor and XTP is really a 64-bit protocol,
all of XTP's 64 bit fields are only "half" used. All 64 bit XTP fields
are data structures with two 32-bit unsigned integers. It's not the
most elagant way to manipulate data but it's quick to implement.
Command Option Bits
The following Command Option Bits are not implemented: MULTI,
The following Command Option Bits are currently not implemented but
will be:
Implementation Schedule/Development
XTP-Linux Alpha: ensure correctness of XTP Protocol, algorithms, XTP
mechanisms, and XTP policies.
XTP-Linux Beta: optimize all internal data structures, hashes, etc.
Provide all traffic services to applications.
XTP-Linux 1.0: stabalize the implementation and ensure that it works
both in an Ethernet LAN and Internet.
Academic
This work is part of a Master Thesis project at Concordia
University. For other related XTP work at Concordia University
see ConU-HSPL.
XTP-Linux 2.3.1 patch:
patch for kernel 2.3.1
(click here to download an unzipped and untarred
patch)
How To Install XTP-Linux: instructions on how to compile XTP into the Linux kernel
XTP-Tcpdump patch: patch to enable capture of XTP packets
How To Install XTP-Tcpdump:
instructions on how to install xtp-tcpdump, interpret xtp packet dumps,
and
examples of xtp traces
XTP Test Programs:
several programs that illustrate the BSD interface to xtp, can send/recv
trivial
"user-data" via the XTP or TCP protocols, generate request/response traffic
Linux Kernel Networking Mailing List
Linux Kernel Development Mailing List
...upcoming links
XTP vs TCP Performance
Papers
...and a few others...