[ih] internet-history Digest, Vol 84, Issue 10

[Bob Braden]

On 5/21/2014 12:00 PM, internet-history-request at postel.org wrote:
> Send internet-history mailing list submissions to
> 	internet-history at postel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.postel.org/mailman/listinfo/internet-history
> or, via email, send a message with subject or body 'help' to
> 	internet-history-request at postel.org
>
> You can reach the person managing the list at
> 	internet-history-owner at postel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of internet-history digest..."
>
>   
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 May 2014 10:31:31 -0400 (EDT)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> Subject: Re: [ih] internet-history Digest, Vol 84, Issue 4
> To: internet-history at postel.org
> Cc: jnc at mercury.lcs.mit.edu
> Message-ID: <20140521143131.5577A18C0E0 at mercury.lcs.mit.edu>
>
>      > From: Guy Almes <galmes at tamu.edu>
>
>      > Clarity on the degree to which the authors of the early TCP RFCs did
>      > not recognize the importance of developing very good congestion control
>      > algorithms.
>
> I think it was as much (if not more) an issue of 'we didn't have the
> capability to do one as good as Van's' as "recogniz[ing] the importance of
> developing [a] very good" one.

Very definitely the latter. Van brought an entirely new perspective to 
the problem, from his experience designing digital control systems for LBL.

>
> To what degree that was the lack of a good understanding of the problem, and
> to what degree simply that Van was better at control theory and analysis of
> the system than the rest of us, is a good question, and one I don't have a
> ready answer too. But if you look at something like "Why TCP Timers Don't
> Work Well", it's clear we all just didn't understand what could be done.

It is not a "good question", there is no doubt.
>
> We did understand that congestion control was important (although my
> recollection is that I don't think we clearly foresaw the severe congestive
> collapse which the ARPANET-based section of the Internet suffered not too
> long before Van started working on the problem). Hence, we did put a certain
> amount of thought into congestion control (Source Quench, the Nagle
> algorithm, etc).

Nagle and Partridge had only recently made us clearly aware of the 
congestion collapse problem; Mills had already produced the disasterous 
consequences in NSFnet  ;-)


> My vague recollection is that in the very early days we were more focused on
> flow control in the hosts, rather than congestion control in the network, but

Yes, and to the extent we did recognize the problem, we had no clue 
about how to cure it. Van worked out, and taught the rest of  us, the 
fundamentals of "packet physics".  Once he explained about ack clocking, 
slow start, etc., it made sense, but that does not mean we figured it 
out ourselves.

  I think we did understand that congestion in the network was also aan 
issue (hence SQ,

Yes, and Source Quench was a perfect example of our pre-VJ 
cluelesssness. Wwhat seemed a plausible congestion control mechanism was 
in fact completely broken.

etc). The thing is that we understand all this so much better now - the 
importance of congestion control, source algorithms to control it, etc - 
and we were really groping in the dark back then. The ARPANET (because 
of its effective VC nature, with flow and thus congestion control built 
into the network itself) hadn't given us much in the way of advance 
experience in this particular area. So, as with many things, what is 
crystal clear in

Quite true.


Also, in fairness, we were being stressed by the complexity of making 
the entire system work at all in the face of exponential growth.  We 
struggled to make routing actually work  despite repeated routing table 
overflows, and we had to solve the network management problem. Until we 
began to experience congestion collapse in NSFnet, congestion control 
seemed more an academic problem.  The early Internet was a continuing 
"success disaster".

Bob Braden


to solve  hindsight was rather obscured without the mental frameworks, 
etc that we have now (e.g. F=ma). > Clarity on how/when it began to 
become evident that the naive > algorithms documented in the TCP RFCs 
and used in early testing would > themselves become the source of 
trouble. Not just testing, but early service! (Q.v. the ARPANET-local 
congestive collapse.) But your wording makes it sound like they were 
positively incorrect. Well, not really (to my eyes); they mostly simply 
were not _always effective_ at controlling congestion (although they did 
generate some useless, duplicate packets). But they were not positively 
defective, the way TFTP was, with Sorcerer's Apprentice Syndrome: 
http://en.wikipedia.org/wiki/Sorcerer's_Apprentice_Syndrome Noel 
------------------------------ ------------------------------



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140521/1575331a/attachment.htm>