3.2. SCHC Compound ACK Behavior (Comportement ACK Composé SCHC)

3.2. SCHC Compound ACK Behavior (Comportement ACK Composé SCHC)

Le comportement SCHC ACK-on-Error est décrit dans la Section 8.4.3 de [RFC8724]. Le présent document modifie légèrement ce comportement. Dans la spécification SCHC de base, un SCHC ACK rapporte uniquement une bitmap pour la réception d'exactement une window de tiles. La présente spécification SCHC Compound ACK étend le format du message SCHC ACK de sorte qu'il puisse contenir plusieurs bitmaps, chaque bitmap étant identifiée par son numéro de window correspondant.

Comme présenté dans [RFC8724], le format SCHC ACK peut être considéré comme un cas spécial de SCHC Compound ACK dans lequel il rapporte uniquement les tiles d'une window. Par conséquent, le SCHC Compound ACK est rétrocompatible avec le format SCHC ACK présenté dans [RFC8724]. Le récepteur peut supposer que l'émetteur ne supporte pas le SCHC Compound ACK si, bien que le SCHC Compound ACK envoyé par le récepteur rapporte des pertes dans plus d'une window, l'émetteur ne renvoie aucune tile des windows autres que la première window rapportée dans le SCHC Compound ACK. Dans ce cas, le récepteur peut envoyer des SCHC Compound ACKs avec une seule window de tiles.

De plus, une certaine flexibilité est introduite par rapport à [RFC8724] en ce sens que le récepteur a la capacité de répondre (ou non) au All-0 avec un SCHC Compound ACK, en fonction de certains paramètres, tels que les conditions du réseau, la taille du tampon/cache de l'émetteur et le délai d'application pris en charge. Notez que même si le protocole permet une telle flexibilité, les critères de décision réels ne sont pas spécifiés dans ce document. L'application DOIT définir les valeurs d'expiration du temporisateur en fonction du moment où le retour d'information est censé être reçu, par exemple après le All-0 ou après le All-1.

La Section 3.2.1 (et ses sous-sections) remplace la Section 8.4.3 complète (et ses sous-sections) de [RFC8724].