TCP/IP uses an ACKing system to ensure transfer reliability; when you send your information over the Internet with this protocol, you can be sure that it is received and intact. Specifically, the information is broken up into chunks, which are encapsulated and sent as packets. After each packet (or group of packets) is sent by the sender, the receiver replies with an ACK message to indicate that the packets were received. The packets are numbered sequentially, so the sender can tell if a packet was lost (because he won't have gotten an ACK for that packet), and re-send it.
This is well and good for unicast transmissions, where only one sender is transmitting to only one receiver. However, in the case of multicast transmissions, where one sender may be sending to many receivers, the problem of ACK implosion arises. If one sender is sending the same information to a hundred receivers, he'll be getting back a hundred ACKs for each group of packets! That's a poor use of bandwidth.
One (partial) solution to this problem is the use of NACKing, where a message is sent to the sender by a receiver only when a packet isn't received. Since you expect that far more packets are received than not, the amount of overhead is greatly reduced by NACKing instead of ACKing.