Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics

Date de publication du RFC : Juillet 2001
Auteur(s) du RFC : M. Mathis (Pittsburgh supercomputing center), M. Allman (BBN/NASA)
Pour information
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 8 février 2009


Parmi les différentes métriques qu'on peut définir sur l'Internet, une est particulièrement intéressante pour les utilisateurs, c'est le débit possible lors d'un transfert de fichiers. Si l'administrateur système tend à regarder plutôt le RTT avec ping, l'utilisateur préférerait savoir le temps qu'il lui reste avant l'arrivée des copies de la dernière saison de Desperate Housewives. D'où la définition formelle de ce débit, dans ce RFC.

Bulk Transfer Capacity (Capacité de Transfert en Gros) est donc définie comme la capacité du réseau à transporter des données en quantité importante lors d'une seule connexion (typiquement TCP). Il s'agit des données utiles, excluant les en-têtes des paquets, et intégrant la retransmission de données en cas de perte de paquets. La section 1 dit que la BTC peut tout simplement être définie comme la division de la quantité de données effectivement transmise par le temps écoulé. C'est typiquement elle qu'affichent des outils comme ncftp ou netpipe.

Toute implémentation de TCP, ou d'un protocole équivalent, devrait donc, dans le cas idéal, afficher la même BTC, puisque tous doivent suivre les mêmes principes de contrôle de la congestion (RFC 5681). Ce n'est pas forcément le cas en pratique, certaines mises en œuvre de TCP affichant des résultats non-linéaires dans certaines plages de fonctionnement.

La question des algorithmes utilisés en cas de congestion est détaillée en section 2. Les définitions habituelles de ces algorithmes laissent pas mal de latitude au programmeur qui les met en œuvre et la définition d'une métrique nécessite donc de rajouter quelques contraintes. Par exemple, en cas d'utilisation d'algorithmes « avancés » comme NewReno (RFC 2582), ceux-ci doivent être complètement spécifiés dans la définition de la métrique. Même chose avec les détails de l'algorithme de retransmission (RFC 2988).

La section 3 couvre ensuite certaines métriques secondaires qui peuvent aider à comprendre le comportement du réseau. Par exemple 3.6 explique la séparation entre le chemin aller et le chemin retour, beaucoup de liens sur Internet étant asymétriques.


Téléchargez le RFC 3148

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)