Hubbry Logo
Acknowledgement (data networks)Acknowledgement (data networks)Main
Open search
Acknowledgement (data networks)
Community hub
Acknowledgement (data networks)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Acknowledgement (data networks)
Acknowledgement (data networks)
Acknowledgement (data networks)
View on Wikipedia
from Wikipedia

In data networking, telecommunications, and computer buses, an acknowledgement (ACK) is a signal that is passed between communicating processes, computers, or devices to signify acknowledgement, or receipt of message, as part of a communications protocol. Correspondingly a negative-acknowledgement (NAK or NACK[1]) is a signal that is sent to reject a previously received message or to indicate some kind of error. Acknowledgments and negative acknowledgments inform a sender of the receiver's state so that it can adjust its own state accordingly.

Acknowledgment signal types

[edit]

The ASCII code point for ACK is 0x06 (binary 0000 0110). By convention a receiving device sends an ACK to indicate it successfully received a message. ASCII also provides a NAK code point (0x15, binary 0001 0101) which can be used to indicate the receiving device cannot, or will not, comply with the message.[2] Unicode provides visible symbols for these ASCII characters, U+2406 (␆) and U+2415 (␕).

ACK and NAK symbols may also take the form of single bits or bit fields depending on the protocol data link layer definition or even as a dedicated wire at physical layer.

Protocol usage

[edit]

Many protocols are acknowledgement-based, meaning that they positively acknowledge receipt of messages. The internet's Transmission Control Protocol (TCP) is an example of an acknowledgement-based protocol. When computers communicate via TCP, received packets are acknowledged by sending a return packet with an ACK bit set.[3]

While some protocols send an acknowledgement per each packet received, other protocols such as TCP and ZMODEM allow many packets to be transmitted before sending an acknowledgement for the set of them, a procedure necessary to fill high bandwidth-delay product links with a large number of bytes in flight.

Some protocols are NAK-based, meaning that they only respond to messages if there is a problem. Examples include many reliable multicast protocols which send a NAK when the receiver detects missing packets [4] or protocols that use checksums to verify the integrity of the payload and header.

Still other protocols make use of both NAKs and ACKs. Binary Synchronous Communications (Bisync) and Adaptive Link Rate (for Energy-Efficient Ethernet) are examples.

The acknowledgement function is used in the automatic repeat request (ARQ) function. Acknowledgement frames are numbered in coordination with the frames that have been received and then sent to the transmitter. This allows the transmitter to avoid overflow or underrun at the receiver, and to become aware of any missed frames.

In IBM Binary Synchronous Communications, the NAK is used to indicate that a transmission error was detected in the previously received block and that the receiver is ready to accept retransmission of that block. Bisync does not use a single ACK character but has two control sequences for alternate even/odd block acknowledgement.

ACK and NAK based methodologies are not the only protocol design paradigms. Some protocols such as the RC-5, User Datagram Protocol (UDP), and X10 protocols perform blind transmission with no acknowledgement, often transmitting the same message multiple times in hopes that at least one copy of the message gets through.

Hardware acknowledgement

[edit]

Some computer buses have a dedicated acknowledge wire in the control bus used to acknowledge bus operations: DACK used for ISA DMA; DATACK used in the STEbus, the data transfer acknowledge pin of the Motorola 68000 that inspired the title of DTACK Grounded, etc. Some computer buses do not wait for acknowledgement of every transmission, see for instance posted write.

The I²C serial bus has a time slot for an acknowledgement bit after each byte.[5][6]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Acknowledgement (data networks)

View on Grokipedia
from Grokipedia
In data networks, an acknowledgement (ACK) is a control signal transmitted by a receiving device to a sending device to confirm the successful receipt of a data packet, segment, or . This mechanism forms the basis of reliable data transmission protocols by providing feedback that allows the sender to verify delivery, detect losses or errors, and retransmit unacknowledged data if necessary. Acknowledgements operate primarily through positive confirmation (ACK) or, less commonly, negative acknowledgement (NACK), where the receiver explicitly signals a failure or . In positive ACK systems, the sender relies on the timely arrival of an ACK; its absence within a predefined timeout prompts retransmission, ensuring end-to-end reliability over unreliable physical and link layers. NACKs, by contrast, directly request retransmission of specific erroneous packets, reducing unnecessary traffic but requiring more explicit error detection. The acknowledgement process is integral to various layers of the OSI model, particularly the transport and data link layers. In the Transmission Control Protocol (TCP), defined in RFC 793, each data octet is assigned a sequence number, and the receiver responds with an ACK specifying the next expected sequence number, confirming all prior data via a cumulative mechanism. Extensions like Selective Acknowledgment (SACK), introduced in RFC 2018, enable receivers to acknowledge non-contiguous blocks of data, improving efficiency in high-loss environments. At the , protocols such as (HDLC) employ similar ACKs within frames to manage point-to-point links, while wireless standards like use immediate ACK frames to combat interference and hidden node problems. Beyond reliability, acknowledgements support flow control and congestion control by regulating rates based on receiver capacity and network conditions, as outlined in TCP strategies like those in RFC 813. However, they introduce overhead from extra packets, which optimizations such as delayed ACKs (bunching multiple confirmations) and piggybacking (combining ACKs with ) mitigate to enhance throughput. In contemporary networks, ACK mechanisms continue to evolve, incorporating features like to balance performance and robustness.

Fundamentals

Definition and Purpose

In data networks, an acknowledgement (ACK) serves as a control signal transmitted from the receiver to the sender to confirm the successful and error-free receipt of a unit, such as a frame or packet. Correspondingly, a negative acknowledgement (NAK) is a signal sent by the receiver to indicate that the unit was received with errors, was corrupted, or did not arrive at all, thereby notifying the sender of the need for corrective measures. The fundamental purpose of ACK and NAK mechanisms is to facilitate reliable data transmission across unreliable communication channels, where packet loss, corruption, or delays are common due to factors like noise or congestion. By providing explicit feedback on reception status, these signals enable error recovery through processes like Automatic Repeat reQuest (ARQ), in which the sender retransmits affected data units upon detecting a missing ACK (via timeout) or receiving a NAK. This approach ensures data integrity without requiring the sender to assume successful delivery blindly. Beyond error handling, acknowledgements support flow control by regulating the rate of data transmission to match the receiver's processing capacity, thereby preventing buffer overflows that could lead to further . In layered network protocols, particularly connection-oriented ones, ACK and NAK exchanges synchronize the states between sender and receiver—such as advancing sequence numbers or adjusting window sizes—to maintain ordered delivery and efficient resource utilization. These mechanics establish a foundational prerequisite for robust communication, underscoring why acknowledgements are indispensable in protocols aiming for dependable end-to-end transfer.

Historical Development

The concept of acknowledgement in data networks traces its roots to early practices, where of message receipt was essential for reliable transmission. In the , telegraph operators employed manual error-checking methods, such as repeating messages back to the sender for verification, to mitigate distortions from electrical interference or over long distances. This foundational idea of positive influenced subsequent systems, evolving into formalized control signals in 20th-century . The introduction of the ACK character in the American Standard Code for Information Interchange (ASCII) in 1963 marked a pivotal step, standardizing a binary signal (0x06) for acknowledging successful receipt in digital communications, drawing directly from protocols used in descendants. By the late 1960s, acknowledgement mechanisms appeared in the ARPANET's Network Control Protocol (NCP), implemented in 1970, which utilized stop-and-wait protocols where receivers sent ACK signals to confirm packet delivery, ensuring reliability in the world's first operational packet-switching network. A major milestone came in 1974 with Vinton Cerf and Robert Kahn's seminal paper, which specified the Transmission Control Protocol (TCP) and formalized end-to-end acknowledgements for reliable delivery across heterogeneous packet networks, shifting focus from link-level to transport-layer reliability. In the , IBM's Binary Synchronous Communication (Bisync) protocol, originally announced in 1967 but widely adopted during this decade for mainframe communications, incorporated ACK and NAK signals to manage synchronous blocks, enhancing error detection via cyclic redundancy checks. This period saw a broader evolution from hardware-centric wire signals in buses to software-driven ACKs in emerging IP-based networks, enabling scalable . Further advancements included the 1996 introduction of selective acknowledgements (SACK) in TCP via RFC 2018, allowing receivers to report non-contiguous received blocks and reducing unnecessary retransmissions in high-latency environments. Post-2000 developments adapted ACKs for wireless networks, notably with the IEEE 802.11e standard in 2005, which introduced block ACKs to aggregate confirmations for multiple frames, improving efficiency in contention-based mediums amid rising multimedia traffic.

Signal Types

Positive Acknowledgement (ACK)

Positive acknowledgement (ACK) serves as a confirmation signal from the receiver to the sender, verifying the successful and error-free receipt of transmitted data. In its simplest form, the ACK is encoded as the ASCII control character with hexadecimal value 0x06 (binary 0000 0110), historically used in early data communication protocols to indicate readiness for the next transmission. In contemporary network protocols, such as TCP, the positive ACK is typically implemented as a flag bit within the protocol header, accompanied by an acknowledgement number that specifies the next expected sequence number from the sender, thereby echoing the sequence number of the correctly received data. This encoding enables precise tracking of byte-level progress in data streams. Upon receiving a positive ACK, the sender is permitted to advance to the subsequent transmission, ensuring reliable data flow without retransmission of confirmed segments. This behavior underpins stop-and-wait protocols, where the sender dispatches a single frame and halts until an ACK arrives, and extends to sliding window protocols, which permit multiple outstanding frames within a defined window size, using cumulative ACKs to confirm receipt of contiguous sequences or selective ACKs for non-contiguous ones. Key variations include immediate ACKs, transmitted directly upon data reception to minimize latency, and delayed ACKs, where the receiver postpones sending for a brief interval—typically no more than 500 milliseconds—to coalesce multiple confirmations or piggyback them onto outgoing data, thereby interacting with mechanisms like the Nagle algorithm to mitigate the transmission of small, inefficient packets. Protocol headers often incorporate bit fields to facilitate multi-packet confirmations, allowing a single ACK to validate several segments efficiently. In multicast environments, positive ACK approaches can lead to high protocol overhead due to acknowledgment implosion from numerous receivers sending confirmations, even in low- scenarios; mechanisms like hierarchical aggregation are required to mitigate this. NAK-only schemes are often preferred to reduce feedback by limiting signals to cases.

Negative Acknowledgement (NAK)

A negative acknowledgement, or NAK, is a control signal transmitted by a receiver in networks to indicate that a received block or packet contains errors, such as a (CRC) failure, or has not been received at all due to timeout, thereby requesting retransmission from the sender. This mechanism enables efficient recovery in (ARQ) protocols by prompting selective retransmission of only the problematic segments, reducing unnecessary bandwidth consumption compared to retransmitting all . NAKs originated in early protocols designed for unreliable dial-up connections, notably XMODEM, developed by Ward Christensen in 1977 to facilitate robust data exchange over noisy lines. In XMODEM, the receiver issues a NAK upon detecting a mismatch or after a transmission timeout, initiating retransmission of the specific 128-byte block to ensure without restarting the entire transfer. In basic implementations, such as those using the ASCII character set, a NAK is encoded as the 0x15 (binary 0001 0101), a simple byte that signals non-compliance or without additional payload. More advanced protocols extend this by incorporating structured formats, including codes, numbers of missing packets, or gap reports that detail ranges of lost data to enable precise recovery. For instance, in binary synchronous communication (BSC) protocols, the NAK follows a detected in the received block, while modern variants embed diagnostic information to minimize diagnostic overhead. The behavior of NAKs typically involves the receiver monitoring incoming data for integrity via error-detection schemes like CRC; upon failure or absence within a timeout period, it transmits the NAK to trigger the sender's retransmission logic, often limited to affected packets for efficiency. This contrasts with positive acknowledgements (ACKs), which affirm successful receipt, by focusing solely on error notification to streamline recovery in error-prone environments. Variations in NAK usage include implicit forms, where protocols infer a negative response from transmission timeouts rather than explicit signals, as seen in TCP's reliance on retransmission timers without dedicated NAK packets. Explicit NAKs prove particularly advantageous in reliable scenarios, such as the NACK-Oriented Reliable (NORM) protocol defined in RFC 3940, where they suppress feedback implosions by allowing receivers to report only missing segments, avoiding floods of positive ACKs in group communications and enhancing scalability over networks.

Protocol Usage

Transport Layer Protocols

Transport layer protocols utilize acknowledgements to provide end-to-end reliability over potentially unreliable lower-layer networks, ensuring data delivery, ordering, and error recovery between endpoints. These protocols, operating at OSI layer 4, employ positive acknowledgements (ACKs) to confirm receipt of segments, enabling mechanisms like retransmission timeouts and congestion control. Unlike hop-by-hop acknowledgements in lower layers, transport-layer ACKs span the entire path from source to destination, supporting applications such as web browsing and file transfers. Transmission Control Protocol (TCP), defined in RFC 793, uses an ACK flag in its header to signal acknowledgement of received data. The protocol employs cumulative ACKs, where each acknowledgement indicates the next expected byte in the sequence, effectively confirming all prior bytes in the stream. The ACK number specifies the next expected sequence number (RCV.NXT) at the receiver, confirming receipt of all prior bytes in the stream. This cumulative approach simplifies reliability but can lead to unnecessary retransmissions for out-of-order arrivals. To address this, the Selective Acknowledgment (SACK) extension, introduced in RFC 2018, allows receivers to report multiple disjoint blocks of acknowledged data, enabling selective retransmission of only lost segments. TCP's three-way handshake for connection establishment incorporates SYN-ACK, where the server responds to a client's SYN with a SYN-ACK to synchronize sequence numbers and acknowledge the initial request. QUIC, a modern UDP-based transport protocol standardized in RFC 9000 (2021), integrates acknowledgements directly into its frame structure to reduce latency in web applications. QUIC uses dedicated ACK frames (types 0x02 and 0x03) that acknowledge multiple packet number ranges via a largest acknowledged field followed by gap and range length pairs, allowing efficient reporting of non-contiguous s. These frames include an ACK delay field, encoding the time since packet receipt (in microseconds, scaled by 2 raised to the ack_delay_exponent transport parameter, default 3), which aids precise round-trip time (RTT) estimation and supports low-latency adjustments. Unlike TCP's header-integrated ACKs, QUIC's design minimizes through stream and immediate ACK generation for out-of-order or congestion-marked packets, typically within a default 25 ms max_ack_delay. Stream Control Transmission Protocol (SCTP), specified in RFC 4960, extends acknowledgement capabilities for multi-stream and multi-homed scenarios, such as telephony signaling. SCTP uses Selective Acknowledgment (SACK) chunks that provide association-wide cumulative transmission sequence number (TSN) acknowledgements, with gap blocks for out-of-order data, while maintaining per-stream sequence numbering and ordering for independent delivery. This enables reliable multi-homing, where separate round-trip time (RTT) timers and congestion windows per destination address ensure path failover without disrupting streams. SACKs are sent to the destination of the last received DATA chunk, typically every second packet or within 200 ms, supporting end-to-end reliability across multiple paths. In data link layer protocols, acknowledgements are commonly employed for hop-by-hop error detection and retransmission, contrasting with the end-to-end approach typical in layers. High-Level Data Link Control (HDLC), a bit-oriented protocol standardized in ISO 3309, uses positive acknowledgements (ACKs) and negative acknowledgements (NAKs) within its (ARQ) mechanisms to confirm successful frame reception at the link level. For instance, in HDLC's Selective Repeat mode, receivers send ACKs for correctly received frames and NAKs for errored ones, enabling efficient retransmission of only the affected frames. Binary Synchronous Communication (Bisync), a character-oriented protocol developed by in the , relies on STX (Start of Text) and ETX (End of Text) framing delimiters, with NAKs triggering retransmission of entire blocks upon detection of errors via cyclic redundancy checks (CRC). This design addressed early challenges in synchronous data transmission over noisy lines, where Bisync's explicit NAKs for parity or framing errors ensured reliability in legacy mainframe environments. Unlike modern Ethernet, which operates without native ACKs in its basic frame delivery to prioritize speed in local area networks, protocols layered atop Ethernet such as (PPP) incorporate ACK/NAK exchanges during link establishment and optional checks. PPP's Link Control Protocol (LCP) uses Configure-ACK and Configure-NAK messages to negotiate parameters, while its Network Control Protocol (NCP) variants can extend ACKs for protocol-specific reliability. At the application layer, acknowledgements adapt to specialized needs like file transfers and multicast scenarios. ZMODEM, introduced in the 1980s as an enhancement over earlier modem protocols like XMODEM, batches multiple data blocks and uses delayed ACKs to minimize overhead during asynchronous file transfers, allowing the sender to proceed while awaiting confirmation. In reliable multicast protocols, such as Scalable Reliable Multicast (SRM) defined in RFC 2357, negative acknowledgements (NAKs) are preferred over ACKs to enhance ; receivers send NAKs only for missing packets, reducing feedback implosion in group communications. User Datagram Protocol (UDP), an unreliable transport-layer protocol per RFC 768, typically omits acknowledgements to support low-latency applications, but extensions like (TFTP) in RFC 1350 introduce simple 4-byte ACK packets to confirm block reception in lightweight file exchanges. In wireless networks, IEEE 802.11 () employs block acknowledgements (Block ACKs) at the MAC sublayer to efficiently confirm aggregates of multiple frames, reducing polling overhead in high-throughput scenarios like QoS enhancements.

Hardware Implementation

Dedicated Signals and Buses

In hardware implementations of data networks, dedicated signals and buses provide low-level acknowledgments through specialized wiring and pins, enabling direct electrical confirmation of data receipt or transaction readiness without relying on higher-layer software processing. These signals are typically implemented as active-low lines to enhance noise immunity and facilitate open-drain configurations for multi-device buses, where a low state actively asserts the acknowledgment while the high state is maintained by pull-up resistors. A prominent example is the (ISA) bus, where (DMA) operations utilize dedicated DACK# (DMA Acknowledge) wires. These active-low signals, such as DACK0# through DACK3# and DACK5# through DACK7#, are asserted by the DMA controller to acknowledge a peripheral's DMA request (DRQ) and grant bus access, ensuring synchronized data transfer without CPU intervention. Similarly, the (Inter-Integrated Circuit) protocol incorporates a dedicated acknowledgment mechanism via the ninth clock pulse on the SCL (serial clock) line following each byte transmission. The receiver pulls the SDA (serial data) line low during this clock period to signal an ACK (acknowledgment), or leaves it high for a NAK (negative acknowledgment), confirming receipt or indicating an error such as invalid data. In more advanced bus architectures like (Peripheral Component Interconnect), transaction completion is signaled through deassertion of control lines such as TRDY# (Target Ready) or STOP#, which serve as hardware acknowledgments to the initiator. The target device asserts TRDY# during data phases to confirm readiness and deasserts it upon transfer completion, while STOP# can indicate termination due to retry or disconnect needs, all managed via dedicated pins to maintain bus protocol integrity. In (PCIe), a modern serial bus standard, the employs ACK and NAK Data Link Layer Packets (DLLPs) transmitted over dedicated differential lanes to acknowledge the receipt of Transaction Layer Packets (TLPs), triggering retransmissions via NAK if errors are detected, ensuring end-to-end reliability in high-speed environments. For serial interfaces, USB (Universal Serial Bus) employs ACK packets as handshake responses in the protocol's transaction phases; after the host sends a token packet (e.g., OUT or IN) followed by data, the endpoint device transmits an ACK packet—consisting of a sync field, PID (packet identifier) byte, and end-of-packet signal—to verify successful reception before the next phase. Early parallel interfaces, such as the printer port, relied on a dedicated ACK* pulse for handshaking, where the printer drives this active-low signal (pin 10) for at least 500 ns after processing a byte, informing the host that it is ready for the next data strobe. This hardware-level signaling contrasts with software-emulated acknowledgments in upper protocol layers by using direct pin assertions to achieve minimal propagation delays, often in the nanosecond range for bus .

Performance and Optimization

Hardware acknowledgements in data networks introduce significant latency due to round-trip times (RTT), particularly in hardware buses where the sender must await confirmation before transmitting the next frame, leading to delays in high-latency environments. For instance, in bus systems like PCI or custom interconnects, the delay across the bus exacerbates this RTT, potentially stalling flow and reducing effective throughput. Additionally, ACK signals or packets consume bandwidth; in scenarios with small payloads, this overhead can approach 50% or more of the total traffic, as each ACK requires dedicated transmission resources. In stop-and-wait protocols commonly implemented in hardware, the throughput efficiency is limited by η = Tt / (Tt + 2 Tp + Ta), where Tt is the transmission time of the frame, Tp is the delay, and Ta is the transmission time of the ACK, highlighting how increased delays diminish efficiency. To mitigate these impacts, several optimizations are employed in hardware designs. Piggybacking integrates ACK information into outgoing data frames, such as by reusing header fields in bus protocols, thereby eliminating separate ACK transmissions and reducing bandwidth overhead by up to 50% in bidirectional flows. Delayed ACKs batch multiple confirmations into a single response, further minimizing traffic; this technique, adapted from software protocols, allows hardware controllers to wait for a or threshold before issuing ACKs, improving utilization in bursty traffic. Error detection mechanisms, like cyclic redundancy checks (CRC), are often integrated prior to ACK generation to ensure only valid frames are acknowledged, preventing wasteful retransmissions and enhancing reliability without additional latency. A key trade-off in implementing hardware ACKs is the balance between performance gains and design costs: offloading ACK processing to dedicated hardware, such as network interface controllers (NICs), significantly reduces CPU load by shifting interrupt handling and protocol logic away from the processor, enabling higher throughput in resource-constrained systems. However, this requires additional control wires for ACK signals, increasing wiring complexity, pin counts, and overall interconnect overhead in bus architectures, which can complicate PCB layout and raise manufacturing costs.

References

  1. https://www.techtarget.com/searchnetworking/definition/ACK
  2. https://www.baeldung.com/cs/ack-nack-signals
  3. https://www.noction.com/blog/ack-and-nack-in-networking
  4. https://www.rfc-editor.org/rfc/rfc2018.html
  5. https://www.erg.abdn.ac.uk/users/Gorry/course/dl-pages/hdlc-ack.html
  6. https://jumpcloud.com/it-index/what-is-an-acknowledgment-number
  7. https://datatracker.ietf.org/doc/html/rfc3168
  8. https://book.systemsapproach.org/direct/reliable.html
  9. https://www.sciencedirect.com/topics/computer-science/negative-acknowledgement
  10. https://www.kaspersky.com/blog/telegraph-grandpa-of-internet/9034/
  11. https://www.ascii-code.com/character/%25E2%2590%2586
  12. https://twobithistory.org/2021/03/08/arpanet-protocols.html
  13. https://www.cs.princeton.edu/courses/archive/fall20/cos461/papers/TCPIP74.pdf
  14. https://www.jaredsec.com/bisync/
  15. https://datatracker.ietf.org/doc/rfc2018/
  16. https://www.sciencedirect.com/science/article/abs/pii/S1389128610001015
  17. https://ss64.com/ascii.html
  18. https://datatracker.ietf.org/doc/html/rfc793
  19. https://datatracker.ietf.org/doc/html/rfc5401
  20. https://www.techtarget.com/searchnetworking/definition/NAK
  21. https://www.historyofinformation.com/detail.php?id=4992
  22. https://www.ascii-code.com/character/%25E2%2590%2595
  23. https://www.rfc-editor.org/rfc/rfc3940.html
  24. https://www.geeksforgeeks.org/computer-networks/what-is-nack-negative-acknowledgment/
  25. https://www2.hawaii.edu/~esb/2014fall.ics651/notes3.html
  26. https://datatracker.ietf.org/doc/html/rfc9293
  27. https://datatracker.ietf.org/doc/html/rfc2018
  28. https://datatracker.ietf.org/doc/html/rfc9000
  29. https://datatracker.ietf.org/doc/html/rfc9000#section-19.3
  30. https://datatracker.ietf.org/doc/html/rfc9000#section-13.2
  31. https://datatracker.ietf.org/doc/html/rfc4960
  32. https://datatracker.ietf.org/doc/html/rfc4960#section-6.2
  33. https://electronics.stackexchange.com/questions/60401/why-does-active-low-even-exist
  34. https://www.ti.com/lit/an/slva704/slva704.pdf
  35. https://www.huinck.net/connectors/co_ISA_Tech.html
  36. https://www.ti.com/lit/pdf/slva704
  37. https://www.ics.uci.edu/~harris/ics216/pci/PCI_22.pdf
  38. https://pcisig.com/specifications
  39. https://www.beyondlogic.org/usbnutshell/usb3.shtml
  40. https://www.cs.unc.edu/~porter/courses/comp630/ref/an062_Updating_the_parallel_port.pdf
  41. https://www.geeksforgeeks.org/efficiency-of-stop-and-wait-protocol/
  42. https://www.redhat.com/en/blog/should-i-offload-my-networking-hardware-look-hardware-offloading
  43. https://passat.crhc.illinois.edu/isca05.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.