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 () voient ce
contrôle fait automatiquement pour elles. Le protocole de notre , TFRC, peut être utilisé par DCCP, son principal client (),
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 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 . 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é.