Fwd: Re: [e2e] Why Buffering?

[Giuseppe Bianchi < >]

Sembra essere il periodo delle paternali ;-). Dopo la paternale off 
topic sugli automi a stati finiti, questa paternale e' invece on topic.

Premessa. La mailing list end2end-interest e' secondo me di gran 
lunga la migliore mailing list relativa a problemi architetturali di 
internet. La migliore anche e soprattutto perche' frequentata da 
bravi "nonnetti" (by the way, ben piu' nonnetti di me) che hanno 
FATTO pezzi/protocolli di internet tanti anni fa. E' una mailing list 
in stile "herpes", ben diversa penso da tutte quelle che frequentate 
voi. Sta zitta per settimane. Poi, spesso in conseguenza di qualche 
email innocente magari mandata da qualche newcomer, si scatenano 
dibattiti a volte anche violenti (!) che in genere toccano problemi 
di tipo filosofico-strutturale. Tra le varie risposte in genere 
girano email veramente interessanti sia scritte da gente che di 
queste cose ci capisce DAVVERO, sia scritte da gente che tira fuori 
aspetti storici pregevoli. Personalmente vi RACCOMANDO di iscrivervi, 
standovene ovviamente rigorosamente zitti (almeno per qualche annetto 
finche' non siete preparati a puntino). Al peggio poi cancellerete 
senza leggere. Ma vi assicuro che qualche discussione merita davvero.

Dopo questa premessa, arrivo al punto. Nella discussione scatenatasi 
in questi giorni, qualcuno ha chiesto a cosa serve il buffering nelle 
reti. E fin qui tutto normale; domanda lecita, se uno e' un beginner. 
La cosa interessante, come al solito in questa mailing list, e' lo 
sviluppo successivo della discussione... Leggetevi per esempio cosa 
scrive tale David Reed (un vecchietto saggio) in quest'ultima email, 
a fronte di un paio di email precedenti che, nel "rispondere" non 
denotano sicuramente una particolare brillantezza culturale 
(eufemismo --  notate per esempio l'incredibile "perla" di tale Paddy 
Ganti, un tizio a cui suggerirei di contare fino a 100.000 prima di 
omaggiarci di cotali "risposte" e per di piu' per iscritto; perla che 
sicuramente archiviero' nel mio directory "perle rare" a futura memoria).

La morale della risposta di David Reed e' che l'ignoranza oggi regna 
sovrana, e che e' sconvolgente scoprire come gente anche di un certo 
livello (dottorato di ricerca) non ha le "basi" teoriche minimali. 
Chi tra voi, durante il corso, si e' magari chiesto: "ma 'sto bianchi 
perche' ci rompe il xxxxx con tutta 'sta teoria che non serve a 
nulla" spero ora capira' il "perche'"...

Saluti, GB

> Date: Sat, 20 Jun 2009 20:41:20 -0400
> From: "David P. Reed" 
> <
>  >
>
> Dave - This is variously known as Little's Theorem or Little's 
> Lemma.  The general pattern  is true for many stochastic arrival 
> processes into queues.  It precedes Kleinrock, and belongs to queueing theory.
>
> I continue to be shocked, and dismayed, at the number of practicing 
> protocol designers who have never learned (or even *studied* without 
> learning) basic queueing theory.  In my opinion, one cannot be 
> qualified to speak about protocol engineering without working 
> knowledge of queueing theory, control theory, and information 
> theory.  Yet most CS depts. fail their students by completely 
> ignoring these disciplines in favor of teaching network protocols as 
> a course in bit-field layouts.
>
> One can actually get a Ph.D. in Computer Networking without ever 
> studying or using these important mathematical tools.
>
>
> On 06/20/2009 12:23 AM, Dave CROCKER wrote:
> > Paddy Ganti wrote:
> > > The real reason for having buffers is the fact that information about
> > > congestions takes some time to propagate. (In TCP/IP congestion are
> > > detected by seeing lost packets).
> >
> >
> > In the late 70s and 80s, Kleinrock gave a rather simple explanation 
> > for using queuing (buffering) that I think is compatible with Antonov's point:
> >
> >      After a lengthy and detailed introduction, he put up a graph 
> > of throughput (x) versus delay (y).  It had a very shallow 
> > increase until hitting a very sharp knee and then was almost vertical.
> >
> >      He observed that before the knee, you don't need queuing 
> > because you don't have any congestion.  And after the knee, 
> > queuing doesn't help because you simply don't have enough capacity.
> >
> > Queuing is for transient problems rather than an excessive 
> > average:  The knee of the curve.
> >
> > d/