5
3
Is an ACK necessary when using reliable protocols like TCP? How much overhead / throughput penalty does it create?
5
3
Is an ACK necessary when using reliable protocols like TCP? How much overhead / throughput penalty does it create?
25
Yes. the ACKs are the mechanism that makes TCP a reliable protocol.
If ACKs were removed from the protocol, then TCP would no longer know if a packet had been dropped or lost and therefore needed to be re-transmitted.
That would make it more like UDP.
In general this cannot be answered as it depends on the network conditions between the two endpoints.
Clearly the overhead is lowest if there is no packet loss, but if there is significant packet loss then the overhead will be much higher because data is re-transmitted.
5
You asked about "reliable protocols Like TCP/IP"; I'll answer for TCP/IP.
Yes, it is an integral part of TCP/IP. TCP/IP is a sliding window protocol. The ACK allows the receiver to "slide the window," allowing the sender to send more data. Without the ACK, TCP/IP will not send more unacknowledged data than the window size allows.
Without a sliding window, the sender would have to preserve the entire contents of the data stream in case the receiver wanted a re-transmissions of some part of it. The sliding window allows the sender to just keep some small part of the data stream around for possible retransmission.
In a case where the window size is adequate for the network conditions, and the receiver's bandwidth to the sender is not saturated, the ACK (and the sequence number that go with it) should cause no throughput penalty. That is because TCP/IP does not require that a packet be acknowledged before a subsequent packet can be sent. Under favorable conditions, the sender can send without pause while concurrently receiving a stream of ACKs from the receiver.
2If data is flowing both ways, the ACKs are free since the ACK information rides in the same packets as the data. – pedz – 2016-12-24T22:01:25.610
3
An application layer ACK is prefered in order to know that the other end has actually processed the data. The reliability of TCP does not in itself help the application in knowing if the data has actually arrived and been processed by the other end. It is a common misunderstanding that TCP in itself makes communication reliable. Data over TCP connections can be stuck for an arbitrary time in buffers on either the sender's side or the receiver's side and if the connection breaks there is no way for the sender to know how much was processed by the receiver, unless application layer ACKs are used.
The overhead is an extra roundtrip between the parties but if there is constant communication then it doesn't need to add any latency if data is sent in parallel. The bandwidth overhead is quite small, at a minimum the receiver can ACK with a simple 1-byte packet but in more complex cases the ACK-packet may need to be a few tens of bytes.
1Welcome to the site. And thank you for such a good first post. You just saved me the time of writing an answer to address what was missing from the earlier answers. – kasperd – 2016-12-28T23:29:11.857
22Are you talking about application-level acks, or TCP-level acks? – user1686 – 2016-12-24T11:54:20.890
12How does the protocol know if its reliable unless there's confirmation its reliable? – Journeyman Geek – 2016-12-24T11:56:24.680
8It is the ACK that makes it reliable. – user207421 – 2016-12-24T23:44:32.433
The ACK flag uses 1 bit per packet, and is always present in tcp communications as a 0 or 1. So 80,000 packets=roughly 8k. Generally a packet is 1500 bytes, excluding jumbo packets, so 114mb vs 8k. Jumbo packets are 9000 so 686mb vs 8k. – cybernard – 2016-12-25T17:54:29.357