Being Efficient with Bandwidth
n three fundamental capabilities: assured command and control (C2), battlespace awareness, and integrated fires. None of these are possible without effective communications links. Networks—and more specifically, the information flowing through them—are now a center of gravity for the Fleet.1 Maritime tactics and operational plans rely on levels of synchronization only possible through high-bandwidth communications. Satellite communication (SATCOM) is the Fleet’s primary path for high-bandwidth C2. However, afloat units may be denied access due to equipment failure, technical problems, weather phenomenon, or enemy actions, forcing reliance on lower-bandwidth alternatives.For afloat units, bandwidth has become a critical but painfully finite resource that must be conserved. SATCOM carries data from a large number of disparate systems often referred to as “stovepipes.” These systems vary in function from tactical to administrative, and the data formats for each application vary greatly. The result is communications only occurring vertically within a system, but not across the breadth of different systems. When many such stovepipes contend for access to the same ship-to-shore transport path, even the largest SATCOM channels can become congested. Future assured C2 requires interoperability between stovepipes and better prioritization of network traffic.
Before identifying the solution, we must understand the factors that impose constraints on the transmission path: bandwidth, latency, and throughput.
Bandwidth: Not The Same As “Throughput”
Bandwidth is literally the “width” of the frequency band used to carry a data signal. It is more often described as the transmission capacity of the communications medium, measured in terms of bits per second.2 To increase the capacity of an electromagnetic communications channel, modulation technologies and methods would need improvement, or an additional antenna could be installed. Both approaches illustrate significant engineering and financial constraints associated with increasing bandwidth, particularly in the shipboard environment.
SATCOM connections are often depicted as lightning bolts connecting deployed units with relay systems. These lightning bolts convey the impression that data are instantaneously transmitted from unit A to unit B through an optimally placed satellite node. Unfortunately SATCOM transmissions are far from instantaneous: They incur significant delays in comparison to terrestrial communications paths. The combined delay is known as latency.
Latency is an accumulated series of delays that can occur in each step of the communications path between the sender and receiver. Such delays occur as part of propagation delay during signal transmission, network processing and interface delays, varying methods for buffering and queuing, and cumulative router and switch delays.3 Latency from the perspective of network traffic is the delay from the time of the start of packet transmission at the sender host to the time of the end of packet reception at the receiver host.
Unfortunately latency has significant effects on throughput. This is due in part to the degradation experienced by the primary networking protocol TCP when operating over a high latency network.4 SATCOM channels routinely operate with latency between 500 to 800 milliseconds. Response “waiting time” is a particular problem for communications protocols like TCP that includes frequent acknowledgement among participants. Increased latency ultimately results in decreased throughput.
Throughput is the rate at which new data—actual information—is transferred through a system. Like bandwidth, it is measured in bits per second and can be considered the actual effective capacity of a channel or the “rate of successful message delivery” being achieved. A common misconception is that bandwidth and throughput are synonymous. Numerous additional constraints can limit the amount of data that can be transferred between two points, such as the overhead of communication protocols and latency delays, which may keep a channel idle. Thus bandwidth indicates the maximum possible data-transfer capacity, while throughput is what capacity actually occurs. Throughput is often significantly lower than the communications channel’s bandwidth capacity. Ultimately round-trip-time dominates performance more than bandwidth does.5
Common Practice: SATCOM
For Navy ships at sea, the only access to high bandwidth is through SATCOM systems. In our increasingly connected world, the value placed on access to high bandwidth continues to rise. As bandwidth increases, the amount of data that can be transferred between two points also increases. As bandwidth is increased, additional capacity is quickly consumed by ever-more sophisticated sensors, unmanned vehicles, and other network-centric dependencies.6 Most high-bandwidth paths utilize the super- and extremely-high frequency (SHF/EHF) spectrum for SATCOM communications. Though data and voice circuits exist in other portions of the spectrum, SHF and EHF carry the brunt of Navy traffic, with SHF (C/Ku/X band) ultimately providing the biggest “pipe” for data flows.
In the past, the solution to demand for increasing data transfer was to increase bandwidth, and thereby capacity. As the DoD throttles back spending, many areas must become more efficient in order to accomplish defense missions. Similar approaches for efficiency must be applied with respect to communication systems. The amount of information to be shared is not expected to decrease. Because constraints on SATCOM bandwidth make even marginal increases a costly venture, the Navy must explore new tactics. Perhaps solutions lie not in the channel itself, but in the format of data transmitted. What if we can convey the same information using just a fraction of the original zeros and ones, while at the same time connecting stovepipes through data interoperability?
XML: The Language of Interoperability
Interoperability is essential to the key information dominance capabilities. Shipboard computers must talk to each other, computers from other service branches, and computers from partner nations. To facilitate interoperability, an open-standards approach is critical. The Department of the Navy’s chief information officer has designated the extensible markup language (XML) as the data-definition language of choice for information standardization, and for good reason: It is the de facto standard format for systems talking across the web.7 By design, XML adds structure to data, which in turn facilitates validation of correctness and system interoperability. XML is the lingua franca of the world’s computers.
Though XML is a path to both technical and semantic interoperability, it has an Achilles heel: It was never intended to be compact.8 In terrestrial networks with low latency contributing to massive throughput, this is usually unimportant. For the Navy, however, large messages mean slower connections and less information to forward-deployed units relying on SATCOM. Transmitting large messages also draws more power, so XML isn’t ideal for mobile or unmanned devices running on batteries. Viewed in this light, XML is less attractive, but it doesn’t have to be that way. Recent advances in data compression are providing new design options.
Shrinking Data, Broadening the Web
In 2004, the World Wide Web Consortium began to address this issue, and in 2014 released the Efficient XML Interchange (EXI) Format Recommendation.9 EXI is an alternate encoding of XML data that leverages the inherent structure of XML to tightly compress it. Since it is designed specifically for XML, the results are superior to generic compression methods. In some cases, EXI compression results in files that are less than 10 percent the size of the original XML file.10 Perhaps even more surprising is that EXI decompresses faster, using fewer computations and therefore drawing less power than plain text-based ZIP and GZIP compression.
Given that XML enables interoperability, and that EXI shrinks it, Fleet communications architects and program managers should be interested.11 Systems could potentially convert and transmit information in XML format, and with EXI they could send more information in less time. By incorporating EXI, web-based architectures such as CANES and C4I systems using service-oriented architectures may be viable over constrained SATCOM links. Unmanned systems and remote sensors might use EXI to conserve batteries on extended missions. A single file cut to a tenth of its original size is useful in itself, but the aggregate impact over thousands of nodes in a cloud, each sending thousands of files, could be immense.
Other impacts pertain as well. For example, encryption is usually considered independent of compression. However, by randomizing a bit stream, encryption scrambles the structure necessary for effective compression. That means encrypted streams cannot be compressed. Compression must occur before encryption when transmitting, and decompression after decryption on the receiving end. This principle is so important that the order should be checked for all Navy communications channels.
Since message size is just one of many factors in network throughput, EXI is not a silver-bullet for Navy bandwidth woes, but it certainly can’t hurt. It is not mutually exclusive of other attempts to address the issue. Navy communications designers need not choose between a new SATCOM constellation and EXI, or between commercial network accelerators and EXI; they can have both. Considering that EXI is open standard, supports interoperability, and shrinks data the Navy is already sending over its networks, there is little to lose and much to gain. The Navy can be more efficient with a precious afloat resource: bandwidth.
1. Chief of Naval Operations Information Dominance, Navy Strategy for Achieving Information Dominance, 2013-2017, 1 January 2013, www.dtic.mil/docs/citations/ADA571217.
2. Anu A. Gokhale, Introduction to Telecommunications (Cengage Learning, 2004), http://books.google.com/books?id=QowmxWAOEtYC&pgis=1, 455.
3. Rony Kay, “Pragmatic Network Latency Engineering Fundamental Facts and Analysis” (cPacket Networks Inc, 2009), http://cpacket.com/wp-content/files_mf/introductiontonetworklatencyengineering.pdf.
4. Thomas R. Henderson, Randy H. Katz, TCP Performance over Satellite Channels (Berkeley, CA: University of California at Berkeley, 1999), www.eecs.berkeley.edu/Pubs/TechRpts/1999/CSD-99-1083.pdf.
5. Mike Belshe, “More Bandwidth Doesn’t Matter (Much),” 2010, www.chromium.org/spdy.
6. Isaac R. Porche, Bradley Wilson, Erin-Elizabeth Johnson, Shane Tierney, Evan Saltzman, RAND Corporation, “Data Flood: Helping the Navy Address the Rising Tide of Sensor Information,” 2014, www.rand.org/pubs/research_reports/RR315.html.
7. Department of the Navy Chief Information Officer, “DON policy on the use of extensible markup language (XML),” 2012, http://xml.coverpages.org/DON-XMLPolicy200212.pdf.
8. Mike Cokus, Santiago Pericas-Geertsen, “XML binary characterization properties,” 2005, www.w3.org/TR/xbc-properties/#xml-design-goals.
9. Takuki Kamiya, Efficient XML Interchange Working Group, 2014, www.w3.org/XML/EXI.
10. Sheldon Snyder, Don McGregor, Don Brutzman, “Efficient XML interchange: Compact, efficient, and standards-based XML for modeling and simulation,” 2009, http://calhoun.nps.edu/public/handle/10945/5422.
11. Jeffrey Williams, “Document-based message-centric security using XML authentication and encryption for coalition and interagency operations,” master’s thesis, Naval Postgraduate School, 2009, http://calhoun.nps.edu/public/handle/10945/4610.
Captain Miller is a retired information professional officer serving as a research associate at NPS. He is the former commanding officer of the Navy Center for Tactical Systems Interoperability.
Dr. Brutzman is a retired submarine officer working in the information sciences department, Undersea Warfare Academic Group, and MOVES Institute at NPS. Additional insights by Dr. Dan Boger, Captain Louis Unrein (U.S. Navy) and other reviewers are gratefully acknowledged.
A Time to Innovate, A Time to Steal
At a meeting of the Disruptive Thinkers group in the summer of 2013, attendees were asked to name the most innovative military leader they knew. I have to admit, I was stumped. Others produced tales of front-line leaders developing creative solutions to near-insurmountable obstacles. The only answer I could immediately conjure was Lieutenant Commander Thomas Dodge, Kelsey Grammar’s submarine commander in the movie Down Periscope, who, among other exploits, disguised his World War II-era diesel electric boat as a fishing vessel—complete with drunken strains of “Louie, Louie”—to avoid detection by a Navy patrol.
My inability to name a real-life Lieutenant Commander Dodge wasn’t because I have known no great leaders. In my naval service I have encountered outstanding leaders—male and female, officer and enlisted—but no particularly innovative ones. This apparent disconnect is all the more perplexing given the recent emphasis on developing a culture of innovation in the Navy. The truth is a good leader does not need to be innovative, and an innovative leader is not necessarily a good one.
It is important to define “innovative” as a leadership trait. An innovative leader develops new methods and solutions to tasks and problems. This is an admirable characteristic, and one the Navy needs within its ranks. However, the Navy is best served when the burden of innovation does not fall to the leaders of its front-line operational units. Quite simply, the time and energy they spend developing original solutions to problems would be wasted if an effective answer already exists. Instead, the Navy should encourage these leaders to “steal” what works best until something better—and proven—comes along.
Good Leaders Innovate; Great Leaders Steal
A leader adept at stealing requires an awareness of existing solutions, receptiveness to others’ ideas, and the humility to adopt methods that are not one’s own. The aim is to reduce duplication and extra work—not only for leaders, but also for those they lead. From shipboard instructions to training-team scenarios, great leaders know how to copy what works and are willing to do so, liberally dispensing credit as they go. They also require keen judgment: to determine the methods worth taking, to identify those most applicable to the situation at hand, and to know when to ditch the stolen goods for something better.
At the same time, no two situations, and therefore no two problem sets, are identical. Nor can any method or solution, such as a ship’s force protection plan, hope to cover every conceivable scenario. To deal with a steady stream of new situations, it would appear at first glance that good leaders must be innovative. For example, a unique pier set-up might prevent the deployment of jersey barriers as required by the force protection plan. When such a seemingly original situation is broken down into its fundamental parts, however, few truly new elements emerge. While the force protection plan as written might not incorporate the pier set-up, adhering to the force protection principle of distance suggests implementing something else to separate the ship from potential threats.
Here again a great front-line leader acts as a thief, aware of others’ “jewels”—existing solutions and approaches to this more generic problem of creating separation—and intelligent enough to know which to grab in the circumstances. Granted, an innovative operational leader might come up with an interesting approach to the composite issue, and the trait would indeed be useful for truly new and unanticipated needs. In the great majority of situations, however, the operational leader is better off copying another’s work because it is already known to be effective, or applying proven principles to address the component parts of a problem.
In the midst of the response to November 2013’s super typhoon Haiyan/Yolanda, the U.S. Navy faced the challenge of quickly and simultaneously filling multiple water containers. Hull maintenance technicians (HTs) on board the USS George Washington (CVN-73) used their ingenuity to devise a system they called “the Octopus” by welding together water distribution piping that could fill up to eight containers at once with fresh water. Upon completion it was flown to a shore location to aid in assistance efforts.1
This story was heralded as a model of Fleet innovation on the fly, yet observers noted that a similar need and set of solutions arose during previous U.S. Navy disaster-response efforts. For example, during the relief operations after the January 2010 earthquake in Haiti, HTs on board the USS Carl Vinson (CVN-70) built two 12-faucet fresh-water dispensers.2 While the similarities should not detract from the innovativeness of the George Washington’s crew, they were denied an opportunity to consider the experience of their counterparts and had to spend time “re-inventing the wheel” with the real possibility of not meeting their objective. The anecdote also illustrates what Rear Admiral Scott Jerabeck meant when remarking that the Navy has lessons logged, not lessons learned, and the failures of its current infrastructure for capturing, validating, and disseminating those lessons.3
A History of Thievery
The Navy must do two things to support thievery in the Fleet. First, it needs to inculcate a spirit of humility and receptiveness among operational leaders toward ideas that are not their own. Training should focus on breaking problems into their component parts and on the methods for finding and selecting something worth stealing, applying it, and determining when to ditch it.
Second, the Navy must ensure that organizational infrastructure supports this type of leader. The Navy needs a centralized, well-publicized den of thieves, a place where those in search of answers can find and copy from those who have already done the work of testing and validating an approach. A leader can’t steal existing solutions they don’t have access to or can’t locate across fragmented individual databases.
The Navy has long supported thievery, from the study of naval history and broad military principles to attempts to capture lessons learned on the operation of specific weapon systems. Deckplate gouge is a time-honored example of informal attempts to pass on solutions, but technology offers the possibility of leveraging informal networks to do more. The Navy has begun pursuing internet crowd-sourcing efforts such as Massively Multiplayer Online Wargames Leveraging the Internet and the CNO’s Reducing Administrative Distractions website.4 In fact, many ideas on the latter site centered on the desire to make this form of information swapping and locating easier.
Whatever form this infrastructure takes, it needs more than just thieves. For front-line leaders to focus on applying proven approaches developed elsewhere, there has to be an “elsewhere” that focuses on developing the approaches. While this has traditionally taken the form of experts and academics in development groups, schools, and research facilities, it is increasingly the province of volunteers on the internet. Innovators are also needed to mitigate predictability—one of the dangers of using only the best approaches, especially as applied to tactics against an enemy—by generating multiple validated approaches and keeping new ones on file in case those in use lose their utility.
Conversely, innovators need feedback. This means that operational leaders at times need to validate innovation or provide a point of departure for innovators to refine. Communication is crucial in this partnership, including an awareness of the range of resources—or lack thereof— frontline leaders have at their disposal.
Having developed, tested, or validated an approach—whether original or stolen—the best leaders freely encourage dissemination of their findings. Richard Gallagher, author of a book on workplace leadership, believes that people gain more leadership credentials by encouraging others to spread their ideas than by squabbling over credit. “When you openly encourage people to steal your ideas and get in the habit of stealing from others and crediting them, wonderful things happen to your career that you could never imagine when you try to be the lone ranger with a great idea,” Gallagher says.5 Here the Navy’s role is to provide efficient infrastructure for that dissemination so that it’s easy to find and see.
The Navy is trying to sustain its commitments with less resources, a situation that typically equates to less time for front-line leaders. They have less time to practice and perfect their mission areas, less time to meet their operational requirements, and less time to lead. To succeed, they must steep themselves in the art of stealing to obtain tested means to achieve their objectives. They need to know that they don’t have to create everything from scratch themselves, and the Navy must support their efforts with training and infrastructure.
Good leaders and innovators, while distinct, are interdependent. Good leaders need innovators to develop the methods, the tactics, and even the administrative forms they steal. Yet while feedback and innovation from the Fleet are always welcome, the Navy should not emphasize it as the focal point of development. Innovation must exist to support operational leaders, not vice versa.
It is better for an operational leader to copy than create, to steal rather than innovate. By doing so they are more likely to have the time—and the proven tools—to succeed.
1. MC3 Peter Burghart, “George Washington HTs Pump Out Aid,” www.navy.mil/submit/display.asp?story_id=77655, 15 November 2013.
2. MC3 Shentel M. Yarnell and MCSN Heather Roe, “Carl Vinson Sends Desperately Needed Water Ashore,” www.navy.mil/submit/display.asp?story_id=50661, 20 January 2010.
3. RADM Scott Jerabeck, Lecture at Surface Navy Association, Hampton Roads Chapter Lunch, Hampton Roads VA, 20 November 2013.
4. Massively Multiplayer Online Wargame Leveraging the Internet: Wargames run by the U.S. Naval Postgraduate School. Campaign now concluded, formerly at http://navyrad.ideascale.com/a/pages/about.
5. Rachel Zupek, “When a Co-worker Steals an Idea,” CareerBuilder.com, http://msn.empleoscb.com/CBMiniSite/SharedPages/PrinterFriendlyArticle.aspx?articleID=395.
Command and Operations School: 28 Years and Counting
On 20 October 1978, the USCGC Cuyahoga (WIX-127), a 125-foot training cutter, was conducting a training mission for embarked officer candidates when she collided with the 521-foot motor vessel Santa Cruz II in the Chesapeake Bay. Ten Coast Guardsmen and one foreign exchange officer were killed in the incident, which was caused by human error. A subsequent Marine Board of Investigation determined the Cuyahoga failed to properly identify the Santa Cruz II either visually or by radar, therefore not maneuvering as required by the Navigation Rules.1
On 28 January 1980, the USCGC Blackthorn (WLB-391), a 180-foot buoy tender, was in Tampa Bay transiting outbound toward Mobile, Alabama, following an extensive three month dry-dock period. As she steamed out of the main shipping channel, she encountered several vessels, including the 605-foot tanker Capricorn, which collided nearly head-on with the Blackthorn in the vicinity of the Sunshine Skyway Bridge. The Capricorn’s port anchor tore into and lodged in the Blackthorn’s port side hull, ultimately resulting in the capsizing of the latter. Twenty-three Coast Guardsmen perished. Just as with the Cuyahoga, the subsequent investigation concluded the crews aboard both vessels failed to properly identify each other. Furthermore, they eschewed the Navigation Rules’ requirement to favor the starboard side of the channel.
The official investigation ultimately recommended that the Coast Guard require all cutter commanding officers to attend some form of refresher training prior to assuming command to prevent similar tragedies.2 Thus Command and Operations School, more commonly referred to as Prospective Commanding Officer/Executive Officer (PCO/PXO) School, was established. Now completing its 28th training season, it remains the preeminent schoolhouse for command cadre training.
The Early Years
In 1986, the Coast Guard Academy in New London, Connecticut, was installing a new, state-of-the-art Ship Control and Navigation Training System visual simulator facility, which could simulate a realistic bridge environment for training cadets in shipboard navigation, piloting, and shiphandling. This made the Academy the ideal location for PCO/PXO School, which was initially staffed by Academy personnel and placed under the supervision of the Professional Maritime Studies Branch. Lieutenant Commander Michael Hunt was assigned as school chief, and Lieutenant Ivan Luke served as assistant school chief. The Academy’s Engineering Branch and Law Section provided additional instructor support. According to now-retired Captain Luke, the staff was given broad direction to develop the PCO/PXO course, to include a core curriculum of navigation rules, command leadership, stability, and operational law. The first course was two weeks long, with a third week for students assigned to flight deck-equipped cutters.
Over the course of the first few years, staff built the curriculum and drafted lesson plans, while simultaneously developing realistic visual simulator scenarios. As they do today, lessons incorporated previous cutter mishap investigations and analyses. However, the initial request for access to the mishap investigations was denied. After considerable pressure from the Academy Professional Maritime Studies Branch Chief, Captain Ikens, and support from the Cutter Forces staff at Headquarters, PCO/PXO School was granted unfettered access to these vital reports.3 The investigation files were subsequently consolidated to create the school’s case study booklet. This publication is used for student analysis and the development of lessons learned in hope of avoiding similar accidents in the future. Today, PCO/PXO School automatically receives copies of navigation mishap investigations to ensure that case studies remain relevant and determine if trends can be identified to improve course delivery and classroom discussions.
Program Evolution
In 1998, responsibility for PCO/PXO School transferred to the newly established Leadership Development Center within the Coast Guard Academy. Over the years, the Command and Operations Schoolhouse has expanded its courses to include the two-week Boat Forces Command Cadre course, two-week Prospective Operations Officer Course, four-day Bridge Resource Management course, and the four-day Command Assignment Preparatory Course for shore-based commanding officers. Twice a year, in support of Training Center Yorktown’s International Training Division, the Command and Operations School also hosts a four-day class on navigation and leadership embedded into the International Maritime Officers Course for students from multiple foreign nations. Although the PCO/PXO course has gone through significant curriculum iterations over the years, it has always remained true to its original objectives: to prevent the loss of life from cutter operations; prevent collisions, allisions, and groundings; mitigate operational risk; and enhance operational readiness.
Since its inception, PCO/PXO School has convened over 260 classes, instructing over 2,700 officer and enlisted students bound for the demanding positions of CO, officer in charge, executive officer, or executive petty officer on board a cutter. Just as Alexander Hamilton did when selecting the first 10 Revenue Cutter service captains in 1791, the Coast Guard carefully identifies and selects top performing officers and enlisted members for command at sea. These men and women have willingly taken the burden of afloat command and led the service through many of the nation’s most significant events.
Cutters have met every challenge including the Haitian and Cuban mass migrations in the late 1980s, responses to Hurricanes Andrew and Katrina, the Exxon Valdez oil spill, and the 9/11 terrorist attacks. More recently, they led our nation’s response to both the 2010 Haitian earthquake and the Deepwater Horizon oil spill, and have participated in countless other operations around the globe. A CO’s authority is vast, responsibility is absolute, and accountability is inescapable. An afloat CO exercises tremendous autonomy and is expected and trusted to take the initiative in the absence of orders from an operational commander.
In addition to honing navigation skills, the school has increased its emphasis on improving command leadership in an effort to promote positive command climates and improve shipboard relationships. Over the past few years, there have been too many cases involving a pervasively negative command climate at ashore and afloat units. Sometimes this has resulted in the early relief of a unit CO, or as we refer to it during the course, a “change of command without hors d’oeuvres.” In response, the Coast Guard has devoted efforts to find the best way to create, assess, and maintain a positive command climate. The afloat community is addressing this issue during CO and executive officer pipeline preparation training. Through focused lectures and case studies, PCO/PXO School has divided command leadership into four interwoven lessons: Responsibility, Authority, and Accountability; Command Relationships; Command Philosophy; and Command Climate.
PCO/PXO School embodies the Commandant’s guiding principle of “honor our profession” by preparing cuttermen to go forth and perform vital, dangerous work that demands superior technical expertise, absolute responsibility, and strict accountability.4 Fortunately, since the 1980 Blackthorn collision, the Coast Guard has not experienced another major cutter accident with multiple personnel fatalities. Accidents have occurred, however, and through critical analysis, lessons learned were identified resulting in necessary service-wide changes to tactics, doctrine, procedures, and training. The staff continuously strives to improve safety and reduce risks while still maintaining a strong mission focus. Coast Guard missions at sea are dangerous, and the duties and responsibilities of command personnel require a steadfast commitment to both the mission and crew. Command and Operations School is devoted to providing cutter leadership with the very best training in preparation for their assignments, and proudly finds itself with a solid foundation built by 28 years of dedicated cuttermen.
1. U.S. Coast Guard, Marine Casualty Report, “USCGC Cuyahoga, M/V Santa Cruz II; Collision in Chesapeake Bay on 20 October 1978 with Loss of Life,” Report No. USCG 16732/93268.
2. U.S. Coast Guard, Marine Casualty Report, USCG Blackthorn, SS Capricorn; Collision in Tampa Bay on 28 January 1980 with Loss of Life; Report No. USCG 16732/01279.3. U.S. Coast Guard, PCO/PXO Afloat Curriculum Outline, 14 January 2010.
3. U.S. Coast Guard, PCO/PXO Afloat Curriculum Outline, 14 January 2010.
4. U.S. Coast Guard, Commandant’s Direction, The Commandant’s Guiding Principles, 2011.
Lieutenant Commander Godwin served as the PCO/PXO Assistance School Chief for three years at the Coast Guard Leadership Development Center prior to his current assignment as the Pacific Area Scheduler. His most recent underway assignment was as CO of the CGC Biscayne Bay (WTGB-104) in St. Ignace, Michigan.