I. Introduzione

Come annunciato in NEW/RFC #53, sottoponiamo qui il protocollo a critiche, commenti, ecc. Intendiamo che questo protocollo diventi il protocollo ufficiale iniziale e saremo quindi molto lieti se non verranno sollevate obiezioni serie. Accoglieremo tuttavia critiche di ogni genere fino al 13 luglio 1970; tali critiche dovranno essere pubblicate come NWG/RFC o indirizzate al primo autore.

Dopo il 13 luglio si deciderà se adottare questo protocollo (o una sua leggera variante) oppure se riprogettarlo e sottoporlo nuovamente a critica.

Soltanto il protocollo

Nelle precedenti discussioni sul protocollo non è stata fatta una chiara distinzione tra le specifiche valide per l'intera rete e le strategie locali. Affermiamo qui che le uniche questioni che riguardano l'intera rete sono i formati dei messaggi e le restrizioni sul contenuto dei messaggi. L'implementazione di un Network Control Program (NCP) e la scelta delle chiamate di sistema sono questioni strettamente locali.

Questo documento si limita alle sole questioni che riguardano l'intera rete e non tratterà quindi le chiamate di sistema né le tabelle dell'NCP; tuttavia un protocollo è inutile senza un NCP e un insieme di chiamate di sistema, perciò abbiamo dedicato molto impegno alla realizzazione di un NCP prototipico. Questo lavoro è descritto in NWG/RFC #55, e il lettore dovrebbe mettere in relazione il protocollo qui presentato con i suggerimenti per il suo uso lì esposti. È importante ricordare, però, che il contenuto di NWG/RFC #55 è solo indicativo e che proposte alternative dovrebbero essere esaminate prima di scegliere un'implementazione.

Controllo di flusso

Nel corso della progettazione di questo protocollo abbiamo capito che il controllo di flusso è più complesso di quanto immaginassimo. Riteniamo ora che le tecniche di controllo di flusso saranno uno dei temi di maggiore attenzione con l'aumentare del traffico di rete. Abbiamo quindi tratto beneficio da alcune idee suggerite da Richard Kaline e Anatol Holt e abbiamo modificato la procedura di controllo di flusso. (I difetti del nostro schema sono, naturalmente, solo colpa nostra.) Questa nuova procedura ha limiti dimostrabili, ma ha il vantaggio di essere implementabile in modo più pulito e di supportare l'uso iniziale della rete. È l'unico cambiamento sostanziale rispetto al protocollo già concordato.

Il nuovo meccanismo di controllo di flusso richiede che l'host ricevente allochi spazio di buffer per ogni connessione e comunichi all'host mittente quanto spazio, in bit, è disponibile. L'host mittente tiene traccia di quanto spazio è disponibile e non invia mai più testo di quanto ritiene che l'host ricevente possa accettare.

Per implementare questo meccanismo, l'host mittente mantiene un contatore associato a ciascuna connessione. Il contatore è inizializzato a zero, viene incrementato dai comandi di controllo inviati dall'host ricevente e decrementato della lunghezza del testo di ogni messaggio inviato sulla connessione. All'host mittente è vietato inviare testo più lungo del valore del contatore, quindi il contatore non scende mai sotto zero.

Idealmente, l'host ricevente allocherà un po' di spazio di buffer non appena la connessione è stabilita. La quantità allocata non deve mai superare ciò che il ricevente può garantire di accettare. Man mano che il testo arriva, occupa lo spazio di buffer allocato. Quando il processo ricevente assorbe dal buffer il testo in attesa, l'NCP rimanda una nuova allocazione di spazio per quella connessione. L'NCP può allocare spazio anche se il processo ricevente non ha assorbito il testo in attesa, se ritiene opportuno dello spazio di buffer aggiuntivo. Analogamente, l'NCP può decidere di non riallocare lo spazio di buffer dopo che il processo ricevente lo ha reso disponibile.

Il comando di controllo che alloca lo spazio è

ALL <link> <space>

Questo comando è inviato soltanto dall'host ricevente all'host mittente.

Questa formulazione del controllo di flusso rende superflui i comandi RSM e SPD di NWG/RFC #36, nonché il messaggio Host-IMP di tipo 10 e i messaggi IMP-Host di tipo 10 e 11 dell'attuale revisione del BBN Report 1822.

Il limite evidente di questo schema è che all'host ricevente non è consentito basarsi sull'utilizzo medio dei buffer: si assume sempre il caso peggiore. Se sono aperte solo poche connessioni, è improbabile che si ottenga un risparmio significativo. Con più di qualche connessione, però, l'utilizzo medio dei buffer sarà molto inferiore allo spazio di buffer allocato. Abbiamo esaminato estensioni di questo protocollo che includerebbero un'allocazione adattiva e crediamo che siano realizzabili. Per il momento questo schema limitato sembra il migliore, e contiamo di discutere in seguito schemi più sofisticati. Anche il vecchio schema dei RFNM speciali, ecc. resta in discussione.

Per rispondere alle domande e discutere i dettagli terremo due riunioni di rete. La prima si svolgerà il 29 giugno a Harvard e la seconda il 1º luglio a UCLA. Chiediamo che a ogni riunione partecipi non più di un programmatore per host e che ciascun host sia rappresentato a una sola di queste riunioni. Due di noi (J.N. e S.C.) saranno presenti a entrambe le riunioni.

Per prenotare la partecipazione alla riunione di Harvard, contattare

   Mrs. Margi Robison
   (617) 495-3989
      or 495-3991

Per prenotare la partecipazione alla riunione di UCLA, contattare Mrs. Benita Kirstel (213) 825-2368.