[ih] principles of the internet

[John Day]

At 20:59 -0400 2010/06/01, Noel Chiappa wrote:
>     > From: Alex McKenzie <amckenzie3 at yahoo.com>
>
>     > I disagree with John's definition of what it means to be a datagram
>     > network. In my opinion, all that is required is the independent routing
>     > of packets.
>
>He'd probably call that a packet network... :-) But I do think he has a bit
>of a point, though, that the _service interface_ offered to the user is
>important.
>
>For example, you could, today, build a network that was POTS user interface,
>but independently routed packets inside. (Nobody would bother to do such a
>crazy thing, I agree, but it's technically possible! :-) But I wouldn't
>really call the result a 'datagram network'....

I would.  Datagrams are internal function of the layer.  Whether they 
are used has no reason to be visible over the layer boundary. One 
requests a certain form of service.  The layer determines what it has 
to do to provide it.  How it does it is none of your business. 
Hiding internal operation is what a layer is all about.

>
>     > the ARPANET did go to great lengths to insure that messages, once
>     > accepted, were correctly delivered to the recipient with high
>     > probability. ARPANET also kept messages between a given pair of Hosts
>     > in order. These two design decisions put a great deal of complication
>     > into the IMPs.
>     > It should be remembered, though, that the original concept of the
>     > ARPANET was that each Host would contain a program to do all the
>     > store-and-forward functions. It was Wes Clark's idea that a
>     > minicomputer should sit next to each Host to do all the hard jobs
>     > ... so that each Host did not have to write programs to get these jobs
>     > done. Larry Roberts was enthusiastic about this idea because it
>     > provided a more cost-effective way of getting the programming done,
>     > done on time, and done correctly. So it was a design decision that the
>     > complexity SHOULD all go in the IMPs.
>
>Excellent point.

Right. The IMP as front end.  I remember the RFCs discussing the 
buffering problems after the Christmas lock up and coming to the 
conclusion that no amount of memory in the IMP would guarantee it 
couldn't happen, so the switches would have to be able to throw 
things away and final reassembly would have to be in the hosts.

>
>	Noel