Reliable UDP and ACK method question

Question

I am reading about implementations of reliable UDP (ie. sending ACK packets and resending non-ACKed packets again).

Of the two main patterns I seem to find arround the net:

1. Client sends an ACK for each received packet with the sequence of that packet. Server assumes packet is undelivered unless it receives an ACK.

2. Client sends an ACK packet with the sequences of the packets it thinks are missing. Server assumes packet is delivered unless it receives an ACK from the client saying it's missing a sequence, then it resends the requested (missing) packets again.

In short, in 1. the clients sends the sequence of the received packets, while in 2. client sends the sequence of the missing packets.

Just wondering what are the pros/cons of each method, and which one is more mainstream (I assume 1, but 2 seems like a very clever method since assumably most packets do arrive and only a few are usually lost).

EDIT: A short example on both methods:

Method 1: Server sends: 1,2,3,4,5 
Client received: 1,3,5,4 
Client sends back: ACK 1, ACK 3, ACK 5, ACK 4  
Server resends: 2.. maybe more if ACK packets were lost


Method 2:
Server sends 1,2,3,4,5,6,7,8
Client receives: 1,3,2,5,7
Client Sends :ACK (lowest continuous 3,highest received 7,  seem to be missing 4,6)
Server resends: 4,6,8

Throes

So what if in method two, the clients ack packet that says it is missing something is never delivered? – Curate

From what I understand, in method 2 there is an ACK saying 'no missing packets here(and highest received seq is 532)'... so if server sends 1 packet and no ACK is recevied then that packet is resent.Also, the ACK packets in method 2 are usually send periodically.. acting much like a ping I guess – Throes

Then could you perhaps clarify a bit more regarding the differences? So method 1 acks packets explicitly, whenever a new seq no is reached (thus could be an ack for more than one packet) and method 2 acks packets periodically instead and never explicitly? – Curate

No, method 1 sends an ACK for EACH received packet. no other logic is embedded. Method 2 sends an ACK periodically and embedds a logic to provide some kind of transmision window: I have all packets until sequence 40, and I seem to be missing packets 41,45 and 47. (or: I have all packets to sequence 56 , no missing packets) – Throes

Answer 1

#2 is also known as Negative ACK, aka NAK, it is an optimistic viewpoint of a transport. That means is scales better when the transport is functioning correctly.

#1 is a pessimistic viewpoint and assumes a transport will frequently fail.

TCP uses ACKs because there is fundamental dependency on congestion control to drop packets to perform traffic shaping to create a fair network. Reliable UDP channels typically use NAKs because you are using a reliable high speed medium or low rate stream with requirement for low latency over the lock step typical of a basic ACK implementation.

Note if you rise a step higher and look at say subscription management above a reliable UDP channel there is no clear winner for ACK or NAK usage. The market data world has proven usage of both technologies at high speed on high capacity networks. ACKs have the benefit, with subscriptions, that you don't need a complicated re-synchronisation after a network fault, however you will see a consistent peak of network and CPU usage when every host issues a re-subscription.

Levitation