, and a collection ofcommunication media that interconnect the packetswitches. Within each HOST, we assume that thereexist
`
`processes
`
`packet switching subnet
`
`Abstract
`
`packet switches
`
` which must communicate withprocesses in their own or other HOSTS. Any currentdefinition of a process will be adequate for ourpurposes [13]. These processes are generally theultimate source and destination of data in thenetwork. Typically, within an individual network,there exists a protocol for communication betweenany source and destination process. Only the sourceand destination processes require knowledge of thisconvention for communication to take place.Processes in two distinct networks would ordinarilyuse different protocols for this purpose. Theensemble of packet switches and communicationmedia is called the
`
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974A Protocol for Packet Network IntercommunicationVINTON G. CERF AND ROBERT E. KAHN,MEMBER, IEEE
` — A protocol that supports the sharing of resources that existin different packet switching networks is presented. The protocol providesfor variation in individual network packet sizes, transmission failures,sequencing, flow control, end-to-end error checking, and the creation anddestruction of logical process-to-process connections. Someimplementation issues are considered, and problems such as internetworkrouting, accounting, and timeouts are exposed.INTRODUCTIONIN THE LAST few years considerable effort hasbeen expended on the design and implementation ofpacket switching networks [1]-[7],[14],[17]. A prin-ciple reason for developing such networks has beento facilitate the sharing of computer resources. Apacket communication network includes a transpor-tation mechanism for delivering data between com-puters or between computers and terminals. Tomake the data meaningful, computer and terminalsshare a common protocol (i.e, a set of agreed uponconventions). Several protocols have already beendeveloped for this purpose [8]-[12],[16]. However,these protocols have addressed only the problem ofcommunication on the same network. In this paperwe present a protocol design and philosophy thatsupports the sharing of resources that exist in differ-ent packet switching networks.After a brief introduction to internetworkprotocol issues, we describe the function of aGATEWAY as an interface between networks anddiscuss its role in the protocol. We then consider thevarious details of the protocol, including addressing,formatting, buffering, sequencing, flow control,error control, and so forth. We close with adescription of an interprocess communicationmechanism and show how it can be supported bythe internetwork protocol.Even though many different and complexproblems must be solved in the design of anindividual packet switching network, theseproblems are manifestly compounded whendissimilar networks are interconnected. Issues arisewhich may have no direct counterpart in anindividual network and which strongly influence theway in which internetwork communication can takeplace.A typical packet switching network is composedof a set of computer resources called HOSTS, a setof one or more
`. Fig. 1illustrates these ideas.In a typical packet switching subnet, data of afixed maximum size are accepted from a sourceHOST, together with a formatted destination addresswhich is used to route the data in a store andforward fashion. The transmit time for this data isusually dependent upon internal network parameterssuch as communication media data rates, bufferingand signalling strategies, routeing, propagationdelays, etc. In addition, some mechanism isgenerally present for error handling anddetermination of status of the networks components.Individual packet switching networks may differin their implementations as follows.1)Each network may have distinct ways ofaddressing the receiver, thus requiring that auniform addressing scheme be created which can beunderstood by each individual network.2)Each network may accept data of differentmaximum size, thus requiring networks to deal inunits of the smallest maximum size (which may beimpractically small) or requiring procedures whichallow data crossing a network boundary to bereformatted into smaller pieces.3)The success or failure of a transmission andits performance in each network is governed bydifferent time delays in accepting, delivering, andtransporting the data. This requires carefuldevelopment of internetwork timing procedures toinsure that data can be successfully deliveredthrough the various networks.4)Within each network, communication may bedisrupted due to unrecoverable mutation of the dataor missing data. End-to-end restoration proceduresare desirable to allow complete recovery from theseconditions.Paper approved by the Associate Editor for Data Communications of theIEEE Communications Society for publications without oral presentation.Manuscript received November 5, 1973. The research reported in this pa-per was supported in part by the Advanced Research Projects Agency ofthe Department of Defense under Contract DAHC 15-73-C-0370.V.G. Cerf is with the Department of Computer Science and Electrical En-gineering, Standford University, Stanford, Calif.R.E. Kahn is with the Information Processing Technology Office,Advanced Research Projects Agency, Department of Defense, Arlington,Va.
`
`Netflix 1022 - Page 1
`
`

`
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974Fig. 1.Typical packet switching network.5)Status information, routing, fault detection,and isolation are typically different in each network.thus, to obtain verification of certain conditions,such as an inaccessible or dead destination, variouskinds of coordination must be invoked between thecommunicating networks.It would be extremely convenient if all thedifferences between networks could beeconomically resolved by suitable interfacing at thenetwork boundaries. For many of the differences,this objective can be achieved. However, botheconomic and technical considerations lead us toprefer that the interface be as simple and reliable aspossible and deal primarily with passing databetween networks that use different packetswitching strategies.The question now arises as to whether theinterface ought to account for differences in HOST orprocess level protocols by transforming the sourceconventions into the corresponding destinationconventions. We obviously want to allowconversion between packet switching strategies atthe interface, to permit interconnection of existingand planned networks. However, the complexityand dissimilarity of the HOST or process levelprotocols makes it desirable to avoid having totransform between them at the interface, even if thistransformation were always possible. Rather,compatible HOST and process level protocols must bedeveloped to achieve effective internetworkresource sharing. The unacceptable alternative is forevery HOST or process to implement every protocol(a potentially unbounded number) that may beneeded to communicate with other networks. Wetherefore assume that a common protocol is to beused between HOST’S or processes in differentnetworks and that the interface between networksshould take as small a role as possible in thisprotocol.To allow networks under different ownership tointerconnect, some accounting will undoubtedly beneeded for traffic that passes across the interface. Inits simplest terms, this involves an accounting ofpackets handled by each net for which charges arepassed from net to net until the buck finally stops atthe user or his representative. Furthermore, theinterconnection must preserve intact the internaloperation of each individual network. This is easilyachieved if two networks interconnect as if eachwere a HOST to the other network, but withoututilising or indeed incorporating any elaborate HOSTprotocol transformations.It is thus apparent that the interface betweennetworks must play a central role in thedevelopment of any network interconnectionstrategy. We give a special name to this interfacethat performs these functions and call it a GATEWAY.THE GATEWAY NOTIONIn Fig. 2 we illustrate three individual networkslabelled
`
` Again thederivation of the next GATEWAY address isaccomplished based on the address of thedestination
`
`A
`X
`Y
`C
` destined forprocess
`X
`is initiallyspecified by process
`M
` Wemake no attempt to specify whether the choice ofGATEWAY is made by process
`A
` its HOST, or one ofthe packet switches in network
`A
`. The packettraverses network
` Atthe GATEWAY, the packet is reformatted to meet therequirements of network
`A
`B
` account is taken of thisunit of flow between
`, and the GATEWAYdelivers the packet to network
`
`M .
`
`Y .
`
`B .
`
`X ,
`
`B ,
`
`B
`
`M
`
`C
`
`B
`A
`M
`N
`N
` withnetwork
`C
`tonetwork
`B
`. We assume that an individual networkmay have more than one GATEWAY (e.g., network
`
`A ,
`
`B ,
`
`)and that there may be more than one GATEWAY pathto use in going between a pair of networks. Theresponsibility for properly routing data resides inthe GATEWAY.In practice, a GATEWAY between two networksmay be composed of two halves, each associatedwith its own network. It is possible to implementeach half of a GATEWAY so it need only embedinternetwork packets in local packet format orextract them. We propose that the GATEWAY handleinternetwork packets in a standard format, but weare not proposing any particular transmissionprocedure between GATEWAY halves.Let us now trace the flow of data through theinterconnected networks. We assume a packet ofdata from process
`
`Y
`
`N
`B
` is the nextone. The packet traverses network
`N
` until it finallyreaches GATEWAY
`C
` where it is formatted to meet therequirements of network
`C
`. Account is again takenof this unit of flow between networks
`C
`.Upon entering network
`, the packet is routed to theHOST in which process
`resides and there it isdelivered to its ultimate destination.
`
`B
`
`Y
`
`Y .
`
`Netflix 1022 - Page 2
`
`
`, and
` which are joined by GATEWAYS
` and
`. GATEWAY
`interfaces network
` and GATEWAY
` interfaces network
` enters network
` in network
`. The address of
` and the address of GATEWAY
` is derived from the address of process
` until it reaches GATEWAY
` and
` In this case, GATEWAY
`and
`

`
`internetwork header
`
`not
`
`prefixed to the packet by the source HOST. Thepacket format, including the internetwork header, isillustrated in Fig. 3. The source and destinationentries uniformly and uniquely identify the addressof every HOST in the composite network. Addressingis a subject of considerable complexity which isdiscussed in greater detail in the next section. Thenext two entries in the header provide a sequencenumber and a byte count that may be used toproperly sequence the packets upon delivery to thedestination and may also enable the GATEWAYS todetect fault conditions affecting the packet. The flagfield is used to convey specific control informationand is discussed in the section on retransmission andduplicate detection later. The remainder of thepacket consists of text for delivery to the destinationand a trailing check sum used for end-to-endsoftware verification. The GATEWAY does
`
` in thefigure which is prefixed to the beginning of thepacket. This local header is introduced merely toillustrate the concept of embedding an internetworkpacket in the format of the individual networkthrough which the packet must pass. It willobviously vary in its exact form from network tonetwork and may even be unnecessary in somecases. Although not explicitly indicated in thefigure, it is also possible that a local trailer may beappended to the end of the packet.Unless all transmitted packets are legislativelyrestricted to be small enough to be accepted byevery individual network, the GATEWAY may beforced to split a packet into two or more smallerpackets. This action is called fragmentation andmust be done in such a way that the destination isable to piece together the fragmented packet. It isclear that the internetwork header format imposes aminimum packet size which all networks must carry(obviously all networks will want to carry packetslarger than this minimum). We believe the longrange growth and development of internetworkcommunication would be seriously inhibited byspecifying how much larger than the minimum apacket size can be, for the following reasons.1)If a maximum permitted packet size isspecified then it becomes impossible to completelyisolate the internal packet size parameters of onenetwork from the internal packet size parameters ofall other networks.2)It would be very difficult to increase themaximum permitted packet size in response to newtechnology (e.g. large memory systems, higher datarate communication facilities, etc.) since this wouldrequire the agreement and then implementation byall participating networks.3)Associative addressing and packet encryptionmay require the size of a particular packet to expandduring transit for incorporation of new information.Provision for fragmentation (regardless ofwhere it is performed) permits packet size variationsto be handled on an individual network basiswithout global administration and also permitsHOSTS and processes to be insulated from changes inthe packet sizes permitted in any networks throughwhich their data must pass.If fragmentation must be done, it appears best todo it upon entering the next network at the GATEWAYsince only this GATEWAY (and not the othernetworks) must be aware of the internal packet sizeparameters which made the fragmentationnecessary.If a GATEWAY fragments an incoming packet intotwo or more packets, they must eventually be passedalong to the destination HOST as fragments orreassembled for the HOST. It is conceivable that onemight desire the GATEWAY to perform the reassemblyto simplify the task of the destination HOST (orprocess) and/or to take advantage of the largerpacket size. We take the position that GATEWAYshould not perform this function since GATEWAYreassembly can lead to serious buffering problems,potential deadlocks, the necessity for all fragmentsof a packet to pass through the same GATEWAY, andincreased delay in transmission. Furthermore, it isnot sufficient for the GATEWAY to provide thisfunction since the final GATEWAY may also have tofragment a packet for transmission. Thus thedestination HOST must be prepared to do this task.Let us now turn briefly to the somewhat unusualaccounting effect which arises when a packet maybe fragmented by one or more GATEWAY. Weassume, for simplicity, that each network initiallycharges a fixed rate per packet transmitted,regardless of distance, and if one network canhandle a larger packet size than another, it charges aproportionally larger price per packet. We alsoassume that a subsequent increase in any network’spacket size does not result in additional cost perpacket to its users. The charge to a user thus remains
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974Fig. 2.Three networks interconnected by two GATEWAYS.Fig. 3.Internetwork packet format (fields not shown to scale).Since the GATEWAY must understand the addressof the source and destination HOSTS, this informationmust be available in a standard format in everypacket which arrives at the GATEWAY. Thisinformation is contained in an
`
` modifythe text and merely forwards the check sum alongwithout computing or recomputing it.Each network may need to augment the packetformat before it can pass through the individualnetwork. We have indicated a
`
`local header
`
`Netflix 1022 - Page 3
`
`

`
`Case
`
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974basically constant through any net which mustfragment a packet. The unusual effect occurs when apacket is fragmented into smaller packets whichmust individually pass through a subsequentnetwork with a larger packet size than the originalunfragmented packet. We expect that most networkswill naturally select packet sizes close to oneanother, but in any case, an increase in packet sizein one net, even when it causes fragmentation, willnot increase the cost of transmission and mayactually decrease it. In the event that any otherpacket charging policies (than the one we suggest)are adopted, differences in cost can be used as aneconomic lever toward optimisation of individualnetwork performance.PROCESS LEVEL COMMUNICATIONWe suppose that processes wish to communicatein full duplex with their correspondents usingunbounded but finite length messages. A singlecharacter might constitute the text of a messagefrom a process to a terminal or vice versa. An entirepage of characters might constitute the text of amessage from a file to a process. A data stream (e.g.a continuously generated bit string) can berepresented as a sequence of finite length messages.Within a HOST we assume that existence of atransmission control program (TCP) which handlesthe transmission and acceptance of messages onbehalf of the processes it serves. The TCP is in turnserved by one or more packet switches connected tothe HOST in which the TCP resides. Processes thatwant to communicate present messages to the TCPfor transmission, and TCP’s deliver incomingmessages to the appropriate destination processes.We allow the TCP to break up messages intosegments because the destination may restrict theamount of data that may arrive, because the localnetwork may limit the maximum transmissin size,or because the TCP may need to share its resourcesamong many processes concurrently. Furthermore,we constrain the length of a segment to an integralnumber of 8-bit bytes. This uniformity is mosthelpful in simplifying the software needed withHOST machines of different natural word lengths.Provision at the process level can be made forpadding a message that is not an integral number ofbytes and for identifying which of the arriving bytesof text contain information of interest to thereceiving process.Mutliplexing and demultiplexing of segmentsamong processes are fundamental tasks of the TCP.On transmission, a TCP must multiplex togethersegments from different source processes andproduce internetwork packets for delivery to one ofits serving packet switches. On reception, a TCPwill accept a sequence of packets from its servingpacket switch(es). From this sequence of arrivingpackets (generally from different HOSTS), the TCPmust be able to reconstruct and deliver messages tothe proper destination processes.We assume that every segment is augmentedwith additional information that allows transmittingand receiving TCP’s to identify destination andsource processes, respectively. At this point, wemust face a major issue. How should the sourceTCP format segments destined for the samedestination TCP? We consider two cases.
` 1): If we take the position that segmentboundaries are immaterial and that a byte streamcan be formed of segments destined for the sameTCP, then we may gain improved transmissionefficiency and resource sharing by arbitrarilyparceling the stream into packets, permitting manysegments to share a single internetwork packetheader. However, this position results in the need toreconstruct exactly, and in order, the stream of textbytes produced by the source TCP. At thedestination, this stream must first be parsed intosegments and these in turn must be used toreconstruct messages for delivery to the appropriateprocesses.There are fundamental problems associated withthis strategy due to the possible arrival of packetsout of order at the destination. The most criticalproblem appears to be the amount of interferencethat processes sharing the same TCP-TCP bytestream may cause among themselves. This isespecially so at the receiving end. First, the TCPmay be put to some trouble to parse the stream backinto segments and then distribute them to bufferswhere messages are reassembled. If it is not readilyapparent that all of a segment has arrived(remember, it may come as several packets), thereceiving TCP may have to suspend parsingtemporarily until more packets have arrived.Second, if a packet is missing, it may not be clearwhether succeeding segments, even if they areidentifiable, can be passed on to the receivingprocess, unless the TCP has knowledge of someprocess level sequencing scheme. Such knowledgewould permit the TCP to decide whether asucceeding segment could be delivered to itswaiting process. Finding the beginning of a segmentwhen there are gaps in the byte stream may also behard.
`
`Case
`
` 2): Alternatively, we might take theposition that the destination TCP should be able todetermine, upon its arrival and without additionalinformation, for which process or processes areceived packet is intended, and if so, whether itshould be delivered then.If the TCP is to determine for which process anarriving packet is intended, every packet mustcontain a
`
`process header
`
` (distinct from theinternetwork header) that completely identifies thedestination process. For simplicity, we assume thateach packet contains text from a single processwhich is destined for a single process. Thus each
`
`Netflix 1022 - Page 4
`
`

`
`.ADDRESS FORMATSThe selection of address formats is a problembetween networks because the local networkaddresses of TCP’s may vary substantially in formatand size. A uniform internetwork TCP addressspace, understood by each GATEWAY and TCP, isessential to routing and delivery of internetworkpackets.Similar troubles are encountered when we dealwith process addressing and, more generally, portaddressing. We introduce the notion of
`
`ports
`
`internetwork transmission
`protocol
`
`
`
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974packet need contain only one process header. Todecide whether the arriving data is deliverable to thedestination process, the TCP must be able todetermine whether the data is in the proper sequence(we can make provision for the destination processto instruct its TCP to ignore sequencing, but this isconsidered a special case). With the assumption thateach arriving packet contains a process header, thenecessary sequencing and destination processidentification is immediately available to thedestination TCP.Both Cases 1) and 2) provide for thedemultiplexing and delivery of segments todestination processes, but only Case 2) does sowithout the introduction of potential interprocessinterference. Furthermore, Case 1) introduces extramachinery to handle flow control on a HOST-to-HOSTbasis, since there must also be some provision forprocess level control, and this machinery is littleused since the probability is small that within agiven HOST, two processes will be coincidentallyscheduled to send messages to the same destinationHOST. For this reason, we select the method of Case2) as a part of the inorder to permit a process to distinguish betweenmultiple message streams. The port is simply adesignator of one such message stream associatedwith a process. The means for identifying a port aregenerally different in different operating systems,and therefore, to obtain uniform addressing, astandard port address format is also required. A portaddress designates a full duplex message stream.TCP ADDRESSINGTCP addressing is intimately bound up inrouteing issues, since a HOST or GATEWAY mustchoose a suitable destination HOST or GATEWAY for anoutgoing internetwork packet. Let us postulate thefollowing address format for the TCP address (Fig.4). The choice for network identification (8 bits)allows up to 256 distinct networks. This size seemssufficient for the foreseeable future. Similarly, theTCP identifier field permits up to 65 536 distinctTCP’s to be addressed, which seems more thansufficient for any given network.As each packet passes through a GATEWAY, theGATEWAY observes the destination network ID todetermine how to route the packet. If the destinationnetwork is connected to the GATEWAY, the lower 16bits of the TCP address are used to produce a localTCP address in the destination network. If thedestination network is not connected to theGATEWAY, the upper 8 bits are used to select asubsequent GATEWAY. We make no effort to specifyhow each individual network shall associate theinternetwork TCP identifier with its local TCPaddress. We also do not rule out the possibility thatthe local network understands the internetworkaddressing scheme and thus alleviates the GATEWAYof the routing responsibility.PORT ADDRESSINGA receiving TCP is faced with the task ofdemultiplexing the stream of internetwork packets itreceives and reconstructing the original messagesfor each destination process. Each operating systemhas its own internal means of identifying processesand ports. We assume that 16 bits are sufficient toserve as internetwork port identifiers. A sendingprocess need not know how the destination portidentification will be used. The destination TCP willbe able to parse this number appropriately to findthe proper buffer into which it will place arrivingpackets. We permit a large port number field tosupport processes which want to distinguishbetween many different message streamsconcurrently. In reality, we do not care how the 16bits are sliced up by the TCP’s involved.Fig. 4.TCP address.Even though the transmitted port name field islarge, it is still a compact external name for theinternal representation of the port. The use of shortnames for port identifiers is often desirable toreduce transmission overhead and possibly reducepacket processing time at the destination TCP.Assigning short names to each port, however,requires an initial negotiation between source anddestination to agree on a suitable short nameassignment, the subsequent maintenance ofconversion tables at both the source and thedestination, and a final transaction to release theshort name. For dynamic assignment of port names,this negotiation is generally necessary in any case.SEGMENT AND PACKET FORMATSAs shown in Fig. 5, messages are broken by theTCP into segments whose format is shown in moredetail in Fig. 6. The field lengths illustrated are
`
`Netflix 1022 - Page 5
`
`

`
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974merely suggestive. The first two fields (source portand destination port in the figure) have already beendiscussed in the preceding section on addressing.The uses of the third and fourth fields (window andacknowledgement in the figure) will be discussedlater in the section on retransmission and duplicatedetection.We recall from Fig. 3 that an internetworkheader contains both a sequence number and a bytecount, as well as a flag field and a check sum. Theuses of these fields are explained in the followingsection.REASSEMBLY AND SEQUENCINGThe reconstruction of a message at the receivingTCP clearly requires1 that each internetwork packetcarry a sequence number which is unique to itsparticular destination port message stream. Thesequence numbers must be monotonic increasing(or decreasing) since they are used to reorder andreassemble arriving packets into a message. If thespace of sequence numbers were infinite, we couldsimply assign the next one to each new packet.Clearly, this space cannot be infinite, and we willconsider what problems a finite sequence numberspace will cause when we discuss retransmissionand duplicate detection in the next section. Wepropose the following scheme for performing thesequencing of packets and hence the reconstructionof messages by the destination TCP.A pair of ports will exchange one or moremessages over a period of time. We could view thesequence of messages produced by one port as if itwere embedded in an infinitely long stream of bytes.Each byte of the message has a unique sequencenumber which we take to be its byte locationrelative to the beginning of the stream. When asegment is extracted from the message by the sourceTCP and formatted for internetwork transmission,the relative location of the first byte of segment textis used as the sequence number for the packet. Thebyte count field in the internetwork header accountsfor all the text in the segment (but does not includethe check-sum bytes or the bytes in eitherinternetwork or process header). We emphasise thatthe sequence number associated with a given packetis unique only to the pair of ports that arecommunicating (see Fig. 7). Arriving packets areexamined to determine for which port they areintended. The sequence numbers on each arrivingpacket are then used to determine the relativelocation of the packet text in the messages underreconstruction. We note that this allows the exactposition of the data in the reconstructed message tobe determined even when pieces are still missing.Every segment produced by a source TCP ispackaged in a single internetwork packet and acheck sum is computed over the text and processheader associated with the segment.The splitting of messages into segments by theTCP and the potential splitting of segments intosmaller pieces by GATEWAY creates the necessity forindicating to the destination TCP when the end of asegment (ES) has arrived and when the end of amessage (EM) has arrived. The flag field of theinternetwork header is used for this purpose (seeFig. 8).The ES flag is set by the source TCP each time itprepares a segment for transmission. If it shouldhappen that the message is completely contained inFig. 5.Creation of segments and packets from messages.Fig. 6.Segment format (process header and text).1 In the case of encrypted packets, a preliminary stage of reassembly maybe required prior to decryption.Fig. 7.Assignment of sequence numbers.Fig. 8.Internetwork header flag field.Fig. 9.Message splitting and packet splitting.
`
`Netflix 1022 - Page 6
`
`

`
`A
`A
`A
` in Fig. 9 is shown splitinto two segments
`A
`2 and formatted by theTCP into a pair of internetwork packets. Packets
`A
`A
`1and
`A
`2 has its EM bitset as well. When packet
`A
`1 passes through theGATEWAY, it is split into two pieces: packet
`11 forwhich neither EM nor ES bits are set, and packetA A
`
`A
`2 is splitsuch that the first piece, packet
`A
`21, has neither bitset, but packet
`
`© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974the segment, then the EM flag would also be set.The EM flag is also set on the last segment of amessage, if the message could not be contained inone segment. These two flags are used by thedestination TCP, respectively, to discover thepresence of a check sum for a given segment and todiscover that a complete message has arrived.The ES and EM flags in the internetwork headerare known to the GATEWAY and are of specialimportance when packets must be split apart frompropagation through the next local network. Weillustrate their use with an example in Fig. 9.The original message
`w - 1.2) On timeout (duration unspecified), the senderretransmits unacknowledged bytes.3) On receipt of acknowledgment consisting ofthe receiver’s current left window edge, the sender’s2 The ARPANET is one such example.Fig. 10.The window concept.Fig. 11.Conceptual TCB format.
`22, assuming all otherpackets have arrived, the destination TCP detectsthat it has reassembled a complete message and cannow advise the destination process of its receipt.RETRANSMISSION AND DUPLICATE DETECTIONNo transmission can be 100 percent reliable. Wepropose a timeout and positive acknowledgementmechanism which will allow TCP’s to recover frompacket losses from one HOST to another. A TCPtransmits packets and waits for replies(acknowledgements) that are carried in the reversepacket stream. If no acknowledgement for aparticular packet is received, the TCP willretransmit. It is our expectation that the HOST levelretransmission mechanism, which is described inthe following paragraphs, will not be called uponvery often in practice. Evidence already exists2 thatindividual networks can be effectively constructedwithout this feature. However, the inclusion of aHOST retransmission capability makes it possible torecover from occasional network problems andallows a wide range of HOST protocol strategies to beincorporated. We envision it will occasionally beinvoked to allow HOST accommodation to infrequentoverdemands for limited buffer resources, andotherwise not used much.Any retransmission policy requires some meansby which the receiver can detect duplicate arrivals.Even if an infinite number of distinct packetsequence numbers were available, the receiverwould still have the problem of knowing how longto remember previously received packets in order todetect duplicates. Matters are complicated by thefact that only a finite number of distinct sequencenumbers are in fact available, and if they are reused,the receiver must be able to distinguish betweennew transmissions and r