6.3. Demandes de retransmission
Le format de message de retour NACK défini dans le profil AVPF SHOULD être utilisé par les récepteurs pour envoyer des demandes de retransmission. Qu'un récepteur choisisse ou non de demander un paquet relève de l'implémentation. Une implémentation réelle de récepteur devrait tenir compte de facteurs tels que le délai tolérable par l'application, l'environnement réseau et le type de média.
Le récepteur devrait en général évaluer si le paquet retransmis serait encore utile au moment où il est reçu. L'horodatage du paquet manquant peut être estimé à partir des horodatages des paquets précédant et/ou suivant la discontinuité de numéro de séquence causée par le paquet manquant dans le flux d'origine. Dans la plupart des cas, une forme d'estimation linéaire de l'horodatage suffit.
En outre, un récepteur devrait calculer une estimation du temps aller-retour (RTT) vers l'émetteur. Cela peut se faire, par exemple, en mesurant le délai de retransmission pour recevoir un paquet de retransmission après qu'un NACK a été envoyé pour ce paquet. Cette estimation peut aussi être obtenue à partir d'observations passées, du temps aller-retour des rapports RTCP s'il est disponible, ou par tout autre moyen. Un mécanisme normalisé pour que le récepteur estime le RTT est spécifié dans « RTP Control Protocol Extended Reports (RTCP XR) » [11].
Le récepteur ne devrait pas envoyer une demande de retransmission dès qu'il détecte un numéro de séquence manquant mais devrait ajouter un délai supplémentaire pour compenser le réordonnancement des paquets. Ce délai supplémentaire peut, par exemple, reposer sur des observations passées du réordonnancement de paquets constaté. Il convient de noter que, dans les environnements où le réordonnancement des paquets est rare ou n'a pas lieu, par exemple si la couche liaison de données sous-jacente assure une livraison ordonnée, le délai peut être extrêmement faible ou même nul. Dans de tels cas, un algorithme approprié de « délai de réordonnancement » peut ne pas être fondé sur une minuterie mais sur les paquets. Par exemple, si n paquets sont reçus après la détection d'une discontinuité, on peut supposer que le paquet a été réellement perdu plutôt que hors ordre. Cela peut s'avérer bien plus simple à coder sur certaines plateformes qu'un mécanisme à minuterie, par exemple via une mémoire tampon FIFO de paquets de taille fixe très courte.
Pour accroître la robustesse à la perte d'un NACK ou d'un paquet de retransmission, un récepteur peut envoyer un nouveau NACK pour le même paquet. On parle alors de retransmissions multiples. Avant d'envoyer un nouveau NACK pour un paquet manquant, le récepteur devrait s'appuyer sur une minuterie pour être raisonnablement sûr que la tentative de retransmission précédente a échoué et ainsi éviter des retransmissions inutiles. La valeur de la minuterie doit reposer sur le temps aller-retour observé. Une valeur statique ou adaptative MAY être utilisée. Par exemple, une minuterie adaptative pourrait être une minuterie dont la valeur change à chaque nouvelle demande pour le même paquet. Le présent document ne fournit aucune ligne directrice sur le calcul de cette valeur adaptative car aucune expérience n'a été menée pour le déterminer.
Les NACK MUST être envoyés uniquement pour le flux RTP d'origine. Sinon, si un récepteur voulait effectuer des retransmissions multiples en envoyant un NACK dans le flux de retransmission, il ne pourrait pas connaître le numéro de séquence d'origine ni l'estimation d'horodatage du paquet demandé.
L'annexe A donne quelques lignes directrices sur la façon de contrôler le nombre de retransmissions.