Tech Innovation: Quality and Productive Methods

Technology Product: Product Development TCP/IP is the universally-accepted standard for internet-working protocol suites. However, despite its wide use, popularity, and inherent advantages, TCP has one fundamental drawback -- it is not as effective in high-latency environments as it is in terrestrial networks. This analysis sought to address this problem by i) developing a new product with better functionality in high latency, satellite environments; and ii) developing an effective development and marketing plan to ensure the product's successful diffusion into the consumer market.

The analysis established that one of the reasons why TCP underperforms in satellite environments is because the congestion window does not open fast enough to support the long RTT links characteristic of such environments. For this reason, it proposes the development of an alternative protocol with a congestion window comprising of four segments as opposed to one (as is the case in TCP), to speed up communication in high-latency environments.

The subsequent sections then focus on showing how marketing, pricing, and testing will be carried out to ensure that the launched product meets the exact needs, specifications, and requirements for which it was designed. Table of Contents Executive Summary Table of contents Introduction Background Problem Framing A. High-latency, high-bandwidth communications links Market Analysis A. Current Offerings B. Potential competitive products Design team design Talent search A. Universities B. Existing talent from competitors C. Recruitment Innovation Techniques Potential Solutions Design Proposals Development Process Testing Patenting Marketing Plan A.

Customer / Partner Search B. Pricing Conclusion References Appendix Introduction First used as a research project by the Defense Advanced Research Project Agency (DARPA) in 1969, the TCP/IP protocol suite has evolved into the universally-accepted standard for internetworking protocol suites. The primary goal driving its design was the need to establish a suite of protocols capable of connecting diverse types of computer networks, designed by different manufacturers and running different operating systems (Miller, 2009).

Achieving this goal has contributed to its growing success over the years; at present, TCP/IP is the world's most widely-deployed communications protocol suite, providing a base for high-level protocols including NFS, X11, FTP, and TELNET. Thanks to its non-proprietary and open nature, TCP/IP has continually gained popularity among UNIX Operating System users. Background Networking is one of the key-most features of computer applications; all communication protocols are developed with the aim of improving the existing ones' networking capabilities (Miller, 2009).

Two decades ago, proprietary networking protocols such as DECnet were very prevalent; however, these were largely unable to link up different computer networks without the use of a translator. As the number of computer manufacturers grew, it became apparent that there was need to develop standard protocols that could effectively communicate with each other regardless of the type of operating system. This was when the TCP/IP protocol suite was developed, essentially allowing dissimilar systems to communicate with each other through a common language.

Today, a Microsoft-powered PC is able to communicate effectively with a Dell Web server or an Apple Mac, all thanks to the non-proprietary nature of TCP/IP. Besides its open and non-proprietary nature, TCP/IP has several other features that boost its networking capabilities.

These include an integrated addressing system that allow for communication between devices regardless of how each one is constructed; a design-for-routing system that enhances information routing across an arbitrarily complex network; network independence that allows it to function on lower-layer technology including WANs, wireless LANs and LANs; and a high degree of scalability. From this background, TPC/IP may appear as the perfect solution for the 21st century networking.

The truth, however, is that despite its inherent strengths, TCP/IP has one fundamental drawback -- its communication capability in high-latency environments is low. For instance, it takes less than 30 milliseconds to communicate information between New York and Los Angeles on a terrestrial network, but more than 500 milliseconds on a geostationary satellite link, which is taken in this case to represent a high-latency network.

This is rather dangerous given the rising prevalence of global business, and the fact that organizations are increasingly communicating with their subsidiaries across border on high-latency networks. If TCP/IP is to remain relevant in the internetworking environment in future, necessary modifications will have to be made to improve its functionality.

Based on this drawback, I propose to set up a design team to address this matter from either an incremental perspective (designing suitable modifications to improve the functionality of TCP/IP in high-latency environments) or an innovative perspactive (developing an entirely new protocol that can perform well in high-latency environments). I consider the latter the more attractive option - but either way, existing networks will still have to make the necessary adjustments to adapt to the developed changes.

Problem-Framing High Latency, High Bandwidth Communication Links Two fundamental concepts -- congestion window and slow start - can be used to explain the dismal performance of TCP in high latency, high bandwidth environments. The congestion window indicates the amount of outstanding data awaiting transmission at any one time, and it basically determines the rate at which such transmission will be executed by TCP (Henderson & Katz, 1999).

Slow start, on the other hand, is a control strategy used by TCP and other transmission protocols to regulate the amount of data being transmitted and essentially prevent network congestion (Held, 2001). The congestion value window doubles every RTT (round trip time) during slow start. If the system detects congestion, it retransmits the missing segment, halves the congestion window value, and initiates the congestion avoidance phase.

At this point, the value on the congestion window increases by not more than one segment/RTT, and this value is again halved if the system detects further congestion. If a discovery is made that some transmissions may have been lost in the process, "the TCP sender is forced to take a time-out, which involves again retransmitting the missing packet, but this time reducing the window to one segment and resuming slow start" (Henderson & Katz, 1999, p. 4).

In high latency environments, this timeout period and the subsequent slow start may take a number of seconds, and at this period, the throughput is extremely low (Henderson & Katz, 1999). A number of TCP extensions have been proposed (and some are in the course of being implemented) to try and control the semantics that impede on TCP's performance in high-latency environments.

They include i) the Window Scale, which introduces a scaling factor to the window field, thereby increasing the amount of outstanding data, which is particularly helpful for high-latency networks, whose data rates require large windows; ii) selective acknowledgements (SACK), which allow for the recovery of multiple losses in a single RTT, thereby lessening the tome-out period; iii) TCP for Transactions (T/TCP); and iv) Path MTU recovery, which facilitates data transfer by inducing the faster opening of the congestion window (Henderson & Katz, 1999).

Despite these attempts at improvement, however, Henderson and Katz (1999) point out that some vexing attributes that impede on TCP's performance over satellite links are yet to be resolved. They include slow start-up, link asymmetry, and TCP fairness. The authors point out that in order for TPC to achieve the desired performance in high-latency environments, standardized solutions to the aforementioned attributes need to be developed.

This text seeks to develop an entirely new non-proprietary protocol that capitalizes on these inherent weaknesses of TPC to perform at higher speeds over high bandwidth, high latency networks. Market Analysis Current Offerings of TCP/IP TCP serial transmission servers and network chips are used in a wide array of wireless carriers, telephony systems, and internet service providers (ISPs). Some of the major clients include transport management frameworks, home care and medicinal gear, embedded modems, ATM teller machines, and point-of-sale terminals (Reynders & Wright, 2003).

Recently, TCP/IP was introduced in building management systems (BMS), enabling convenient data transmission between subsidiaries and making the physical distance between buildings less relevant. The TCP/IP microcontroller, which is proprietor-independent, enables seamless communication from the sender's end to the receiver's end via telephone, network, company network, or cable. Potential Competitive Products TCP/IP does not currently have a standard competitor, given that most of those that used to be 'competitors' ended up using TCP in their network systems due to its high degree of effectiveness.

All the same, X.25, UDP/IP, DECnet, IP Sec/IP, AppleTalk, and IPX/SPX can be taken, to some extent, as potential competitors to TPC/IP, although they were initially developed as proprietary networks. TCP enjoys a huge advantage over these other products owing to its high degree of scalability, ability to function in lower-layer technology, its design-for-routing, and its integrated addressing system that allow for inter-device communication regardless of how each device is constructed.

Design Team Make-Up The make-up and structure of the design team will lay emphasis on meeting the data innovation objective. Due to the high-risk nature of the proposed project, the resource pool structure will be adopted. According to Friday (2003), this kind of structure minimizes risk to users by essentially pooling efforts, personnel, equipment, and assets together.

Three independent sub-teams -- the user team, the applications team, and the technical team (each with their own defined roles and specialties) will work separately and independently, with only very minimal collaboration with the steering committee to realize their particular set of objectives, which will all contribute, in part, to the achievement of the overall objective.

However, differently from the typical resource-pool structure, inter-team collaboration and skill transfer will be highly encouraged as a way of ensuring that the solution developed is of high quality, and that the risk of developing a product that does not appeal to the user community is potentially avoided. See fig 1 for full details on the structure and make-up of the design team. Talent Search Universities and Colleges Colleges and universities will be the main recruitment platforms for the design team.

The steering committee and the respective sub-teams will conduct recruitment drives in colleges and universities around the country to identify students with talent, and those shortlisted will then undergo intense training coordinated by the respective sub-team leaders, where they will be oriented on, among other things, the project's objectives and their respective sub-team's contribution or role in achieving the overall objective. Due to resource limitations, however, the recruiting team will only focus on the top 25 universities and colleges identified by recruiters as best picks in 2010 (Wall Street Journal, 2010).

Some of the key benefits of recruiting from institutions of higher learning include increased chances of obtaining fresh ideas and perspectives and better opportunities for diversity and inclusion. Diversity is a key factor for this project -- success will be highly dependent on the product's ability to respond effectively to the specific needs of the diverse user base. Competitors TCP may not have any standard competitors at the moment, given that most of those that were initially competitors now use TCP for their data transmissions.

These include NetWare, ISO-7, DECnet, X.25 to mention but a few. These would obviously be invaluable platforms from which to source hands-on experience. Hands-on experience will be crucial in both the planning and implementation phases of product development, as it will help the design team to correctly identify the current needs of the user population, and implement specific implementation strategies to appeal to the same.

Further, hands-on experience will be key in the rightful identification of trends in user needs, and hence, in the assessment of the product's relevance in future years. Recruitment As already mentioned, colleges and universities, and existing TCP 'competitors' will be the main platforms from which design team members will be recruited. The idea is to bring in fresh perspectives, and then complement these with hands-on experience to develop a high-quality solution that is capable of responding to users' communication needs in an era of rapidly-changing data-transmission needs.

Innovation Techniques in Product Development and Product Launch Watkins and his colleagues (2012) emphasize the need to conduct a needs-assessment before developing or launching a new product or an improvement to an existing product. A proper needs-assessment will ensure that key product drivers are identified, and that consequently, the product is developed in such a way that it meets the most critical of these needs (Watkins, et al., 2012).

The five-stage product development mechanism proposed by Khan (2014) and which involves opportunity identification, concept generation, pre-technical evaluation, technical evaluation, and commercialization, will be employed in this case. See Fig 3 in the appendices section for a schematic of this product development framework. The deep-dive brainstorming technique suggested by Dykes (2011) will be used as the basis for conducting needs-assessment (opportunity identification) for the proposed product.

It will mainly involve brainstorming options and ideas within the context of user needs using SWOT and PESTEL analysis, with the aim of prototyping potential solutions (concepts) to address the same. This way, the design team was able to not only distill and prioritize user needs, but to also identify effective value streams for product development. The pre-technical and technical stages mainly focus on evaluating the identified solutions or concepts to assess their financial viability as well as ability to respond to the user needs identified in the opportunity-identification stage.

An innovative launch methodology will be used to introduce the developed product into the market (commercialization). It will follow three different stages -- the pre-launch stage, the actual launch stage, and the post-launch stage, each with a specific set of strategies as proposed by Khan (2014). The pre-launch stage will focus on creating awareness of the product's existence among users.

The design team will mainly make use of early adopter community members at this stage of the launch, whose core functions will be to i) ensure the product's readiness to enter the market; ii) take note and notify the design team of any complaints and concerns that customers may have on the company's selling and/or marketing processes; and iii) lay the groundwork for the word-of-mouth marketing strategy to be implemented in the later stages of the product launch process.

In the actual launch stage, the team will focus on creating early momentum around the business, its commercial website, and the product itself. Bonuses and special offers will be provided to drive social proof as actual adoption takes shape. The idea is to induce users to make early purchases, and then use the resultant to drive early cash flows, sales, and profits. Engagement with resellers, affiliates, and partners will also be key at this stage. The post-launch stage will focus mainly on driving early demand.

At this stage, the team will rely mainly on third-party reviews, testimonials, and success stories, as well as word-of-moth referrals from resellers, partners, and affiliates to drive sales. Potential Solutions The 4K Slow Start Policy: TCP is slow in high-latency environments because the congestion window does not open fast enough to support the long RTT links characteristic of high bandwidth satellite environments (Henderson & Katz, 1999).

This situation is even worse if slow start is induced to premature termination, "forcing TCP into the linear window growth phase of congestion avoidance early in the connection" (Henderson & Katz, 1999, p. 4). To correct this, we would need to design a protocol with a congestion window that contains multiple segments as opposed to one segment (researchers have proposed four segments) (Henderson & Katz, 1999).

Under this arrangement, file sizes below 4K bytes would only require one RTT to complete, and not two or three as is currently the case (Henderson & Katz, 1999). ACK filtering and Reconstruction: TCP performs well in reverse paths with sufficient bandwidths because in such networks, the stream of acknowledgements (ACKs) responsible for clocking out new segments and advancing the congestion window are able to flow in a smooth and steady manner (Henderson & Katz, 1999).

In cases of limited bandwidth, however, the acknowledgment stream is congested, and the ACKs are either dropped or clumped together, and unable to move effectively (Henderson & Katz, 1999). Researchers have put forth several solutions for correcting this. A faction of researchers, for instance, have suggested the use of ACK congestion control mechanisms that grow the congestion window on the basis of the amount of acknowledged data, as opposed to the number of received ACKs, and regulate transmission of new data using timers (Henderson & Katz, 1999).

This approach would, however, have one fundamental weakness -- it would require changes to the transport layer to be effected on both ends of the connection (Henderson & Katz, 1999). For this reason, the ACK filtering and reconstruction option, which offers the same functionality, but requires changes to be made on the TCP sender's end only, has often been preferred (Henderson & Katz, 1999).

Design Proposals Having identified the inherent weaknesses in TCP, and the specific factors that impede on its ability to perform well in high latency environments, the design team will then draft the necessary adjustments that need to be made to correct the same and consequently improve TCP performance in non-terrestrial communication links.

From an Incremental Perspective: the team could improve TCP performance by designing a distributed congestion-avoidance algorithm capable of converging to fair allocations when there are multiple RRTs sharing a bottleneck link to replace the current algorithm, which has been accused of distributing bandwidth allocations unfairly during high bottleneck link utilizations, thereby inhibiting effective data transmission (Henderson & Katz, 1999). From an Innovative Perspective: the team could design an entirely new protocol with a congestion window that contains multiple (at least four) segments as opposed to one segment.

Adopting the four-segment proposal put forward by researchers, for instance, a 4 kilobyte file, would be completed in just a single RTT under the new protocol, implying that the other RTTs (two or three that are needed to complete the same under TPC) can be used to transmit other outstanding data; in the end, more data will have been transmitted within a considerably short period.

We could, for instance, assume that TPC takes 500 milliseconds to transmit 4 kb of data between New York and Los Angeles, and the transmission is completed in 2 RTTs. Under the new protocol, which uses one RTT, 500 milliseconds would be sufficient to transmit 8kb of data over the same distance. To further boost the new protocol's performance in limited bandwidth high-latency environments, the design team could incorporate an ACK filtering and reconstruction system. Development Process This stage focuses mainly on developing the design characteristics into a final or at least near-final form.

The main tasks at this point will include: i) Conducting design failure mode and effects analysis, which basically involves identifying all potential failures in a design, and developing ways of correcting them so that maximum efficiency is realized (Anleitner, 2010).

ii) Enhancing the design manufacturability of the product design through simplification and standardization, incorporation of DFM practices to make the product more producible, evaluation of alternatives, and use of design tools to make a more producible and mature design before releasing the same out for production, and balancing product quality with robustness (Anderson, 2004) iii) Prototyping, which involves releasing an incomplete version of the design to gauge the product's suitability and performance iv) Reviewing the customer-acceptance document, a piece showing the customer's view on the prototype, that is, their opinion on its degree of appropriateness, and the extent to which it addresses their needs, as well as any possible concerns on the design v) Modifying the design to reflect customers' views and opinion as outlined in the acceptance document, and then releasing the same out for manufacture Testing This basically involves validating the product as well as the processes used to manufacture it to determine whether they meet customer specifications, needs and requirements.

It will involve three main steps: i) Performing a dimension analysis on component parts to ensure that tooling was done correctly ii) Conducting capability studies on the product's key characteristics to verify.