PLI
Also written Picture Loss Indication, a=rtcp-fb:nack pli, keyframe request
A receiver saying it can no longer decode and needs a fresh keyframe. Cheap to send, expensive to answer.
When a decoder loses enough of a reference frame that everything after it is garbage, no amount of retransmission helps. It needs the sender to start over with a keyframe. PLI is the message that asks, and it carries nothing but the SSRC in question.
A keyframe is many times the size of a delta frame, so answering a PLI puts a spike into a link that is often already the reason the packets went missing. Do that during congestion and you get the classic loop: loss causes a PLI, the PLI causes a spike, the spike causes more loss.
This bites hardest on a forwarding server. Every viewer who joins, switches layer, or drops a packet asks the one sender for a keyframe, and the sender has no idea how many people are behind that request. Servers therefore rate limit PLIs rather than passing them straight through.
FIR (RFC 5104) asks for the same thing for a different reason, a new participant needing a decodable starting point rather than an existing one recovering from loss.