Operation Iraqi Freedom witnessed an explosive growth in the use of chat as a means of communication between commands on the ground, in the air, and at sea. Today, the Defense Department is in the midst of streamlining and standardizing texted-based chat protocols across the services. But not all chat systems are alike—what might be good for the Army and the Air Force might not be good for the Navy.
If you had walked into a ship's combat information center during Operation Iraqi Freedom, you would have noticed some things have changed since the first Gulf War. No longer would you have heard the chatter of watch standers as they monitored and replied to queries on voice command circuits. All you might have heard was the click-clack, click-clack of watch standers typing on their keyboards. This new generation of war fighters has eschewed the traditional voice circuits of the old Navy for a new way of doing command and control. This new way is chat, and it has important implications for naval operations of the future.
Text-based chat is not new to the Navy. As early as 1994, the Global Command and Control System-Maritime implemented chat on its UNIX workstations. For a long time, operators used chat to pass administrative or technical help between watch standers. With Operation Enduring Freedom in Afghanistan, the use of chat exploded, with hundreds of concurrent users. Lessons learned during Enduring Freedom were applied to Iraqi Freedom, where chat revolutionized coordination between warfare commanders and their assigned forces. Chat was used for a wide range of missions and functions—anything from exchanging tactical information and providing situational awareness to providing online help forums for troubleshooting.
It took a few years for chat to catch on, but the rapid move to its use as a tool for command and control has produced many unresolved questions. The acquisition and legal communities, accustomed to a slower pace of system deployment, have not adapted to the new fast-paced operational changes and legal policies required to govern the use of such a technology. In the case of chat, this has created a condition where a new form of mission planning, situational awareness, and command and control is governed by occasionally conflicting or contrary policies.
Not All Chat Tools Are the Same
With any innovation or change to the way of doing business come challenges, both technical and cultural. Not all chat tools are the same and no one standard or name brand will meet all the needs of the Navy. The most popular and widely used protocol for chat in the Navy is Internet Relay Chat (IRC). IRC is an established Internet protocol that meets the fleet's functional and technical requirements. The original client installed with the Global Command and Control System in 1994 was IRC-compliant and was used exclusively by war fighters experienced with that system. Widespread use of IRC, however, was not realized until Microsoft's MS Chat client was installed as part of the government-off-the-shelf software load on Information Technology 21 (IT-21) machines. There are other proprietary chat applications available, but the fleet uses IRC-based clients as the primary means of maintaining tactical command and control and situational awareness.
The use of proprietary chat tools has both advantages and disadvantages. A proprietary product might satisfy particular operational requirements, but it may not be appropriate for fleetwide use. For example, Sametime, a chat tool that comes with the Lotus Domino server, has the ability to authenticate each member of a chat room. This is important for those times when you need to be certain who is collaborating with you (such as when communicating with coalition partners or during "fireside chats" for an admiral and his warfare commanders, for instance). IRC-based chat rooms do not offer this capability. On the other hand, some proprietary tools allow only one chat room to be open at a time. This is not practical for a watch station that needs to see multiple concurrent rooms.
The issue of cost also is a driving factor. Because MS Chat is included with IT-21 software loads, it is free to the user. Other proprietary tools generally require license fees on a per-user basis. This cost often can be in the millions of dollars. Another common drawback of proprietary tools is that they often do not conform to Internet protocols and cannot interact with other operating systems. This situation is the source of the all-too-common "stovepipe," where one system cannot talk to another.
Silence on the Net
In a bold attempt to address the stovepipe issue, the Defense Information Systems Agency is leading the charge to implement the Defense Collaborative Tool Suite (DCTS) across all the services. As the name implies, this is a set of collaborative tools approved for use by the Department of Defense. DCTS currently includes a set of products including MS Netmeeting, Sun Forum, Envoke Instant Messaging, Digital Dashboard, and CUSeeme. Originally, the vision for DCTS was that it would be a standards-based system allowing the services to choose which product fit their needs for collaboration. As long as the product met certain requirements, it would be considered part of DCTS. This is a noble goal, but it has not yet been realized. Many of the suite's standards are product-based instead of standards-based. This is clear when looking at text-based chat. With DCTS, users have two choices, MS Netmeeting or Envoke. Both these products use proprietary methods for text-based chat, and neither is an industry-standard protocol. At a recent Joint Staff Collaboration Interoperability Working Group meeting, the issue of standards-based text chat was addressed. The Navy presented its case that the IRC protocol should be used as the standard for DCTS text-based chat. This was not met with cheers; several high-placed DCTS representatives were unwilling to accept that their endorsement of a proprietary product as the standard for the suite was wrong.
The issue of having IRC as a DCTS standard is critical. The intention is to limit all collaboration within the Department of Defense to the DCTS tools suite. A department memorandum entitled "DoD Collaboration Interoperability Standards" asserts that collaborative applications that have not been approved by the Joint Interoperability Testing Command by 1 October 2003 will not be authorized for use on Defense Department networks. This means that the Defense Information Systems Agency will be enforcing the DCTS standard and blocking the ports used for IRC, effectively eliminating IRC-based chat as a means of command and control from Navy ships. As a result, the Navy Network Warfare Command has taken a great interest in this situation and is attempting to provide DCTS with the Navy's requirements for IRC usage.
The Needs of the Navy
Why doesn't the Navy just use the DCTS chat tool? The answer comes from the network environment in which ships at sea operate. DCTS meets the needs of shore-based users with large, stable bandwidth capabilities. The needs of the mobile, tactical user, such as the fleet, are not represented in the current DCTS requirements grid. Many of the applications used in the suite have bandwidth requirements that exceed what is available to the tactical user at sea. For example, many ships in the Navy rely on 64-kilobit-per-second (Kbps) connections to shore. The telephone system is allocated 32 Kbps. The remaining 32 Kbps is distributed among three enclaves, allowing for roughly 10 Kbps per enclave. Generally, collaboration is done within these enclaves on 2-4 Kbps to satisfy the needs of all shipboard users. These severe data throughput constraints have led to the use of "bandwidth-friendly" software applications such as IRC. To illustrate the effects of this, Figure 1 shows the average bits per second used by three chat applications. Sametime and Netmeeting use upward of 2,000 bps, but IRC chat uses only 23 bps. The second graphic turns this around to show how many concurrent users would be allowed given the entire 10 Kbps bandwidth. Sametime and Netmeeting can provide 5 concurrent users; IRC can provide an astounding 435.
Overlooking bandwidth issues, there are several other reasons why IRC meets most of the requirements for Navy text-based chat. A primary one is that IRC supports multiple operating systems. Whether a war fighter is using MS Chat on a Windows NT machine, XIRCON on a UNIX-based Global Command and Control System machine, or even Ircle on Macintosh-based systems, text-based chat is not impeded. This allows a watch stander to chat at his chosen workstation. In the past, each watch station was required to monitor multiple radio circuits. While watch standers still monitor radio circuits, they also monitor several chat rooms, typically three or more. Most commercial products do not have this requirement, as meetings generally are held one at a time. IRC also allows for the display and monitoring of multiple chat rooms simultaneously. These rooms are "standing," meaning they always are up and running even if no user is logged in, and "public," meaning that users can come and go without being invited to join the chat. (The term public should not be construed to mean unclassified; operational and tactical chat is carried out on SIPRNet [Secret Internet Protocol Router Network].) Both these requirements are critical to maintaining the command-and-control character of chat.
IRC as a protocol does not meet all the requirements for the Navy. The most widely used IRC client, MS Chat, does not meet all the text-based chat requirements either. It does not timestamp (the ability to know when comments are made), log conversations (once chat is closed or a connection is lost, the text will be lost), or authenticate who is who in the room, among other things. Some units serving in Iraqi Freedom moved to the mIRC client to meet some of the logging and timestamp requirements. However, mIRC is not IT-21-approved software, and commands used the client at their own risk. While IRC is not a panacea, it has been given the stamp of approval from war fighters by its continual use in providing value-added service to watch standers and commanders alike.
At the outset of planning for Iraqi Freedom, Central Command was committed to using DCTS. During several exercises prior to the operation, the command's C4 Systems Directorate (J6) used DCTS in Saudi Arabia. However, DCTS did not allow watch standers to monitor multiple chat rooms at the same time. After several weeks of struggling with DCTS reliability issues, the staff decided to switch to InfoWorkSpace, a proprietary collaboration tool. This software was purchased at $350 a user, but high latency caused major problems. Finally, in a move to support Central Command's multiple chat room and stable network environment requirements, J6 identified Central Command's Navy IRC server as the text-chat collaboration supporter. Usage of IRC peaked at more than 3,600 users on four servers and one backup. IRC was popular because of its ease of use and little or no need for server administration. During Iraqi Freedom, the servers had close to 3,000 concurrent users.
Meeting the Needs of Coalition Partners
While IRC provides many in the Navy and other services with a great tactical advantage, our coalition partners cannot share the same chat rooms. National security policy does not permit coalition partners to operate on our classified networks such as SIPRNet. For this reason, the Navy has developed a separate network where coalition partners (the United Kingdom, Canada, and Australia, for example) have separate systems that permit use of chat without having access to our network. The workstations for these systems are installed near our workstations and permit watch standers to communicate with coalition units. Currently, the most common chat product used for coalition operations is Sametime. This is an example of a proprietary tool that plays an essential role in missions, such as maritime interdiction operations, where authentication is a requirement when operating with multinational forces. More and more of the tactical planning and execution for coalition forces takes place on the Combined Enterprise Regional Information Exchange System.
The Future of Chat
Chat has had a huge impact on the tactical war fighter. Everything from mission planning to execution often is taking place today without a single radio transmission. Debriefs from Operation Iraqi Freedom confirm this. The technology that permits this to take place is growing, but the policies that support the use of this capability have not kept pace. It is not unusual to find the official policy in a battle group or joint task force for use of chat to include comments such as, "Chat will be used for administrative decisions only; all orders for execution will be confirmed via voice circuits." The problem is, this policy rarely is followed, and it is likely we will see some chat-approved operational or training incident that leads to loss of life or other major mishap. The subsequent investigation will find fault with the manner in which the order was carried out and people will be held accountable. The Navy has an unfortunate history of poorly enforced policies leading to tragic events, and it often has required legal proceedings to bring policies in line with reality. The problem is not with the use of chat, but with the fact that operators are working in a gray area of legal standing if and when something goes wrong. Failure to address this issue ahead of time will cost the Navy much time and effort.
The success of chat (and especially IRC) during Operation Iraqi Freedom has proved it to be an excellent tool to support various areas of mission planning, execution, and command and control. Proprietary chat programs also have a place in the war fighter's toolbox. Every battle group commander has lauded the additional capabilities chat provides to war fighters. Without intervention from Navy type commanders, however, the advantages offered by IRC could be silenced by the introduction of DCTS to the fleet. The Navy, working through its Network Warfare Command, must ensure that DCTS meets all the requirements of IRC before such a system will prove useful to the fleet. Until recently, the Navy has not had adequate representation on the Joint Staff Collaboration Interoperability Working Group or DCTS. With the introduction of Network Warfare Command, the Navy now has an advocate for its requirements in the joint collaboration arena. Commanders and users must state specifically their text-based chat requirements to their superiors to ensure IRC is not silenced and that successor text-based chat protocols meet all the Navy's needs.
Commander Jara is a naval aviator whose tours of duty include flying assignments in SH-2F and SH-60B LAMPS helicopter squadrons. He currently is assigned to Commander, Third Fleet, as Director, Network Centric Innovation Center. Lieutenant Commander Lisowski is an information professional and is currently assigned to Commander, Third Fleet, as Deputy Director, Network Centric Innovation Center.