Mon blog

Tout protocole sur Internet doit gérer la congestion et réagir proprement à celle-ci, sans aggraver le problème par un comportement égoïste. Si ce protocole fonctionne sur TCP, c'est fait automatiquement pour lui. Mais s'il fonctionne sur des protocoles sans notion de connexion, comme UDP, c'est plus complexe. Ce RFC spécifie un mécanisme que les protocoles peuvent utiliser pour assurer un contrôle de congestion compatible avec celui de TCP. Il s'applique aussi bien aux protocoles de la couche transport comme DCCP qu'aux protocoles de la couche application, si la couche transport ne fournit pas de contrôle de congestion.

Il est difficile de demander à chaque application de faire ce contrôle, qui est très complexe. Celles utilisant TCP ou bien DCCP (RFC 4340) voient ce contrôle fait automatiquement pour elles. Le protocole de notre RFC 5348, TFRC, peut être utilisé par DCCP, son principal client (RFC 4342), ou bien par une application utilisant UDP (section 1 du RFC). TFRC n'est d'ailleurs pas un protocole complet, spécifié dans les moindres détails, puisque certains points dépendent du protocole qui l'utilise (le RFC 4342 donne un exemple d'utilisation de TFRC).

Le nom de TFRC vient de son désir d'être « civil » envers TCP lorsqu'un flot de données TCP et un flot de données DCCP sont en compétition sur le même câble. Normalement, chacun des deux flots doit obtenir une part à peu près égale de la capacité disponible. (Un protocole « incivil » enverrait le plus de paquets possible, sans ralentir, malgré la congestion.)

TFRC met en œuvre ses mécanismes chez le récepteur des données (sections 3, 5 et 6). Celui-ci mesure le pourcentage de données perdues et en informe l'émetteur (par des paquets décrits en section 3.2.2), qui devra alors ralentir l'envoi (pour calculer le ralentissement nécessaire, l'émetteur dispose également du RTT, qu'il a mesuré à cette occasion). L'équation exacte est donnée dans la section 3.1 et est très proche de celle dite Reno.

Le contrôle de congestion est un problème complexe, très mathématique, et qui mène facilement à des textes longs, comme ce RFC. Les nombreuses formules qu'il contient sont d'autant plus difficile à lire que, comme tout RFC, il est en texte brut.

La section 4 décrit plus en détail ce que doit faire l'émetteur, notamment s'il ne reçoit pas les paquets d'information du récepteur (l'émetteur doit alors diviser son débit par deux, mesure drastique justifiée par le fait que, si aucun paquet d'information ne passe, c'est probablement que la congestion est sévère).

Notons qu'une variante de TFRC fonctionne avec des mesures du taux de perte de paquets faites par l'émetteur et pas par le récepteur. Elle est décrite en section 7.

TFRC avait été normalisé à ses débuts dans le RFC 3448. La section 9 résume les changements, peu importants. Le principal est que, dans l'ancien RFC, l'émetteur était tenu par le taux d'envoi que lui imposait le récepteur. Si l'émetteur envoyait peu, parce qu'il n'avait pas grand'chose à dire (data limited), le récepteur lui retournait un taux d'envoi faible. Ce problème a été traité.