Introduzione
BBN ci ha consegnato i commenti allegati al NWG/RFC 33, ma non ha voluto pubblicarli per non metterci in imbarazzo. A parte l'imbarazzo, abbiamo trovato i commenti particolarmente utili e abbiamo deciso di condividerli con i nostri amici. L'autore è Bill Crowther.
Ho trovato due errori sostanziali nell'Host Protocol Paper, che per il resto era un ottimo documento. Entrambi riguardano un fraintendimento della natura dell'IMP come dispositivo di comunicazione, e in particolare della natura della memorizzazione temporanea che un IMP deve effettuare. Gli autori considerano la rete come un dispositivo in cui si spinge un messaggio che viaggia un po', attende nei buffer per intervalli di tempo considerevoli e poi emerge a destinazione. In realtà un modello migliore sarebbe che il messaggio riemerga un istante dopo essere stato inserito. Se è vero che esiste un ritardo, esso è imposto per la maggior parte dall'hardware delle linee telefoniche. La memorizzazione temporanea nell'IMP è minima ed è dedicata al controllo degli errori e a picchi momentanei di traffico.
Poiché non possiamo obbligare un host a prendere un messaggio, abbiamo costruito un elaborato meccanismo RFNM che sospende ogni nuovo ingresso finché non lo fa. Questo meccanismo è un tentativo imperfetto di risolvere un problema di comunicazione molto difficile. L'intento è regolare il traffico in modo che, nel momento in cui l'host preleva il suo messaggio dall'IMP, il messaggio successivo arrivi sulla linea telefonica e non si verifichi alcuna memorizzazione temporanea.
In realtà non riusciamo a ottenere questo, e abbiamo quindi incluso una memorizzazione temporanea per far fronte ai picchi di traffico. Questi buffer sono inutili allo scopo previsto se non sono vuoti. Solo i buffer vuoti sono disponibili per assorbire un picco di traffico.
I due errori specifici si trovano alle pagine 5 e 23. A pagina 5 gli autori dicono: « Questo scopo implica l'assunto che un utente non usi collegamenti multipli per ottenere una banda larga. » In realtà uno degli scopi principali dei collegamenti è ottenere una banda più larga.
Vogliamo consentire la maggiore larghezza di banda possibile. I nostri guai non nascono dalla banda larga, ma da uno squilibrio tra ingresso e uscita. Gli autori hanno giustamente notato che i collegamenti multipli compromettono il meccanismo RFNM, rendendo più difficile il nostro compito, ma hanno etichettato male la natura del problema.
Ancora a pagina 5: « Un assunto ancora più fondamentale, naturalmente, è che il carico della rete provenga da alcuni utenti che trasmettono sequenze di messaggi, anziché da molti utenti che trasmettono messaggi singoli per coincidenza. » Siamo in ottima forma contro gli utenti di messaggi singoli quando i loro messaggi sono correlati in modo casuale. Le statistiche sono tutte a nostro favore e abbiamo procedure speciali per le (rare) coincidenze. I nostri problemi nascono dalle coincidenze non casuali, e abbiamo preso precauzioni speciali contro gli utenti che trasmettono raffiche (sequenze) di messaggi. Presumiamo ogni genere di utenti e ci proteggiamo di conseguenza.
Alle pagine 23 e 24 ci sono 4 frasi critiche che lasciano intendere che il progetto del sistema avrebbe potuto essere migliorato consentendo all'host di specificare quale di diversi ingressi in attesa desidera accettare. Ammettiamo che l'host debba memorizzare temporaneamente questi messaggi per i suoi utenti, ma contestiamo fermamente che l'IMP abbia la capacità di effettuare questa memorizzazione.
Se operiamo in modo ideale, avremmo al massimo un messaggio per l'host in qualsiasi momento. Se ne abbiamo più di uno, abbiamo urgentemente bisogno che l'host accetti questi messaggi, perché la nostra capacità di far fronte ai picchi di traffico è ormai sotto lo standard. Al momento consentiamo tre messaggi di lunghezza completa in un IMP per il suo host prima di iniziare ad accumulare traffico nella rete. « Tre » non basta per aiutare l'host e al tempo stesso conservare una riserva per i picchi di traffico.
Ma se la memorizzazione temporanea è necessaria, perché non procurarsi più memoria e farla nell'IMP? Perché la memorizzazione temporanea è una funzione dell'host, è diversa in ogni sistema a tempo condiviso, è difficile da controllare su un canale seriale occupato, potrebbe non servire affatto in certi luoghi ed è meglio farla dove la memoria in più può essere condivisa efficientemente dal sistema operativo dell'host.
Ripeto: i buffer dell'IMP devono essere vuoti, altrimenti non svolgono il loro scopo di comunicazione.
Le frasi incriminate sono:
Paragraph 2 sentence 3
" 3 all
" 4 sentences 1 and 2 (80ms is hardware screw adjustable)
" 4 sentence last
Nota: Questo RFC è stato reso in forma leggibile da una macchina per l'inserimento negli archivi RFC in linea da Jeff & Christy McClellan 2/98.