12. Retransmission Scheduling (Planification de retransmission)
Les protocoles de transport tels que TCP et QUIC fournissent une fiabilité en détectant la perte de paquets et en retransmettant les informations perdues. Au-delà des considérations de la Section 10, la planification des données retransmises peut entrer en concurrence avec les nouvelles données. Le reste de cette section traite des considérations lors de l'utilisation de QUIC.
La Section 13.3 de [QUIC] stipule : "Un point de terminaison devrait (SHOULD) donner la priorité à la retransmission de données sur l'envoi de nouvelles données, à moins que les priorités spécifiées par l'application n'indiquent le contraire." Lorsqu'une application HTTP/3 utilise le schéma de priorité défini dans ce document et que l'implémentation du transport QUIC prend en charge la priorité de flux indiquée par l'application, un transport qui considère la priorité relative des flux lors de la planification à la fois des nouvelles données et des données retransmises pourrait mieux correspondre aux attentes de l'application. Cependant, il n'y a aucune exigence quant à la façon dont le transport choisit une planification basée sur ces informations, car la décision dépend de plusieurs facteurs et compromis. Il pourrait prioriser les nouvelles données des flux de haute urgence sur les données retransmises des flux de faible priorité, ou il pourrait prioriser les données retransmises sur les nouvelles données indépendamment de l'urgence.
La Section 6.2.4 de [QUIC-RECOVERY] met également en évidence les considérations sur la priorité d'application lors de l'envoi de paquets de sonde après l'expiration d'un temporisateur de délai d'attente de sonde. Les implémentations QUIC qui prennent en charge la priorité indiquée par l'application peuvent utiliser la priorité relative des flux lors du choix des données de sonde.