Groupe de travail Réseau	S. Floyd, ICIR	
Request for Comments : 4342	E. Kohler, UCLA	
Catégorie : Sur la voie de la normalisation	J. Padhye, Microsoft Research	
Mise à jour par la RFC5348	mars 2006	
Traduction Claude Brière de L'Isle		

Profil d'identifiant 3 de protocole de contrôle d'encombrement de datagrammes (DCCP) : contrôle de débit favorable à TCP (TFRC)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Ce document contient le profil pour l'identifiant 3 de contrôle d'encombrement, contrôle de débit favorable à TCP (TFRC, TCP-Friendly Rate Control), dans le protocole de contrôle d'encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol). CCID 3 devrait être utilisé par les envoyeurs qui veulent un taux d'envoi favorable à TCP, éventuellement avec la notification explicite d'encombrement (ECN, Explicit Congestion Notification) tout en minimisant les changements abrupts de débit.
Table des matières
1. Introduction	2
2. Conventions	2
3. Usage	2
3.1 Relations avec TFRC	3
3.2 Exemple de demie connexion 	3
4. Établissement de connexion	3
5. Contrôle d'encombrement sur les paquets de données	3
5.1 Réponse aux périodes de repos et d'application limitée	4
5.2 Réponse aux données éliminées et au receveur lent	5
5.3 Tailles de paquet	5
6. Accusés de réception	6
6.1 Définition d'intervalle de perte	6
6.2 Contrôle d'encombrement sur les intervalles de perte	8
6.3 Accusés de réception des accusés de réception	8
6.4 Détermination du repos	8
7. Notification explicite d'encombrement	8
8. Options et caractéristiques	8
8.1 Valeur de compteur de fenêtre	9
8.2 Options de temps écoulé 	10
8.3 Option de taux de réception	10
8.4 Caractéristique de taux d'événement de perte à l'envoi	10
8.5 Option Taux d'événement de perte	11
8.6. Option Intervalles de perte	11
9. Vérification de la conformité du contrôle d'encombrement à ECN	13
9.1 Vérification de l'écho de nom occasionnel ECN	13
9.2 Vérification des intervalles de perte et du taux d'événements de perte rapportés	14
10. Questions de mise en œuvre	14
10.1 Usage de l'horodatage	14
10.2 Détermination des événements de perte chez le receveur	14
10.3 Envoi de paquets de rétroaction	15
11. Considérations sur la sécurité	16
12. Considérations relatives à l'IANA	16
12.1 Codes de réinitialisation	16
12.2 Types d'option	17
12.3 Numéros de caractéristique	17
13. Remerciements	17
Appendice A. Changements futurs possibles à CCID 3	17
Références normatives	18
Références pour information	18
Adresse des auteurs	18
Déclaration complète de droits de reproduction	18

 	1.	Introduction

Le présent document contient le profil pour l'identifiant 3 de contrôle d'encombrement, contrôle de débit favorable à TCP (TFRC, TCP-Friendly Rate Control) dans le protocole de contrôle d'encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol) [RFC4340]. DCCP utilise des identifiants de contrôle d'encombrement (CCID, Congestion Control Identifier) pour spécifier le mécanisme de contrôle d'encombrement utilisé sur une demie connexion.

TFRC est un mécanisme de contrôle d'encombrement fondé sur le receveur qui fournit un taux d'envoi favorable à TCP tout en minimisant la caractéristique de changements abrupts de débit du contrôle d'encombrement de TCP ou de style TCP [RFC3448]. Le taux d'envoi permis à l'envoyeur est réglé en réponse au taux d'événements de perte, qui est normalement rapporté par le receveur à l'envoyeur. Voir à la Section 3 les exigences d'application.

 	2.	Conventions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Toutes les quantités numériques multi octets dans CCID 3, comme les arguments à des options, sont transmises dans l'ordre des octets du réseau (octet de poids fort en premier).

Une demie connexion DCCP consiste en l'envoi des données d'application par un point d'extrémité et en les accusés de réception correspondants envoyés par l'autre point d'extrémité. Les termes "envoyeur HC" et "receveur HC" notent les points d'extrémité qui envoient respectivement les données d'application et les accusés de réception. Comme les CCID s'appliquent au niveau des demies connexions, on abrège envoyeur HC en "envoyeur" et receveur HC en "receveur" dans ce document. Voir plus d'explications dans la [RFC4340].

Pour simplifier, on dit que les envoyeurs envoient des paquets de données DCCP et que les receveurs envoient des paquets DCCP-Ack. Ces deux catégories sont destinées à inclure les paquets DCCP-DataAck.

Les phrases "marqué ECN" et "marqué" se réfèrent aux paquets marqués "encombrement ECN rencontré" sauf mention contraire.

Le présent document utilise un certain nombre de variables provenant de la [RFC3448], incluant ce qui suit :
X_recv : taux de réception en octets par seconde. Voir le paragraphe 3.2.2 de la [RFC3448].
s : taille de paquet en octets. Voir le paragraphe 3.1 de la [RFC3448].
p : taux d'événements de perte. Voir le paragraphe 3.1 de la [RFC3448].

 	3.	Usage

Le contrôle d'encombrement TFRC de CCID 3 est approprié pour les flux qui préféreraient minimiser les changements abrupts du taux d'envoi, incluant des applications de supports en direct avec des capacités faibles ou modérées de mémoire tampon de receveur avant l'exécution. Le contrôle d'encombrement de style TCP, comme celui du CCID 2 de DCCP [RFC4341], diminue par deux le taux d'envoi en réponse à chaque événement d'encombrement et ne peut donc pas fournir un taux d'envoi relativement lissé.

Comme expliqué à la Section 1 de la [RFC3448], la contrepartie d'avoir un débit plus lissé qu'avec TCP tout en ayant une compétition équitable pour la bande passante avec TCP est que le mécanisme TFRC dans CCID 3 répond plus lentement aux changements de la bande passante disponible que ne le font les mécanismes de TCP ou de style TCP. Donc, CCID 3 devrait n'être utilisé que pour les applications qui ont une exigence de débit lissé. Pour les applications qui ont simplement besoin de transférer autant de données que possible dans le plus court délai possible, on recommande d'utiliser un contrôle d'encombrement de style TCP, comme CCID 2.

CCID 3 ne devrait aussi pas être utilisé par les applications qui changent leur taux d'envoi en faisant varier la taille de paquet, plutôt que le taux d'envoi des paquets. Un nouveau CCID va être exigé pour ces applications.

 	3.1	Relations avec TFRC
Les mécanismes de contrôle d'encombrement décrits ici suivent le mécanisme TFRC normalisé par l'IETF [RFC3448]. Les mises en œuvre conformes à CCID 3 PEUVENT retracer directement les mises à jour de l'équation de débit TCP, car les mises à jour sont normalisées par l'IETF, plutôt que d'attendre des révisions du présent document. Cependant, les mises en œuvre conformes DEVRAIENT attendre des mises à jour explicites à CCID 3 avant de mettre en œuvre d'autres changements au contrôle d'encombrement TFRC.

 	3.2	Exemple de demie connexion 
Cet exemple montre les progrès normaux d'une demie connexion utilisant le contrôle d'encombrement TFRC de CCID 3, non inclus l'initiation et la terminaison de connexion. L'exemple est pour information, et n'est pas normatif.

1.	L'envoyeur transmet des paquets DCCP-Data. Son taux d'envoi est gouverné par le taux d'émission permis comme spécifié au paragraphe 3.2 de la [RFC3448]. Chaque paquet DCCP-Data a un numéro de séquence et le champ d'en-tête CCVal de DCCP contient la valeur du compteur de fenêtre, qui est utilisée par le receveur pour déterminer quand plusieurs pertes appartiennent à un seul événement de perte.
Dans le cas normal d'une demie-connexion à capacité ECN, chaque paquet DCCP-Data et DCCP-DataAck est envoyé comme à capacité ECN, avec le codet ECT(0) ou ECT(1) établi. L'utilisation du nom occasionnel ECN avec TFRC est décrit à la Section 9.

2.	Le receveur envoie des paquets DCCP-Ack qui accusent réception des paquets de données au moins une fois par délai d'aller-retour, sauf si l'envoyeur envoie à un débit inférieur à un paquet par délai d'aller-retour, comme indiqué par la spécification TFRC ([RFC3448], Section 6). Chaque paquet DCCP-Ack utilise un numéro de séquence, identifie le plus récent paquet reçu de l'envoyeur, et inclut des rétroactions sur les récents intervalles de perte subis par le receveur.

3.	L'envoyeur continue d'envoyer des paquets DCCP-Data sous le contrôle du taux de transmission permis. À réception des paquets DCCP-Ack, l'envoyeur met à jour son taux de transmission permis comme spécifié au paragraphe 4.3 de la [RFC3448]. Cette mise à jour se fonde sur un taux d'événement de perte calculé par l'envoyeur en utilisant les rétroactions d'intervalles de perte du receveur. Si il le préfère, l'envoyeur peut aussi utiliser un taux d'événement de perte calculé et rapporté par le receveur.

4.	L'envoyeur estime les délais d'aller-retour et calcule un temps de non rétroaction, comme spécifié au paragraphe 4 de la [RFC3448]. Si aucune rétroaction n'est reçue du receveur dans ce délai (au moins quatre délais d'aller-retour) l'envoyeur divise par deux son taux d'envoi.

 	4.	Établissement de connexion

Le client initie la connexion en utilisant les mécanismes décrits dans la spécification DCCP [RFC4340]. Durant ou après la  négociation CCID 3, le client et/ou serveur peut vouloir négocier les valeurs du vecteur d'envoi d'accusés de réception et les caractéristiques de taux d'envoi des événements de perte.

 	5.	Contrôle d'encombrement sur les paquets de données

CCID 3 utilise les mécanismes de contrôle d'encombrement de TFRC [RFC3448]. L'exposé qui suit résume les informations de la [RFC3448], qui devraient être considérées comme normatives sauf mention spécifique contraire.

Taux d'événement de perte : opération de base de CCID 3 centrée sur le calcul du taux d'événements de perte : le nombre d'événements de perte comme fraction du nombre de paquets transmis, pondéré sur les derniers intervalles de perte. Ce taux d'événements de perte, une estimation du délai d'aller-retour, et la taille moyenne de paquet sont entrés dans l'équation de débit TCP, comme spécifié au paragraphe 3.1 de la [RFC3448]. Le résultat est un taux de transmission équitable proche de ce qu'un TCP moderne réaliserait dans les mêmes conditions. Les envoyeurs CCID 3 sont limités à ce taux équitable.

Le taux d'événements de perte lui-même est calculé dans CCID 3 en utilisant les longueurs récentes d'intervalle de perte rapportées par le receveur. Les intervalles de perte sont précisément définis au paragraphe 6.1. En résumé, un intervalle de perte est jusqu'à un RTT de paquets de données éventuellement perdus ou marqués ECN, suivi par un nombre arbitraire de paquets de donnés non éliminés, non marqués. Donc, de longs intervalles de perte représentent de faibles taux d'encombrement. L'option CCID 3 Intervalles de perte est utilisée pour rapporter les longueurs des intervalles de perte ; voir le paragraphe 8.6.

Autres mécanismes de contrôle d'encombrement : l'envoyeur commence par une phase de démarrage lent, doublant en gros son taux d'envoi permis à chaque délai d'aller-retour. La phase de démarrage lent se termine par le rapport du receveur d'un abandon ou marquage de paquet de données, après quoi l'envoyeur utilise le taux d'événements de perte pour calculer son taux d'envoi permis.

La Section 4 de la [RFC3448] spécifie un taux d'envoi initial d'un paquet par délai d'aller-retour (RTT) comme suit : l'envoyeur initialise le taux d'envoi permis à un paquet par seconde. Sitôt qu'un paquet de rétroaction est reçu du receveur, l'envoyeur a une mesure du délai d'aller-retour et il règle alors le taux d'envoi initial permis à un paquet par RTT. Cependant, bien que la fenêtre TCP initiale utilisée soit de un segment, la [RFC2581] permet une fenêtre TCP initiale de deux segments, et la [RFC3390] permet une fenêtre TCP initiale de trois ou quatre segments (jusqu'à 4380 octets). La [RFC3390] fixe une limite supérieure à la fenêtre initiale de min(4*MSS, max(2*MSS, 4380 octets)).

Donc, à la différence de la [RFC3448], il est permis au taux d'envoi initial CCID 3 d'être au moins de deux paquets par RTT, et au plus de quatre paquets par RTT, selon la taille de paquet. Il est seulement permis au taux initial d'être de trois ou quatre paquets par RTT quand, en termes de taille de segment, cela traduit au plus 4380 octets par RTT.

La mesure par l'envoyeur du délai d'aller-retour utilise l'option Temps écoulé et/ou Écho d'horodatage contenue dans des paquets de rétroaction, comme décrit au paragraphe 8.2. L'option Temps écoulé est exigée, tandis que l'option Écho d'horodatage ne l'est pas. L'envoyeur tient un délai d'aller-retour moyen pondéré par les mesures les plus récentes.

Chaque paquet DCCP-Data contient un numéro de séquence. Chaque paquet DCCP-Data contient aussi une valeur de compteur de fenêtre, comme décrit au paragraphe 8.1. Le compteur de fenêtre est généralement incrémenté de un à chaque quart de délai d'aller-retour. Le receveur l'utilise comme un horodatage grossier pour déterminer quand une perte de paquet devrait être considérée comme faisant partie d'un intervalle de perte existant et quand il doit commencer un nouvel intervalle de perte.

Comme TFRC est fondé sur le taux d'envoi au lieu de se fonder sur la fenêtre, et parce que les paquets de rétroaction peuvent être éliminés dans le réseau, l'envoyeur a besoin d'un mécanisme pour réduire son taux d'envoi en l'absence de rétroaction positive du receveur. Comme décrit à la Section 6, le receveur envoie des paquets de rétroaction en gros une fois par délai d'aller-retour. Comme spécifié au paragraphe 4.3 de la [RFC3448], l'envoyeur règle un temporisateur de non rétroaction à au moins quatre délais d'aller-retour, ou deux fois l'intervalle entre les paquets de données, selon celui qui est le plus grand. Si l'envoyeur n'a pas reçu de paquet de rétroaction du receveur quand le temporisateur de non rétroaction expire, l'envoyeur divise alors par deux son taux d'envoi permis. Le taux d'envoi permis n'est jamais réduit en dessous de un paquet par 64 secondes. Noter que tous les accusés de réception ne sont pas considérés être des paquets de rétroaction, car les paquets de rétroaction doivent contenir des options valides Intervalles de perte, Temps écoulé, et Taux de réception.

Si l'envoyeur ne reçoit pas de paquet de rétroaction du receveur, et par conséquent ne peut jamais régler le taux d'envoi permis à un paquet par RTT, alors le taux d'envoi est laissé à son taux initial de un paquet par seconde, avec le temporisateur de non rétroaction qui expire après deux secondes. Le taux d'envoi permis est divisé par deux chaque fois que le temporisateur de non rétroaction expire. Donc, si aucune rétroaction n'est reçue du receveur, le taux d'envoi permis n'est jamais au dessus de un paquet par seconde et est rapidement réduit en dessous de un paquet par seconde.

Les paquets de rétroaction provenant du receveur contiennent une option Taux de réception qui spécifie le taux auquel les paquets de données sont arrivés chez le receveur depuis le dernier paquet de rétroaction. Le taux d'envoi permis peut être au plus deux fois le taux reçu chez le receveur dans le dernier délai d'aller-retour. Cela peut être moins que le taux équitable nominal si, par exemple, l'application envoie moins que sa part équitable.

 	5.1	Réponse aux périodes de repos et d'application limitée
Une conséquence du temporisateur de non rétroaction est que l'envoyeur réduit le taux d'envoi permis quand l'envoyeur a été inactif pendant une période significative. Au paragraphe 4.4 de la [RFC3448], le taux d'envoi permis n'est jamais réduit à moins de deux paquets par délai d'aller-retour par suite d'une période de repos. CCID 3 révise cela pour prendre en compte la plus grande fenêtre initiale permise par la [RFC3390] : le taux d'envoi permis n'est jamais réduit à moins du taux d'envoi initial de la [RFC3390] par suite d'une période de repos. Si le taux d'envoi permis est moins que le taux d'envoi initial à l'entrée de la période de repos, alors il va encore être moins que le taux d'envoi initial quand la période de repos est terminée. Cependant, si le taux d'envoi permis est supérieur ou égal au taux d'envoi initial à l'entrée de la période de repos, il ne devrait alors pas être réduit en dessous du taux d'envoi initial quelle que soit la durée de la période de repos. Le taux d'envoi permis de l'envoyeur est limité à au plus deux fois le taux de réception rapporté par le receveur. Donc, après une période d'application limitée, l'envoyeur peut au plus doubler son taux d'envoi d'un délai d'aller-retour au suivant, jusqu'à ce qu'il atteigne le taux d'envoi permis déterminé par le taux d'événements de perte.

 	5.2	Réponse aux données éliminées et au receveur lent
L'option DCCP Données éliminées permet à un receveur de déclarer qu'un paquet a été éliminé à l'hôte d'extrémité avant la livraison à l'application -- par exemple, à cause de corruption ou de débordement de la mémoire tampon de réception. Son option Receveur lent permet au receveur de déclarer qu'il a des problèmes pour soutenir le rythme d'envoi des paquets de l'envoyeur, bien que rien n'ait encore été éliminé. Les envoyeurs CCID 3 répondent à ces options comme décrit dans la [RFC4340], avec les précisions suivantes.

o	Code d'élimination 2 ("élimination par la mémoire tampon de réception"). Le taux d'envoi permis est réduit d'un paquet par RTT pour chaque paquet nouvellement acquitté comme Code d'élimination 2, sauf qu'il n'est jamais réduit en dessous de un paquet par RTT par suite du code d'élimination 2.

o	Ajustement du taux de réception X_recv. Un envoyeur CCID 3 DEVRAIT aussi répondre aux événements de non encombrement de réseau, comme ceux impliqués par les options Données éliminées et Receveur lent, en ajustant X_recv, le taux de réception rapporté par le receveur dans les options Taux de réception (voir au paragraphe 8.3). Le taux d'envoi permis des envoyeurs CCID 3 est limité à au plus deux fois le taux de réception rapporté par le receveur via la clause "min(..., 2*X_recv)" dans les calculs de débit de TFRC (paragraphe 4.3 de la [RFC3448]). Quand l'envoyeur reçoit une ou plusieurs options Données éliminées et Receveur lent, l'envoyeur ajuste X_recv comme suit :

1.	X_inrecv est égal au taux de réception en octets par seconde rapporté par le receveur dans les plus récents accusés de réception.

 2.	X_drop est réglé à la limite supérieure du taux d'envoi impliquée par les options Données éliminées et Receveur lent. Si l'envoyeur reçoit une option Receveur lent, qui demande que l'envoyeur n'augmente pas son taux d'envoi pendant en gros un délai d'aller-retour [RFC4340], alors X_drop devrait être réglé à X_inrecv. De même, si l'envoyeur reçoit une option Données éliminées qui indique, par exemple, que trois paquets ont été éliminés avec le code d'élimination 2, alors la limite supérieure du taux d'envoi va être diminuée d'au plus trois paquets par RTT par l'envoyeur en réglant X_drop à max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)).
Là encore, s est la taille de paquet en octets.

3.	X_recv est alors réglé à min(X_inrecv, X_drop/2).

Par suite, le taux d'envoi du prochain délai d'aller-retour va être limité à au plus 2*(X_drop/2) = X_drop. Les effets des options Données éliminées et Receveur lent sur X_recv vont pour la plupart disparaître dans le délai d'aller-retour après cela, ce qui est approprié pour cette rétroaction de non encombrement de réseau. Cette procédure DOIT n'être utilisée que pour les codes d'élimination qui n'ont pas de rapport à la corruption (voir la [RFC4340]). Actuellement, ceci est limité aux codes d'élimination 0, 1, et 2.

 	5.3	Tailles de paquet
CCID 3 est destiné aux applications qui utilisent une taille de paquet fixe, et qui font varier leur taux d'envoi en paquets par seconde en réponse à l'encombrement. CCID 3 n'est pas approprié pour les applications qui exigent un intervalle de temps fixe entre les paquets et font varier la taille des paquets plutôt que le taux de paquets en réponse à l'encombrement. Cependant, une certaine attention devraient être nécessaire pour les applications utilisant CCID 3 qui font varier leur taille de paquet non en réponse à l'encombrement mais en réponse à d'autres exigences de niveau application.

La taille de paquet s est utilisée dans l'équation de débit TCP. Une mise en œuvre de CCID 3 PEUT calculer s comme la taille de segment moyenne sur plusieurs temps d'aller-retour -- par exemple, sur les quatre plus récents intervalles de perte, pour les intervalles de perte comme définis au paragraphe 6.1. Autrement, une mise en œuvre de CCID 3 PEUT utiliser la taille maximum de paquet Size pour déduire s. Dans ce cas, s est réglé à la taille maximum de segment (MSS, Maximum Segment Size) la taille maximum en octets pour le segment de données, non inclus les en-têtes de paquet par défault DCCP et IP. Chaque paquet transmis compte alors comme une MSS, sans considération de la taille réelle de segment, et l'équation de débit TCP peut être interprétée comme spécifiant le taux d'envoi en paquets par seconde.

Les mise en œuvre de CCID 3 PEUVENT vérifier les applications qui paraissent manipuler la taille de paquet de façon inappropriée. Par exemple, une application pourrait envoyer de petits paquets pendant un moment, de façon à construire un taux rapide, puis passer à de gros paquets pour tirer parti du taux d'envoi rapide. (Des simulations préliminaires indiquent que les applications peuvent n'être pas capables d'augmenter de cette façon leurs taux de transferts globaux, de sorte qu'il n'est pas clair que cette manipulation puisse apparaître en pratique [V03].)

 	6.	Accusés de réception

Le receveur envoie un paquet de rétroaction à l'envoyeur en gros une fois par délai d'aller-retour, si l'envoyeur envoie les paquets à cette fréquence. Ce taux est déterminé par le protocole TFRC comme spécifié à la Section 6 de la [RFC3448].

Chaque paquet de rétroaction contient un numéro d'accusé de réception, qui est égal au plus grand numéro de séquence valide reçu jusqu'alors sur cette connexion. ("Plus grand" est, bien sûr, mesuré dans un espace de numéros de séquence circulaire.) Chaque paquet de rétroaction inclut aussi au moins les options suivantes :

1.	Une option Temps écoulé et/ou Écho d'horodatage qui spécifie le temps écoulé depuis l'arrivée chez le receveur du paquet dont le numéro de séquence apparaît dans le champ Numéro d'accusé de réception. Ces options sont décrites à la Section 13 de la [RFC4340].

2.	Une option Taux de réception, définie au paragraphe 8.3, qui spécifie le taux de réception des données depuis l'envoi du dernier DCCP-Ack.

3.	Une option Intervalles de perte, définie au paragraphe 8.6, qui spécifie les plus récents intervalles de perte rencontrés par le receveur. (La définition d'un intervalle de perte est donnée ci-dessous.) À partir des intervalles de perte, l'envoyeur peut facilement calculer le taux d'événements de perte p en utilisant la procédure décrite au paragraphe 5.4 de la [RFC3448].

Les accusés de réception qui ne contiennent pas au moins ces trois options ne sont pas considérés comme des paquets de rétroaction.

Le receveur PEUT aussi inclure d'autres options concernant le taux d'événements de perte, incluant l'option Taux d'événements de perte, qui donne le taux d'événements de perte calculé par le receveur (paragraphe 8.5), et l'option DCCP générique Vecteur d'accusés de réception, qui rapporte les numéros de séquence spécifiques de tout paquet perdu ou marqué ([RFC4340], paragraphe 11.4). Vecteur d'accusés de réception n'est pas exigé par les mécanismes de contrôle d'encombrement de CCID 3 : l'option Intervalles de perte fournit toutes les informations nécessaires pour gérer le taux de transmission et vérifie de façon probabiliste les rétroactions du receveur. Cependant, Vecteur d'accusés de réception peut être utile aux applications qui ont besoin de déterminer exactement quels paquets ont été perdus. Le receveur PEUT aussi inclure d'autres options relatives à l'accusé de réception, comme l'option DCCP Données éliminées ([RFC4340], paragraphe 11.7).

Si le receveur HC envoie aussi des paquets de données à l'envoyeur HC, il PEUT alors faire porter les informations d'accusé de réception sur les paquets de données plus fréquemment que ce que permet le taux d'accusés de réception spécifié par TFRC.

 	6.1	Définition d'intervalle de perte
Comme décrit au paragraphe 5.2 de la [RFC3448], un intervalle de perte commence avec un paquet de données perdu ou marqué ECN, continue avec au plus une quantité de paquets tenant dans un délai d'aller-retour qui peuvent ou non être perdus ou marqués, et se termine par une série de longueur arbitraire de paquets de données non éliminés, non marqués. Par exemple, voici un seul intervalle de perte, en supposant que les numéros de séquence augmentent en allant vers la droite :

         Partie avec pertes
            <= 1 RTT   __________ Partie sans perte __________
          /          \/                                   \
          *----*--*--*-------------------------------------
          ^    ^  ^  ^
         pertes ou marques

Noter qu'une patie sans perte d'un intervalle de perte peut être vide, comme dans le premier intervalle ci-dessous :

      Partie à pertes  Partie à pertes
           <= 1 RTT     <= 1 RTT   _____ Partie sans perte_____
         /          \/           \/                         \
         *----*--*--***--------*-*---------------------------
         ^    ^  ^  ^^^        ^ ^
         \_ Int. 1 _/\_____________ Intervalle 2 ___________/

Comme au paragraphe 5.2 de la [RFC3448], la longueur de la partie à pertes DOIT être inférieure ou égale à 1 RTT. CCID  3 utilise des valeurs de compteur de fenêtre, et non des heures de réception, pour déterminer si plusieurs paquets sont arrivés dans le même RTT et donc appartiennent au même événement de perte ; voir le paragraphe 10.2. Un intervalle de perte dont la partie à pertes dure plus d'un 1 RTT, ou dont la partie sans perte contient un paquet de données perdu ou marqué, est invalide.

Un paquet de données manquant ne commence pas un nouvel intervalle de perte tant que NDUPACK paquets n'ont été vus après le "trou", où NDUPACK = 3. Donc, jusqu'à NDUPACK des plus récents numéros de séquence (incluant les numéros de séquence de tous ces trous) peuvent temporairement ne pas faire partie d'un intervalle de perte pendant que la mise en œuvre attend de voir si un trou va être comblé. Voir au paragraphe 5.1 de la [RFC3448], et au paragraphe 3.2 de la [RFC2581] un exposé complet sur NDUPACK.

Comme spécifié à la Section 5 de la [RFC3448], tous les intervalles de perte sauf le premier commencent par un paquet de données perdu ou marqué, et tous les intervalles de perte sont autant que possible soumis aux contraintes de validité ci-dessus.

Les paquets perdus et marqués ECN qui ne sont pas de données peuvent survenir librement dans la partie sans pertes d'un intervalle de perte. (Les paquets non de données consistent en les types de paquets qui ne peuvent pas porter de données d'application, à savoir, DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, et DCCP-SyncAck.) En l'absence de meilleures informations, un receveur DOIT prudemment supposer que chaque paquet perdu était un paquet de données et donc doit se produire dans une partie à pertes. L'option DCCP Compte NDP peut aider le receveur à déterminer si un paquet particulier contenait des données ; voir le paragraphe 7.7 de la [RFC4340].

 	6.1.1	Longueurs d'intervalle de perte
La [RFC3448] définit le mécanisme de contrôle d'encombrement TFRC en termes de transfert unidirectionnel de données, avec les paquets de données allant de l'envoyeur au receveur et les paquets de rétroaction allant du receveur à l'envoyeur. Cependant, CCID 3 s'applique dans un contexte de deux demies-connexions, avec les paquets DCCP-Data et DCCP-DataAck provenant d'une demie-connexion qui partagent l'espace de numéros de séquence avec les paquets DCCP-Ack provenant de l'autre demie-connexion. Pour les besoins du contrôle d'encombrement CCID 3, les longueurs d'intervalle de pertes devraient inclure les paquets de données et devraient exclure les paquets d'accusé de réception provenant de la demie connexion inverse. Cependant, il est aussi utile de rapporter le nombre de paquets total dans chaque intervalle de perte (par exemple, pour faciliter la vérification de nom occasionnel ECN).

L'option Intervalles de perte de CCID 3 rapporte donc trois longueurs pour chaque intervalle de perte, les longueurs des parties à pertes et sans perte définies ci-dessus et une longueur de données séparée. D'abord, les longueurs à perte et sans perte sont mesurées en numéros de séquence. Ensemble, leur somme est la longueur de l'intervalle de séquence, qui est le nombre total de paquets que l'envoyeur a transmis durant l'intervalle. Ceci est facilement calculé dans DCCP comme le plus grand numéro de séquence de paquets dans l'intervalle moins le plus grand numéro de séquence de paquet dans l'intervalle précédent (ou, si il n'y a pas d'intervalle précédent, alors le prédécesseur du numéro de séquence initial de la demie-connexion). La longueur de données de l'intervalle est cependant le numéro utilisé dans le calcul de taux d'événements de perte de TFRC, comme défini à la Section 5 de la [RFC3448], et il est calculé comme suit.

Pour tous les intervalles de perte sauf le premier, la longueur de données est égale à la longueur de séquence moins le nombre de paquets non de données que l'envoyeur a transmis durant l'intervalle de perte, sauf que la longueur de données minimum est un paquet. En l'absence de meilleures informations, un point d'extrémité DOIT prudemment supposer que l'intervalle de pertes contenait seulement des paquets de données, auquel cas la longueur de données est égale à la longueur de séquence. Pour avoir une meilleure précision, l'envoyeur peut calculer le nombre exact de paquets non de données dans un intervalle en se souvenant de quels paquets envoyés contenaient des données ; le receveur peut compter les paquets non de données reçus en ne les incluant pas dans la longueur des donnés, et pour les paquets qui n'ont pas été reçus, il peut être capable de distinguer entre les paquets de données perdus et les paquets non de données perdus en utilisant l'option Compte de NDP de DCCP.

La longueur des données du premier intervalle de perte est indéfinie jusqu'au premier événement de perte. Le paragraphe 6.3.1 de la [RFC3448] spécifie comment la longueur des données du premier intervalle de perte est calculée une fois que le premier événement de perte s'est produit ; ce calcul utilise X_recv, le plus récent taux de réception, comme entrée. Jusqu'à ce premier événement de perte, le taux d'événements de perte est zéro, comme l'est la longueur des données rapportée pour l'intervalle dans l'option Intervalles de perte.

La longueur des données du premier intervalle de pertes pourrait être moins que, égale, ou même supérieure à sa longueur de séquence. Toute autre longueur de données d'intervalle de perte doit être inférieure ou égale à sa longueur de séquence.

Un envoyeur PEUT utiliser le taux d'événements de perte ou les longueurs de données d'intervalle comme rapportées par le receveur, ou il PEUT recalculer le taux d'événements de perte et/ou les longueurs de données d'intervalle sur la base des rétroactions du receveur et d'informations supplémentaires. Par exemple, supposons que le réseau élimine un paquet DCCP-Ack avec le numéro de séquence 50. Le receveur pourrait alors rapporter un intervalle de perte commençant au numéro de séquence 50. Si l'envoyeur a déterminé que cet intervalle de perte ne contenait en fait pas de paquet perdu ou marqué ECN, il pourrait regrouper l'intervalle de perte avec le précédent, résultant en un plus grand taux de transmission permis.

 	6.2	Contrôle d'encombrement sur les intervalles de perte
Le taux et le rythme de génération des accusés de réception est déterminé par l'algorithme TFRC ([RFC3448], Section 6).  Le taux d'envoi des accusés de réception est relativement faible – en gros une fois par délai d'aller-retour – de sorte qu'il n'est pas besoin d'un contrôle d'encombrement explicite sur les accusés de réception.

 	6.3	Accusés de réception des accusés de réception
Les accusés de réception TFRC n'ont généralement pas besoin d'être fiables, de sorte que l'envoyeur n'a généralement pas besoin d'accuser réception des accusés de réception du receveur. Quand Vecteur d'accusé de réception ou Données éliminées est utilisé, l'envoyeur, DCCP A, DOIT cependant occasionnellement accuser réception des accusés de réception du receveur afin que celui ci puisse libérer l'état Vecteur d'accusé de réception ou Données éliminées. Quand les deux demies-connexions sont actives, les accusés de réception nécessaires vont être contenus dans les données d'accusés de réception de A à B. Si la demie-connexion de B à A passe au repos, DCCP A doit cependant envoyer de façon proactive un accusé  de réception.

Donc, quand Vecteur d'accusé de réception ou Données éliminées est utilisé, un envoyeur actif DOIT accuser réception des accusés de réception du receveur approximativement une fois par délai d'aller-retour, dans un facteur de deux ou trois, probablement en envoyant un paquet DCCP-DataAck. Aucune option d'accusé de réception n'est nécessaire, juste le numéro d'accusé de reception dans l'en-tête DCCP-DataAck.

L'envoyeur PEUT choisir d'accuser réception des accusés de réception du receveur même si ils ne contiennent pas d'option Vecteur d'accusé de réception ou Données éliminées. Par exemple, des accusés de réception réguliers peuvent raccourcir la taille de l'option Intervalles de perte. À la différence de Vecteur d'accusé de réception et Données éliminées, l'option Intervalles de perte est cependant limitée en taille (et état de receveur), de sorte que les accusés de réception des accusés de réception ne sont pas exigés.

 	6.4	Détermination du repos
Ce paragraphe décrit comment un receveur CCID 3 détermine que l'envoyeur correspondant n'envoie plus de données et est donc passé au repos. Voir au paragraphe 11.1 de la [RFC4340] des informations générales sur l'état de repos.

Soit T égal au plus grand de 0,2 secondes et deux délais d'aller-retour. (un receveur CCID 3 a une mesure approximative du délai d'aller-retour de sorte qu'il peut réguler ses accusés de réception.) Le receveur détecte que l'envoyeur est passé à l'état repos après que T secondes sont passées sans recevoir de données supplémentaires de l'envoyeur.

 	7.	Notification explicite d'encombrement

CCID 3 prend en charge la notification explicite d'encombrement (ECN, Explicit Congestion Notification) [RFC3168]. Dans le cas normal d'une demie-connexion à capacité ECN (où la caractéristique ECN Incapable du receveur est réglés à zéro) l'envoyeur va utiliser le nom occasionnel ECN pour ses paquets de données, comme spécifié dans la [RFC4340], paragraphe 12.2. Les informations sur le nom occasionnel ECN DOIVENT être retournées par le receveur en utilisant l'option Intervalles de perte, et toutes les options Vecteur d'accusé de réception DOIVENT inclure la somme de nom occasionnel ECN. L'envoyeur PEUT tenir un tableau avec la somme de nom occasionnel ECN pour chaque paquet et utiliser ces informations pour vérifier de façon probabiliste les sommes de noms occasionnels ECN retournées dans les options Intervalles de perte ou Vecteur d'accusé de réception. Ceci est décrit plus en détails à la Section 9.

 	8.	Options et caractéristiques

CCID 3 peut utiliser les options Vecteur d'accusé de réception, Horodatage, Écho d'horodatage, et Temps écoulé, de DCCP, et ses caractéristiques Vecteur d'accusé de réception envoyé et Incapable d'ECN. De plus, les options spécifiques de CCID suivantes sont définie pour être utilisées avec CCID 3.

Type	Longueur d'option	Signification	Données DCCP ?	Paragraphe de référence
128-191	réservé
192	6	Taux d'événements de perte	Non 	8.5
193	variable	Intervalles de perte	Non	8.6
194	6	Taux de réception	Non	8.3
195-255	réservé

Tableau 1 : Options DCCP CCID 3

La colonne "Données DCCP ?" indique que toutes les options spécifiques de CCID 3 actuellement définies DOIVENT être ignorées quand elles sont sur des paquets Données DCCP.

La caractéristique spécifique de CCID suivante est aussi définie.

Numéro	Signification	Règle de réconciliation	Valeur initiale	Exigé	Paragraphe
128-191	réservé
192	Taux d'envoi d'événement de perte	SP	0	Non	8.4
193-255	réservé 

Tableau 2 : Numéros de caractéristique DCCP CCID 3

La signification des colonnes est décrite au Tableau 4 de la [RFC4340]. "Règle de réconciliation" définit la règle de réconciliation de caractéristique, où "SP" signifie "priorité de serveur". "Exigé" spécifie si chaque mise en œuvre CCID 3 DOIT comprendre une caractéristique ; Taux d'envoi d'événement de perte est facultatif, en quoi il se comporte comme une extension ([RFC4340], Section 15).

 	8.1	Valeur de compteur de fenêtre
L'envoyeur des données mémorise une valeur de compteur de fenêtre de quatre bits dans le champ CCVal de l'en-tête DCCP générique sur chaque paquet de données qu'il envoie. Cette valeur est réglée à 0 au début de la transmission et généralement augmentée de 1 à chaque quart d'un délai d'aller-retour, comme décrit au paragraphe 3.2.1 de la [RFC3448]. Les compteurs de fenêtre utilisent une arithmétique circulaire modulo 16 pour toutes les opérations, incluant les comparaisons ; voir au paragraphe 3.1 de la [RFC4340] plus d'informations sur l'arithmétique circulaire. Pour référence, l'en-tête générique DCCP est comme suit. (Le diagramme est répété du paragraphe 5.1 de la [RFC4340], qui montre aussi l'en-tête générique avec un champ de numéro de séquence de 24 bits.)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Accès de source           |     Accès de destination      |
+---------------+---------------+---------------+---------------+
|Décalage donnée| CCVal | CsCov |     Somme de contrôle         |
+-----+---------+-------+-------+---------------+---------------+
|réser| Type  |1|   réservé     |Numéro de séquence (bits de pf).
+-----+-------+-+---------------+---------------+---------------+
.               Numéro de séquence (bits de moindre poids       |
+---------------+---------------+---------------+---------------+

Granularité d'un quart de RTT. L'envoyeur DOIT éviter d'envelopper CCVal sur les paquets adjacents, comme cela pourrait arriver, par exemple, si deux paquets portant des données étaient envoyés séparés de quatre délais d'aller-retour sans paquets entre. Donc, l'envoyeur DEVRAIT utiliser l'algorithme suivant pour régler CCVal. L'algorithme utilise trois variables : "dernier_WC" contient la dernière valeur de compteur de fenêtre envoyée, "dernière_heure_ de_WC" est l'heure à laquelle le premier paquet avec la valeur de compteur de fenêtre "dernier_WC" a été envoyé, et "RTT" est l'estimation actuelle du délai d'aller-retour. "dernier_WC" est initialisé à zéro, et "dernière_heure_ de_WC" est réglé à l'heure d'envoi du premier paquet. Avant d'envoyer un nouveau paquet, on procède comme suit :

Soit quart_RTT = minimum((heure_actuelle - dernière_heure_ de_WC) / (RTT/4)).
Si quart_RTT > 0, alors 
   Régler dernier_WC := (dernier_WC + min(quart_RTT, 5)) mod 16.
   Régler dernière_heure_ de_WC := heure actuelle
Régler le champ CCVal de l'en-tête de paquet à dernier_WC.

Quand cet algorithme est utilisé, les compteurs CCVal des paquets adjacents portant des données ne vont jamais différer de plus de cinq, modulo 16.

La valeur du compteur de fenêtre peut aussi changer lorsque des paquets de rétroaction arrivent. En particulier, après avoir reçu un accusé de réception pour un paquet envoyé avec le compteur de fenêtre WC, l'envoyeur DEVRAIT augmenter son compteur de fenêtre, si nécessaire, afin que les paquets suivants aient une valeur de compteur de fenêtre d'au moins (WC + 4) mod 16.

Les compteurs CCVal sont utilisés par le receveur pour déterminer si plusieurs pertes appartiennent à un seul événement de perte, pour déterminer l'intervalle à utiliser pour le calcul du taux de réception, et pour déterminer quand envoyer des paquets de rétroaction. Aucune de ces procédures n'exige que le receveur maintienne une estimation explicite du délai d'aller-retour. Cependant, les mises en œuvre qui souhaitent conserver une telle estimation de RTT peuvent le faire en utilisant CCVal. Soit T(I) l'heure d'arrivée du paquet valide reçu le plus tôt avec CCVal = I. (Bien sûr, quand la valeur du compteur de fenêtre revient à la même valeur modulo 16, on doit recalculer T(I).) Soit D = 2, 3, ou 4 et disons que T(K) et T(K+D) existent tous deux (les paquets ont été reçus avec les compteurs de fenêtre K et K+D). Alors la valeur (T(K+D) - T(K)) * 4/D PEUT servir d'estimation de délai d'aller-retour. Les valeurs de D = 4 DEVRAIENT être préférées pour l'estimation du RTT. Concrètement, disons que les paquets suivants sont arrivés :

Heure :      T1  T2  T3 T4  T5           T6  T7   T8  T9
          ------*---*---*-*----*------------*---*----*--*---->
CCVal :      K-1 K-1  K  K  K+1          K+3 K+4  K+3 K+4

Alors T7 - T3, la différence entre l'heure de réception du premier paquet reçu avec le compteur de fenêtre K+4 et le premier paquet reçu avec le compteur de fenêtre K, est une estimation raisonnable de délai d'aller-retour. Parce que la contrainte nécessaire est que les mesures ne viennent que des paires de paquet dont les CCVal diffèrent au plus de 4, cette procédure ne fonctionne pas quand les temps d'envoi inter paquets sont significativement plus grands que le RTT, résultant en paires de paquets dont les CCVal diffèrent de 5. Des techniques de mesure explicite de RTT, comme Horodatage, et Écho d'horodatage, devraient être utilisées dans ce cas.

 	8.2	Options de temps écoulé 
Le receveur des données DOIT inclure une valeur de temps écoulé sur chaque accusé de réception requis. Cela aide l'envoyeur a distinguer entre le délai d'aller-retour du réseau, qu'il doit inclure dans ses équations de taux, et le délai au receveur dû au taux d'accusé de réception infréquent de TFRC, qu'il n'a pas besoin d'inclure. Le receveur DOIT au moins inclure une option Temps écoulé dans chaque paquet de rétroaction, mais si au moins un paquet de données récent (c'est-à-dire, un paquet reçu après l'envoi du DCCP-Ack précédent) incluait une option Horodatage, alors le receveur DEVRAIT aussi inclure l'option Écho d'horodatage correspondante, avec la la valeur Temps écoulé. Tous ces types d'option  sont définis dans la spécification DCCP principale [RFC4340].

 	8.3	Option de taux de réception
+--------+--------+--------+--------+--------+--------+
|11000010|00000110|         Taux de réception         |
+--------+--------+--------+--------+--------+--------+
 Type=194  Longueur=6

Cette option DOIT être envoyée par le receveur des données sur tous les accusés de réception exigés. Ses quatre octets de données indiquent le taux de réception des données par le receveur depuis son dernier envoi d'accusé de réception, en octets par seconde. Pour calculer ce taux de réception, le receveur règle t au plus grand du délai d'aller-retour estimé et du temps écoulé depuis l'envoi de la dernière option Taux de réception. (Les compteurs de fenêtre des paquets de données reçus peuvent être utilisés pour produire une estimation convenable du RTT, comme décrit au paragraphe 8.1.) Le taux de réception est alors égal au nombre d'octets de données reçu dans les t secondes les plus récentes, divisé par t.

Les options de taux de réception NE DOIVENT PAS être envoyées sur des paquets DCCP-Data, et toutes les options Taux de réception reçues sur des paquets DCCP-Data DOIVENT être ignorées.

 	8.4	Caractéristique de taux d'événement de perte à l'envoi
La caractéristique Taux d'événement de perte à l'envoi permet aux points d'extrémité CCID 3 de négocier si le receveur DOIT fournir des options Taux d'événement de perte sur ses accusés de réception. DCCP A envoie une option "Change R(Taux d'événement de perte à l'envoi, 1)" pour demander à DCCP B d'envoyer des options Taux d'événement de perte au titre de son trafic d'accusés de réception.

Taux d'événement de perte à l'envoi a le numéro de caractéristique 192 et est de priorité de serveur. Il prend des valeurs booléennes d'un octet. DCCP B DOIT envoyer des options Taux d'événement de perte sur ses accusés de réception quand Taux d'événement de perte à l'envoi/B est un, bien qu'il PUISSE envoyer des options Taux d'événement de perte à l'envoi même quand Taux d'événement de perte à l'envoi/B est zéro. Les valeurs de deux ou plus sont réservées. Une demie-connexion CCID 3 commence avec un Taux d'événement de perte à l'envoi égal à zéro.

 	8.5	Option Taux d'événement de perte
+--------+--------+--------+--------+--------+--------+
|11000000|00000110|    Taux d'événement de perte      |
+--------+--------+--------+--------+--------+--------+
Type=192  Longueur=6

La valeur de l'option indique l'inverse du taux d'événements de perte, arrondi à l'entier supérieur, comme calculé par le receveur. L'unité est le paquet de données par intervalle de perte. Donc, si la valeur de l'option Taux d'événement de perte est 100, alors le taux d'événements de perte est 0,01 événement de perte par paquet de données (et l'intervalle de perte moyen contient 100 paquets de données). Quand chaque événement de perte a exactement un paquet de données perdu, le taux d'événements de perte est le même que le taux d'abandon de paquet de données.

Voir à la Section 5 de la [RFC3448] le calcul normatif du taux d'événements de perte. Avant qu'aucune perte se soit produite, quand le taux d'événements de perte est zéro, la valeur de l'option Taux d'événement de perte est réglée à "11111111111111111111111111111111" en binaire (ou son équivalent, à 2^32 - 1). Le calcul du taux d'événements de perte utilise les longueurs des intervalles de données, comme défini au paragraphe 6.1.1.

Les options Taux d'événement de perte NE DOIVENT PAS être envoyées sur les paquets DCCP-Data, et toutes les options Taux d'événement de perte sur les paquets DCCP-Data reçus DOIVENT être ignorées.

 	8.6.	Option Intervalles de perte
+--------+--------+--------+--------...--------+--------+---
|11000001|Longueur|Longueur|   Intervalle de   | Plus d'intervalles
|        |        | sautée |        pertes     | de pertes...
+--------+--------+--------+--------...--------+--------+---
 Type=193                         9 octets

Chaque intervalle de perte de 9 octets contient trois champs, comme suit :

  ___________________Intervalle de perte ___________________________
 /                                                                   \
+--------...--------+---------...----------------+---------...--------+
|Longueur sans perte|Longueur|E|Longueur de perte| Longueur de données|
+--------...--------+---------...----------------+---------...--------+
       3 octets            3 octets                      3 octets

Le receveur rapporte ses intervalles de perte observés en utilisant une option Intervalles de perte. Le paragraphe 6.1 définit les intervalles de perte. Cette option DOIT être envoyée par le receveur des données sur tous les accusés de réception exigés. L'option rapporte jusqu'à 28 intervalles de perte vus par le receveur, bien que TFRC utilise généralement au plus les neuf derniers. Cela permet à l'envoyeur de calculer un taux d'événements de perte et de vérifier de façon probabiliste l'écho de nom occasionnel ECN du receveur.

L'option Intervalles de perte sert plusieurs objets.
o	L'envoyeur peut utiliser l'option Intervalles de perte pour calculer le taux d'événements de perte.
o	La cohérence des informations d'intervalles de perte est facilement vérifiée par rapport aux précédentes options Intervalles de perte, et au taux d'événements de perte calculé par le receveur.
o	L'envoyeur peut vérifier de façon probabiliste l'écho de nom occasionnel ECN pour chaque intervalle de perte, réduisant la probabilité d'un mauvais comportement.

Les options Intervalles de perte NE DOIVENT PAS être envoyées sur les paquets DCCP-Data, et toute option Intervalles de perte reçue sur un paquet DCCP-Data DOIT être ignorée.

 	8.6.1	Détails de l'option
L'option Intervalles de perte contient des informations sur de un à vingt-huit intervalles de perte consécutifs incluant toujours l'intervalle de perte le plus récent. La liste des intervalles est dans l'ordre chronologique inverse. Si plus de 28 intervalles de perte devaient être rapportés, alors plusieurs options d'intervalles de perte pourraient être envoyées ; la seconde option commence où la première s'arrête, et ainsi de suite. Les options DOIVENT contenir des informations sur au moins le plus récent NINTERVAL + 1 = 9 intervalles de perte sauf si (1) il n'y a pas encore eu NINTERVAL + 1 intervalles de perte, ou (2) le receveur sait, à cause des accusés de réception de l'envoyeur, que des informations d'intervalle de perte précédemment transmises ont été reçues. Dans ce second cas, le receveur n'a pas besoin d'envoyer des intervalles de perte que l'envoyeur connaît déjà, sauf qu'il DOIT transmettre au moins un intervalle de perte de toutes façons.

Le paramètre NINTERVAL est égal à "n" comme défini au paragraphe 5.4 de la [RFC3448].

Les numéros de séquence d'intervalles de perte sont codés par différence en commençant par le numéro d'accusé de réception. Donc, les options Intervalles de perte NE DOIVENT PAS être envoyées sur des paquets sans un numéro d'accusé de réception, et toute option Intervalles de perte reçue sur de tels paquets DOIT être ignorée.

Le premier octet de données d'option est Longueur sautée, qui indique le nombre de paquets, jusque et inclus le numéro d'accusé de réception, qui ne font pas partie d'un intervalle de perte. Comme expliqué ci-dessus, Longueur sautée doit être inférieur ou égal à NDUPACK = 3. Dans un paquet qui contient plusieurs options Intervalles de perte, les longueurs sautées de la seconde option et des suivantes DOIVENT être égales à zéro ; les options avec des longueurs sautées non à zéro DOIVENT être ignorées.

Les structures d'intervalle de perte suivent la longueur sautée. Chaque intervalle de perte comporte une longueur sans perte, une longueur de pertes, un écho de nom occasionnel ECN (E), et une longueur de données.

Longueur sans perte, un nombre de 24 bits, spécifie le nombre de paquets dans la partie sans perte de l'intervalle de perte. Noter encore que cette partie peut contenir des paquets non de données perdus ou marqués.

Longueur de perte, un nombre de 23 bits, spécifie le nombre de paquets dans la partie à perte de l'intervalle de perte. La somme de Longueur sans perte et de Longueur de perte égale la longueur de séquence de l'intervalle de perte. Les receveurs DEVRAIENT rapporter la longueur de perte minimum valide pour chaque intervalle de perte, faisant correspondre le premier et le dernier numéro de séquence dans chaque partie à pertes aux paquets de données perdus ou marqués.

L'écho de nom occasionnel ECN, mémorisé dans le bit de poids fort du champ de trois octets contenant la longueur de perte, est égal à la somme de bits à un (OU exclusif, ou parité) des noms occasionnels des paquet de données reçus sur la partie sans perte de l'intervalle de perte (qui est long de Longueur sans perte paquets). Si Longueur sans perte est 0, le receveur est incapable d'ECN, ou la longueur sans perte ne contenait pas de paquets de données, alors l'écho de nom occasionnel ECN DOIT être rapporté comme 0. Noter qu'aucun nom occasionnel ECN sur des paquets non de données reçus NE DOIT contribuer à l'écho de nom occasionnel ECN.

Finalement, Longueur de données, un nombre de 24 bits, spécifie la longueur des données de l'intervalle de perte, comme défini au paragraphe 6.1.1.

 	8.6.2	Exemple
Considérons la séquence de paquets suivante, où "-" représente un paquet livré en toute sécurité et "*" représenté un paquet perdu ou marqué.

Numéro de séquence : 0         10          20             30        40   44
                                      |           |             |                |           |       |
                                    ----------*--------***-*--------*----------*-

En supposant que le paquet 43 est perdu, non marqué, cette séquence pourrait être divisée en intervalles de perte comme suit :

0          10          20           30          40   44
|             |              |              |             |      |
----------*--------***-*--------*----------*-
\______/\_____/\_________/\_______/
    L0           L1         L2               L3

Une option Intervalles de perte envoyée sur un paquet avec le numéro d'accusé de réception 44 pour accuser réception de cet ensemble d'intervalles de perte pourrait contenir les octets 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. Cette option est interprétée comme suit :

193 : numéro de l'option Intervalles de perte.

39 : longueur de l'option, incluant les octets de type d'option et de longueur. Cette option contient des informations sur 
(39 - 3)/9 = 4 pertes.

2 : la longueur sautée est de 2 paquets. Donc, le plus récent intervalle de perte, L3, se termine immédiatement avant le numéro de séquence 44 - 2 + 1 = 43.

0,0,10, 128,0,1, 0,0,10 : ces octets définissent L3. L3 consiste en une partie de 10 paquets sans perte (0,0,10) précédée par une partie à perte de 1 paquet. En continuant la soustraction, la partie sans perte commence avec le numéro de séquence 43 - 10 = 33, et la partie à pertes commence au numéro de séquence 33 - 1 = 32. L'écho de nom occasionnel ECN pour la partie sans perte (à savoir , les paquets 33 à 42, inclus) égale 1. La longueur de données de l'intervalle est 10, de sorte que le receveur pense que l'intervalle contenait exactement un paquet non de données.

0,0,8, 0,0,5, 0,0,10 : cela définit L2, dont la partie sans perte commence au numéro de séquence 32 - 8 = 24, dont la partie à pertes commence au numéro de séquence 24 - 5 = 19, dont l'écho de nom occasionnel ECN (pour les paquets [24,31]) égale 0, et dont la longueur des données est 10.

0,0,8, 0,0,1, 0,0,8 : la partie sans perte de L1 commence au numéro de séquence 11, sa partie à perte commence au numéro de séquence 10, son écho de nom occasionnel ECN (pour les paquets [11,18]) égale 0, et sa longueur des données est 8.

0,0,10, 128,0,0, 0,0,15 : la partie sans perte de L0 commence au numéro de séquence 0, il n'a pas de partie à pertes, son écho de nom occasionnel ECN (pour les paquets [0,9]) égale 1, et sa longueur de données est 15. (Ce doit être le premier intervalle de perte de la connexion ; autrement, un longueur de données supérieure au numéro de séquence serait invalide.)

 	9.	Vérification de la conformité du contrôle d'encombrement à ECN

L'envoyeur peut utiliser les options Intervalles de perte (et éventuellement tous échos de noms occasionnel ECN de vecteurs d'accusé de réception) pour vérifier de façon probabiliste que le receveur rapporte correctement tous les paquets éliminés ou marqués. Même si ECN n'est pas utilisé (la caractéristique ECN Incapable du receveur est réglée à un) l'envoyeur pourrait encore vérifier que le receveur n'a pas occasionnellement envoyé un paquet déclassé, pour attraper le receveur dans un intervalle de perte ou informations de vecteurs d'accusé de réception erronés. Ceci n'est cependant pas aussi robuste ou non intrusif que la vérification fournie par le nom occasionnel ECN.

 	9.1	Vérification de l'écho de nom occasionnel ECN
Pour vérifier l'écho de nom occasionnel ECN inclus dans une option Intervalles de perte, l'envoyeur tient un tableau avec la somme de noms occasionnels ECN pour chaque paquet de données. Comme défini dans la [RFC3540], la somme de nom occasionnel pour le numéro de séquence S est la somme des bits à un (OU exclusif, ou parité) des noms occasionnels de paquet de données sur la gamme de numéros de séquence [I,S], où I est le numéro de séquence initial. Soit NonceSum(S) qui représente cette somme de noms occasionnels pour le numéro de séquence S, et on définit NonceSum(I - 1) comme 0. Noter que NonceSum ne tient pas compte des noms occasionnels des paquets non de données tels que DCCP-Ack. Alors l'écho de nom occasionnel pour un intervalle de paquets avec les numéros de séquence X à Y, inclus, devrait être égal à la somme de bits un suivante :

NonceSum(X - 1) + NonceSum(Y)

Comme un écho de nom occasionnel ECN est retourné pour la partie sans perte de chaque intervalle de perte, un receveur au mauvais comportement – signifiant un receveur qui rapporte un paquet de données perdu ou marqué comme "reçu non marqué", pour éviter des réductions  de taux – a seulement 50 % de chances de deviner l'écho de nom occasionnel correct pour chaque intervalle de pertes.

Pour vérifier l'écho de nom occasionnel ECN inclus avec une option Vecteur d'accusé de réception, l'envoyeur tient un tableau des valeurs de nom occasionnel ECN envoyées pour chaque paquet. L'option Vecteur d'accusé de réception dit explicitement quels paquets ont été reçus non marqués ; l'envoyeur ajoute juste les noms occasionnels pour ces paquets en utilisant une somme des bits à un et compare le résultat à l'écho de nom occasionnel codé dans le type d'option du vecteur d'accusé de réception. Là encore, un receveur au mauvais comportement a seulement 50 % de chances de deviner l'écho de nom occasionnel correct d'un vecteur d'accusé de réception. Autrement, un écho de nom occasionnel ECN de vecteur d'accusé de réception peut aussi être calculé d'après un tableau des sommes de noms occasionnels ECN, plutôt qu'à partir des noms occasionnels ECN. Si le vecteur d'accusé de réception contient de nombreuses longues séries de paquets non marqués, non éliminés, le calcul fondé sur la somme des nom occasionnels va probablement être plus rapide qu'un calcul fondé directement sur le nom occasionnel.

Noter que l'écho de nom occasionnel ECN du Vecteur d'accusé de réception est mesuré sur les paquets de données et les paquets non de données, tandis que l'option Intervalles de perte rapporte les échos de nom occasionnel ECN seulement pour les paquets de données. Donc, des tableaux de somme de noms occasionnels différentes sont nécessaires pour vérifier les deux options.

 	9.2	Vérification des intervalles de perte et du taux d'événements de perte rapportés
À côté de la vérification probabiliste des échos de nom occasionnel ECN rapportés par le receveur, l'envoyeur peut aussi vérifier les intervalles de perte et tous taux d'événements de perte rapportés par le receveur, si il le désire. Précisément, l'option Intervalles de perte rapporte explicitement la taille de chaque intervalle de perte telle que vue par le receveur; l'envoyeur peut vérifier que le receveur ne combine pas faussement deux événements de perte en un intervalle de perte rapporté en utilisant des informations sauvegardées de compteur de fenêtre. L'envoyeur peut aussi comparer toute option Taux d'événement de perte au taux d'événements de perte qu'il calcule en utilisant l'option Intervalles de perte.

Noter que dans certains cas, le taux d'événements de perte calculé par l'envoyeur pourrait différer d'une option Taux d'événement de perte explicite envoyée par le receveur. En particulier, quand un certain nombre de paquets successifs sont éliminés, le receveur ne connaît pas les heures d'envoi de ces paquets et interprète ces pertes comme un seul événement de perte. À l'opposé, si l'envoyeur a sauvegardé les heures d'envoi ou les informations de compteur de fenêtre pour ces paquets, l'envoyeur peut alors déterminer si ces pertes constituent un seul événement de perte ou plusieurs événements de perte successifs. Donc, avec sa connaissance des heures d'envoi des paquets éliminés, l'envoyeur est capable de faire un calcul plus précis du taux d'événements de perte. Ces sortes de différences NE DEVRAIENT PAS être mal interprétées comme une tentative de mauvais comportement du receveur.

 	10.	Questions de mise en œuvre
 	10.1	Usage de l'horodatage
Les paquets de données CCID 3 n'ont pas besoin de porter d'option Horodatage. L'envoyeur peut mémoriser l'heure à laquelle les paquets récents ont été envoyés ; les options Numéro d'accusé de réception et Temps écoulé contenues dans chaque accusé de réception exigé donnent alors des informations suffisantes pour calculer le temps d'aller-retour. Autrement, l'envoyeur PEUT inclure des options Horodatage dans certains de ses paquets de données. Le receveur va répondre avec des options Écho d'horodatage incluant les temps écoulés, permettant à l'envoyeur de calculer les délais d'aller-retour sans mémoriser du tout les horodatages des paquets envoyés.

 	10.2	Détermination des événements de perte chez le receveur
Le compteur de fenêtre est utilisé par le receveur pour déterminer si plusieurs paquets perdus appartiennent au même événement de perte. L'envoyeur augmente le compteur de fenêtre de un à chaque quart de délai d'aller-retour. Ce paragraphe décrit en détails la procédure pour utiliser le compteur de fenêtre pour déterminer quand deux paquets perdus appartiennent au même événement de perte.

Le paragraphe 3.2.1 de la [RFC3448] spécifie que chaque paquet de données contient un horodatage et donne comme solution de remplacement  un "horodatage" qui est incrémenté à chaque quart de RTT, comme l'est le compteur de fenêtre dans CCID 3. Cependant, le paragraphe 5.2 de la [RFC3448] sur la "traduction d'un historique de pertes en événements de perte" est écrit en termes d'horodatages, et non en termes de compteurs de fenêtre. Dans ce paragraphe, on donne une procédure pour la traduction d'un historique de pertes en événements de perte qui est explicitement en termes de compteur de fenêtre.

Pour déterminer si deux paquets perdus avec les numéros de séquence X et Y appartiennent à des événements de perte différents, le receveur procède comme suit. On suppose Y > X dans un espace de séquence circulaire.

o	Soit X_prev le plus grand numéro de séquence valide reçu avec X_prev < X.

o	Soit Y_prev le plus grand numéro de séquence valide reçu avec Y_prev < Y.

o	Étant donné un numéro de séquence N, soit C(N) la valeur du compteur de fenêtre associé à ce paquet.

o	Les paquets X et Y appartiennent à des événements de perte différents si il existe un paquet avec un numéro de séquence tel que X_prev < S ≤ Y_prev, et si la distance de C(X_prev) à C(S) est supérieure à 4. (La distance est le nombre D tel que C(X_prev) + D = C(S) (mod WCTRMAX), où WCTRMAX est la valeur maximum pour le compteur de fenêtre -- dans notre cas, 16.)

C'est-à-dire que le receveur ne considère les pertes X et Y comme des événements de perte séparés que si il existe des paquet S reçus entre X et Y, avec la distance de C(X_prev) à C(S) supérieure à 4. Ce calcul complexe est nécessaire afin de traiter le cas où l'espace de compteur de fenêtre s'est épuisé complètement entre X et Y. Quand cet espace n'est pas arrivé à son terme, le receveur peut simplement vérifier si la distance de C(X_prev) à C(Y_prev) est supérieure à 4 ; si c'est le cas, alors X et Y appartiennent à des événements de perte séparés.

Les compteurs de fenêtre peuvent aider le receveur a résoudre les ambiguïtés de plusieurs pertes après une soudaine diminution du délai d'aller-retour réel. Quand l'envoyeur reçoit un accusé de réception d'un paquet de données avec compteur de fenêtre i, l'envoyeur augmente son compteur de fenêtre, si nécessaire, afin que les paquets de données suivants soient envoyés avec des valeurs de compteur de fenêtre d'au moins i+4. Ceci peut aider à minimiser les erreurs lorsque le receveur interprète incorrectement plusieurs événements de perte comme un seul.

On note que si tous les paquets entre X et Y sont perdus dans le réseau, alors X_prev et Y_prev sont égaux, et la série de pertes consécutives est traitée par le receveur comme un seul événement de perte. Cependant, l'envoyeur ne va pas recevoir de paquets DCCP-Ack durant une période de pertes consécutives, et l'envoyeur va réduire son taux d'envoi en conséquence.

Comme solution de remplacement au compteur de fenêtre, l'envoyeur pourrait avoir envoyé ses estimations de délai d'aller-retour au receveur directement dans une option de délai d'aller-retour ; le receveur utiliserait l'estimation de délai d'aller-retour de l'envoyeur pour déduire quand plusieurs paquets perdus ou marqués appartiennent au même événement de perte. À certains égards, une option de délai d'aller-retour donnerait un codage plus précis de l'estimation du délai d'aller-retour de l'envoyeur que ne le fait le compteur de fenêtre. Cependant, le compteur de fenêtre porte des informations sur les temps *d'envoi* relatifs des paquets, alors que le receveur pourrait seulement utiliser l'option de délai d'aller-retour pour distinguer entre les temps relatifs de *réception* (en l'absence des horodatages). C'est-à-dire que le compteur de fenêtre va donner des performances plus robustes quand il y a une grande variation de délai pour les paquets envoyés dans une fenêtre de données. Légèrement plus spéculative, une option de délai d'aller-retour pourrait éventuellement être utilisée plus facilement par des boîtiers de médiation qui tentent de vérifier qu'un flux utilisé se conforme au contrôle d'encombrement de bout en bout.

 	10.3	Envoi de paquets de rétroaction
Les paragraphes 6.1 et 6.2 de la [RFC3448] spécifient que le receveur TFRC doit envoyer un paquet de rétroaction quand un taux d'événements de perte nouvellement calculé p est supérieur à sa valeur précédente. CCID 3 suit cette règle.

De plus, le paragraphe 6.2 de la [RFC3448] spécifie que le receveur utilise un temporisateur de rétroaction pour décider quand envoyer des paquets de rétroaction supplémentaires. Si le temporisateur de rétroaction expire et que des paquets de données ont été reçus depuis l'envoi de la rétroaction précédente, le receveur envoie alors un paquet de rétroaction. Quand le temporisateur de rétroaction expire, le receveur réinitialise le temporisateur à expirer après R_m secondes, où R_m est la plus récente estimation de délai d'aller-retour reçue de l'envoyeur. Cependant, les receveurs CCID 3 utilisent généralement des valeurs de compteur de fenêtre au lieu d'un temporisateur de rétroaction pour déterminer quand envoyer des paquets de rétroaction supplémentaires. Ce paragraphe décrit comment.

Chaque fois que le receveur envoie un message de rétroaction, le receveur règle une variable locale dernier_compteur à la plus grande valeur reçue de compteur de fenêtre depuis l'envoi du dernier message de rétroaction, si des paquets de données ont été reçus depuis l'envoi du dernier message de rétroaction. Si le receveur reçoit un paquet de données avec une valeur de compteur de fenêtre supérieure ou égale à dernier_compteur + 4, alors le receveur envoie un nouveau paquet de rétroaction. ("La plus grande" et "supérieure" sont mesurées dans un espace de compteur de fenêtre circulaire.)

Cette procédure assure que quand l'envoyeur envoie à un taux inférieur à un paquet par délai d'aller-retour, le receveur envoie un paquet de rétroaction après chaque paquet de données. De même, cette procédure assure que quand l'envoyeur envoie plusieurs paquets par délai d'aller-retour, le receveur va envoyer un paquet de rétroaction chaque fois qu'un paquet de données arrive avec un compteur de fenêtre au moins quatre fois plus grand que le compteur de fenêtre quand le dernier paquet de rétroaction a été envoyé. Donc, le temporisateur de rétroaction n'est pas nécessaire quand le compteur de fenêtre est utilisé.

Cependant, le temporisateur de rétroaction pourrait encore être utile dans certains cas rares pour empêcher l'envoyeur de diviser inutilement par deux son taux d'envoi. En particulier, on pourrait construire des scénarios où l'utilisation du temporisateur de rétroaction chez le receveur empêcherait l'expiration inutile du temporisateur de non rétroaction chez l'envoyeur. Dans le cas ci-dessous, un paquet de rétroaction est envoyé quand un paquet de données arrive avec un compteur de fenêtre de K.

Compteurs de fenêtre :        K   K+1   K+2   K+3   K+4   K+5   K+6  ...  K+15   K+16   K+17 ...
                                              |     |         |         |          |         |          |              |           |            |
Paquets de données reçus :     -   -       ---       -                                      ...     -    -    --   -      --   --      -
                                                 |                                         |                            |          |            |              |
Événements :                          1 :                                      2 :                        3 :        4 :         5 :          6 :
                                        "A" envoyé                                                 "B" envoyé  Tempo. "B" reçu

1 : le message de rétroaction A est envoyé.
2 : un message de rétroaction aurait été envoyé si des temporisateurs de rétroaction avaient été utilisés.
3 : le message de rétroaction B est envoyé.
4 : le temporisateur de non rétroaction de l'envoyeur expire.
5 : le message de rétroaction B est reçu chez l'envoyeur.
6 : le temporisateur de non rétroaction de l'envoyeur aurait expiré si des temporisateurs de rétroaction avaient été utilisés, et le message de rétroaction en 2 aurait été envoyé.

Le receveur reçoit les données après que le paquet de rétroaction a été envoyé mais n'a pas reçu de paquets de données avec un compteur de fenêtre entre K+4 et K+14. Un paquet de données avec un compteur de fenêtre de K+4 ou plus grand aurait déclenché l'envoi d'un nouveau paquet de rétroaction, mais aucun paquet de rétroaction n'est envoyé jusqu'à temps 3.

Le protocole TFRC spécifie qu'après la réception d'un paquet de rétroaction, l'envoyeur règle un temporisateur de non rétroaction à au moins quatre fois le délai d'aller-retour estimé. Si l'envoyeur ne reçoit aucun paquet de rétroaction avant l'expiration du temporisateur de non rétroaction, il divise alors son taux d'envoi par deux. Dans la figure, l'envoyeur reçoit un message de rétroaction A (temps 1) et ensuite règle le temporisateur de non rétroaction à expirer en gros quatre délais d'aller-retour plus tard (temps 4). L'envoyeur recommence l'envoi juste avant l'expiration du temporisateur de non rétroaction mais il ne reçoit pas le message de rétroaction résultant avant son expiration, ce qui résulte en une division par deux inutile du taux d'envoi. Si la connexion avait utilisé des temporisateurs de rétroaction, le receveur aurait envoyé un message de rétroaction quand le temporisateur de rétroaction aurait expiré au temps 2, et la division par deux du taux d'envoi aurait été évitée.

Pour les mises en œuvre qui souhaitent mettre en œuvre un temporisateur de rétroaction pour le receveur des données, on suggère d'estimer le délai d'aller-retour à partir du plus récent paquet de données, comme décrit au paragraphe 8.1. On note que cette procédure ne fonctionne pas quand les temps d'envoi inter paquets sont supérieurs au RTT.

 	11.	Considérations sur la sécurité

Les considérations sur la sécurité de DCCP sont discutées dans la [RFC4340], et les considérations sur la sécurité pour TFRC sont discutées à la Section 9 de la [RFC3448]. Les considérations sur la sécurité pour TFRC incluent le besoin de protéger contre les rétroactions falsifiées et le besoin de protéger les mécanismes de contrôle d'encombrement contre des informations incorrectes provenant du receveur.

Dans le présent document, on a largement discuté les mécanismes que l'envoyeur peut utiliser pour vérifier les informations envoyées par le receveur. Quand ECN est utilisé, le receveur retourne les informations de nom occasionnel ECN à l'envoyeur. Quand ECN n'est pas utilisé, comme le montre la Section 9, l'envoyeur pourrait alors encore utiliser diverses techniques qui pourraient saisir que le receveur a fait une erreur en rapportant l'encombrement, mais ceci n'est pas aussi robuste ou non intrusif que la vérification fournie par le nom occasionnel ECN.

 	12.	Considérations relatives à l'IANA

La présente spécification définit la valeur 3 dans l'espace de noms DCCP CCID géré par l'IANA. Cette allocation est aussi mentionnée dans la [RFC4340].

CCID 3 introduit aussi trois ensembles de nombres dont les valeurs devraient être allouées par l'IANA, à savoir les codes de réinitialisation spécifiques de CCID 3, les types d'option, et les numéros de caractéristique. Ces gammes empêcheront toute allocation future spécifique de CCID 3 de polluer les espaces de noms mondiaux correspondants de DCCP ; voir au paragraphe 10.3 de la [RFC4340]. Cependant, on note que le présent document ne fait pas d'allocations particulières dans la gamme de codes de réinitialisation, sauf pour l'utilisation expérimentale et d'essai [RFC3692]. On se réfère à la politique d'action de normalisation mentionnée dans la [RFC2434].

 	12.1	Codes de réinitialisation
Chaque entrée dans le registre DCCP CCID 3 des codes de réinitialisation contient un code de réinitialisation spécifique de CCID 3, qui est un nombre dans la gamme 128 à 255, un brève description du code de réinitialisation, et une référence à la RFC qui définit le code de réinitialisation. Les codes de réinitialisation 184 à 190 et 248 à 254 sont réservés en permanence  pour l'utilisation expérimentale et d'essai. Les codes de réinitialisation restants – 128 à 183, 191 à 247, et 255 -- sont actuellement réservés et devraient être alloués selon la politique d'action de normalisation, qui exige l'examen et l'approbation de l'IESG et la publication d'une RFC de l'IETF sur la voie de la normalisation.

 	12.2	Types d'option
Chaque entrée dans le registre des types d'option DCCP CCID 3 contient un type d'option spécifique de CCID 3, qui est un nombre dans la gamme de 128 à 255, le nom de l'option, comme "Intervalles de perte", et une référence à la RFC qui définit le type d'option. Le registre est initialement rempli en utilisant les valeurs du Tableau 1 (Section 8). Le présent document alloue les types d'option 192 à 194, et les types d'option 184 à 190 et 248 à 254 sont en permanence réservés pour utilisation expérimentale et d'essai. Les types d'option restants – 128 à 183, 191, 195 à 247, et 255 -- sont actuellement réservés et devrait être alloués selon la politique d'action de normalisation, qui exige l'examen et l'approbation de l'IESG et la publication d'une RFC de l'IETF sur la voie de la normalisation.

 	12.3	Numéros de caractéristique
Chaque entrée dans le registre DCCP CCID 3 des numéros de caractéristique contient un numéro de caractéristique spécifique de CCID 3, qui est un numéro dans la gamme de 128 à 255, le nom de la caractéristique, comme "Taux d'événement de perte à l'envoi", et une référence à la RFC qui définit le numéro de caractéristique. Le registre est initialement rempli en utilisant les valeurs du Tableau 2 (Section 8). Le présent document alloue le numéro de caractéristique 192, et les numéros de caractéristique 184 à 190 et 248 à 254 sont en permanence réservés pour utilisation expérimentale et d'essai. Les numéros de caractéristique restants – 128 à 183, 191, 193 à 247, et 255 -- sont actuellement réservés et devrait être alloués selon la politique d'action de normalisation, qui exige l'examen et l'approbation de l'IESG et la publication d'une RFC de l'IETF sur la voie de la normalisation.

 	13.	Remerciements

Merci à Mark Handley de son aide pour définir CCID 3. Merci aussi à Mark Allman, Aaron Falk, Ladan Gharai, Sara Karlberg, Greg Minshall, Arun Venkataramani, David Vos, Yufei Wang, Magnus Westerlund, et aux membres du groupe de travail DCCP pour leurs retours sur les différentes versions du présent document.

 	Appendice A.	Changements futurs possibles à CCID 3

Il y a un certain nombre de cas où le comportement de TFRC comme spécifié dans la [RFC3448] ne correspond pas aux désirs de possibles utilisateurs de DCCP. Cela inclut ce qui suit :

1.	Le taux d'envoi initial d'au plus quatre paquets par RTT, comme spécifié dans la [RFC3390].

2.	L'envoi par le receveur d'un accusé de réception pour chaque paquet de données reçu, quand le receveur reçoit à un taux inférieur à un paquet par délai d'aller-retour.

3.	La limitation de l'envoyeur à au plus doubler le taux d'envoi d'un délai d'aller-retour au prochain (ou, plus précisément, de limiter le taux d'envoi à au plus deux fois le taux de réception rapporté sur le précédent délai d'aller-retour).

4.	La limitation de diviser par deux le taux d'envoi permis après une période de repos de quatre délais d'aller-retour (éventuellement jusqu'au taux d'envoi initial de deux à quatre paquets par délai d'aller-retour).

5.	La fonction de réponse utilisée au paragraphe 3.1 de la [RFC3448] qui ne correspond pas très bien au comportement de TCP dans des environnements avec fort taux d'élimination de paquets [RFC3714].

Une suggestion pour de plus forts taux d'envoi initial est un taux d'envoi initial de jusqu'à huit petits paquets par RTT, quand la taille de paquet totale, incluant les en-têtes, est au plus de 4380 octets. Parce que les paquets vont être régulés sur un délai d'aller-retour, au lieu d'être envoyés à la file comme ils le seraient dans TCP, un taux d'envoi initial de huit petits paquets par RTT avec un contrôle d'encombrement fondé sur TFRC va être considérablement plus doux que l'impact d'une fenêtre initiale de huit petits paquets envoyés à la file dans TCP. Comme décrit au paragraphe 5.1, le taux d'envoi initial sert aussi de limite inférieurs aux réductions du taux d'envoi permis durant une période de repos.

On note qu'avec CCID 3, l'envoyeur est en démarrage lent au début et répond rapidement au rapport d'une perte ou marque de paquet. Cependant, en l'absence de rétroaction de la part du receveur, l'envoyeur peut conserver son taux d'envoi pendant jusqu'à quatre délais d'aller-retour. Une possibilité serait une fenêtre initiale de huit petits paquets, le temporisateur de non rétroaction initial serait réglé à deux délais d'aller-retour au lieu de quatre, de sorte que le taux d'envoi serait réduit après deux allers-retours sans rétroactions.

Des recherches et de l'ingénierie vont être nécessaires pour examiner le pour et le contre d'une modification de ces limitations afin de permettre de plus grands taux d'envoi initial, d'envoyer moins d'accusés de réception quand le taux d'envoi des données est bas, pour permettre des changements plus abrupts du taux d'envoi, ou pour permettre un taux d'envoi plus élevé après une période de repos.

 	Références normatives
[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC2581]	M. Alman, V. Paxson et W. Stevens, "Contrôle d'encombrement avec TCP", avril 1999. (Obsolète, voir RFC5681)

[RFC3168]	K. Ramakrishnan et autres, "Ajout de la notification explicite d'encombrement (ECN) à IP", septembre 2001. (P.S. ; MàJ par RFC8311)

[RFC3390]	M. Allman, S. Floyd, C. Partridge, "Augmentation de la fenêtre initiale de TCP", octobre 2002. (P.S.)

[RFC3448]	M. Handley, S. Floyd, J. Padhye, J. Widmer, "Contrôle de débit convivial sur TCP (TFRC) : Spécification du protocole", janvier 2003. (Obsolète, voir RFC5348) (P.S.)

[RFC3692]	T. Narten, "L'allocation de numéros expérimentaux et d'essai est considérée comme utile", janvier 2004. (BCP0082)

[RFC4340]	E. Kohler et autres, "Protocole de contrôle d'encombrement de datagrammes (DCCP)", mars 2006. (P.S.) (MàJ par 6773)

 	Références pour information
[RFC3540]	N. Spring, D. Wetherall, D. Ely, "Signalisation de notification robuste d'encombrement explicite (ECN) avec des noms occasionnels", juin 2003. (Expérimentale)

[RFC3714]	S. Floyd et J. Kempf, éd., "Considérations de l'IAB sur le contrôle de l'encombrement en trafic vocal sur l'Internet", mars  2004. (Information)

[RFC4341]	S. Floyd, E. Kohler, "Profil d'identifiant 2 de protocole de contrôle d'encombrement de datagrammes (DCCP) : Contrôle d'encombrement de style TCP", mars 2006. (P.S. ; MàJ par RFC8311)

[V03]	Arun Venkataramani, août 2003. Citation pour mémoire.

 	Adresse des auteurs
Sally Floyd	Eddie Kohler	Jitendra Padhye	
ICSI Center for Internet Research	4531C Boelter Hall	Microsoft Research	
1947 Center Street, Suite 600	UCLA Computer Science Department	One Microsoft Way	
Berkeley, CA 94704	Los Angeles, CA 90095	Redmond, WA 98052	
USA	USA	USA	
mél : floyd@icir.org 	mél : kohler@cs.ucla.edu 	mél : padhye@microsoft.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administratif (IASA) de l'IETF.