4.3. Mécanismes de Récupération de Perte

Un certain nombre d'algorithmes de récupération de perte qui complètent la retransmission rapide et la récupération rapide ont été proposés par des chercheurs travaillant sur TCP et spécifiés dans la série RFC. Si certains de ces algorithmes reposent sur l'option d'accusé de réception sélectif (SACK) de TCP [RFC2018], tels que [FF96], [MM96a], [MM96b] et [RFC3517], d'autres n'exigent pas de SACK, tels que [Hoe96], [FF96] et [RFC3782]. Les algorithmes non-SACK utilisent des « accusés de réception partiels » (des ACK qui couvrent des données auparavant non acquittées, mais pas toutes les données en suspens au moment où la perte a été détectée) pour déclencher des retransmissions. Bien que ce document ne normalise aucun des algorithmes spécifiques susceptibles d'améliorer la retransmission rapide/récupération rapide, ces algorithmes améliorés sont implicitement autorisés, tant qu'ils suivent les principes généraux des quatre algorithmes de base décrits ci-dessus.

Autrement dit, lorsque la première perte dans une fenêtre de données est détectée, ssthresh DOIT (MUST) être fixé à une valeur ne dépassant pas celle donnée par l'équation (4). Deuxièmement, jusqu'à ce que toutes les pertes dans la fenêtre de données en question soient réparées, le nombre de segments transmis à chaque RTT DOIT (MUST) être au plus égal à la moitié du nombre de segments en suspens au moment où la perte a été détectée. Enfin, après que toutes les pertes dans la fenêtre de segments considérée ont été retransmises avec succès, cwnd DOIT (MUST) être fixé à une valeur ne dépassant pas ssthresh et l'évitement de congestion DOIT (MUST) être utilisé pour augmenter davantage cwnd. Une perte dans deux fenêtres de données successives, ou la perte d'une retransmission, devrait être considérée comme deux indications de congestion et, par conséquent, cwnd (et ssthresh) DOIVENT (MUST) être abaissés deux fois dans ce cas.

Nous RECOMMANDONS (RECOMMEND) que les implémenteurs de TCP emploient une forme de récupération de perte avancée capable de faire face à des pertes multiples dans une fenêtre de données. Les algorithmes détaillés dans [RFC3782] et [RFC3517] sont conformes aux principes généraux décrits ci-dessus. Nous notons que, bien que ce ne soient pas les deux seuls algorithmes conformes aux principes généraux ci-dessus, ces deux algorithmes ont été examinés par la communauté et sont actuellement sur la voie de normalisation (Standards Track).