3.2. SCHC Compound ACK Behavior (Comportamento ACK Composto SCHC)

3.2. SCHC Compound ACK Behavior (Comportamento ACK Composto SCHC)

Il comportamento SCHC ACK-on-Error è descritto nella Sezione 8.4.3 di [RFC8724]. Il presente documento modifica leggermente questo comportamento. Nella specifica SCHC di base, un SCHC ACK riporta solo una bitmap per la ricezione di esattamente una window di tiles. La presente specifica SCHC Compound ACK estende il formato del messaggio SCHC ACK in modo che possa contenere più bitmaps, con ogni bitmap identificata dal suo corrispondente window number.

Come presentato in [RFC8724], il formato SCHC ACK può essere considerato un caso speciale di SCHC Compound ACK in cui riporta solo le tiles di una window. Pertanto, il SCHC Compound ACK è retrocompatibile con il formato SCHC ACK presentato in [RFC8724]. Il ricevitore può presumere che il mittente non supporti il SCHC Compound ACK se, sebbene il SCHC Compound ACK inviato dal ricevitore riporti perdite in più di una window, il mittente non rinvia alcuna tile da windows diverse dalla prima window riportata nel SCHC Compound ACK. In tal caso, il ricevitore può inviare SCHC Compound ACKs con solo una window di tiles.

Inoltre, viene introdotta una certa flessibilità rispetto a [RFC8724] in quanto il ricevitore ha la capacità di rispondere (o meno) all'All-0 con un SCHC Compound ACK, a seconda di determinati parametri, come le condizioni di rete, la dimensione del buffer/cache del mittente e il ritardo dell'applicazione supportato. Si noti che anche se il protocollo consente tale flessibilità, i criteri di decisione effettivi non sono specificati in questo documento. L'applicazione DEVE impostare i valori del timer di scadenza in base al momento in cui si prevede di ricevere il feedback, ad esempio dopo l'All-0 o dopo l'All-1.

La Sezione 3.2.1 (e le sue sottosezioni) sostituisce la completa Sezione 8.4.3 (e le sue sottosezioni) di [RFC8724].