From cls at rkey.com  Mon Nov  2 06:11:17 2009
From: cls at rkey.com (Craig Simon)
Date: Mon, 02 Nov 2009 09:11:17 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091030152010.1A6366BE697@mercury.lcs.mit.edu>
References: <20091030152010.1A6366BE697@mercury.lcs.mit.edu>
Message-ID: <4AEEE885.9070408@rkey.com>

Here's another article on the 40th anniversary of the first host to host 
communication on the Arpanet, including a video of Leonard Kleinrock 
with the original IMP log (at the very end).

http://seedmagazine.com/content/article/lo_and_behold_the_internet/

Craig Simon


From bernie at fantasyfarm.com  Mon Nov  2 06:53:48 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 02 Nov 2009 09:53:48 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <4AEEE885.9070408@rkey.com>
References: <20091030152010.1A6366BE697@mercury.lcs.mit.edu>,
	<4AEEE885.9070408@rkey.com>
Message-ID: <4AEEAC2C.22231.1C21A93E@bernie.fantasyfarm.com>

On 2 Nov 2009 at 9:11, Craig Simon wrote:

> Here's another article on the 40th anniversary of the first host to host 
> communication on the Arpanet, including a video of Leonard Kleinrock 
> with the original IMP log (at the very end).

Does the IMP log include the part where the BBN folk had been exchanging 
messages over the "net" for a couple of weeks before UCLA and SRI started 
getting their host interfaces and software running?

The event that Len keeps trumpeting as the first message sent over the 
net was, of course, nowhere *NEAR* that: it was the first, staggering 
steps at debugging the *host* code and interfaces at UCLA and SRI.  The 
net, itself, had been up and running for a little while by that time.  
Ben Barker [who was at UCLA] reported when he first saw the light on the 
imp lights-panel tell him that the SRI IMP had just come up, which to my 
view would _really_ be when the ARPAnet first came alive.

  /Bernie\


-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From jnc at mercury.lcs.mit.edu  Mon Nov  2 07:43:08 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  2 Nov 2009 10:43:08 -0500 (EST)
Subject: [ih] ARPANet anniversary
Message-ID: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>

    > From: "Bernie Cosell" <bernie at fantasyfarm.com>

    > the first message sent over the net was, of course, nowhere *NEAR*
    > that ... The net, itself, had been up and running for a little while by
    > that time. ... first saw the light on the imp lights-panel tell him
    > that the SRI IMP had just come up, which to my view would _really_ be
    > when the ARPAnet first came alive.

As a systems person, I have a somewhat different perspective. Yes, the event
you mention was a very important milestone, but to me, the most significant
milestone would have been something that exercised the entire system, and did
_what the system was intended to achieve as an overall goal_: i.e. have a
packet go from the source host, through the host and IMP host->Imp interface
pair, across the network, out the Imp->host interface pair on the other side,
and into the destination host.

Something I'm curious about, though: how much of this stuff was all
demonstrated internally at BBN, first? E.g. I would have guessed that the
first frame (for want of a better word to differentiate IMP-IMP datagrams
from host-host datagrams) sent from one IMP to another happened at BBN? Or
was there insufficient hardware/testbed stuff to do that, and in fact the
first IMP-IMP frames sent actually were sent between the SRI and UCLA IMPs?
Did BBN have any host-IMP host interfaces (and hosts) they could play with,
or were the host interfaces at the user sites the first ones actually plugged
in and tried?

	Noel


From vint at google.com  Mon Nov  2 08:06:14 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 2 Nov 2009 11:06:14 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>
References: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>
Message-ID: <CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>

there were "fake host" exchanges almost certainly but the host-host  
protocols were some time in coming. I drove traffic into the net  
either to fake hosts or round-trip from the Sigma-7 at UCLA to get  
statistical measurements and to test Bob Kahn's hypotheses about  
lockup. That would be have been end of 1969 or perhaps more likely  
early in 1970. But going end-end through the BBN 1822 host/IMP  
interfaces would be the key to noel's metric (and mine as I agree with  
him).

v

On Nov 2, 2009, at 10:43 AM, Noel Chiappa wrote:

>> From: "Bernie Cosell" <bernie at fantasyfarm.com>
>
>> the first message sent over the net was, of course, nowhere *NEAR*
>> that ... The net, itself, had been up and running for a little  
>> while by
>> that time. ... first saw the light on the imp lights-panel tell him
>> that the SRI IMP had just come up, which to my view would _really_ be
>> when the ARPAnet first came alive.
>
> As a systems person, I have a somewhat different perspective. Yes,  
> the event
> you mention was a very important milestone, but to me, the most  
> significant
> milestone would have been something that exercised the entire  
> system, and did
> _what the system was intended to achieve as an overall goal_: i.e.  
> have a
> packet go from the source host, through the host and IMP host->Imp  
> interface
> pair, across the network, out the Imp->host interface pair on the  
> other side,
> and into the destination host.
>
> Something I'm curious about, though: how much of this stuff was all
> demonstrated internally at BBN, first? E.g. I would have guessed  
> that the
> first frame (for want of a better word to differentiate IMP-IMP  
> datagrams
> from host-host datagrams) sent from one IMP to another happened at  
> BBN? Or
> was there insufficient hardware/testbed stuff to do that, and in  
> fact the
> first IMP-IMP frames sent actually were sent between the SRI and  
> UCLA IMPs?
> Did BBN have any host-IMP host interfaces (and hosts) they could  
> play with,
> or were the host interfaces at the user sites the first ones  
> actually plugged
> in and tried?
>
> 	Noel



From bernie at fantasyfarm.com  Mon Nov  2 08:21:32 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 02 Nov 2009 11:21:32 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>
References: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>
Message-ID: <4AEEC0BC.5304.1C71FA95@bernie.fantasyfarm.com>

On 2 Nov 2009 at 10:43, Noel Chiappa wrote:

> Something I'm curious about, though: how much of this stuff was all
> demonstrated internally at BBN, first? E.g. I would have guessed that the
> first frame (for want of a better word to differentiate IMP-IMP datagrams
> from host-host datagrams) sent from one IMP to another happened at BBN?

Yes.  We had a three-node network up and fully running [we could debug 
the routing code and such with it].

> Did BBN have any host-IMP host interfaces (and hosts) they could play with,
> or were the host interfaces at the user sites the first ones actually plugged
> in and tried?

Those were the first *hardware* host interfaces.  I can't remember when 
we connected up an actual host to an IMP at BBN -- the host interface 
hardware must have been shaken down by Severo's crew but I can't remember 
anything about how that happened.  The host *code* in the IMP was already 
pretty much debugged: the way we implemented the imp-TTY to imp-TTY 
communication (which had been up and working solidy quite a while before 
the IMP was even shipped west) was by a "fake host".  What the TTY 
handler did, for both send and receive, was simulate acting as a real 
host [and so all the reassembly, RFNMs, etc, stuff was exercised by it].  
There was another fake host that was a little DDT-like debugger that also 
ran as a host and hacking from the IMP console TTY was a little like 
using telnet [a decade later..:o)]: you had to tell the local TTY handler 
"connect me to Host X at IMP Y" and then it just acted as a regular host, 
sending and receiving traffic.  If the "remote host" was the other IMP's 
TTY, then we had a primitive IM system; if the "remote host" was the 
other IMP's debugger, we could restart the IMP, install patches, etc.  We 
could [did] help debug actual host code that way [sending to/from a 
"real" host from our TTY "fake" one].

And so, also as a systems guy, that's why I was relatively unimpressed 
with the host->host "L O <crash>": the *system* had _already_ been pretty 
much tested.  The 1822 host interface was just one of a number of "host 
plugins" that the IMP code handled [including the TIP, which also ran as 
a "fake host"].  From *my* point of view, the only real new ground that 
was broken there [and that was done well before the "L O"] was that the 
Imp-Imp modem code was actually running over a relatively-long real-world 
communications line [with real delays, errors, noise, etc] rather than on 
our testbed].

  /Bernie\
-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From dhc2 at dcrocker.net  Mon Nov  2 09:11:38 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 02 Nov 2009 09:11:38 -0800
Subject: [ih] ARPANet anniversary
In-Reply-To: <CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>
References: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>
	<CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>
Message-ID: <4AEF12CA.3000701@dcrocker.net>



Vint Cerf wrote:
>  But going
> end-end through the BBN 1822 host/IMP interfaces would be the key to 
> noel's metric (and mine as I agree with him).


+1

In spite of being another UCLA guy, I'm a bit embarrassed by its being touted as 
the birth of the Internet, given the earlier work elsewhere.  That said I do 
believe that at legitimate host-to-host, end-to-end, packet-based demonstration 
would be the best criterion for declaring the live birth of the world we now 
call the Internet.   It would be the networking equivalent of "Watson, come 
here; I need you."

If that was at BBN, fine. If it was the first long-distance exchange, between 
two sites fine. However the demo at UCLA seems to be the most touted.

But we should perhaps first settle on the criteria.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From LarrySheldon at cox.net  Mon Nov  2 09:31:59 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 02 Nov 2009 11:31:59 -0600
Subject: [ih] ARPANet anniversary
In-Reply-To: <4AEF12CA.3000701@dcrocker.net>
References: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>	<CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>
	<4AEF12CA.3000701@dcrocker.net>
Message-ID: <4AEF178F.1070706@cox.net>

Dave CROCKER wrote:
> 
> 
> Vint Cerf wrote:
>>  But going
>> end-end through the BBN 1822 host/IMP interfaces would be the key to 
>> noel's metric (and mine as I agree with him).
> 
> 
> +1
> 
> In spite of being another UCLA guy, I'm a bit embarrassed by its being 
> touted as the birth of the Internet, given the earlier work elsewhere.  
> That said I do believe that at legitimate host-to-host, end-to-end, 
> packet-based demonstration would be the best criterion for declaring the 
> live birth of the world we now call the Internet.   It would be the 
> networking equivalent of "Watson, come here; I need you."
> 
> If that was at BBN, fine. If it was the first long-distance exchange, 
> between two sites fine. However the demo at UCLA seems to be the most 
> touted.
> 
> But we should perhaps first settle on the criteria.

How does this incident and history's view of it compare to the "What
Hath God Wrought" and "Watson, Come here, I need you" incidents.

Remember, History is written by the winners.

-- 
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information:
	http://tinyurl.com/4sqczs
	http://tinyurl.com/7tp8ml
	



From bernie at fantasyfarm.com  Mon Nov  2 10:33:28 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 02 Nov 2009 13:33:28 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>
References: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>,
	<CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>
Message-ID: <4AEEDFA8.4325.1CEAC6C7@bernie.fantasyfarm.com>

On 2 Nov 2009 at 11:06, Vint Cerf wrote:

> .... But going end-end through the BBN 1822 host/IMP  
> interfaces would be the key to noel's metric (and mine as I agree with  
> him).

I guess I disagree -- *IF* it was actually a successful communication 
[which as I understand took a while longer, since the original "test" 
crashed], then that'd be right: the first time someone at UCLA 
*LOGGED*IN* to SRI.  YAY!!  -- does anyone know when *THAT* actually 
happened??

But the actual test that Len has ensured is fabled in story and song 
exercised little that hadn't/couldn't be tested previously.  The sigma-7 
had already communicated with its IMP [through its 1822 interface and as 
far as the sigma-7 was concerned was as end-to-end as any other].  I know 
Ben reported helping Mike Wingfield with the interface while he was there 
and I helped debug another problem with the interface some time later 
[but before the SRI connection]].  I actually don't know what happened at 
SRI prior to its connection [there's no reason I can see why they 
couldn't have tried to "log in" locally from the IMP TTY but I don't know 
a lot about the host side of those tests].

As for history written by the 'winner' -- that's not exactly right: often 
it is written by the person with the best PR instincts.

  /Bernie\

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From jnc at mercury.lcs.mit.edu  Mon Nov  2 11:02:05 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  2 Nov 2009 14:02:05 -0500 (EST)
Subject: [ih] ARPANet anniversary
Message-ID: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>

    > From: Dave CROCKER <dhc2 at dcrocker.net>

    > the live birth of the world we now call the Internet

Call me picky, but I do like to differentiate between 'the Internet' and 'the
global communcation/information catenetwork'. The birth of the ARPAnet is, I
think, the birth of the latter, but to me, not the Internet. (I.e. the entity
which speaks TCP/IP - although it's not clear that definition of 'the
Internet' is really the best definition, though).

Although the ARPAnet was clearly the forerunner, I think there are important
distinctions, in particular the Internet's express intent to incorporate a
wide range of disparate data communications subsystems into a tightly-coupled
integrated entity.

And speaking of the Internet as a distinct entity, whats it's birth-day
anyway? I would call it the first day on which a packet was sent from one
host, across a particular kind of network, through a router (or gateway as we
called them back then), across another network, into another host. (That would
have been a TCP packet, I guess - no IP back then!) So where and when was
that?

	Noel


From craig at aland.bbn.com  Mon Nov  2 11:37:15 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Mon, 02 Nov 2009 14:37:15 -0500
Subject: [ih] ARPANet anniversary
Message-ID: <20091102193715.6913A28E137@aland.bbn.com>

>     > From: Dave CROCKER <dhc2 at dcrocker.net>
> 
>     > the live birth of the world we now call the Internet
> 
> Call me picky, but I do like to differentiate between 'the Internet' and 'the
> global communcation/information catenetwork'. The birth of the ARPAnet is, I
> think, the birth of the latter, but to me, not the Internet. (I.e. the entity
> which speaks TCP/IP - although it's not clear that definition of 'the
> Internet' is really the best definition, though).
> 
> Although the ARPAnet was clearly the forerunner, I think there are important
> distinctions, in particular the Internet's express intent to incorporate a
> wide range of disparate data communications subsystems into a tightly-coupled
> integrated entity.
> 
> And speaking of the Internet as a distinct entity, whats it's birth-day
> anyway? I would call it the first day on which a packet was sent from one
> host, across a particular kind of network, through a router (or gateway as we
> called them back then), across another network, into another host. (That woul
> d
> have been a TCP packet, I guess - no IP back then!) So where and when was
> that?

First TCP running over a single network by 1975.  First router c. first
half of 1976 (Ginny Strazisar implemented it and she joined BBN in 1975).
By late 1976 the proto-Internet had three routers active (one at BBN,
one at SRI and one at UCL).

Thanks!

Craig


From dhc2 at dcrocker.net  Mon Nov  2 11:55:49 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 02 Nov 2009 11:55:49 -0800
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
References: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
Message-ID: <4AEF3945.7020603@dcrocker.net>



Noel Chiappa wrote:
> Call me picky, but I do like to differentiate between 'the Internet' and 'the
> global communcation/information catenetwork'. The birth of the ARPAnet is, I
> think, the birth of the latter, but to me, not the Internet. (I.e. the entity
> which speaks TCP/IP


Worthy technical distinctions, and important enhancements, but they do not 
represent paradigmatic changes, in global, historical terms.

The introduction of packet switching fundamentally changed the economics of 
wide-area data communication and the original user services (applications) 
created during the Arpanet have remained in continuous and important operation 
into today's Internet.

 From the perspective of the mass media, it makes far more sense to use this 
initial demonstration of the Arpanet as the start of the Internet, than does a 
reliance on TCP/IP.

IMO.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From LarrySheldon at cox.net  Mon Nov  2 12:02:04 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 02 Nov 2009 14:02:04 -0600
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
References: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
Message-ID: <4AEF3ABC.8040607@cox.net>

Noel Chiappa wrote:
>     > From: Dave CROCKER <dhc2 at dcrocker.net>
> 
>     > the live birth of the world we now call the Internet
> 
> Call me picky, but I do like to differentiate between 'the Internet' and 'the
> global communcation/information catenetwork'. The birth of the ARPAnet is, I
> think, the birth of the latter, but to me, not the Internet. (I.e. the entity
> which speaks TCP/IP - although it's not clear that definition of 'the
> Internet' is really the best definition, though).

I've long thought that an internet was a thing (a little more 
intelligent than a twisted pair, but not necessarily much more than 
that) that connected one or mote network--the thing that was between 
networks, but not a network in and of itself.

And it seems to me that an Internet (the case-change is important) is 
what most people think Mosaic, et alia talks to.


From braden at ISI.EDU  Mon Nov  2 12:20:06 2009
From: braden at ISI.EDU (Bob Braden)
Date: Mon, 02 Nov 2009 12:20:06 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <mailman.4611.1257190731.20530.internet-history@postel.org>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
Message-ID: <4AEF3EF6.20709@isi.edu>


Noel wrote:

   And speaking of the Internet as a distinct entity, whats it's birth-day
 > anyway? I would call it the first day on which a packet was sent from one
 > host, across a particular kind of network, through a router (or 
gateway as we
 > called them back then), across another network, into another host. 
(That woul
 > d
 > have been a TCP packet, I guess - no IP back then!) So where and when was
 > that?

At the time, we reckoned the beginning of the Internet to be the Red 
Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1, 1983.
I think someone has an "I survived..." sweatshirt to commemorate that date.

Bob Braden



From lpress at csudh.edu  Mon Nov  2 12:56:36 2009
From: lpress at csudh.edu (Larry Press)
Date: Mon, 2 Nov 2009 12:56:36 -0800
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
References: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
Message-ID: <6A424DE0AE59154CBAD11F78618CD7696B25EDDE16@DHX7MBX.campus.csudh.edu>

> And speaking of the Internet as a distinct entity, whats it's birth-day
anyway? I would call it the first day on which a packet was sent from one
host, across a particular kind of network, through a router (or gateway as we
called them back then), across another network, into another host. (That would
have been a TCP packet, I guess - no IP back then!) So where and when was
that?




There was evidently a demonstration of ARPANet, SATNet, and the San Francisco Bay area packet radio network in October 1977.  Was that the first public demo?

There is a diagram of the demo network at:
http://www.sri.com/about/timeline/images/1977map_000.jpg

I include it in a 12-slide teaching presentation on Internet history at:
http://localhost/som/presentations/tcpip/tcphistory2.ppt

Any corrections would be appreciated by me and my students.

Lar


From craig at aland.bbn.com  Mon Nov  2 13:16:24 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Mon, 02 Nov 2009 16:16:24 -0500
Subject: [ih] ARPANet anniversary
Message-ID: <20091102211624.BDD0D28E137@aland.bbn.com>


Hi Larry:

The 1977 diagram certainly looks like the early Internet.  I know that
in late 1976 there was router/gateway between SRI and the Packet Radio
network, between ARPANET and BBN's test network (BBN had an internal
network using ARPANET technology used to serve BBN and test ARPANET
code before deployment), and via SATNET at UCL.  Your diagram shows
one more gateway/router in Norway, which is plausible by 1977.

Thanks!

Craig

> > And speaking of the Internet as a distinct entity, whats it's birth-day
> anyway? I would call it the first day on which a packet was sent from one
> host, across a particular kind of network, through a router (or gateway as we
> called them back then), across another network, into another host. (That woul
> d
> have been a TCP packet, I guess - no IP back then!) So where and when was
> that?
> 
> 
> 
> 
> There was evidently a demonstration of ARPANet, SATNet, and the San Francisco
>  Bay area packet radio network in October 1977.  Was that the first public de
> mo?
> 
> There is a diagram of the demo network at:
> http://www.sri.com/about/timeline/images/1977map_000.jpg
> 
> I include it in a 12-slide teaching presentation on Internet history at:
> http://localhost/som/presentations/tcpip/tcphistory2.ppt
> 
> Any corrections would be appreciated by me and my students.
> 
> Lar
********************
Craig Partridge
Chief Scientist, BBN Technologies
E-mail: craig at aland.bbn.com or craig at bbn.com
Phone: +1 517 324 3425


From jack at 3kitty.org  Mon Nov  2 13:44:57 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Mon, 02 Nov 2009 13:44:57 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <4AEF3EF6.20709@isi.edu>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
	<4AEF3EF6.20709@isi.edu>
Message-ID: <1257198297.3385.35.camel@localhost>

This is like the arguments about when life begins - lots of different
opinions...

I like Bob's milestone - the Internet came to life when its technology
(i.e., the TCP technology that enabled the "inter" aspect of Internet)
was adopted for operational use and there was no going back.  Everything
before that was prenatal, part of a lengthy R&D gestation.  Much of the
Arpanet software "DNA" carried over to the Internet algorithms.  But
1/1/1983 seems like a good date for when the Internet was "born".

Subsequently, the offspring Internet consumed its mother Arpanet, which
disappeared totally - as happens in the animal kingdom.  But of course,
opinions may differ.

At the time, the "Arpanet people" didn't think they were creating an
Internet.  In fact, as I remember, the Internet was somewhat of an
annoyance, since it significantly altered the traffic patterns which the
Arpanet internal algorithms were optimized to handle and caused
operational problems as a result.  Those "gateways" (now called routers)
just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D was
intently focused on making the network bigger and better, converting to
the X.25 interface, deploying clone networks for anyone who wanted one,
and in general evolving and commercializing the Arpanet technology.  

The government had to mandate the transition to TCP in order to make it
possible to communicate across several networks - the "inter" in
Internet.  Without the mandate, I doubt it would have happened.   Our
"Internet" today would probably be a gaggle of X.25 networks
interconnected by X.75 gateways - that was certainly the plan.  The
economics and performance of X.25/X.75 would probably never have
permitted the creation of the Web, or any of the other "killer apps"
that we now use everyday.  Packet-switching may have changed the
economics of using long lines, but I think the "Internet economics"
changed the cost structure on data comm dramatically, and that's what
enabled the explosion of growth of "The Internet" from the mid-90s on.
If the Arpanet had had its way, today's Internet, if it existed at all,
would be X.25/X.75.

So, my perspective is that the Arpanet was not the fledgling Internet -
the Arpanet reluctantly nurtured the Internet, and eventually died as a
result.  Once TCP was required, the Arpanet was doomed; it took only a
few years.  I wonder if there are any Arpanet-style X.25 networks
left...

I have a big red button that says "I Survived the TCP Transition
1/1/83".  They were handed out to commemorate the cutover, but I don't
remember exactly where I got it.  Sounds like something Jon Postel would
have done though.  Anybody else have one?

/Jack Haverty
Point Arena, CA

On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
> Noel wrote:
> 
>    And speaking of the Internet as a distinct entity, whats it's birth-day
>  > anyway? I would call it the first day on which a packet was sent from one
>  > host, across a particular kind of network, through a router (or 
> gateway as we
>  > called them back then), across another network, into another host. 
> (That woul
>  > d
>  > have been a TCP packet, I guess - no IP back then!) So where and when was
>  > that?
> 
> At the time, we reckoned the beginning of the Internet to be the Red 
> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1, 1983.
> I think someone has an "I survived..." sweatshirt to commemorate that date.
> 
> Bob Braden
> 
> 



From the.map at alum.mit.edu  Mon Nov  2 13:58:30 2009
From: the.map at alum.mit.edu (Mike Padlipsky)
Date: Mon, 02 Nov 2009 13:58:30 -0800
Subject: [ih] ARPANet anniversary
In-Reply-To: <4AEEDFA8.4325.1CEAC6C7@bernie.fantasyfarm.com>
References: <20091102154308.5B8686BE59E@mercury.lcs.mit.edu>
	<CC8D089D-0E2F-414C-823F-9AD56B00F4D9@google.com>
	<4AEEDFA8.4325.1CEAC6C7@bernie.fantasyfarm.com>
Message-ID: <200911022158.nA2LwatE089646@zoom.lafn.org>

At 10:33 AM 11/2/2009, Bernie Cosell wrote:
>As for history written by the 'winner' -- that's not exactly right: often
>it is written by the person with the best PR instincts.

indeed.  and let us not forget the power of Proof by Strong Assertion....


cheers, map

[whose shoulder problems caused him to break down some time ago and 
create a 'signature' file to apologize for the lack of his formerly 
customary e-volubility -- and who's been employing shiftless typing 
for a long time now to spare his wristsnfingers, in case you didn't 
know ... and who's further broken down and done 
http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly]



From vint at google.com  Mon Nov  2 15:33:54 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 2 Nov 2009 18:33:54 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <1257198297.3385.35.camel@localhost>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
	<4AEF3EF6.20709@isi.edu> <1257198297.3385.35.camel@localhost>
Message-ID: <83650733-CAC1-4EBB-9C45-9FDC32DEDE76@google.com>

the big button was an Interop innovation I think (Dan Lynch).
v

On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:

> This is like the arguments about when life begins - lots of different
> opinions...
>
> I like Bob's milestone - the Internet came to life when its technology
> (i.e., the TCP technology that enabled the "inter" aspect of Internet)
> was adopted for operational use and there was no going back.   
> Everything
> before that was prenatal, part of a lengthy R&D gestation.  Much of  
> the
> Arpanet software "DNA" carried over to the Internet algorithms.  But
> 1/1/1983 seems like a good date for when the Internet was "born".
>
> Subsequently, the offspring Internet consumed its mother Arpanet,  
> which
> disappeared totally - as happens in the animal kingdom.  But of  
> course,
> opinions may differ.
>
> At the time, the "Arpanet people" didn't think they were creating an
> Internet.  In fact, as I remember, the Internet was somewhat of an
> annoyance, since it significantly altered the traffic patterns which  
> the
> Arpanet internal algorithms were optimized to handle and caused
> operational problems as a result.  Those "gateways" (now called  
> routers)
> just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D  
> was
> intently focused on making the network bigger and better, converting  
> to
> the X.25 interface, deploying clone networks for anyone who wanted  
> one,
> and in general evolving and commercializing the Arpanet technology.
>
> The government had to mandate the transition to TCP in order to make  
> it
> possible to communicate across several networks - the "inter" in
> Internet.  Without the mandate, I doubt it would have happened.   Our
> "Internet" today would probably be a gaggle of X.25 networks
> interconnected by X.75 gateways - that was certainly the plan.  The
> economics and performance of X.25/X.75 would probably never have
> permitted the creation of the Web, or any of the other "killer apps"
> that we now use everyday.  Packet-switching may have changed the
> economics of using long lines, but I think the "Internet economics"
> changed the cost structure on data comm dramatically, and that's what
> enabled the explosion of growth of "The Internet" from the mid-90s on.
> If the Arpanet had had its way, today's Internet, if it existed at  
> all,
> would be X.25/X.75.
>
> So, my perspective is that the Arpanet was not the fledgling  
> Internet -
> the Arpanet reluctantly nurtured the Internet, and eventually died  
> as a
> result.  Once TCP was required, the Arpanet was doomed; it took only a
> few years.  I wonder if there are any Arpanet-style X.25 networks
> left...
>
> I have a big red button that says "I Survived the TCP Transition
> 1/1/83".  They were handed out to commemorate the cutover, but I don't
> remember exactly where I got it.  Sounds like something Jon Postel  
> would
> have done though.  Anybody else have one?
>
> /Jack Haverty
> Point Arena, CA
>
> On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
>> Noel wrote:
>>
>>   And speaking of the Internet as a distinct entity, whats it's  
>> birth-day
>>> anyway? I would call it the first day on which a packet was sent  
>>> from one
>>> host, across a particular kind of network, through a router (or
>> gateway as we
>>> called them back then), across another network, into another host.
>> (That woul
>>> d
>>> have been a TCP packet, I guess - no IP back then!) So where and  
>>> when was
>>> that?
>>
>> At the time, we reckoned the beginning of the Internet to be the Red
>> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1, 1983.
>> I think someone has an "I survived..." sweatshirt to commemorate  
>> that date.
>>
>> Bob Braden
>>
>>
>



From vint at google.com  Mon Nov  2 15:34:36 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 2 Nov 2009 18:34:36 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <1257198297.3385.35.camel@localhost>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
	<4AEF3EF6.20709@isi.edu> <1257198297.3385.35.camel@localhost>
Message-ID: <D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>

oh, duh, that can't be right (Interop wasn't born until about 1986 was  
it?).

so I guess I don't know where that pin came from.

v

On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:

> This is like the arguments about when life begins - lots of different
> opinions...
>
> I like Bob's milestone - the Internet came to life when its technology
> (i.e., the TCP technology that enabled the "inter" aspect of Internet)
> was adopted for operational use and there was no going back.   
> Everything
> before that was prenatal, part of a lengthy R&D gestation.  Much of  
> the
> Arpanet software "DNA" carried over to the Internet algorithms.  But
> 1/1/1983 seems like a good date for when the Internet was "born".
>
> Subsequently, the offspring Internet consumed its mother Arpanet,  
> which
> disappeared totally - as happens in the animal kingdom.  But of  
> course,
> opinions may differ.
>
> At the time, the "Arpanet people" didn't think they were creating an
> Internet.  In fact, as I remember, the Internet was somewhat of an
> annoyance, since it significantly altered the traffic patterns which  
> the
> Arpanet internal algorithms were optimized to handle and caused
> operational problems as a result.  Those "gateways" (now called  
> routers)
> just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D  
> was
> intently focused on making the network bigger and better, converting  
> to
> the X.25 interface, deploying clone networks for anyone who wanted  
> one,
> and in general evolving and commercializing the Arpanet technology.
>
> The government had to mandate the transition to TCP in order to make  
> it
> possible to communicate across several networks - the "inter" in
> Internet.  Without the mandate, I doubt it would have happened.   Our
> "Internet" today would probably be a gaggle of X.25 networks
> interconnected by X.75 gateways - that was certainly the plan.  The
> economics and performance of X.25/X.75 would probably never have
> permitted the creation of the Web, or any of the other "killer apps"
> that we now use everyday.  Packet-switching may have changed the
> economics of using long lines, but I think the "Internet economics"
> changed the cost structure on data comm dramatically, and that's what
> enabled the explosion of growth of "The Internet" from the mid-90s on.
> If the Arpanet had had its way, today's Internet, if it existed at  
> all,
> would be X.25/X.75.
>
> So, my perspective is that the Arpanet was not the fledgling  
> Internet -
> the Arpanet reluctantly nurtured the Internet, and eventually died  
> as a
> result.  Once TCP was required, the Arpanet was doomed; it took only a
> few years.  I wonder if there are any Arpanet-style X.25 networks
> left...
>
> I have a big red button that says "I Survived the TCP Transition
> 1/1/83".  They were handed out to commemorate the cutover, but I don't
> remember exactly where I got it.  Sounds like something Jon Postel  
> would
> have done though.  Anybody else have one?
>
> /Jack Haverty
> Point Arena, CA
>
> On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
>> Noel wrote:
>>
>>   And speaking of the Internet as a distinct entity, whats it's  
>> birth-day
>>> anyway? I would call it the first day on which a packet was sent  
>>> from one
>>> host, across a particular kind of network, through a router (or
>> gateway as we
>>> called them back then), across another network, into another host.
>> (That woul
>>> d
>>> have been a TCP packet, I guess - no IP back then!) So where and  
>>> when was
>>> that?
>>
>> At the time, we reckoned the beginning of the Internet to be the Red
>> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1, 1983.
>> I think someone has an "I survived..." sweatshirt to commemorate  
>> that date.
>>
>> Bob Braden
>>
>>
>



From vint at google.com  Mon Nov  2 15:37:43 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 2 Nov 2009 18:37:43 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <20091102211624.BDD0D28E137@aland.bbn.com>
References: <20091102211624.BDD0D28E137@aland.bbn.com>
Message-ID: <E1C1A70E-1831-4BF8-80D4-D95A2FFBCCED@google.com>

the 3 network demo was nov 22, 1977 according to my records.

v

On Nov 2, 2009, at 4:16 PM, Craig Partridge wrote:

>
> Hi Larry:
>
> The 1977 diagram certainly looks like the early Internet.  I know that
> in late 1976 there was router/gateway between SRI and the Packet Radio
> network, between ARPANET and BBN's test network (BBN had an internal
> network using ARPANET technology used to serve BBN and test ARPANET
> code before deployment), and via SATNET at UCL.  Your diagram shows
> one more gateway/router in Norway, which is plausible by 1977.
>
> Thanks!
>
> Craig
>
>>> And speaking of the Internet as a distinct entity, whats it's  
>>> birth-day
>> anyway? I would call it the first day on which a packet was sent  
>> from one
>> host, across a particular kind of network, through a router (or  
>> gateway as we
>> called them back then), across another network, into another host.  
>> (That woul
>> d
>> have been a TCP packet, I guess - no IP back then!) So where and  
>> when was
>> that?
>>
>>
>>
>>
>> There was evidently a demonstration of ARPANet, SATNet, and the San  
>> Francisco
>> Bay area packet radio network in October 1977.  Was that the first  
>> public de
>> mo?
>>
>> There is a diagram of the demo network at:
>> http://www.sri.com/about/timeline/images/1977map_000.jpg
>>
>> I include it in a 12-slide teaching presentation on Internet  
>> history at:
>> http://localhost/som/presentations/tcpip/tcphistory2.ppt
>>
>> Any corrections would be appreciated by me and my students.
>>
>> Lar
> ********************
> Craig Partridge
> Chief Scientist, BBN Technologies
> E-mail: craig at aland.bbn.com or craig at bbn.com
> Phone: +1 517 324 3425



From vint at google.com  Mon Nov  2 15:47:15 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 2 Nov 2009 18:47:15 -0500
Subject: [ih] ARPANet anniversary
In-Reply-To: <4AEF3945.7020603@dcrocker.net>
References: <20091102190205.DEA056BE583@mercury.lcs.mit.edu>
	<4AEF3945.7020603@dcrocker.net>
Message-ID: <87FC9D54-2A05-4381-8E14-63E2711C104E@google.com>

dave, if you want to celebrate packet switching specifically i have no  
problem but I think equating Internet with packet switching is a  
disservice in several dimensions.

I fails to attend to the many packet switched networks that drove the  
need for Internet (TCP/IP) and it also fails to acknowledge that the  
particular form  that packet switching took in TCP/IP allowed for a  
plethora of diverse packet switched networks to be interconnected.  
That would not have happened if we had stayed on the ARPANET, Telenet,  
BBN X.25 path, as Jack Haverty points out.

v

On Nov 2, 2009, at 2:55 PM, Dave CROCKER wrote:

>
>
> Noel Chiappa wrote:
>> Call me picky, but I do like to differentiate between 'the  
>> Internet' and 'the
>> global communcation/information catenetwork'. The birth of the  
>> ARPAnet is, I
>> think, the birth of the latter, but to me, not the Internet. (I.e.  
>> the entity
>> which speaks TCP/IP
>
>
> Worthy technical distinctions, and important enhancements, but they  
> do not represent paradigmatic changes, in global, historical terms.
>
> The introduction of packet switching fundamentally changed the  
> economics of wide-area data communication and the original user  
> services (applications) created during the Arpanet have remained in  
> continuous and important operation into today's Internet.
>
> From the perspective of the mass media, it makes far more sense to  
> use this initial demonstration of the Arpanet as the start of the  
> Internet, than does a reliance on TCP/IP.
>
> IMO.
>
> d/
> -- 
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net



From johnl at iecc.com  Mon Nov  2 23:39:41 2009
From: johnl at iecc.com (John R. Levine)
Date: 3 Nov 2009 02:39:41 -0500
Subject: [ih] Throwing packets away
Message-ID: <alpine.BSF.2.00.0911030224370.62178@simone.lan>

[ Feel free to point me at documents or archives I should have read if
   this is a FAQ. I have at least read RFC 635. ]

I'm trying to understand the origins of the TCP/IP approach to congestion 
management by throwing excess packets away, which I gather was a pretty 
radical idea.

It is my impression that the ARPAnet used a reservation approach so that 
the source end wasn't supposed to send a packet until the destination end 
said it had room for that packet, with resends primarily for line errors. 
TCP went to byte windows and congestion discarding partly to make it more 
adaptable to varying network speeds, partly to unify the virtual circuit
management, and that it took a fair amount of twiddling of the details of 
TCP to get good performance out of it.

CYCLADES had a lot of these features.  Did the window and congestion 
discards come from there, or somewhere else, or some combination?

Signed,
Confused in Trumansburg


From vint at google.com  Tue Nov  3 02:27:18 2009
From: vint at google.com (Vint Cerf)
Date: Tue, 3 Nov 2009 05:27:18 -0500
Subject: [ih] Throwing packets away
In-Reply-To: <alpine.BSF.2.00.0911030224370.62178@simone.lan>
References: <alpine.BSF.2.00.0911030224370.62178@simone.lan>
Message-ID: <432B1964-EA27-4C69-8F07-280846F461F1@google.com>

we assumed that the transmission system(s) below IP level would not be  
guaranteed (ethernet and packet radio and dynamically shared satellite  
channels did not have the same properties that ARPANET had). So we  
built into the TCP layer a re-transmission scheme. This led to the  
need for re-sequencing and detection and discard of duplicates. The  
flow control in TCP was adapted from the CYCLADES sliding window  
mechanism. Gateways (before they were called routers) had finite  
storage and because packet networks were NOT synchronous end-to-end,  
there was the potential for congestion. You might have a 10 Mb/s  
interface on one end sending to a dialup device on the other end. A  
good deal of experimentation went into the TCP round-trip time  
estimates and packet loss was assumed to be a potential hazard. Van  
Jacobson was a pioneer in the development of mechanisms to discipline  
TCP flow control, and slow-start to detect when congestion resulted in  
packet loss. The capacity of a dynamically shared packet net varies  
continuously depending on the traffic matrix. It is not like circuit  
switching where capacity is dedicated and unused even when no traffic  
is flowing between pairs of end points. Consequently, there was need  
to adapt the flow control window on a more-or-less continuous basis  
and the potential for congestion produced a concomitant packet loss  
potential. one of the interesting statistical observations was that  
fair allocation of capacity among dynamic flows could be achieved by  
random discard of packets (rather than discarding the packet that  
encountered the buffer overflow). This was referred to variously as  
"random early discard." Finally, a crude signal was devised to  
indicate congestion back to the source when a packet was discarded for  
lack of buffer space.



vint

On Nov 3, 2009, at 2:39 AM, John R. Levine wrote:

> [ Feel free to point me at documents or archives I should have read if
>  this is a FAQ. I have at least read RFC 635. ]
>
> I'm trying to understand the origins of the TCP/IP approach to  
> congestion management by throwing excess packets away, which I  
> gather was a pretty radical idea.
>
> It is my impression that the ARPAnet used a reservation approach so  
> that the source end wasn't supposed to send a packet until the  
> destination end said it had room for that packet, with resends  
> primarily for line errors. TCP went to byte windows and congestion  
> discarding partly to make it more adaptable to varying network  
> speeds, partly to unify the virtual circuit
> management, and that it took a fair amount of twiddling of the  
> details of TCP to get good performance out of it.
>
> CYCLADES had a lot of these features.  Did the window and congestion  
> discards come from there, or somewhere else, or some combination?
>
> Signed,
> Confused in Trumansburg



From jeanjour at comcast.net  Tue Nov  3 04:37:33 2009
From: jeanjour at comcast.net (John Day)
Date: Tue, 3 Nov 2009 07:37:33 -0500
Subject: [ih] Throwing packets away
In-Reply-To: <432B1964-EA27-4C69-8F07-280846F461F1@google.com>
References: <alpine.BSF.2.00.0911030224370.62178@simone.lan>
	<432B1964-EA27-4C69-8F07-280846F461F1@google.com>
Message-ID: <a0624080cc715c962451c@[10.0.1.40]>

I am not the best person on this topic, but let me suggest a couple 
of things I remember.  In the 1970s, it was reasonably common 
knowledge that congestion control in datagram networks was an open 
issue.  Early CYCLADES TS and later TCP had flow control to prevent 
the sending host from overrunning the receiving host.  At the time it 
was generally believed that congestion control would go in the 
network somehow.

(BTW, I have come to distinguish flow control from congestion control 
as follows:  Flow control is a feedback mechanism that is co-located 
with the resource being control. Congestion control is a feedback 
mechanism that is not co-located with the resource being controlled. 
So early TS and TCP had flow control but no congestion control.)

I remember an RFC (I think it was, maybe not) by Vint ( and maybe 
others, do you remember what it was?) arguing that we could not bound 
the amount of buffer space required in the switches, so discarding 
was the only real option.  (If memory serves, I *saw* this just prior 
to *seeing*that first TCP spec.  IOW, I won't swear it was written 
before the TCP spec but I think so.  ;-)  So 1974 or 1975).  There 
was considerable work early on the problem by Gerard LeLann at Rennes 
and others at IRIA, now INRIA.

There is also the 1977 IEN#1 from UCL in which there is some 
discussion of the problem and a conjecture that something like 
ingress flow control may be the solution.  In 1979, the INRIA guys 
held a conference on the topic, Flow Control in Computer Networks. 
About this time, you also have quite a lot of work at DEC by former 
CYCLADES people and Raj Jain.  In the early 80s, you have the work by 
Nagle on the problems they were seeing in Ford's IP network.  Ford 
was operating over lower b/w links so was seeing the problem earlier.

So there was a fair amount of work and understanding on the problem 
prior to the 1986 episode.

I have also conjectured that delay in seeing severe congestion in the 
Internet between the switch from NCP to IP was due to two factors: 
The higher bandwidth links and that in 1982 hosts attached to 
switches as opposed to LANs were using either 1822 or X.25, which had 
ingress flow control.  As they disappeared and the population of LAN 
attached hosts increased, what congestion control there was became 
ineffective and disappeared.

But there was plenty of evidence that the problem was out there and a 
fair amount of work on what to do about it.  It would be interesting 
to understand better, why the Internet waited until the crisis was 
upon them before they acted to adopt Jacobson's stop-gap measure.  As 
Vint alluded in his response  control theory says one should put such 
mechanisms as close to the resource being controlled.  The further 
away the more hysterisis in the control.  Jacobson puts them as far 
away as possible.  Of course, at the same time you want to avoid 
putting it at every hop. (The trick with reductio ad absurdum is 
knowing when to stop.)  ;-)  So what was the happy medium?  We still 
don't know really.  Everthing seems to have been one extreme 
(Jacobson) or the other (MPLS, ATM).  We never have figured out how 
to mix the oil and water of connection and connectionless.  Or did we?

Did we choose the host based approach because we were so performance 
constrained in the routers at the time, that people were afraid 
solutions such as Jain's and others would over burden the routers? 
It was true then but isn't now.

Take care,
John

At 5:27 -0500 2009/11/03, Vint Cerf wrote:
>we assumed that the transmission system(s) below IP level would not 
>be guaranteed (ethernet and packet radio and dynamically shared 
>satellite channels did not have the same properties that ARPANET 
>had). So we built into the TCP layer a re-transmission scheme. This 
>led to the need for re-sequencing and detection and discard of 
>duplicates. The flow control in TCP was adapted from the CYCLADES 
>sliding window mechanism. Gateways (before they were called routers) 
>had finite storage and because packet networks were NOT synchronous 
>end-to-end, there was the potential for congestion. You might have a 
>10 Mb/s interface on one end sending to a dialup device on the other 
>end. A good deal of experimentation went into the TCP round-trip 
>time estimates and packet loss was assumed to be a potential hazard. 
>Van Jacobson was a pioneer in the development of mechanisms to 
>discipline TCP flow control, and slow-start to detect when 
>congestion resulted in packet loss. The capacity of a dynamically 
>shared packet net varies continuously depending on the traffic 
>matrix. It is not like circuit switching where capacity is dedicated 
>and unused even when no traffic is flowing between pairs of end 
>points. Consequently, there was need to adapt the flow control 
>window on a more-or-less continuous basis and the potential for 
>congestion produced a concomitant packet loss potential. one of the 
>interesting statistical observations was that fair allocation of 
>capacity among dynamic flows could be achieved by random discard of 
>packets (rather than discarding the packet that encountered the 
>buffer overflow). This was referred to variously as "random early 
>discard." Finally, a crude signal was devised to indicate congestion 
>back to the source when a packet was discarded for lack of buffer 
>space.
>
>
>
>vint
>
>On Nov 3, 2009, at 2:39 AM, John R. Levine wrote:
>
>>[ Feel free to point me at documents or archives I should have read if
>>  this is a FAQ. I have at least read RFC 635. ]
>>
>>I'm trying to understand the origins of the TCP/IP approach to 
>>congestion management by throwing excess packets away, which I 
>>gather was a pretty radical idea.
>>
>>It is my impression that the ARPAnet used a reservation approach so 
>>that the source end wasn't supposed to send a packet until the 
>>destination end said it had room for that packet, with resends 
>>primarily for line errors. TCP went to byte windows and congestion 
>>discarding partly to make it more adaptable to varying network 
>>speeds, partly to unify the virtual circuit
>>management, and that it took a fair amount of twiddling of the 
>>details of TCP to get good performance out of it.
>>
>>CYCLADES had a lot of these features.  Did the window and 
>>congestion discards come from there, or somewhere else, or some 
>>combination?
>>
>>Signed,
>>Confused in Trumansburg



From jack at 3kitty.org  Thu Nov  5 13:30:39 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Thu, 05 Nov 2009 21:30:39 +0000
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
	<4AEF3EF6.20709@isi.edu> <1257198297.3385.35.camel@localhost>
	<D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>
Message-ID: <1257456639.3343.5.camel@localhost>

I just found my souvenir plastic pocket protector - "TCP/IP '87 Geeks on
the Bay in Monterey".  I think this was probably just before the name
"Interop" appeared, but it was arguably the first Interop conference.
The first name was "Advanced Computing Environments" (on my ceramic
souvenir tile.)

I wonder what else is down in this drawer....  /Jack


On Mon, 2009-11-02 at 18:34 -0500, Vint Cerf wrote:
> oh, duh, that can't be right (Interop wasn't born until about 1986 was  
> it?).
> 
> so I guess I don't know where that pin came from.
> 
> v
> 
> On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:
> 
> > This is like the arguments about when life begins - lots of different
> > opinions...
> >
> > I like Bob's milestone - the Internet came to life when its technology
> > (i.e., the TCP technology that enabled the "inter" aspect of Internet)
> > was adopted for operational use and there was no going back.   
> > Everything
> > before that was prenatal, part of a lengthy R&D gestation.  Much of  
> > the
> > Arpanet software "DNA" carried over to the Internet algorithms.  But
> > 1/1/1983 seems like a good date for when the Internet was "born".
> >
> > Subsequently, the offspring Internet consumed its mother Arpanet,  
> > which
> > disappeared totally - as happens in the animal kingdom.  But of  
> > course,
> > opinions may differ.
> >
> > At the time, the "Arpanet people" didn't think they were creating an
> > Internet.  In fact, as I remember, the Internet was somewhat of an
> > annoyance, since it significantly altered the traffic patterns which  
> > the
> > Arpanet internal algorithms were optimized to handle and caused
> > operational problems as a result.  Those "gateways" (now called  
> > routers)
> > just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D  
> > was
> > intently focused on making the network bigger and better, converting  
> > to
> > the X.25 interface, deploying clone networks for anyone who wanted  
> > one,
> > and in general evolving and commercializing the Arpanet technology.
> >
> > The government had to mandate the transition to TCP in order to make  
> > it
> > possible to communicate across several networks - the "inter" in
> > Internet.  Without the mandate, I doubt it would have happened.   Our
> > "Internet" today would probably be a gaggle of X.25 networks
> > interconnected by X.75 gateways - that was certainly the plan.  The
> > economics and performance of X.25/X.75 would probably never have
> > permitted the creation of the Web, or any of the other "killer apps"
> > that we now use everyday.  Packet-switching may have changed the
> > economics of using long lines, but I think the "Internet economics"
> > changed the cost structure on data comm dramatically, and that's what
> > enabled the explosion of growth of "The Internet" from the mid-90s on.
> > If the Arpanet had had its way, today's Internet, if it existed at  
> > all,
> > would be X.25/X.75.
> >
> > So, my perspective is that the Arpanet was not the fledgling  
> > Internet -
> > the Arpanet reluctantly nurtured the Internet, and eventually died  
> > as a
> > result.  Once TCP was required, the Arpanet was doomed; it took only a
> > few years.  I wonder if there are any Arpanet-style X.25 networks
> > left...
> >
> > I have a big red button that says "I Survived the TCP Transition
> > 1/1/83".  They were handed out to commemorate the cutover, but I don't
> > remember exactly where I got it.  Sounds like something Jon Postel  
> > would
> > have done though.  Anybody else have one?
> >
> > /Jack Haverty
> > Point Arena, CA
> >
> > On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
> >> Noel wrote:
> >>
> >>   And speaking of the Internet as a distinct entity, whats it's  
> >> birth-day
> >>> anyway? I would call it the first day on which a packet was sent  
> >>> from one
> >>> host, across a particular kind of network, through a router (or
> >> gateway as we
> >>> called them back then), across another network, into another host.
> >> (That woul
> >>> d
> >>> have been a TCP packet, I guess - no IP back then!) So where and  
> >>> when was
> >>> that?
> >>
> >> At the time, we reckoned the beginning of the Internet to be the Red
> >> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1, 1983.
> >> I think someone has an "I survived..." sweatshirt to commemorate  
> >> that date.
> >>
> >> Bob Braden
> >>
> >>
> >
> 
> 



From vint at google.com  Thu Nov  5 21:14:44 2009
From: vint at google.com (Vint Cerf)
Date: Fri, 6 Nov 2009 00:14:44 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <1257456639.3343.5.camel@localhost>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
	<4AEF3EF6.20709@isi.edu> <1257198297.3385.35.camel@localhost>
	<D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>
	<1257456639.3343.5.camel@localhost>
Message-ID: <AEAA6265-59B8-4D6F-A329-ABB2DBC5337F@google.com>

i thought the first meeting was 1986 and was just lectures by Internet  
geeks?

On Nov 5, 2009, at 4:30 PM, Jack Haverty wrote:

> I just found my souvenir plastic pocket protector - "TCP/IP '87  
> Geeks on
> the Bay in Monterey".  I think this was probably just before the name
> "Interop" appeared, but it was arguably the first Interop conference.
> The first name was "Advanced Computing Environments" (on my ceramic
> souvenir tile.)
>
> I wonder what else is down in this drawer....  /Jack
>
>
> On Mon, 2009-11-02 at 18:34 -0500, Vint Cerf wrote:
>> oh, duh, that can't be right (Interop wasn't born until about 1986  
>> was
>> it?).
>>
>> so I guess I don't know where that pin came from.
>>
>> v
>>
>> On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:
>>
>>> This is like the arguments about when life begins - lots of  
>>> different
>>> opinions...
>>>
>>> I like Bob's milestone - the Internet came to life when its  
>>> technology
>>> (i.e., the TCP technology that enabled the "inter" aspect of  
>>> Internet)
>>> was adopted for operational use and there was no going back.
>>> Everything
>>> before that was prenatal, part of a lengthy R&D gestation.  Much of
>>> the
>>> Arpanet software "DNA" carried over to the Internet algorithms.  But
>>> 1/1/1983 seems like a good date for when the Internet was "born".
>>>
>>> Subsequently, the offspring Internet consumed its mother Arpanet,
>>> which
>>> disappeared totally - as happens in the animal kingdom.  But of
>>> course,
>>> opinions may differ.
>>>
>>> At the time, the "Arpanet people" didn't think they were creating an
>>> Internet.  In fact, as I remember, the Internet was somewhat of an
>>> annoyance, since it significantly altered the traffic patterns which
>>> the
>>> Arpanet internal algorithms were optimized to handle and caused
>>> operational problems as a result.  Those "gateways" (now called
>>> routers)
>>> just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D
>>> was
>>> intently focused on making the network bigger and better, converting
>>> to
>>> the X.25 interface, deploying clone networks for anyone who wanted
>>> one,
>>> and in general evolving and commercializing the Arpanet technology.
>>>
>>> The government had to mandate the transition to TCP in order to make
>>> it
>>> possible to communicate across several networks - the "inter" in
>>> Internet.  Without the mandate, I doubt it would have happened.    
>>> Our
>>> "Internet" today would probably be a gaggle of X.25 networks
>>> interconnected by X.75 gateways - that was certainly the plan.  The
>>> economics and performance of X.25/X.75 would probably never have
>>> permitted the creation of the Web, or any of the other "killer apps"
>>> that we now use everyday.  Packet-switching may have changed the
>>> economics of using long lines, but I think the "Internet economics"
>>> changed the cost structure on data comm dramatically, and that's  
>>> what
>>> enabled the explosion of growth of "The Internet" from the mid-90s  
>>> on.
>>> If the Arpanet had had its way, today's Internet, if it existed at
>>> all,
>>> would be X.25/X.75.
>>>
>>> So, my perspective is that the Arpanet was not the fledgling
>>> Internet -
>>> the Arpanet reluctantly nurtured the Internet, and eventually died
>>> as a
>>> result.  Once TCP was required, the Arpanet was doomed; it took  
>>> only a
>>> few years.  I wonder if there are any Arpanet-style X.25 networks
>>> left...
>>>
>>> I have a big red button that says "I Survived the TCP Transition
>>> 1/1/83".  They were handed out to commemorate the cutover, but I  
>>> don't
>>> remember exactly where I got it.  Sounds like something Jon Postel
>>> would
>>> have done though.  Anybody else have one?
>>>
>>> /Jack Haverty
>>> Point Arena, CA
>>>
>>> On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
>>>> Noel wrote:
>>>>
>>>>  And speaking of the Internet as a distinct entity, whats it's
>>>> birth-day
>>>>> anyway? I would call it the first day on which a packet was sent
>>>>> from one
>>>>> host, across a particular kind of network, through a router (or
>>>> gateway as we
>>>>> called them back then), across another network, into another host.
>>>> (That woul
>>>>> d
>>>>> have been a TCP packet, I guess - no IP back then!) So where and
>>>>> when was
>>>>> that?
>>>>
>>>> At the time, we reckoned the beginning of the Internet to be the  
>>>> Red
>>>> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1,  
>>>> 1983.
>>>> I think someone has an "I survived..." sweatshirt to commemorate
>>>> that date.
>>>>
>>>> Bob Braden
>>>>
>>>>
>>>
>>
>>
>



From richard at bennett.com  Thu Nov  5 22:23:09 2009
From: richard at bennett.com (Richard Bennett)
Date: Thu, 05 Nov 2009 22:23:09 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <AEAA6265-59B8-4D6F-A329-ABB2DBC5337F@google.com>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>	<4AEF3EF6.20709@isi.edu>
	<1257198297.3385.35.camel@localhost>	<D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>	<1257456639.3343.5.camel@localhost>
	<AEAA6265-59B8-4D6F-A329-ABB2DBC5337F@google.com>
Message-ID: <4AF3C0CD.9000602@bennett.com>

There were a few tables for companies to pitch their wares, as I recall. 
Dan Lynch would know, of course.

RB

Vint Cerf wrote:
> i thought the first meeting was 1986 and was just lectures by Internet 
> geeks?
>
> On Nov 5, 2009, at 4:30 PM, Jack Haverty wrote:
>
>> I just found my souvenir plastic pocket protector - "TCP/IP '87 Geeks on
>> the Bay in Monterey".  I think this was probably just before the name
>> "Interop" appeared, but it was arguably the first Interop conference.
>> The first name was "Advanced Computing Environments" (on my ceramic
>> souvenir tile.)
>>
>> I wonder what else is down in this drawer....  /Jack
>>
>>
>> On Mon, 2009-11-02 at 18:34 -0500, Vint Cerf wrote:
>>> oh, duh, that can't be right (Interop wasn't born until about 1986 was
>>> it?).
>>>
>>> so I guess I don't know where that pin came from.
>>>
>>> v
>>>
>>> On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:
>>>
>>>> This is like the arguments about when life begins - lots of different
>>>> opinions...
>>>>
>>>> I like Bob's milestone - the Internet came to life when its technology
>>>> (i.e., the TCP technology that enabled the "inter" aspect of Internet)
>>>> was adopted for operational use and there was no going back.
>>>> Everything
>>>> before that was prenatal, part of a lengthy R&D gestation.  Much of
>>>> the
>>>> Arpanet software "DNA" carried over to the Internet algorithms.  But
>>>> 1/1/1983 seems like a good date for when the Internet was "born".
>>>>
>>>> Subsequently, the offspring Internet consumed its mother Arpanet,
>>>> which
>>>> disappeared totally - as happens in the animal kingdom.  But of
>>>> course,
>>>> opinions may differ.
>>>>
>>>> At the time, the "Arpanet people" didn't think they were creating an
>>>> Internet.  In fact, as I remember, the Internet was somewhat of an
>>>> annoyance, since it significantly altered the traffic patterns which
>>>> the
>>>> Arpanet internal algorithms were optimized to handle and caused
>>>> operational problems as a result.  Those "gateways" (now called
>>>> routers)
>>>> just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D
>>>> was
>>>> intently focused on making the network bigger and better, converting
>>>> to
>>>> the X.25 interface, deploying clone networks for anyone who wanted
>>>> one,
>>>> and in general evolving and commercializing the Arpanet technology.
>>>>
>>>> The government had to mandate the transition to TCP in order to make
>>>> it
>>>> possible to communicate across several networks - the "inter" in
>>>> Internet.  Without the mandate, I doubt it would have happened.   Our
>>>> "Internet" today would probably be a gaggle of X.25 networks
>>>> interconnected by X.75 gateways - that was certainly the plan.  The
>>>> economics and performance of X.25/X.75 would probably never have
>>>> permitted the creation of the Web, or any of the other "killer apps"
>>>> that we now use everyday.  Packet-switching may have changed the
>>>> economics of using long lines, but I think the "Internet economics"
>>>> changed the cost structure on data comm dramatically, and that's what
>>>> enabled the explosion of growth of "The Internet" from the mid-90s on.
>>>> If the Arpanet had had its way, today's Internet, if it existed at
>>>> all,
>>>> would be X.25/X.75.
>>>>
>>>> So, my perspective is that the Arpanet was not the fledgling
>>>> Internet -
>>>> the Arpanet reluctantly nurtured the Internet, and eventually died
>>>> as a
>>>> result.  Once TCP was required, the Arpanet was doomed; it took only a
>>>> few years.  I wonder if there are any Arpanet-style X.25 networks
>>>> left...
>>>>
>>>> I have a big red button that says "I Survived the TCP Transition
>>>> 1/1/83".  They were handed out to commemorate the cutover, but I don't
>>>> remember exactly where I got it.  Sounds like something Jon Postel
>>>> would
>>>> have done though.  Anybody else have one?
>>>>
>>>> /Jack Haverty
>>>> Point Arena, CA
>>>>
>>>> On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
>>>>> Noel wrote:
>>>>>
>>>>>  And speaking of the Internet as a distinct entity, whats it's
>>>>> birth-day
>>>>>> anyway? I would call it the first day on which a packet was sent
>>>>>> from one
>>>>>> host, across a particular kind of network, through a router (or
>>>>> gateway as we
>>>>>> called them back then), across another network, into another host.
>>>>> (That woul
>>>>>> d
>>>>>> have been a TCP packet, I guess - no IP back then!) So where and
>>>>>> when was
>>>>>> that?
>>>>>
>>>>> At the time, we reckoned the beginning of the Internet to be the Red
>>>>> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1, 1983.
>>>>> I think someone has an "I survived..." sweatshirt to commemorate
>>>>> that date.
>>>>>
>>>>> Bob Braden
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC



From jack at 3kitty.org  Thu Nov  5 23:39:58 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 06 Nov 2009 07:39:58 +0000
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <AEAA6265-59B8-4D6F-A329-ABB2DBC5337F@google.com>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>
	<4AEF3EF6.20709@isi.edu> <1257198297.3385.35.camel@localhost>
	<D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>
	<1257456639.3343.5.camel@localhost>
	<AEAA6265-59B8-4D6F-A329-ABB2DBC5337F@google.com>
Message-ID: <1257493198.3343.23.camel@localhost>

I think that's right - but it's been a long time....  I vaguely remember
the event was more like a traditional Internet Working Group meeting
(lectures and debates by Internet geeks) than a conference, with the
main agenda being presentations about various things being worked on.
That's where I think that the ceramic tiles were given out.  Dan was the
one who figured out that there were lots of people who'd be interested
enough to pay real money even to be able to just listen, and he knew all
the people (yes, geeks are people too...) who'd be willing to come and
talk - especially if the next event was held somewhere like Monterey.
It was an amazingly short journey from there to Moscone to Vegas.

I wonder if the Internet would have been such a success if Interop
hadn't happened to allow the "real world" to join the party.  And of
course the signature chocolate chip cookies were crucial.

/Jack


On Fri, 2009-11-06 at 00:14 -0500, Vint Cerf wrote:
> i thought the first meeting was 1986 and was just lectures by Internet  
> geeks?
> 
> On Nov 5, 2009, at 4:30 PM, Jack Haverty wrote:
> 
> > I just found my souvenir plastic pocket protector - "TCP/IP '87  
> > Geeks on
> > the Bay in Monterey".  I think this was probably just before the name
> > "Interop" appeared, but it was arguably the first Interop conference.
> > The first name was "Advanced Computing Environments" (on my ceramic
> > souvenir tile.)
> >
> > I wonder what else is down in this drawer....  /Jack
> >
> >
> > On Mon, 2009-11-02 at 18:34 -0500, Vint Cerf wrote:
> >> oh, duh, that can't be right (Interop wasn't born until about 1986  
> >> was
> >> it?).
> >>
> >> so I guess I don't know where that pin came from.
> >>
> >> v
> >>
> >> On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:
> >>
> >>> This is like the arguments about when life begins - lots of  
> >>> different
> >>> opinions...
> >>>
> >>> I like Bob's milestone - the Internet came to life when its  
> >>> technology
> >>> (i.e., the TCP technology that enabled the "inter" aspect of  
> >>> Internet)
> >>> was adopted for operational use and there was no going back.
> >>> Everything
> >>> before that was prenatal, part of a lengthy R&D gestation.  Much of
> >>> the
> >>> Arpanet software "DNA" carried over to the Internet algorithms.  But
> >>> 1/1/1983 seems like a good date for when the Internet was "born".
> >>>
> >>> Subsequently, the offspring Internet consumed its mother Arpanet,
> >>> which
> >>> disappeared totally - as happens in the animal kingdom.  But of
> >>> course,
> >>> opinions may differ.
> >>>
> >>> At the time, the "Arpanet people" didn't think they were creating an
> >>> Internet.  In fact, as I remember, the Internet was somewhat of an
> >>> annoyance, since it significantly altered the traffic patterns which
> >>> the
> >>> Arpanet internal algorithms were optimized to handle and caused
> >>> operational problems as a result.  Those "gateways" (now called
> >>> routers)
> >>> just acted weird, unlike normal well-behaved hosts.  The Arpanet R&D
> >>> was
> >>> intently focused on making the network bigger and better, converting
> >>> to
> >>> the X.25 interface, deploying clone networks for anyone who wanted
> >>> one,
> >>> and in general evolving and commercializing the Arpanet technology.
> >>>
> >>> The government had to mandate the transition to TCP in order to make
> >>> it
> >>> possible to communicate across several networks - the "inter" in
> >>> Internet.  Without the mandate, I doubt it would have happened.    
> >>> Our
> >>> "Internet" today would probably be a gaggle of X.25 networks
> >>> interconnected by X.75 gateways - that was certainly the plan.  The
> >>> economics and performance of X.25/X.75 would probably never have
> >>> permitted the creation of the Web, or any of the other "killer apps"
> >>> that we now use everyday.  Packet-switching may have changed the
> >>> economics of using long lines, but I think the "Internet economics"
> >>> changed the cost structure on data comm dramatically, and that's  
> >>> what
> >>> enabled the explosion of growth of "The Internet" from the mid-90s  
> >>> on.
> >>> If the Arpanet had had its way, today's Internet, if it existed at
> >>> all,
> >>> would be X.25/X.75.
> >>>
> >>> So, my perspective is that the Arpanet was not the fledgling
> >>> Internet -
> >>> the Arpanet reluctantly nurtured the Internet, and eventually died
> >>> as a
> >>> result.  Once TCP was required, the Arpanet was doomed; it took  
> >>> only a
> >>> few years.  I wonder if there are any Arpanet-style X.25 networks
> >>> left...
> >>>
> >>> I have a big red button that says "I Survived the TCP Transition
> >>> 1/1/83".  They were handed out to commemorate the cutover, but I  
> >>> don't
> >>> remember exactly where I got it.  Sounds like something Jon Postel
> >>> would
> >>> have done though.  Anybody else have one?
> >>>
> >>> /Jack Haverty
> >>> Point Arena, CA
> >>>
> >>> On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
> >>>> Noel wrote:
> >>>>
> >>>>  And speaking of the Internet as a distinct entity, whats it's
> >>>> birth-day
> >>>>> anyway? I would call it the first day on which a packet was sent
> >>>>> from one
> >>>>> host, across a particular kind of network, through a router (or
> >>>> gateway as we
> >>>>> called them back then), across another network, into another host.
> >>>> (That woul
> >>>>> d
> >>>>> have been a TCP packet, I guess - no IP back then!) So where and
> >>>>> when was
> >>>>> that?
> >>>>
> >>>> At the time, we reckoned the beginning of the Internet to be the  
> >>>> Red
> >>>> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1,  
> >>>> 1983.
> >>>> I think someone has an "I survived..." sweatshirt to commemorate
> >>>> that date.
> >>>>
> >>>> Bob Braden
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> 
> 



From vint at google.com  Fri Nov  6 05:31:40 2009
From: vint at google.com (Vint Cerf)
Date: Fri, 6 Nov 2009 08:31:40 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <4AF3C0CD.9000602@bennett.com>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>	<4AEF3EF6.20709@isi.edu>
	<1257198297.3385.35.camel@localhost>	<D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>	<1257456639.3343.5.camel@localhost>
	<AEAA6265-59B8-4D6F-A329-ABB2DBC5337F@google.com>
	<4AF3C0CD.9000602@bennett.com>
Message-ID: <89B1E288-55EC-43BB-9D81-19EA0BE47BB4@google.com>

i asked him in an email.

v

On Nov 6, 2009, at 1:23 AM, Richard Bennett wrote:

> There were a few tables for companies to pitch their wares, as I  
> recall. Dan Lynch would know, of course.
>
> RB
>
> Vint Cerf wrote:
>> i thought the first meeting was 1986 and was just lectures by  
>> Internet geeks?
>>
>> On Nov 5, 2009, at 4:30 PM, Jack Haverty wrote:
>>
>>> I just found my souvenir plastic pocket protector - "TCP/IP '87  
>>> Geeks on
>>> the Bay in Monterey".  I think this was probably just before the  
>>> name
>>> "Interop" appeared, but it was arguably the first Interop  
>>> conference.
>>> The first name was "Advanced Computing Environments" (on my ceramic
>>> souvenir tile.)
>>>
>>> I wonder what else is down in this drawer....  /Jack
>>>
>>>
>>> On Mon, 2009-11-02 at 18:34 -0500, Vint Cerf wrote:
>>>> oh, duh, that can't be right (Interop wasn't born until about  
>>>> 1986 was
>>>> it?).
>>>>
>>>> so I guess I don't know where that pin came from.
>>>>
>>>> v
>>>>
>>>> On Nov 2, 2009, at 4:44 PM, Jack Haverty wrote:
>>>>
>>>>> This is like the arguments about when life begins - lots of  
>>>>> different
>>>>> opinions...
>>>>>
>>>>> I like Bob's milestone - the Internet came to life when its  
>>>>> technology
>>>>> (i.e., the TCP technology that enabled the "inter" aspect of  
>>>>> Internet)
>>>>> was adopted for operational use and there was no going back.
>>>>> Everything
>>>>> before that was prenatal, part of a lengthy R&D gestation.  Much  
>>>>> of
>>>>> the
>>>>> Arpanet software "DNA" carried over to the Internet algorithms.   
>>>>> But
>>>>> 1/1/1983 seems like a good date for when the Internet was "born".
>>>>>
>>>>> Subsequently, the offspring Internet consumed its mother Arpanet,
>>>>> which
>>>>> disappeared totally - as happens in the animal kingdom.  But of
>>>>> course,
>>>>> opinions may differ.
>>>>>
>>>>> At the time, the "Arpanet people" didn't think they were  
>>>>> creating an
>>>>> Internet.  In fact, as I remember, the Internet was somewhat of an
>>>>> annoyance, since it significantly altered the traffic patterns  
>>>>> which
>>>>> the
>>>>> Arpanet internal algorithms were optimized to handle and caused
>>>>> operational problems as a result.  Those "gateways" (now called
>>>>> routers)
>>>>> just acted weird, unlike normal well-behaved hosts.  The Arpanet  
>>>>> R&D
>>>>> was
>>>>> intently focused on making the network bigger and better,  
>>>>> converting
>>>>> to
>>>>> the X.25 interface, deploying clone networks for anyone who wanted
>>>>> one,
>>>>> and in general evolving and commercializing the Arpanet  
>>>>> technology.
>>>>>
>>>>> The government had to mandate the transition to TCP in order to  
>>>>> make
>>>>> it
>>>>> possible to communicate across several networks - the "inter" in
>>>>> Internet.  Without the mandate, I doubt it would have  
>>>>> happened.   Our
>>>>> "Internet" today would probably be a gaggle of X.25 networks
>>>>> interconnected by X.75 gateways - that was certainly the plan.   
>>>>> The
>>>>> economics and performance of X.25/X.75 would probably never have
>>>>> permitted the creation of the Web, or any of the other "killer  
>>>>> apps"
>>>>> that we now use everyday.  Packet-switching may have changed the
>>>>> economics of using long lines, but I think the "Internet  
>>>>> economics"
>>>>> changed the cost structure on data comm dramatically, and that's  
>>>>> what
>>>>> enabled the explosion of growth of "The Internet" from the  
>>>>> mid-90s on.
>>>>> If the Arpanet had had its way, today's Internet, if it existed at
>>>>> all,
>>>>> would be X.25/X.75.
>>>>>
>>>>> So, my perspective is that the Arpanet was not the fledgling
>>>>> Internet -
>>>>> the Arpanet reluctantly nurtured the Internet, and eventually died
>>>>> as a
>>>>> result.  Once TCP was required, the Arpanet was doomed; it took  
>>>>> only a
>>>>> few years.  I wonder if there are any Arpanet-style X.25 networks
>>>>> left...
>>>>>
>>>>> I have a big red button that says "I Survived the TCP Transition
>>>>> 1/1/83".  They were handed out to commemorate the cutover, but I  
>>>>> don't
>>>>> remember exactly where I got it.  Sounds like something Jon Postel
>>>>> would
>>>>> have done though.  Anybody else have one?
>>>>>
>>>>> /Jack Haverty
>>>>> Point Arena, CA
>>>>>
>>>>> On Mon, 2009-11-02 at 12:20 -0800, Bob Braden wrote:
>>>>>> Noel wrote:
>>>>>>
>>>>>> And speaking of the Internet as a distinct entity, whats it's
>>>>>> birth-day
>>>>>>> anyway? I would call it the first day on which a packet was sent
>>>>>>> from one
>>>>>>> host, across a particular kind of network, through a router (or
>>>>>> gateway as we
>>>>>>> called them back then), across another network, into another  
>>>>>>> host.
>>>>>> (That woul
>>>>>>> d
>>>>>>> have been a TCP packet, I guess - no IP back then!) So where and
>>>>>>> when was
>>>>>>> that?
>>>>>>
>>>>>> At the time, we reckoned the beginning of the Internet to be  
>>>>>> the Red
>>>>>> Flag day when the ARPAnet converted from NCP to TCP/IP: Jan 1,  
>>>>>> 1983.
>>>>>> I think someone has an "I survived..." sweatshirt to commemorate
>>>>>> that date.
>>>>>>
>>>>>> Bob Braden
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
> -- 
> Richard Bennett
> Research Fellow
> Information Technology and Innovation Foundation
> Washington, DC
>



From dhc2 at dcrocker.net  Fri Nov  6 13:08:56 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Sat, 07 Nov 2009 06:08:56 +0900
Subject: [ih] internet-history Digest, Vol 37, Issue 1
In-Reply-To: <1257456639.3343.5.camel@localhost>
References: <mailman.4611.1257190731.20530.internet-history@postel.org>	<4AEF3EF6.20709@isi.edu>
	<1257198297.3385.35.camel@localhost>	<D8D357AE-573C-4766-8B1D-DE2D2A01B50F@google.com>
	<1257456639.3343.5.camel@localhost>
Message-ID: <4AF49068.2030207@dcrocker.net>


Jack Haverty wrote:
 > I just found my souvenir plastic pocket protector - "TCP/IP '87 Geeks on
 > the Bay in Monterey".  I think this was probably just before the name
 > "Interop" appeared, but it was arguably the first Interop conference.
 > The first name was "Advanced Computing Environments" (on my ceramic
 > souvenir tile.)

As I recall, that was the sponsored event that the DoD's Heidi Heiden initiated. 
  I definitely remember that it was in Monterey.

Dan can confirm this, but I recall his crediting Heidi with the creation of 
Interop:  Dan asked Heidi about further such events and Heidi said there were 
none planned.  This opened the door for Dan's entrepreneurial effort.

I don't remember whether this was the event Dan referred to as Interop 0 or 
whether there was a later, practice run, before producing the open, formal event 
we know under the name.


> I wonder if the Internet would have been such a success if Interop
> hadn't happened to allow the "real world" to join the party.  And of
> course the signature chocolate chip cookies were crucial.

I share Jack's view that Interop was a significant contributor to the adoption 
of the Internet.  The hands-on quality of any interop (little 'i') seems to jump 
the quality of products by at least six-months.  More importantly, interop 
events socialize the technology and create a technical community with shared 
experience.

Instantiating such processes into Interop (big 'I') essentially created a place 
for an entire industry to coalesce.

IMO, the simulated chocolate cookies provided when Interop moved to the San Jose 
Convention Center were not even close to the wonderfulness of the Monterey 
Doubletree's recipe...

d/



-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From vint at google.com  Sat Nov  7 06:52:23 2009
From: vint at google.com (Vint Cerf)
Date: Sat, 7 Nov 2009 09:52:23 -0500
Subject: [ih] does anyone have copies of IEN 26 and 27?
Message-ID: <0D75938C-5512-48D9-9CF0-BC292E943EAD@google.com>



From vint at google.com  Sat Nov  7 07:23:43 2009
From: vint at google.com (Vint Cerf)
Date: Sat, 7 Nov 2009 10:23:43 -0500
Subject: [ih] [ipv6] IP versions explained
In-Reply-To: <922f6670911070654p1fa93106r92b1b97022a6210a@mail.gmail.com>
References: <63a2e74f0911062147t7c011229w571fd2e7d47b4a4e@mail.gmail.com>
	<7B7327FF-269C-4098-8090-C115DF9B1719@google.com>
	<922f6670911070654p1fa93106r92b1b97022a6210a@mail.gmail.com>
Message-ID: <2905DAF2-85E6-47DA-B679-6BFC109A190F@google.com>

i did some digging around.

The first documented split of IP from TCP came with TCP v3 which was  
published as IEN21 in January 1978. The "internetwork header" showed a  
variable length (!) source and destination address field among other  
things, separate from the TCP header. This was subsequently revised in  
TCP 3.1 in Feb 1978  with IENs 26, 27, 28 and again, in June 1978 with  
IPv4 and TCPv4 in IENs 40 (TCP) and 41(IP).

IPv5 was an excursion into streaming communication but was abandoned.

v



On Nov 7, 2009, at 9:54 AM, Steve Wilcox wrote:

> Well, "IP" was never of a particular version in the sense that IPv4  
> and IPv6 are compared - they are fundementally different protocols  
> with different ether-types, IP is the first such protocol not the  
> fourth (but the version within the protocol is 4).. (0x0800 which is  
> "IP" currently uses version "4" but IPv6 does not use an 0x0800  
> ethertype with version "6", it actually is a totally different  
> protocol)
>
> I think you are right that the version just recorded the latest  
> version of the IP protocol packet at a time when these things were  
> subject to being changable. Whatever happened to 1, 2, 3 I'm sure  
> you have a better idea that I but what emerged was version=4. I  
> believe later versions were used as proposals for the IPng solution  
> but ultimately it was decided to invent a new addressing scheme and  
> ether protocol entirely and someone decided that calling it "v6" was  
> the way to go.
>
> Searching for this throws up a lot of results which don't seem to be  
> correct.. I think what happened in the 90s and before is not well  
> recorded.. perhaps time to write it up? :-)
>
> I certainly recall when I was getting into networking (during the  
> 90s) that "IP" was nothing special and many variants existed of  
> protocols such as IPX, DEC and within IP we had ether-II, snap, and  
> other things whose names escape me.. all of which seemed quite  
> normal at the time - unlike todays "IP" dominated world!
>
> Steve
>
> On Sat, Nov 7, 2009 at 2:28 PM, Vint Cerf <vint at google.com> wrote:
> This is an incorrect assumption - IPv5 was simply the next version  
> after IPv4. As it happened, it didn't work out very well (scaling  
> problems as I recall) so it was abandoned. IPv6 is, of course, the  
> version with the larger address space. There were no official IPv1  
> or IPv2 versions. I would have to go back to double check whether we  
> split off IP from TCP at TCPv3 or TCPv4. If at v4 then there were  
> never any versions of IP until IPv4. We just numbered in parallel  
> with TCP because of the intimate linkage between the two protocols.
>
> vint
>
>
> On Nov 7, 2009, at 12:47 AM, Michael Shields wrote:
>
>> From http://www.whatismyip.com/ and many other sites:
>>
>> IP version 5: This is an experimental protocol for UNIX based  
>> systems. In keeping with standard UNIX (a computer Operating  
>> System) release conventions, all odd-numbered versions are  
>> considered experimental. It was never intended to be used by the  
>> general public.
>>
>> http://hb.corp.google.com/?mode=sent&sent=IP+version+5:+This+is+an+experimental+protocol+for+UNIX+based+systems.&xsent=IP+version+5:+This+is+an+experimental+protocol+for+UNIX+based+systems.&ref=1
>
>
>
>
> -- 
> Network Operations - Standards & Design
> Google Inc.
> E: stevewilcox at google.com
> M: +44 7920 041930

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091107/9aed74a3/attachment.htm>

From jack at 3kitty.org  Sat Nov  7 09:59:54 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 07 Nov 2009 09:59:54 -0800
Subject: [ih] [ipv6] IP versions explained
In-Reply-To: <2905DAF2-85E6-47DA-B679-6BFC109A190F@google.com>
References: <63a2e74f0911062147t7c011229w571fd2e7d47b4a4e@mail.gmail.com>
	<7B7327FF-269C-4098-8090-C115DF9B1719@google.com>
	<922f6670911070654p1fa93106r92b1b97022a6210a@mail.gmail.com>
	<2905DAF2-85E6-47DA-B679-6BFC109A190F@google.com>
Message-ID: <1257616794.3379.43.camel@localhost>

Depends on how you define "documented"...do the TCP Working Group
distributions qualify?

The "TCP Meeting Notes", written by Jon Postel and emailed to
[isie]<postel>TCP-Working-Group.List on 21 Oct 1977 1728-PDT, documented
the activity at the meeting of 13-14 October 1977.  The first agenda
item was "Discussion of TCP-3" and the notes say that "Vint spoke first
and outlined his goal for the meeting: 'Define TCP-3'"  An extensive
summary of the discussions follows - Rubber EOL, Resynchronization,
Three Way Handshake, etc.  There is also an appendix: "Proposal for TCP
3" by Ray Tomlinson, dated 12 October 1977.

There was also "Discussion of TCP-4" on the agenda.  One of the action
items for Jon was "TCP-3 Specification: draft in two weeks, final two
weeks after that - Postel"  From the notes, the idea was to write down a
TCP-3 spec, which provided only reliable-transport service, and then
focus on TCP-4, to provide also an unreliable datagram service for
applications such as packet voice, conferencing, and such that were
clamoring for support.  The splitting of the headers in version 3
enabled the creation of protocols above IP that were not TCP - e.g., UDP
et al for voice.  It also made possible the variety of fun and games of
internet plumbers - e.g., running SPX over IPX over IP to glue together
Netware-islands via the Internet (and vice versa).

As far as I remember, there was only one implementation of TCP V3, I
think by Ford Aero, which couldn't find anyone to communicate with,
since the rest of us were very quickly running on the rapidly congealing
TCP4 architecture (which then produced the spec in June 78).   Specs
always came well after code, when we knew the ideas and technical
approaches actually seemed to work OK in the live net.

As I recall, the main pressure for TCP-3 was a result of the DoD
standardizing on TCP, and needing a formal spec for inclusion in
contracts.  The research group was reluctant (to put it mildly) to nail
things down with so many unresolved issues - which took another 6 months
or so to congeal into the TCP4 design.

There's some fascinating experiences in all of this with respect to the
challenge of taking a technology from research to production.   The
research-side pattern was meeting, discussion, arguments, write the
code, get it working, repeat until interrupt: oh yeah, I guess we need
to write a spec.  The production-side pattern was write the spec, get
everyone to approve it, issue rfps, issue contracts, write code, pass
the acceptance tests, deploy it to the users, see it it works.

Once TCP/IP got out of the realm where all of the implementors could sit
together in a room or on a mailing list and argue, it became harder to
change things.  Research goals never seem to include "must be easily
upgradeable without disruption to current operations."

I think we all expected TCP V5, 6 etc. to come along in rapid succession
- certainly not decades!  But once those pesky users enter the scene,
the world is different....as we learned in doing things like the
NCP->TCP transition in 1983 and all of the machinery and procedures that
had to be invented to make it work.

/Jack Haverty
Point Arena, CA


On Sat, 2009-11-07 at 10:23 -0500, Vint Cerf wrote:
> i did some digging around.
> 
> 
> The first documented split of IP from TCP came with TCP v3 which was
> published as IEN21 in January 1978. The "internetwork header" showed a
> variable length (!) source and destination address field among other
> things, separate from the TCP header. This was subsequently revised in
> TCP 3.1 in Feb 1978  with IENs 26, 27, 28 and again, in June 1978 with
> IPv4 and TCPv4 in IENs 40 (TCP) and 41(IP).
> 
> 
> IPv5 was an excursion into streaming communication but was abandoned.
> 
> 
> v
> 
> 
> 
> 
> 
> On Nov 7, 2009, at 9:54 AM, Steve Wilcox wrote:
> 
> > Well, "IP" was never of a particular version in the sense that IPv4
> > and IPv6 are compared - they are fundementally different protocols
> > with different ether-types, IP is the first such protocol not the
> > fourth (but the version within the protocol is 4).. (0x0800 which is
> > "IP" currently uses version "4" but IPv6 does not use an 0x0800
> > ethertype with version "6", it actually is a totally different
> > protocol)
> > 
> > I think you are right that the version just recorded the latest
> > version of the IP protocol packet at a time when these things were
> > subject to being changable. Whatever happened to 1, 2, 3 I'm sure
> > you have a better idea that I but what emerged was version=4. I
> > believe later versions were used as proposals for the IPng solution
> > but ultimately it was decided to invent a new addressing scheme and
> > ether protocol entirely and someone decided that calling it "v6" was
> > the way to go.
> > 
> > Searching for this throws up a lot of results which don't seem to be
> > correct.. I think what happened in the 90s and before is not well
> > recorded.. perhaps time to write it up? :-)
> > 
> > I certainly recall when I was getting into networking (during the
> > 90s) that "IP" was nothing special and many variants existed of
> > protocols such as IPX, DEC and within IP we had ether-II, snap, and
> > other things whose names escape me.. all of which seemed quite
> > normal at the time - unlike todays "IP" dominated world!
> > 
> > Steve
> > 
> > On Sat, Nov 7, 2009 at 2:28 PM, Vint Cerf <vint at google.com> wrote:
> >         This is an incorrect assumption - IPv5 was simply the next
> >         version after IPv4. As it happened, it didn't work out very
> >         well (scaling problems as I recall) so it was abandoned.
> >         IPv6 is, of course, the version with the larger address
> >         space. There were no official IPv1 or IPv2 versions. I would
> >         have to go back to double check whether we split off IP from
> >         TCP at TCPv3 or TCPv4. If at v4 then there were never any
> >         versions of IP until IPv4. We just numbered in parallel with
> >         TCP because of the intimate linkage between the two
> >         protocols.
> >         
> >         
> >         vint
> >         
> >         
> >         
> >         
> >         On Nov 7, 2009, at 12:47 AM, Michael Shields wrote:
> >         
> >         > From http://www.whatismyip.com/ and many other sites:
> >         >         
> >         >         IP version 5: This is an experimental protocol for
> >         >         UNIX based systems. In keeping with standard UNIX
> >         >         (a computer Operating System) release conventions,
> >         >         all odd-numbered versions are considered
> >         >         experimental. It was never intended to be used by
> >         >         the general public.
> >         > 
> >         > 
> >         > http://hb.corp.google.com/?mode=sent&sent=IP+version+5:
> >         > +This+is+an+experimental+protocol+for+UNIX+based
> >         > +systems.&xsent=IP+version+5:+This+is+an+experimental
> >         > +protocol+for+UNIX+based+systems.&ref=1
> >         
> >         
> > 
> > 
> > 
> > -- 
> > Network Operations - Standards & Design
> > Google Inc.
> > E: stevewilcox at google.com
> > M: +44 7920 041930
> 
> 



From cos at aaaaa.org  Sat Nov  7 11:53:50 2009
From: cos at aaaaa.org (Ofer Inbar)
Date: Sat, 7 Nov 2009 14:53:50 -0500
Subject: [ih] Enforecment of NSFNET's Acceptable Use Policy
In-Reply-To: <4A82D9A9.50003@cs.tu-berlin.de>
References: <4A82D9A9.50003@cs.tu-berlin.de>
Message-ID: <20091107195350.GZ17854@mip.aaaaa.org>

This is months old but I just stumbled on it again and it reminded me
of something.

On Wed, Aug 12, 2009 at 05:03:05PM +0200,
Matthias Brwolff <mbaer at cs.tu-berlin.de> wrote:
> I was wondering if anyone knows about or has pointers to sources on
> actual cases of violations of NSFNET's Acceptable Use Policy and
> repercussions of such cases. The final report is silent on this specific
> point.
> 
> - Has there ever been a case where someone (some network) had its access
> to NSFNET's backbone removed (or was at least told off or fined in any way)?
> 
> - How did NSF monitor the use of their backbone?
> 
> - Was there any effect of the AUP other than people "feeling"
> constrained by it, and not blatantly advertising things in a commercial
> fashion?
> 
> The only statement I found on this comes from an obscure source
> (netdictionary.com/a.html) saying "its [NSFnet's AUP's] limitations on
> commercial activity were so widely ignored that it was finally abandoned
> in 1994".

I recall that when world.std.com, which had been selling accounts like
many other "pubnix" sites, got an Internet hookup via UUNET circa 1991,
there were a lot of pieces of the Internet that World users couldn't
route to directly, because the NFSnet backbone didn't route their traffic.

I had friends on World and we used to do various things to get around
the restrictions.  For example, they couldn't always talk/ytalk to
their friends' accounts, but there were some IRC servers they could
connect to, and their chat would get through the IRC network.

I do remember people at Software Tool and Die telling me that the
NFSnet AUP was the reason for this, but I don't have any real
information beyond that.
  -- Cos


From deering at brunzel.org  Sat Nov  7 13:36:50 2009
From: deering at brunzel.org (Steve Deering)
Date: Sat, 7 Nov 2009 13:36:50 -0800
Subject: [ih] [ipv6] IP versions explained
In-Reply-To: <2905DAF2-85E6-47DA-B679-6BFC109A190F@google.com>
References: <63a2e74f0911062147t7c011229w571fd2e7d47b4a4e@mail.gmail.com>
	<7B7327FF-269C-4098-8090-C115DF9B1719@google.com>
	<922f6670911070654p1fa93106r92b1b97022a6210a@mail.gmail.com>
	<2905DAF2-85E6-47DA-B679-6BFC109A190F@google.com>
Message-ID: <335FF81A-AD11-42BB-9DFA-18B4AE064C3B@brunzel.org>

> On Nov 7, 2009, at 9:54 AM, Steve Wilcox wrote:
>> ... I think what happened in the 90s and before is not well  
>> recorded.. perhaps time to write it up? :-)

Regarding the '90s and IP version numbers greater than 4...

Version 5 was assigned to the Stream Protocol, ST (see RFC 1190).  ST  
was designed not as a successor to IP, but rather as a companion  
protocol to IP, providing a stream- or circuit-oriented internet-layer  
service.   It used the same ether-type as IP, and relied on the IP  
version number (first 4 bits of the header) to distinguish ST from  
IP.  There were multiple implementations of ST, and it was used in the  
'80s and '90s to support experiments (and perhaps production use?) in  
"real-time" applications such as teleconferencing.

The protocol now know as IPv6 was primarily derived from my proposed  
IPv4 successor called SIP (Simple Internet Protocol).  Originally, SIP  
did not include an IP version number field and used a separate ether- 
type.  Several prototype implementations of SIP were undertaken, and  
the requirement to use a new ether-type created an obstacle for at  
least one of those implementations (probably on some early version of  
Windows), so I changed the specification of SIP to include an IP  
version number field and to use the same ether-type as IPv4.

I therefore applied to IANA for an IP version number to use in SIP  
prototypes, and was assigned number 6, because that was the next  
available value.  In order not to be seen as "blessing" SIP as the  
next version of IP,  Jon at the same time assigned IP version numbers  
to all the other IPng candidates then under consideration in the IETF,  
even though their headers didn't have or require an IP version number  
field.  The assignments were as follows:

   6 - SIP
   7 - TP/IX
   8 - PIP
   9 - TUBA

About a year later, we in the SIP (later SIPP) Working Group received  
reports of a problem arising in the deployment of ST.   Apparently,
ST had been failing in some environments because of intermediate  
devices -- not routers, but rather things like layer-2 switches or  
security devices -- that were snooping in IP headers and taking some  
action (such as discarding packets) based on what they found.   
Unfortunately, those devices were identifying IP packets simply by  
ether-type, and were failing to verify the IP version number before  
proceeding to parse other parts of the IP header.  Despite the fact  
that those devices were clearly "in the wrong", we decided to go back  
to using the separate ether-type for SIP so that we wouldn't risk  
encountering the same deployment problem as ST.  So that's how IPv6  
ended up with the redundancy of both an IP version number field and  
its own ether-type.

Steve



From mbaer at cs.tu-berlin.de  Sun Nov  8 14:44:25 2009
From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=)
Date: Sun, 08 Nov 2009 23:44:25 +0100
Subject: [ih] does anyone have copies of IEN 26 and 27?
In-Reply-To: <0D75938C-5512-48D9-9CF0-BC292E943EAD@google.com>
References: <0D75938C-5512-48D9-9CF0-BC292E943EAD@google.com>
Message-ID: <4AF749C9.20607@cs.tu-berlin.de>

http://www.postel.org/ien/pdf/



From dhc2 at dcrocker.net  Sun Nov  8 16:33:42 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 09 Nov 2009 09:33:42 +0900
Subject: [ih] [ipv6] IP versions explained
In-Reply-To: <335FF81A-AD11-42BB-9DFA-18B4AE064C3B@brunzel.org>
References: <63a2e74f0911062147t7c011229w571fd2e7d47b4a4e@mail.gmail.com>	<7B7327FF-269C-4098-8090-C115DF9B1719@google.com>	<922f6670911070654p1fa93106r92b1b97022a6210a@mail.gmail.com>	<2905DAF2-85E6-47DA-B679-6BFC109A190F@google.com>
	<335FF81A-AD11-42BB-9DFA-18B4AE064C3B@brunzel.org>
Message-ID: <4AF76366.80704@dcrocker.net>



Steve Deering wrote:
> The protocol now know as IPv6 was primarily derived from my proposed 
> IPv4 successor called SIP (Simple Internet Protocol). 


And, with about equal frequency by my informal reading at the time, also known 
as Steve's IP.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From braden at ISI.EDU  Sun Nov  8 16:42:04 2009
From: braden at ISI.EDU (Bob Braden)
Date: Sun, 08 Nov 2009 16:42:04 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <mailman.6790.1257623657.20530.internet-history@postel.org>
References: <mailman.6790.1257623657.20530.internet-history@postel.org>
Message-ID: <4AF7655C.10303@isi.edu>


Vint wrote:

  The first documented split of IP from TCP came with TCP v3 which was  
  published as IEN21 in January 1978. The "internetwork header" showed a  
  variable length (!) source and destination address field among other  
  things, separate from the TCP header. This was subsequently revised in  
  TCP 3.1 in Feb 1978  with IENs 26, 27, 28 and again, in June 1978 with  
  IPv4 and TCPv4 in IENs 40 (TCP) and 41(IP).


Vint,

I recall rather vividly the variable vs fixed length address discussion. 
Jon Postel and Danny Cohen strongly favored variable length addresses, 
for architectural reasons.  I assume that Jon slipped them into IEN21. 
In your DARPA role, you then decreed (and it was perfectly clear to the 
rest of us that this was non-negotiable) that addresses would be 32 bits 
and fixed length.  Your argument was that it would significantly 
simplify implementations of the protocols, and that would strengthen the 
acceptability of TCP/IP in the struggle with OSI. I have often wondered 
who was right. In the short run, you were probably right about the 
threat of OSI.  In the long run, would variable length addresses have 
avoided the IPv4/IPv6 mess?  I can only speculate.

Bob Braden






From jeanjour at comcast.net  Sun Nov  8 18:12:55 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 8 Nov 2009 21:12:55 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <4AF7655C.10303@isi.edu>
References: <mailman.6790.1257623657.20530.internet-history@postel.org>
	<4AF7655C.10303@isi.edu>
Message-ID: <a06240810c71d28758618@[10.0.1.45]>

Just one problem with that memory Bob.

OSI didn't start until March,1978 and there was no network layer 
group until at least 1980.  (There was a lower layer group, but no 
group to develop protocols for the Network Layer).  There was no 
proposal within OSI for a subnet independent protocol, i.e. an 
internet protocol, nor an indication it wouldn't be IP until after 
83.  It wasn't even decided that the Europeans would allow datagrams 
into OSI in any form until Oct 1983.

Also, IEN 21 is dated January 1978.  The split must have occurred 
well before that because if *my memory serves* ;-) one of the 
discussions in arriving at INWG 96 by Dec 1977 was whether or not the 
protocol chosen could be used over something other than a datagram 
service and for TCP, IP already existed.

Lets not fall into the "effects of T.S. Eliot on Shakespeare" trap.  ;-)

John

At 16:42 -0800 2009/11/08, Bob Braden wrote:
>Vint wrote:
>
>  The first documented split of IP from TCP came with TCP v3 which 
>was   published as IEN21 in January 1978. The "internetwork header" 
>showed a   variable length (!) source and destination address field 
>among other   things, separate from the TCP header. This was 
>subsequently revised in   TCP 3.1 in Feb 1978  with IENs 26, 27, 28 
>and again, in June 1978 with   IPv4 and TCPv4 in IENs 40 (TCP) and 
>41(IP).
>
>
>Vint,
>
>I recall rather vividly the variable vs fixed length address 
>discussion. Jon Postel and Danny Cohen strongly favored variable 
>length addresses, for architectural reasons.  I assume that Jon 
>slipped them into IEN21. In your DARPA role, you then decreed (and 
>it was perfectly clear to the rest of us that this was 
>non-negotiable) that addresses would be 32 bits and fixed length. 
>Your argument was that it would significantly simplify 
>implementations of the protocols, and that would strengthen the 
>acceptability of TCP/IP in the struggle with OSI. I have often 
>wondered who was right. In the short run, you were probably right 
>about the threat of OSI.  In the long run, would variable length 
>addresses have avoided the IPv4/IPv6 mess?  I can only speculate.
>
>Bob Braden



From jnc at mercury.lcs.mit.edu  Sun Nov  8 18:30:03 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  8 Nov 2009 21:30:03 -0500 (EST)
Subject: [ih] IPv4 address size debate
Message-ID: <20091109023004.0F87D6BE5BD@mercury.lcs.mit.edu>

    > From: Bob Braden <braden at ISI.EDU>

    > I have often wondered who was right. In the short run, you were
    > probably right about the threat of OSI. In the long run, would variable
    > length addresses have avoided the IPv4/IPv6 mess? I can only speculate.

You've pressed one of my long-standing hot buttons.... :-)

The right answer, IMO, to the question of "who was right" is 'both/neither'.
To be a bit less cryptic, what _I_ would have pushed for (had I been more
involved at that point; I was part of the MIT crew, and vividly recall David
Reed reporting on this debate, but I was not yet part of the TCP/IP group)
would have been a _packet format_ which _allowed_ for variable length, but
'temporarily' subsetted it so that for the immediate term, the only
allowed/supported value for the addresz length was '4'.

IMNSHO this choice would have been better than either of the two other
options, as it would have had the advantages of both (easy initial
implementation, as well as long-term flexibility), and the disadvantages of
neither.

(As a corollary to that observation, it should be obvious that I feel that
both sides of the debate had some good points; a less obvious corollary is
that both had such force that it would probably have been unwise to entirely
blow off either - as I believe blowing off the variable-length crew has
shown.)


To explore a related question a bit, I must confess I'm somewhat puzzled why
this wasn't done. Maybe it's just me, but it seems to me to be a relatively
obvious idea, and also, to me at least, 'obviously' better than the other
alternatives.

Yes, phasing in support for lengths other than 4 would not have been trivial,
but it would have been possible without being unutterably painful (witness
phasing in support for first A/B/C, and then later, CIDR; although I concede
these were somewhat easier than variable-length addresses would have been).

It would, I guess, have meant the header would be a full-word longer (since
extending it by a short, to hold two byte-length address length fields, would
have left it non-long-word aligned), i.e. more overhead, but I can't think of
any other flat-out downside.

Was this possibility discussed at the time, or was the choice seen as only all
or nothing (i.e. only '32-bits/fully-variable')?

	Noel


From jack at 3kitty.org  Sun Nov  8 19:39:20 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Sun, 08 Nov 2009 19:39:20 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <a06240810c71d28758618@[10.0.1.45]>
References: <mailman.6790.1257623657.20530.internet-history@postel.org>
	<4AF7655C.10303@isi.edu>  <a06240810c71d28758618@[10.0.1.45]>
Message-ID: <1257737960.3371.7.camel@localhost>

On Sun, 2009-11-08 at 21:12 -0500, John Day wrote:
> Also, IEN 21 is dated January 1978.  The split must have occurred 
> well before that

My experience is that, as a general rule, any "internet document" was
written after, often well after, the design had been coded, deployed,
and tested, with extensive email discussions along the way.  This was
especially true of anything purporting to be a specification, rather
than a proposal.  So the TCP/IP split certainly occurred well before the
IEN was issued.

The "Internet philosophy" was always "rough consensus and working code"
- in sharp contrast to OSI which created large stacks of paper first,
then un leashed armies of programmers to try to implement it.

IMHO, that's another major reason why the Internet won.

/Jack Haverty
Point Arena, CA



From jack at 3kitty.org  Sun Nov  8 19:46:43 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Sun, 08 Nov 2009 19:46:43 -0800
Subject: [ih] IPv4 address size debate
In-Reply-To: <20091109023004.0F87D6BE5BD@mercury.lcs.mit.edu>
References: <20091109023004.0F87D6BE5BD@mercury.lcs.mit.edu>
Message-ID: <1257738403.3371.12.camel@localhost>

On Sun, 2009-11-08 at 21:30 -0500, Noel Chiappa wrote:
> Was this possibility discussed at the time

I remember lots of discussion about the appropriate length of various
fields in the headers (TCP and IP) - not just the address.  In the end,
I think the "options" functionality was viewed as a way to fix things
later if it turned out that some field wasn't big enough.  You could
always define a new option to hold a bunch of extra bytes for whatever
field needed them.  Not elegant, but it was a way to stop the debate.

/Jack




From jeanjour at comcast.net  Sun Nov  8 20:03:25 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 8 Nov 2009 23:03:25 -0500
Subject: [ih] IPv4 address size debate
In-Reply-To: <20091109023004.0F87D6BE5BD@mercury.lcs.mit.edu>
References: <20091109023004.0F87D6BE5BD@mercury.lcs.mit.edu>
Message-ID: <a06240817c71d4392e0d3@[10.0.1.45]>

Once one understands the bigger picture, one realizes that question 
of variable vs fixed is a non-sequitor. But one does have to get free 
of the constraints of a Ptolemaic approach to architecture.

At which point fixed is variable.

At 21:30 -0500 2009/11/08, Noel Chiappa wrote:
>     > From: Bob Braden <braden at ISI.EDU>
>
>     > I have often wondered who was right. In the short run, you were
>     > probably right about the threat of OSI. In the long run, would variable
>     > length addresses have avoided the IPv4/IPv6 mess? I can only speculate.
>
>You've pressed one of my long-standing hot buttons.... :-)
>
>The right answer, IMO, to the question of "who was right" is 'both/neither'.
>To be a bit less cryptic, what _I_ would have pushed for (had I been more
>involved at that point; I was part of the MIT crew, and vividly recall David
>Reed reporting on this debate, but I was not yet part of the TCP/IP group)
>would have been a _packet format_ which _allowed_ for variable length, but
>'temporarily' subsetted it so that for the immediate term, the only
>allowed/supported value for the addresz length was '4'.
>
>IMNSHO this choice would have been better than either of the two other
>options, as it would have had the advantages of both (easy initial
>implementation, as well as long-term flexibility), and the disadvantages of
>neither.
>
>(As a corollary to that observation, it should be obvious that I feel that
>both sides of the debate had some good points; a less obvious corollary is
>that both had such force that it would probably have been unwise to entirely
>blow off either - as I believe blowing off the variable-length crew has
>shown.)
>
>
>To explore a related question a bit, I must confess I'm somewhat puzzled why
>this wasn't done. Maybe it's just me, but it seems to me to be a relatively
>obvious idea, and also, to me at least, 'obviously' better than the other
>alternatives.
>
>Yes, phasing in support for lengths other than 4 would not have been trivial,
>but it would have been possible without being unutterably painful (witness
>phasing in support for first A/B/C, and then later, CIDR; although I concede
>these were somewhat easier than variable-length addresses would have been).
>
>It would, I guess, have meant the header would be a full-word longer (since
>extending it by a short, to hold two byte-length address length fields, would
>have left it non-long-word aligned), i.e. more overhead, but I can't think of
>any other flat-out downside.
>
>Was this possibility discussed at the time, or was the choice seen as only all
>or nothing (i.e. only '32-bits/fully-variable')?
>
>	Noel



From sbrim at cisco.com  Sun Nov  8 20:16:29 2009
From: sbrim at cisco.com (Scott Brim)
Date: Mon, 09 Nov 2009 13:16:29 +0900
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <1257737960.3371.7.camel@localhost>
References: <mailman.6790.1257623657.20530.internet-history@postel.org>	<4AF7655C.10303@isi.edu>
	<a06240810c71d28758618@[10.0.1.45]>
	<1257737960.3371.7.camel@localhost>
Message-ID: <4AF7979D.9060502@cisco.com>

Jack Haverty allegedly wrote on 11/09/2009 12:39 PM:
> The "Internet philosophy" was always "rough consensus and working code"

Not officially until the IETF in Munich.




From craig at aland.bbn.com  Mon Nov  9 03:27:32 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Mon, 09 Nov 2009 06:27:32 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
Message-ID: <20091109112732.CE9D728E137@aland.bbn.com>


> Also, IEN 21 is dated January 1978.  The split must have occurred 
> well before that because if *my memory serves* ;-) one of the 
> discussions in arriving at INWG 96 by Dec 1977 was whether or not the 
> protocol chosen could be used over something other than a datagram 
> service and for TCP, IP already existed.

A few years ago I went digging to try to find out when and where IP
was invented.

The simple answer appears to be it was created in a hallway conversation
at an TCP meeting at ISI in 1977.  (Full answer is more complex and
involves tracing various research efforts and ideas to that hallway...).

Thanks!

Craig


From vint at google.com  Mon Nov  9 03:55:18 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 9 Nov 2009 06:55:18 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <20091109112732.CE9D728E137@aland.bbn.com>
References: <20091109112732.CE9D728E137@aland.bbn.com>
Message-ID: <6744CEEF-6858-488F-8993-4378F93913B7@google.com>

this comports with my recollection. Danny Cohen, David Reed and Jon  
Postel lobbied strongly for a non-sequential, fast delivery mechanism  
and TCP 3.0 made reference to a new header that performed this  
function (routing). We decided later to split off into a distinct  
protocol document, developed UDP for user access to this mode of  
operation and put TCP on top. This was all codified in the first TCP  
and IP v4 documents in 1978.

v

On Nov 9, 2009, at 6:27 AM, Craig Partridge wrote:

>
>> Also, IEN 21 is dated January 1978.  The split must have occurred
>> well before that because if *my memory serves* ;-) one of the
>> discussions in arriving at INWG 96 by Dec 1977 was whether or not the
>> protocol chosen could be used over something other than a datagram
>> service and for TCP, IP already existed.
>
> A few years ago I went digging to try to find out when and where IP
> was invented.
>
> The simple answer appears to be it was created in a hallway  
> conversation
> at an TCP meeting at ISI in 1977.  (Full answer is more complex and
> involves tracing various research efforts and ideas to that  
> hallway...).
>
> Thanks!
>
> Craig



From jeanjour at comcast.net  Mon Nov  9 06:10:40 2009
From: jeanjour at comcast.net (John Day)
Date: Mon, 9 Nov 2009 09:10:40 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <6744CEEF-6858-488F-8993-4378F93913B7@google.com>
References: <20091109112732.CE9D728E137@aland.bbn.com>
	<6744CEEF-6858-488F-8993-4378F93913B7@google.com>
Message-ID: <a06240819c71dc76b4879@[10.0.1.45]>

That is interesting. I would have thought it was a little bit sooner, 
but then there isn't much room for it to be much sooner.  ;-)

It is in some sense ironic.  We were so concerned about overhead 
(both bandwidth and processing) that it was thought that the 
transport protocol had to operate directly over whatever was at the 
network layer.  The Europeans knew they had to deal with X.25 and the 
pseudo header pretty much prevented TCP from use with X.25 directly. 
And it was thought to be too much overhead to run transport over an 
IP like protocol over X.25.  So WG6.1 chose the older TS protocol. 
which was then carried into OSI as a liaison contribution to become 
TP4.

However, when OSI finally got around to working out what the Network 
Layer was all about (IONL) they found that it was 3 "sublayers." 
Ironically, X.25 became a subnet access protocol at the bottom 
(referred to as 3a) of the network layer (since that is what the 
title of the document said it was!, i.e. a DTE-to-DCE protocol)  ;-) 
Not the network protocol at the top of the network layer. The top of 
the network layer was subnet-independent (referred to as 3c) or what 
has been called the internet layer, where CLNP was connectionless 
subnet independent protocol.  (For some reason the connection 
advocates in OSI never did the connection-oriented subnet independent 
protocol. They were invited to.)  For completeness, 3b was suppose to 
be whatever was required to convert between subnet-dependent and 
subnet-independent.  Although, I don't know of any such protocols 
ever being proposed.

So OSI ended doing what WG6.1 had avoided. Transport (TP4/TS) over an 
internet protocol (CLNP) that names the node over a network protocol 
(X.25 or IP) that names the interface.  In the space of just a few 
years the overhead issue had become a non-issue.

Had we gone this route, we wouldn't even have noticed the issues the 
current silliness emanating from the RRG are struggling with. Where 
the false distinction of loc/id split (you can't identify something 
without locating it and vice versa) has backed into loc/loc split. 
(Like that old joke that Communism was the longest most tortuous road 
from capitalism to capitalism.)  But it just keeps getting messier 
and messier as they try to save IPv6 from its own incompetence.  To 
think this was all well-understood before 1990, actually to some 
extent by 1972.

Of course, once one understands that the view of Transport and 
Network as separate layers is the telecom (beads-on-a-string) view 
and not the systems view and understands the natural structure of 
that class of protocols, you realize that IP is unnecessary as a 
distinct protocol.  In essence, TCP was split in the wrong direction. 
It would have been better to split vertically to separate "control 
from data" which yields a much more powerful, efficient and flexible 
design.

We were all too heavily influenced by the politics of the debate and 
what we thought was the case and not enough by what the problem was 
telling us, i.e. the science.  In some sense, it is too bad that 
software is so forgiving and Moore's Law allowed us to avoid problems 
that we could get by and didn't have to dig deeper.  Now we have 
quite a mess on our hands.



At 6:55 -0500 2009/11/09, Vint Cerf wrote:
>this comports with my recollection. Danny Cohen, David Reed and Jon 
>Postel lobbied strongly for a non-sequential, fast delivery 
>mechanism and TCP 3.0 made reference to a new header that performed 
>this function (routing). We decided later to split off into a 
>distinct protocol document, developed UDP for user access to this 
>mode of operation and put TCP on top. This was all codified in the 
>first TCP and IP v4 documents in 1978.
>
>v
>
>On Nov 9, 2009, at 6:27 AM, Craig Partridge wrote:
>
>>
>>>Also, IEN 21 is dated January 1978.  The split must have occurred
>>>well before that because if *my memory serves* ;-) one of the
>>>discussions in arriving at INWG 96 by Dec 1977 was whether or not the
>>>protocol chosen could be used over something other than a datagram
>>>service and for TCP, IP already existed.
>>
>>A few years ago I went digging to try to find out when and where IP
>>was invented.
>>
>>The simple answer appears to be it was created in a hallway conversation
>>at an TCP meeting at ISI in 1977.  (Full answer is more complex and
>>involves tracing various research efforts and ideas to that hallway...).
>>
>>Thanks!
>>
>>Craig



From LarrySheldon at cox.net  Mon Nov  9 07:27:46 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 09 Nov 2009 09:27:46 -0600
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <a06240819c71dc76b4879@[10.0.1.45]>
References: <20091109112732.CE9D728E137@aland.bbn.com>	<6744CEEF-6858-488F-8993-4378F93913B7@google.com>
	<a06240819c71dc76b4879@[10.0.1.45]>
Message-ID: <4AF834F2.3050500@cox.net>

[This may be off-topic and unwelcome--please so indicate by not 
responding to it in any way.  I have been involved with computers for a 
long time, but not involved in network development in the sense the term 
is used here.]

John Day wrote:

>                                         In the space of just a few years
> the overhead issue had become a non-issue.


I have long been interested in how often this syndrome has occurred 
(worrying about things that we spent a lot of time and other resources 
that became non-issues before we solved them).

When I started, things had to fit in 16,000 characters (32,000 if you 
were very wealthy, 64,000 rumored but never seen) of memory (14XX's), 
then 10,000 decimal words (707X's).

We went to extraordinary lengths to reduce the number of characters 
written to (256BPI, 7-track) tapes (some of the bizarre stuff takes a 
while to explain so I'll spare you).

Then we went to disks and drums where the space issue also involved the 
dreaded read-before-writes, and minimization of head movement and 
latency (hard to do in COBOL).

Now we have memory-by-the-acre, disc-by-the-cubic-mile, and disk speeds, 
high-speed cache, and solid-state-discs of huge size that have 
eliminated all those concerns (and we use programming language that 
makes them hard to see and impossible to do anything about).

What is there left to worry about?

Besides batteries that spontaneously combust in one of our several 
computes in our pockets.

-- 
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information:
	http://tinyurl.com/4sqczs
	http://tinyurl.com/7tp8ml
	


From jeanjour at comcast.net  Mon Nov  9 07:59:59 2009
From: jeanjour at comcast.net (John Day)
Date: Mon, 9 Nov 2009 10:59:59 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <4AF834F2.3050500@cox.net>
References: <20091109112732.CE9D728E137@aland.bbn.com>
	<6744CEEF-6858-488F-8993-4378F93913B7@google.com>
	<a06240819c71dc76b4879@[10.0.1.45]> <4AF834F2.3050500@cox.net>
Message-ID: <a0624081fc71deb6fb973@[10.0.1.45]>

Completely agreed.  And along the way re-inventing stuff.  I have 
always contend that CS is the only field in which Ontogeny really 
does Recapitulate Phylogeny!  ;-)  With mainframes, minis and micros 
we went through all the same things yet again.  In networking, it was 
terminal/host, client/server, network computer and now cloud 
computing.

You ask, what is there left to worry about?

Getting it right.  What is the structure and the solution the problem 
is telling is what we should be doing, i.e. we can get back to 
understanding the science of computer science.

I know that there are a lot of people saying that CS isn't a science. 
They simply lack the imagination and vision.  It was a science.  It 
has become a craft.  It will be a lot of hard unpleasant work, but it 
needs to reclaim its science.  Or as I like to characterize it,

maximizing the invariances and minimizing the discontinuities.

At 9:27 -0600 2009/11/09, Larry Sheldon wrote:
>[This may be off-topic and unwelcome--please so indicate by not 
>responding to it in any way.  I have been involved with computers 
>for a long time, but not involved in network development in the 
>sense the term is used here.]
>
>John Day wrote:
>
>>                                         In the space of just a few years
>>the overhead issue had become a non-issue.
>
>
>I have long been interested in how often this syndrome has occurred 
>(worrying about things that we spent a lot of time and other 
>resources that became non-issues before we solved them).
>
>When I started, things had to fit in 16,000 characters (32,000 if 
>you were very wealthy, 64,000 rumored but never seen) of memory 
>(14XX's), then 10,000 decimal words (707X's).
>
>We went to extraordinary lengths to reduce the number of characters 
>written to (256BPI, 7-track) tapes (some of the bizarre stuff takes 
>a while to explain so I'll spare you).
>
>Then we went to disks and drums where the space issue also involved 
>the dreaded read-before-writes, and minimization of head movement 
>and latency (hard to do in COBOL).
>
>Now we have memory-by-the-acre, disc-by-the-cubic-mile, and disk 
>speeds, high-speed cache, and solid-state-discs of huge size that 
>have eliminated all those concerns (and we use programming language 
>that makes them hard to see and impossible to do anything about).
>
>What is there left to worry about?
>
>Besides batteries that spontaneously combust in one of our several 
>computes in our pockets.
>
>--
>Requiescas in pace o email              Two identifying characteristics
>                                              of System Administrators:
>Ex turpi causa non oritur actio        Infallibility, and the ability to
>                                              learn from their mistakes.
>Eppure si rinfresca
>
>ICBM Targeting Information:
>	http://tinyurl.com/4sqczs
>	http://tinyurl.com/7tp8ml
>



From lpress at csudh.edu  Mon Nov  9 13:01:33 2009
From: lpress at csudh.edu (Larry Press)
Date: Mon, 9 Nov 2009 13:01:33 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <a0624081fc71deb6fb973@[10.0.1.45]>
References: <20091109112732.CE9D728E137@aland.bbn.com>	<6744CEEF-6858-488F-8993-4378F93913B7@google.com>	<a06240819c71dc76b4879@[10.0.1.45]>
	<4AF834F2.3050500@cox.net> <a0624081fc71deb6fb973@[10.0.1.45]>
Message-ID: <4AF8832D.2080309@csudh.edu>

> always contend that CS is the only field in which Ontogeny really 
> does Recapitulate Phylogeny!  ;-)  With mainframes, minis and micros 
> we went through all the same things yet again.  In networking, it was 
> terminal/host, client/server, network computer and now cloud 
> computing.


Hardware too -- the 360 model 91 had a pretty modern CPU if you ignore 
the fact that it would not quite fit inside a cell phone.

Lar


From lpress at csudh.edu  Mon Nov  9 13:07:20 2009
From: lpress at csudh.edu (Larry Press)
Date: Mon, 9 Nov 2009 13:07:20 -0800
Subject: [ih] internet-history Digest, Vol 37, Issue 6
In-Reply-To: <6744CEEF-6858-488F-8993-4378F93913B7@google.com>
References: <20091109112732.CE9D728E137@aland.bbn.com>
	<6744CEEF-6858-488F-8993-4378F93913B7@google.com>
Message-ID: <4AF88488.80901@csudh.edu>



Vint Cerf wrote:
> this comports with my recollection. Danny Cohen, David Reed and Jon  
> Postel lobbied strongly for a non-sequential, fast delivery mechanism  

Was this motivated by voice applications?

Larry


From vint at google.com  Mon Nov  9 13:11:40 2009
From: vint at google.com (Vint Cerf)
Date: Mon, 9 Nov 2009 16:11:40 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
Message-ID: <a488301ca6181$3b0c7cb0$b1257610$@com>

In part, for sure.

----- Original Message -----
From: Larry Press <lpress at csudh.edu>
To: Vint Cerf <vint at google.com>
Cc: Craig Partridge <craig at aland.bbn.com>; internet-history at postel.org
<internet-history at postel.org>
Sent: Mon Nov 09 16:07:20 2009
Subject: Re: [ih] internet-history Digest, Vol 37, Issue 6



Vint Cerf wrote:
> this comports with my recollection. Danny Cohen, David Reed and Jon
> Postel lobbied strongly for a non-sequential, fast delivery mechanism

Was this motivated by voice applications?

Larry


From craig at aland.bbn.com  Mon Nov  9 21:00:25 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Tue, 10 Nov 2009 00:00:25 -0500
Subject: [ih] internet-history Digest, Vol 37, Issue 6
Message-ID: <20091110050025.9FD7A28E137@aland.bbn.com>

> Vint Cerf wrote:
> > this comports with my recollection. Danny Cohen, David Reed and Jon  
> > Postel lobbied strongly for a non-sequential, fast delivery mechanism  
> 
> Was this motivated by voice applications?

>From what little I've been told, Danny was working with voice and Dave Reed
was working on computer-to-computer stuff for which datagrams made sense
(perhaps a precursor to RPC, but I really don't know).  PUP at XEROX PARC
used datagrams and folks realized it might be a useful transport abstraction.
There's also a comment about supporting anticipated infrastructure like DNS
queries, though, that seems a bit improbable as DNS didn't exist and
wasn't envisioned.

Thanks!

Craig


From jnc at mercury.lcs.mit.edu  Tue Nov 10 06:42:28 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 10 Nov 2009 09:42:28 -0500 (EST)
Subject: [ih] Genesis of User Datagram Protocol (was: internet-history
	Digest, Vol 37, Issue 6)
Message-ID: <20091110144228.5ACB06BE610@mercury.lcs.mit.edu>

    > From: Craig Partridge <craig at aland.bbn.com>

    > Danny was working with voice and Dave Reed was working on
    > qcomputer-to-computer stuff for which datagrams made sense

Just so.

    > (perhaps a precursor to RPC, but I really don't know).

I don't recall exactly what Dave Reed was working on, but RPC-like things (as
well as more specialized distributed computation things) were definitely in
the air at the time (Dave had just done, or was doing, two-phase commit, as I
recall).

    > There's also a comment about supporting anticipated infrastructure like
    > DNS queries, though, that seems a bit improbable as DNS didn't exist
    > and wasn't envisioned.

No, but there _was_ at a very early stage a 'hostname resolution' protocol,
which was one of the first applications for UDP. It was for hosts (perhaps
without stable storage) which didn't have (or want to have) a host table, and
just wanted to be able to look up IP addresses. Some stuff at MIT actually
used it; IIRC, the server we used was on MIT-Multics.

The first version (IEN-61) even predated UDP, and ran on top of IP. A later
version (IEN-89) used UDP.

	Noel


From brian at platohistory.org  Tue Nov 10 14:49:54 2009
From: brian at platohistory.org (Brian Dear)
Date: Tue, 10 Nov 2009 14:49:54 -0800
Subject: [ih] Users vs Hosts on ARPANET
Message-ID: <7A878698-871A-4806-A838-702698E574F5@platohistory.org>

Most of the histories of the first 10 years of ARPANET show graphs  
depicting how the number of host machine connections grew year by  
year.   That's swell, but what I've always wondered was, how many  
PEOPLE used the ARPANET during those years?   That is, how many people  
were connected to those host machines and at what year-by-year rate  
did the "ARPANET population" grow?

Anyone have any references to such data?

- Brian


Brian Dear
PLATO History Project
La Jolla, California
brian at platohistory.org



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

From vint at google.com  Tue Nov 10 16:46:05 2009
From: vint at google.com (Vint Cerf)
Date: Tue, 10 Nov 2009 19:46:05 -0500
Subject: [ih] Users vs Hosts on ARPANET
In-Reply-To: <7A878698-871A-4806-A838-702698E574F5@platohistory.org>
References: <7A878698-871A-4806-A838-702698E574F5@platohistory.org>
Message-ID: <A020CFB3-AAC1-4472-A5FD-DA8B803E2B62@google.com>

the number reached 50,000 very quickly as I recall.

v

On Nov 10, 2009, at 5:49 PM, Brian Dear wrote:

> Most of the histories of the first 10 years of ARPANET show graphs  
> depicting how the number of host machine connections grew year by  
> year.   That's swell, but what I've always wondered was, how many  
> PEOPLE used the ARPANET during those years?   That is, how many  
> people were connected to those host machines and at what year-by- 
> year rate did the "ARPANET population" grow?
>
> Anyone have any references to such data?
>
> - Brian
>
>
> Brian Dear
> PLATO History Project
> La Jolla, California
> brian at platohistory.org
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091110/040cc609/attachment.htm>

From jnc at mercury.lcs.mit.edu  Tue Nov 10 17:05:56 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 10 Nov 2009 20:05:56 -0500 (EST)
Subject: [ih] Users vs Hosts on ARPANET
Message-ID: <20091111010557.007976BE607@mercury.lcs.mit.edu>

    > From: Brian Dear <brian at platohistory.org>

    > Anyone have any references to such data?

I don't know of any such data offhand, but that doesn't mean there wasn't any.


One thing I do know of are the so-called "ARPANET Directory" books, which
list many (but not _all_) people using the ARPANet. New versions came out
periodically (every year or two, perhaps?), and one can get some idea of
growth from them.

E.g. I have two (NIC 49000, March 1982; and NIC 50000, June 1984). These are
of course later than the time period you are concerned with, but they are
perhaps of some interest anyway. In the former, there are 389 pages (pp.
31-389) of names, at roughly 17 names per page (averaging over about 8 pages
or so), or about 6,600 names; the latter has 578 pages of names (pp 17-594),
at about 25 per page, for about 14,500.

For the machines/institutions I was familiar with (the ones at Tech Square at
MIT), these volumes appear to list most everyone; a few are missing, but it's
just a few. For the research group which I was in, almost everyone whom I can
think of is listed - faculty, staff, and grad students and those undergrads
who were part of the research group.

Interestingly enough, those numbers sort of roughly fits with the
approximately 'doubling in size every year or so' that we later observed in
the early Internet. If we assume an exponential growth model, with the
numbers above, it tracks back to a fairly small group of people in roughly to
1970 or so, which would be correct.

	Noel


From jeanjour at comcast.net  Tue Nov 10 17:52:35 2009
From: jeanjour at comcast.net (John Day)
Date: Tue, 10 Nov 2009 20:52:35 -0500
Subject: [ih] Users vs Hosts on ARPANET
In-Reply-To: <A020CFB3-AAC1-4472-A5FD-DA8B803E2B62@google.com>
References: <7A878698-871A-4806-A838-702698E574F5@platohistory.org>
	<A020CFB3-AAC1-4472-A5FD-DA8B803E2B62@google.com>
Message-ID: <a06240835c71fc404d1a6@[168.122.15.96]>

At the places like BBN or SRI, it might be very easy to tell because 
it was the employees, but I know at Illinois someone might have known 
who all was using it, but it would have been difficult.  We had 
people from several parts of physics, people from Argonne (Fermilab 
didn't exist yet), land-use planners around Chicago, energy guys 
doing the energy I/O matrix for the US economy, math, CS (some), 
chemists, economists, musicians, dancers, and I am undoubtedly 
leaving some out.

But Noel is right.  A good indicator would be an early ARPANET 
directory but I know those didn't come close to including all of the 
users.  At Illinois, it included primarily the people in our facility 
alone, which was a fraction of all of the users of our node.

Frankly, no one really paid all that much attention to it.


At 19:46 -0500 2009/11/10, Vint Cerf wrote:
>the number reached 50,000 very quickly as I recall.
>
>v
>
>On Nov 10, 2009, at 5:49 PM, Brian Dear wrote:
>
>>Most of the histories of the first 10 years of ARPANET show graphs 
>>depicting how the number of host machine connections grew year by 
>>year.   That's swell, but what I've always wondered was, how many 
>>PEOPLE used the ARPANET during those years?   That is, how many 
>>people were connected to those host machines and at what 
>>year-by-year rate did the "ARPANET population" grow?
>>
>>Anyone have any references to such data?
>>
>>- Brian
>>
>>
>>Brian Dear
>>PLATO History Project
>>La Jolla, California
>><mailto:brian at platohistory.org>brian at platohistory.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091110/42172b36/attachment.htm>

From craig at aland.bbn.com  Wed Nov 11 08:26:50 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Wed, 11 Nov 2009 11:26:50 -0500
Subject: [ih] Users vs Hosts on ARPANET
Message-ID: <20091111162650.0BBD928E137@aland.bbn.com>

> One thing I do know of are the so-called "ARPANET Directory" books, which
> list many (but not _all_) people using the ARPANet. New versions came out
> periodically (every year or two, perhaps?), and one can get some idea of
> growth from them.

I thought the standard for getting into the ARPANET Directory was that you
had a NIC handle and were in the NIC database.  Jake F. probably remembers
far better than I do, but as I recall, this meant you fell into one of
the following categories: (a) the official contact for an IP address; (b)
the official contact for a host; (c) had a TAC account; or (d) were a contact
for some IANA number (protocol, port, EGP AS)...

Even for BBN, I doubt more than 25% of us met that requirement but we were
all on the 'Net.

Thanks!

Craig


From jeanjour at comcast.net  Wed Nov 11 09:52:28 2009
From: jeanjour at comcast.net (John Day)
Date: Wed, 11 Nov 2009 12:52:28 -0500
Subject: [ih] Users vs Hosts on ARPANET
In-Reply-To: <20091111162650.0BBD928E137@aland.bbn.com>
References: <20091111162650.0BBD928E137@aland.bbn.com>
Message-ID: <a06240844c720aa461dd0@[168.122.15.96]>

That was the criteria much much later.  Early on it was much broader.

At 11:26 -0500 2009/11/11, Craig Partridge wrote:
>  > One thing I do know of are the so-called "ARPANET Directory" books, which
>>  list many (but not _all_) people using the ARPANet. New versions came out
>>  periodically (every year or two, perhaps?), and one can get some idea of
>>  growth from them.
>
>I thought the standard for getting into the ARPANET Directory was that you
>had a NIC handle and were in the NIC database.  Jake F. probably remembers
>far better than I do, but as I recall, this meant you fell into one of
>the following categories: (a) the official contact for an IP address; (b)
>the official contact for a host; (c) had a TAC account; or (d) were a contact
>for some IANA number (protocol, port, EGP AS)...
>
>Even for BBN, I doubt more than 25% of us met that requirement but we were
>all on the 'Net.
>
>Thanks!
>
>Craig



From jack at 3kitty.org  Wed Nov 11 11:29:23 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Wed, 11 Nov 2009 11:29:23 -0800
Subject: [ih] Users vs Hosts on ARPANET
In-Reply-To: <20091111162650.0BBD928E137@aland.bbn.com>
References: <20091111162650.0BBD928E137@aland.bbn.com>
Message-ID: <1257967763.3357.14.camel@localhost>

IIRC, in the beginning (early 70s), in order to be on the ARPAnet, you
had to be working on a research contract with ARPA.  You could connect
your computer to the ARPAnet to support the research, but management had
to guarantee that government resources were only being used to support
the government work.

"Research" was not limited to network R&D.  Since the goal was to use
ARPAnet as a means to share expensive resources (big computers, e.g.,
Illiac), people with permission to use those computers (scientists et
al) also had permission to use the ARPAnet to get to them, and to
interact with other researchers (Email, FTP).  The permission extended
to jobs that were ancillary to the research too - e.g., to deal with
accounting, administrative issues, etc.

I suspect the growth in number of users is pretty closely correlated to
the growth in email accounts, since that was the "killer app" du jour.
Maybe someone has some data on email...

/Jack Haverty
Point Arena, CA

On Wed, 2009-11-11 at 11:26 -0500, Craig Partridge wrote:
> > One thing I do know of are the so-called "ARPANET Directory" books, which
> > list many (but not _all_) people using the ARPANet. New versions came out
> > periodically (every year or two, perhaps?), and one can get some idea of
> > growth from them.
> 
> I thought the standard for getting into the ARPANET Directory was that you
> had a NIC handle and were in the NIC database.  Jake F. probably remembers
> far better than I do, but as I recall, this meant you fell into one of
> the following categories: (a) the official contact for an IP address; (b)
> the official contact for a host; (c) had a TAC account; or (d) were a contact
> for some IANA number (protocol, port, EGP AS)...
> 
> Even for BBN, I doubt more than 25% of us met that requirement but we were
> all on the 'Net.
> 
> Thanks!
> 
> Craig
> 



From jnc at mercury.lcs.mit.edu  Wed Nov 11 12:48:48 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 11 Nov 2009 15:48:48 -0500 (EST)
Subject: [ih] Users vs Hosts on ARPANET
Message-ID: <20091111204848.487026BE667@mercury.lcs.mit.edu>

    > From: Craig Partridge <craig at aland.bbn.com>

    > I thought the standard for getting into the ARPANET Directory was
    > that you had a NIC handle and were in the NIC database.

The '82 Directory lists NIC Idents, the '84 one doesn't (refers to people by
full names and email addresses). Dunno if that means NIC Idents been fully
discarded by the later one, or what.

    > this meant you fell into one of the following categories: (a) the
    > official contact for an IP address; (b) the official contact for a
    > host; (c) had a TAC account; or (d) were a contact for some IANA
    > number (protocol, port, EGP AS)...

I don't think so. The '82 book says:

  'All individuals with accounts on ARPANET machines, who are capable
  of passing traffic across the ARPANET, are requested by DCA to be
  registered in the NIC Identification data base.'

(p. 7) and the '92 book says something almost identical (since by then
here were MILNET and MINET as well; p. 7):

  'All individuals with accounts on DDN hosts, who are capable
  of passing traffic across the network, are requested by DCA to be
  registered in the NIC user registration data base.'

So clearly these directories are _intended_ to be mostly complete. And,
like I said, when I checked, most of the people I recall from this period
in my research group at MIT were listed, including undergrads who were
working with us.

No doubt some sites were lax about registering people, and there were also
lots of 'randoms' (as they were called) using TIP dial-up lines to get on
(most of whom showed up at the MIT ITS machines :-). So they are not
absolutely accurate, and the number of people listed therein is certainly
only a floor, but I suspect they still are _relatively_ complete.

(You, for instance, are not in the '82 one, but are in the '84 one. :-) 

	Noel


From craig at aland.bbn.com  Wed Nov 11 22:46:57 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Thu, 12 Nov 2009 01:46:57 -0500
Subject: [ih] IPv4 address size debate
Message-ID: <20091112064657.7865628E137@aland.bbn.com>

> Once one understands the bigger picture, one realizes that question 
> of variable vs fixed is a non-sequitor. But one does have to get free 
> of the constraints of a Ptolemaic approach to architecture.

Hi John:

I'm afraid I disagree (at the risk of being lumped in the distinguished
company of Ptolemy).

I agree that in much of the networking and distributed systems world, variable
vs. fixed is not a big deal and has all the utility of the binary vs. ASCII
representations debate (i.e. not much).

But, in routers and encrypters and similar boxes that handle large volumes
of data, fixed vs. variable is still a challenge.  The fundamental issue is
that while links work in terms of bits and bytes, processors and memories
actually work in terms of blocks/chunks.  That's because they use parallelism
they use to go fast (and one reason they use parallelism is physics -- prop
times across chip boundaries, etc).

So when writing code for routers that has to go fast, you are constantly
thinking about those blocks and trying to avoid crossing block boundaries
(both in instructions and data accesses) and trying to keep your software
using the minimum number of blocks, as touching an additional block is
a serious performance hit.   Knowing exactly how your data is laid out
is a huge boon here -- it removes the uncertainty of how many blocks you'll
have to touch (and how many instructions you have to execute).

And sizing for the max (assuming the variable address is always max length)
doesn't help either -- because there are two addresses in a header, if the
first one is short then all your plans for the second address are undone.

Upleveling my point -- we have a computing abstraction (bytes) which doesn't
match how computers, when stressed for performance, actually work and that
has implications for packet headers.

Thanks!

Craig


From jeanjour at comcast.net  Thu Nov 12 04:04:27 2009
From: jeanjour at comcast.net (John Day)
Date: Thu, 12 Nov 2009 07:04:27 -0500
Subject: [ih] IPv4 address size debate
In-Reply-To: <20091112064657.7865628E137@aland.bbn.com>
References: <20091112064657.7865628E137@aland.bbn.com>
Message-ID: <a0624084dc721a7890546@[168.122.15.96]>

You missed the point of my comment.  I am well aware of the coding 
issues.  Although, Oran and others have always argued that variable 
was not a big deal in hardware.

The point was that if you think in terms of a relative architecture, 
rather than the traditional fixed flat architecture, fixed is 
variable, or was that variable is fixed?  ;-)

I was implying that fixed was really all that was necessary, if you 
really understood the inherent structure.  But then you knew that, 
didn't you?

Take care,
John

At 1:46 -0500 2009/11/12, Craig Partridge wrote:
>  > Once one understands the bigger picture, one realizes that question
>>  of variable vs fixed is a non-sequitor. But one does have to get free
>>  of the constraints of a Ptolemaic approach to architecture.
>
>Hi John:
>
>I'm afraid I disagree (at the risk of being lumped in the distinguished
>company of Ptolemy).
>
>I agree that in much of the networking and distributed systems world, variable
>vs. fixed is not a big deal and has all the utility of the binary vs. ASCII
>representations debate (i.e. not much).
>
>But, in routers and encrypters and similar boxes that handle large volumes
>of data, fixed vs. variable is still a challenge.  The fundamental issue is
>that while links work in terms of bits and bytes, processors and memories
>actually work in terms of blocks/chunks.  That's because they use parallelism
>they use to go fast (and one reason they use parallelism is physics -- prop
>times across chip boundaries, etc).
>
>So when writing code for routers that has to go fast, you are constantly
>thinking about those blocks and trying to avoid crossing block boundaries
>(both in instructions and data accesses) and trying to keep your software
>using the minimum number of blocks, as touching an additional block is
>a serious performance hit.   Knowing exactly how your data is laid out
>is a huge boon here -- it removes the uncertainty of how many blocks you'll
>have to touch (and how many instructions you have to execute).
>
>And sizing for the max (assuming the variable address is always max length)
>doesn't help either -- because there are two addresses in a header, if the
>first one is short then all your plans for the second address are undone.
>
>Upleveling my point -- we have a computing abstraction (bytes) which doesn't
>match how computers, when stressed for performance, actually work and that
>has implications for packet headers.
>
>Thanks!
>
>Craig



From richard at bennett.com  Thu Nov 12 11:04:42 2009
From: richard at bennett.com (Richard Bennett)
Date: Thu, 12 Nov 2009 11:04:42 -0800
Subject: [ih] IPv4 address size debate
In-Reply-To: <a0624084dc721a7890546@[168.122.15.96]>
References: <20091112064657.7865628E137@aland.bbn.com>
	<a0624084dc721a7890546@[168.122.15.96]>
Message-ID: <4AFC5C4A.8020509@bennett.com>

I remember when handling packets at wirespeed was a challenge, but that 
was solved by hardware. The 48-bit EtherMac address was a much bigger 
issue than IP addresses, and the size of the Ethernet header (112 bits) 
guaranteed that the IP header wasn't going to be 32-bit aligned anyhow.

John Day wrote:
> You missed the point of my comment.  I am well aware of the coding 
> issues.  Although, Oran and others have always argued that variable 
> was not a big deal in hardware.
>
> The point was that if you think in terms of a relative architecture, 
> rather than the traditional fixed flat architecture, fixed is 
> variable, or was that variable is fixed?  ;-)
>
> I was implying that fixed was really all that was necessary, if you 
> really understood the inherent structure.  But then you knew that, 
> didn't you?
>
> Take care,
> John
>
> At 1:46 -0500 2009/11/12, Craig Partridge wrote:
>>  > Once one understands the bigger picture, one realizes that question
>>>  of variable vs fixed is a non-sequitor. But one does have to get free
>>>  of the constraints of a Ptolemaic approach to architecture.
>>
>> Hi John:
>>
>> I'm afraid I disagree (at the risk of being lumped in the distinguished
>> company of Ptolemy).
>>
>> I agree that in much of the networking and distributed systems world, 
>> variable
>> vs. fixed is not a big deal and has all the utility of the binary vs. 
>> ASCII
>> representations debate (i.e. not much).
>>
>> But, in routers and encrypters and similar boxes that handle large 
>> volumes
>> of data, fixed vs. variable is still a challenge.  The fundamental 
>> issue is
>> that while links work in terms of bits and bytes, processors and 
>> memories
>> actually work in terms of blocks/chunks.  That's because they use 
>> parallelism
>> they use to go fast (and one reason they use parallelism is physics 
>> -- prop
>> times across chip boundaries, etc).
>>
>> So when writing code for routers that has to go fast, you are constantly
>> thinking about those blocks and trying to avoid crossing block 
>> boundaries
>> (both in instructions and data accesses) and trying to keep your 
>> software
>> using the minimum number of blocks, as touching an additional block is
>> a serious performance hit.   Knowing exactly how your data is laid out
>> is a huge boon here -- it removes the uncertainty of how many blocks 
>> you'll
>> have to touch (and how many instructions you have to execute).
>>
>> And sizing for the max (assuming the variable address is always max 
>> length)
>> doesn't help either -- because there are two addresses in a header, 
>> if the
>> first one is short then all your plans for the second address are 
>> undone.
>>
>> Upleveling my point -- we have a computing abstraction (bytes) which 
>> doesn't
>> match how computers, when stressed for performance, actually work and 
>> that
>> has implications for packet headers.
>>
>> Thanks!
>>
>> Craig
>

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC



From vint at google.com  Fri Nov 13 03:13:49 2009
From: vint at google.com (Vint Cerf)
Date: Fri, 13 Nov 2009 06:13:49 -0500
Subject: [ih] IPv4 address size debate
In-Reply-To: <4AFC5C4A.8020509@bennett.com>
References: <20091112064657.7865628E137@aland.bbn.com>
	<a0624084dc721a7890546@[168.122.15.96]>
	<4AFC5C4A.8020509@bennett.com>
Message-ID: <4896FFDF-6BF4-4983-B2AF-E055062DCE0E@google.com>

that's a red herring. by the time IP and TCP dealt with the headers,  
the ethernet portion was stripped away.
v

On Nov 12, 2009, at 2:04 PM, Richard Bennett wrote:

> I remember when handling packets at wirespeed was a challenge, but  
> that was solved by hardware. The 48-bit EtherMac address was a much  
> bigger issue than IP addresses, and the size of the Ethernet header  
> (112 bits) guaranteed that the IP header wasn't going to be 32-bit  
> aligned anyhow.
>
> John Day wrote:
>> You missed the point of my comment.  I am well aware of the coding  
>> issues.  Although, Oran and others have always argued that variable  
>> was not a big deal in hardware.
>>
>> The point was that if you think in terms of a relative  
>> architecture, rather than the traditional fixed flat architecture,  
>> fixed is variable, or was that variable is fixed?  ;-)
>>
>> I was implying that fixed was really all that was necessary, if you  
>> really understood the inherent structure.  But then you knew that,  
>> didn't you?
>>
>> Take care,
>> John
>>
>> At 1:46 -0500 2009/11/12, Craig Partridge wrote:
>>> > Once one understands the bigger picture, one realizes that  
>>> question
>>>> of variable vs fixed is a non-sequitor. But one does have to get  
>>>> free
>>>> of the constraints of a Ptolemaic approach to architecture.
>>>
>>> Hi John:
>>>
>>> I'm afraid I disagree (at the risk of being lumped in the  
>>> distinguished
>>> company of Ptolemy).
>>>
>>> I agree that in much of the networking and distributed systems  
>>> world, variable
>>> vs. fixed is not a big deal and has all the utility of the binary  
>>> vs. ASCII
>>> representations debate (i.e. not much).
>>>
>>> But, in routers and encrypters and similar boxes that handle large  
>>> volumes
>>> of data, fixed vs. variable is still a challenge.  The fundamental  
>>> issue is
>>> that while links work in terms of bits and bytes, processors and  
>>> memories
>>> actually work in terms of blocks/chunks.  That's because they use  
>>> parallelism
>>> they use to go fast (and one reason they use parallelism is  
>>> physics -- prop
>>> times across chip boundaries, etc).
>>>
>>> So when writing code for routers that has to go fast, you are  
>>> constantly
>>> thinking about those blocks and trying to avoid crossing block  
>>> boundaries
>>> (both in instructions and data accesses) and trying to keep your  
>>> software
>>> using the minimum number of blocks, as touching an additional  
>>> block is
>>> a serious performance hit.   Knowing exactly how your data is laid  
>>> out
>>> is a huge boon here -- it removes the uncertainty of how many  
>>> blocks you'll
>>> have to touch (and how many instructions you have to execute).
>>>
>>> And sizing for the max (assuming the variable address is always  
>>> max length)
>>> doesn't help either -- because there are two addresses in a  
>>> header, if the
>>> first one is short then all your plans for the second address are  
>>> undone.
>>>
>>> Upleveling my point -- we have a computing abstraction (bytes)  
>>> which doesn't
>>> match how computers, when stressed for performance, actually work  
>>> and that
>>> has implications for packet headers.
>>>
>>> Thanks!
>>>
>>> Craig
>>
>
> -- 
> Richard Bennett
> Research Fellow
> Information Technology and Innovation Foundation
> Washington, DC
>



From jack at 3kitty.org  Fri Nov 13 09:56:29 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 13 Nov 2009 17:56:29 +0000
Subject: [ih] IPv4 address size debate
In-Reply-To: <4896FFDF-6BF4-4983-B2AF-E055062DCE0E@google.com>
References: <20091112064657.7865628E137@aland.bbn.com>
	<a0624084dc721a7890546@[168.122.15.96]> <4AFC5C4A.8020509@bennett.com>
	<4896FFDF-6BF4-4983-B2AF-E055062DCE0E@google.com>
Message-ID: <1258134989.3379.76.camel@localhost>

Since I was one of the people arguing for fixed-length addresses back in
those days, I guess maybe it's time to explain why...

It all started with the network hardware, i.e., the I/O box that sat
between your computer and the network wire (Ethernet, IMP, whatever).
Your computer, whatever it was, was very slow and very expensive.  Also,
as I recall, none of the early TCP/IP implementors were what you would
call "network people".  We were all operating-system people, and the
network was yet another I/O device to be attached to the computer.

That last observation is important because it dictated design
philosophy, both of code and protocol.  The goal was to get the network
attached as an I/O device while absolutely minimizing the load on the
computer.  Running network code (interrupt handlers, drivers, TCP, etc.)
was overhead, not viewed as useful work.  In some computers that charged
their users for cycles-used, it was "waste" that generated no revenue.
In other contexts it consumed cycles that would otherwise be used for
real work - like playing Zork.   Network I/O had to be tolerated, but
kept to a bare minimum.

In that context, TCP/IP was designed and implemented.  

Starting right at the hardware interface box, the low-level device
driver code in the O/S could typically instruct the hardware to read (or
write) bytes between the wire and memory.  Of course you had to tell the
hardware where to put/get the data, i.e., the memory address.

So, when reading from the net, the resultant data in memory would
contain the physical net header, then the IP header, then the TCP
header, then the "user data".

There was a great desire to avoid moving large amounts of data.
Machines were slooowwww - on the order of 1MHz instruction rate.  With
maybe 20 users on the machine, each had a 50KHz computer -- quite a bit
slower than the 3 GHz machine I'm typing on right now.   Memory was slow
too, and there wasn't much of it.  Every time you had to move parts of a
packet, it was a big load on the processor.  It was very very desirable
to have the hardware put the data into the "right place" for subsequent
processing. 

Depending on the computer architecture, sometimes memory could be
"moved" by simply mapping it into a different address.  But there were
lots of constraints imposed by the hardware, e.g., "block boundaries".

The "holy grail" was to be able to read a packet from the net and have
the "user data" transferred directly into memory that could be simply
handed over to the user program.  If you could do that, no in-memory
copying of large data buffers would be needed, and the O/S overhead was
kept small.

Any variable-length fields in the headers made it very difficult to aim
the incoming data at the right place in memory.   Of course, you could
avoid in-memory copying by reading data in pieces - i.e., read the next
piece of header, look at it, decide how much to read next, etc.  That
however meant multiple interrupts per packet, which was about as bad or
worse than copying in-memory.

With fixed-size Ethernet (or IMP) headers, you could point incoming data
at memory in such a way that the Ethernet header fell into one memory
block, and the rest of the data fell in the adjacent memory block.  That
is of course only if your particular computer and network interface
allowed it.  Then it was easy to simply give only that second block to
the next level.  This was how Ethernet headers were typically "stripped
off".

With variable length IP headers (options) you couldn't play this trick
at the next level.  So "user data" (e.g., Telnet or FTP data) had to be
copied in-memory to pass it up the line.   More complex/sophisticated
TCP/IP implementations might play the odds, and target the incoming data
into the right place hoping that the IP header turned out to be
fixed-size (no options).  If all worked well, the "user data" would end
up on a block boundary, easily passed to the user code.  In the
hopefully rare cases that it wasn't fixed-size, the data would have to
be moved.  IP packets with no options would be fast, those with options
would suffer.

Variable-length addresses would have changed the odds significantly, so
that such a trick would probably rarely work, and packet data would
always have to be moved.  Hence the pressure for fixed-length header
fields, at least for the always-present fields - like the addresses.

The pressure to avoid copying was so strong that it motivated some
unique ideas.  There was at least one implementation of Ethernet (MIT?
IIRC) that put the Ethernet header at the *back end* of the packet on
the wire - i.e., it became a trailer rather than a header.  This
violated the Ethernet spec, but it worked fine as long as both players
understood what was going on.  It allowed incoming user data to be
placed directly in physical memory that could be transferred (not
copied) to the upper protocol software.  I remember at BBN discovering
this trick one day when one of these implementations started sending
such packets to one of our gateways, which of course got continuous
checksum failures trying to interpret the user data as packet headers.

Inside a gateway/router environment, we were always looking for ways to
make things faster and avoid copying and buffering.  I remember toying
in the 80s with the idea of short-circuiting IP packet processing, so
that a packet could be sent out to its next destination *while* it was
still being read in from the previous hop.  The router would read enough
of the header to decide where to send the packet, and then "splice" the
two wires together (in hardware/firmware) to send the rest of the packet
on its way.  This would have required, among other things, redefining
the IP header so that the checksum was kept in a trailer - since you
couldn't finish computing the checksum until all of the data had come
in. 

This would have violated the IP spec, but between consenting routers
anything was possible (and facilitated by the EGP/IGP structure - IGPs
could do their own thing inside their worlds).  Essentially you would
end up with a circuit-switched network that had an IP datagram
interface, so it would have low-delay no matter how many hops were
involved.  In this architecture, IP is an interface spec at the edges
only, and what goes on inside is hidden and could be anything.  I wonder
if today's routers play such tricks....

Of course, now CPUs and memory are dirt cheap, and most of this kind of
data juggling happens anyway inside a chip on a $20 NIC, so it's not a
big deal.  Times have changed.

HTH,
/Jack Haverty
Point Arena, CA

On Fri, 2009-11-13 at 06:13 -0500, Vint Cerf wrote:
> that's a red herring. by the time IP and TCP dealt with the headers,  
> the ethernet portion was stripped away.
> v
> 
> On Nov 12, 2009, at 2:04 PM, Richard Bennett wrote:
> 
> > I remember when handling packets at wirespeed was a challenge, but  
> > that was solved by hardware. The 48-bit EtherMac address was a much  
> > bigger issue than IP addresses, and the size of the Ethernet header  
> > (112 bits) guaranteed that the IP header wasn't going to be 32-bit  
> > aligned anyhow.
> >
> > John Day wrote:
> >> You missed the point of my comment.  I am well aware of the coding  
> >> issues.  Although, Oran and others have always argued that variable  
> >> was not a big deal in hardware.
> >>
> >> The point was that if you think in terms of a relative  
> >> architecture, rather than the traditional fixed flat architecture,  
> >> fixed is variable, or was that variable is fixed?  ;-)
> >>
> >> I was implying that fixed was really all that was necessary, if you  
> >> really understood the inherent structure.  But then you knew that,  
> >> didn't you?
> >>
> >> Take care,
> >> John
> >>
> >> At 1:46 -0500 2009/11/12, Craig Partridge wrote:
> >>> > Once one understands the bigger picture, one realizes that  
> >>> question
> >>>> of variable vs fixed is a non-sequitor. But one does have to get  
> >>>> free
> >>>> of the constraints of a Ptolemaic approach to architecture.
> >>>
> >>> Hi John:
> >>>
> >>> I'm afraid I disagree (at the risk of being lumped in the  
> >>> distinguished
> >>> company of Ptolemy).
> >>>
> >>> I agree that in much of the networking and distributed systems  
> >>> world, variable
> >>> vs. fixed is not a big deal and has all the utility of the binary  
> >>> vs. ASCII
> >>> representations debate (i.e. not much).
> >>>
> >>> But, in routers and encrypters and similar boxes that handle large  
> >>> volumes
> >>> of data, fixed vs. variable is still a challenge.  The fundamental  
> >>> issue is
> >>> that while links work in terms of bits and bytes, processors and  
> >>> memories
> >>> actually work in terms of blocks/chunks.  That's because they use  
> >>> parallelism
> >>> they use to go fast (and one reason they use parallelism is  
> >>> physics -- prop
> >>> times across chip boundaries, etc).
> >>>
> >>> So when writing code for routers that has to go fast, you are  
> >>> constantly
> >>> thinking about those blocks and trying to avoid crossing block  
> >>> boundaries
> >>> (both in instructions and data accesses) and trying to keep your  
> >>> software
> >>> using the minimum number of blocks, as touching an additional  
> >>> block is
> >>> a serious performance hit.   Knowing exactly how your data is laid  
> >>> out
> >>> is a huge boon here -- it removes the uncertainty of how many  
> >>> blocks you'll
> >>> have to touch (and how many instructions you have to execute).
> >>>
> >>> And sizing for the max (assuming the variable address is always  
> >>> max length)
> >>> doesn't help either -- because there are two addresses in a  
> >>> header, if the
> >>> first one is short then all your plans for the second address are  
> >>> undone.
> >>>
> >>> Upleveling my point -- we have a computing abstraction (bytes)  
> >>> which doesn't
> >>> match how computers, when stressed for performance, actually work  
> >>> and that
> >>> has implications for packet headers.
> >>>
> >>> Thanks!
> >>>
> >>> Craig
> >>
> >
> > -- 
> > Richard Bennett
> > Research Fellow
> > Information Technology and Innovation Foundation
> > Washington, DC
> >
> 
> 



From jnc at mercury.lcs.mit.edu  Fri Nov 13 13:34:10 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 13 Nov 2009 16:34:10 -0500 (EST)
Subject: [ih] IPv4 address size debate
Message-ID: <20091113213410.E06336BE681@mercury.lcs.mit.edu>

    > From: Jack Haverty <jack at 3kitty.org>

    > Since I was one of the people arguing for fixed-length addresses back
    > in those days, I guess maybe it's time to explain why...

I don't disagree that fixed-length addresses were the right choice _at the
time_; I was actually interested in why we didn't pick something with a
little more long-term flexibility (i.e. flexible syntax, with 'temporarily'
subsetted semantics to produce _effectively_ fixed-length addresses), and if
that option was even considered.

Did people think 32 bits was 'more than enough for any conceivable
circumstances', or did they not think that TCP/IP would be anything other
than a large-scale trial that would be supplanted by something new, or what?

Had someone suggested a format with address-length fields, and the only
allowed/supported value in them being '4', do you think that would have been
accepted?


    > It was very very desirable to have the hardware put the data into the
    > "right place" for subsequent processing.

I take your point (I used techniques to do the same thing in the router code
I did, to avoid having to ever move data), but at the same time it undermines
the then-current reasoning that 'if we need to do anything else, we can do it
with a header option' - since (as you point out below) using options produces
variable-length headers, and those negate the advantages of a fixed-length
header.

    > IP packets with no options would be fast, those with options would
    > suffer.

Which is still the situation today... I was going to say 'sadly', but I'm not
sure that's warranted. But it is certainly a very high bar to the use of
options for extensions that are anything other than 'low-duty-cycle' (i.e. in
few packets), and that definitely limits the value of the option-based
extensibility mechanism.

    > There was at least one implementation of Ethernet (MIT? IIRC) that put
    > the Ethernet header at the *back end* of the packet on the wire - i.e.,
    > it became a trailer rather than a header. 

Ah, no. That was Berzerkley. (See RFC 893.) (Gratuitous comment suppressed... ;-)

    > This would have required, among other things, redefining the IP header
    > so that the checksum was kept in a trailer - since you couldn't finish
    > computing the checksum until all of the data had come in.

??? The IP checksum covers only the IP header, no?


    > Essentially you would end up with a circuit-switched network that had
    > an IP datagram interface ... In this architecture, IP is an interface
    > spec at the edges only, and what goes on inside is hidden and could be
    > anything. I wonder if today's routers play such tricks....

That's exactly how today's networks actually operate. Things like Frame Relay
and MPLS avoid processing IP headers on many hops - although on a local basis
only (i.e. not system-wide).

I do forsee IP becoming an interface-spec at the edges, with something new
being used _inside_ the network, i.e. router-router (much like an RJ11 analog
jack is an old interface to a wholly different/modern internals), but then
again this is hardly a new idea - the Nimrod deployment plan used the same
concept! So my crystal ball may be a bit out of focus, timewise... :-)

At the moment IP is in fact still used for the generic router-router
interface, but I do think the day is drawing closer when something else will
(slowly, admittedly) replace it in that role.

	Noel


From tony.li at tony.li  Fri Nov 13 14:46:08 2009
From: tony.li at tony.li (Tony Li)
Date: Fri, 13 Nov 2009 14:46:08 -0800
Subject: [ih] IPv4 address size debate
In-Reply-To: <1258134989.3379.76.camel@localhost>
References: <20091112064657.7865628E137@aland.bbn.com>	<a0624084dc721a7890546@[168.122.15.96]>
	<4AFC5C4A.8020509@bennett.com>	<4896FFDF-6BF4-4983-B2AF-E055062DCE0E@google.com>
	<1258134989.3379.76.camel@localhost>
Message-ID: <4AFDE1B0.7080301@tony.li>

Jack Haverty wrote:
> Variable-length addresses would have changed the odds significantly, so
> that such a trick would probably rarely work, and packet data would
> always have to be moved.  Hence the pressure for fixed-length header
> fields, at least for the always-present fields - like the addresses.

Was there ever any debate of making addresses variable length, but only 
using one of those lengths in practice?

Tony


From vint at google.com  Fri Nov 13 14:54:31 2009
From: vint at google.com (Vint Cerf)
Date: Fri, 13 Nov 2009 17:54:31 -0500
Subject: [ih] IPv4 address size debate
In-Reply-To: <20091113213410.E06336BE681@mercury.lcs.mit.edu>
References: <20091113213410.E06336BE681@mercury.lcs.mit.edu>
Message-ID: <9ECEE51E-796A-4859-A2A7-2B7D6C0DB5ED@google.com>

since I made the decision to go with 32 bits, i can say that at the  
time I thought this was still very much an experiment and that if it  
proved successful, we would design a production version. We sort of  
neglected that step.

vint


On Nov 13, 2009, at 4:34 PM, Noel Chiappa wrote:

>> From: Jack Haverty <jack at 3kitty.org>
>
>> Since I was one of the people arguing for fixed-length addresses back
>> in those days, I guess maybe it's time to explain why...
>
> I don't disagree that fixed-length addresses were the right choice  
> _at the
> time_; I was actually interested in why we didn't pick something  
> with a
> little more long-term flexibility (i.e. flexible syntax, with  
> 'temporarily'
> subsetted semantics to produce _effectively_ fixed-length  
> addresses), and if
> that option was even considered.
>
> Did people think 32 bits was 'more than enough for any conceivable
> circumstances', or did they not think that TCP/IP would be anything  
> other
> than a large-scale trial that would be supplanted by something new,  
> or what?
>
> Had someone suggested a format with address-length fields, and the  
> only
> allowed/supported value in them being '4', do you think that would  
> have been
> accepted?
>
>
>> It was very very desirable to have the hardware put the data into the
>> "right place" for subsequent processing.
>
> I take your point (I used techniques to do the same thing in the  
> router code
> I did, to avoid having to ever move data), but at the same time it  
> undermines
> the then-current reasoning that 'if we need to do anything else, we  
> can do it
> with a header option' - since (as you point out below) using options  
> produces
> variable-length headers, and those negate the advantages of a fixed- 
> length
> header.
>
>> IP packets with no options would be fast, those with options would
>> suffer.
>
> Which is still the situation today... I was going to say 'sadly',  
> but I'm not
> sure that's warranted. But it is certainly a very high bar to the  
> use of
> options for extensions that are anything other than 'low-duty- 
> cycle' (i.e. in
> few packets), and that definitely limits the value of the option-based
> extensibility mechanism.
>
>> There was at least one implementation of Ethernet (MIT? IIRC) that  
>> put
>> the Ethernet header at the *back end* of the packet on the wire -  
>> i.e.,
>> it became a trailer rather than a header.
>
> Ah, no. That was Berzerkley. (See RFC 893.) (Gratuitous comment  
> suppressed... ;-)
>
>> This would have required, among other things, redefining the IP  
>> header
>> so that the checksum was kept in a trailer - since you couldn't  
>> finish
>> computing the checksum until all of the data had come in.
>
> ??? The IP checksum covers only the IP header, no?
>
>
>> Essentially you would end up with a circuit-switched network that had
>> an IP datagram interface ... In this architecture, IP is an interface
>> spec at the edges only, and what goes on inside is hidden and could  
>> be
>> anything. I wonder if today's routers play such tricks....
>
> That's exactly how today's networks actually operate. Things like  
> Frame Relay
> and MPLS avoid processing IP headers on many hops - although on a  
> local basis
> only (i.e. not system-wide).
>
> I do forsee IP becoming an interface-spec at the edges, with  
> something new
> being used _inside_ the network, i.e. router-router (much like an  
> RJ11 analog
> jack is an old interface to a wholly different/modern internals),  
> but then
> again this is hardly a new idea - the Nimrod deployment plan used  
> the same
> concept! So my crystal ball may be a bit out of focus, timewise... :-)
>
> At the moment IP is in fact still used for the generic router-router
> interface, but I do think the day is drawing closer when something  
> else will
> (slowly, admittedly) replace it in that role.
>
> 	Noel



From jack at 3kitty.org  Fri Nov 13 18:41:58 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Sat, 14 Nov 2009 02:41:58 +0000
Subject: [ih] IPv4 address size debate
In-Reply-To: <20091113213410.E06336BE681@mercury.lcs.mit.edu>
References: <20091113213410.E06336BE681@mercury.lcs.mit.edu>
Message-ID: <1258166519.3379.112.camel@localhost>

Answering a few messages...

I don't recall any significant discussion of variable-length addresses.
There was discussion of the fixed size of the address field, and
especially of the way to split it up into class A/B/C/etc, which was I
guess a form of variable addressing.  There weren't all that many
computers around, but a new concern was the number of *networks* that
could be handled (256 wasn't enough), and the number of hosts that could
be on a particular net.  So IP4 *does* have variable-length addresses.
Sort of. 

This also was I think when the need for ARP surfaced, since there wasn't
enough "host" space left in the IP address to contain a full lower-layer
address for the then-new LANs.  I think that the limitation to 32 bits
may have partially been to force the issue of dealing with physical nets
whose addresses were "too big" to just stuff into the IP address host
part.  If the IP address had been 64 bits, you can bet that 48 of them
would have held Ethernet MACs...it would have been too tempting.

Lastly, there was some real concern about efficiency.  A lot of traffic
was Telnet, much of it character-at-a-time, which meant each TCP/IP
packet often carried exactly one byte of user data, reaching an
astounding wire efficiency of less than 5%.  So 95+% of the $$$s buying
those expensive leased lines was for overhead.  More if you considered
that you never wanted to run lines at 100%.  If you took an analyzer and
snooped on the IMP/IMP circuits, it was sometimes really hard to see any
actual user data for all the headers and control packets (TCP ACKs).
Not so good. 

The 32-bit decision and the various splits of net/host space got things
from discussion to coding.

As Vint points out, you have to remember that all this work was an
experiment.  That's what ARPA did.  In fact, sometimes decisions were
made to try an unproven approach, even when a known proven approach was
applicable, because that was the mission - in Star Trek terms, to "go
where no man has gone before".

Besides, in just a couple of years we had gone from TCP 2, through a
slew of point-releases (I remember TCP 2.5 and TCP "2.5+epsilon"), TCP 3
(for a few weeks) and were working on TCP 4.  Everyone I think pretty
much believed that TCP 5, 6, etc. would come along in short order and
the headers could be readily changed again if the experimentation
results warranted.  We surely didn't think it would take decades and the
TCP4 design would have to last that long...so 32 bits fixed could easily
handle the needs for the next 12 months or so!

When the government made TCP a DoD standard, the concrete set really
quickly...

Ah yes, Ethernet hacking sounds like a BSD project.  I may also be
confusing the TCP and IP checksumming - it's been a long time.  There
was some reason for considering trailers though.  Can't remember..

/Jack


On Fri, 2009-11-13 at 16:34 -0500, Noel Chiappa wrote:
> > From: Jack Haverty <jack at 3kitty.org>
> 
>     > Since I was one of the people arguing for fixed-length addresses back
>     > in those days, I guess maybe it's time to explain why...
> 
> I don't disagree that fixed-length addresses were the right choice _at the
> time_; I was actually interested in why we didn't pick something with a
> little more long-term flexibility (i.e. flexible syntax, with 'temporarily'
> subsetted semantics to produce _effectively_ fixed-length addresses), and if
> that option was even considered.
> 
> Did people think 32 bits was 'more than enough for any conceivable
> circumstances', or did they not think that TCP/IP would be anything other
> than a large-scale trial that would be supplanted by something new, or what?
> 
> Had someone suggested a format with address-length fields, and the only
> allowed/supported value in them being '4', do you think that would have been
> accepted?
> 
> 
>     > It was very very desirable to have the hardware put the data into the
>     > "right place" for subsequent processing.
> 
> I take your point (I used techniques to do the same thing in the router code
> I did, to avoid having to ever move data), but at the same time it undermines
> the then-current reasoning that 'if we need to do anything else, we can do it
> with a header option' - since (as you point out below) using options produces
> variable-length headers, and those negate the advantages of a fixed-length
> header.
> 
>     > IP packets with no options would be fast, those with options would
>     > suffer.
> 
> Which is still the situation today... I was going to say 'sadly', but I'm not
> sure that's warranted. But it is certainly a very high bar to the use of
> options for extensions that are anything other than 'low-duty-cycle' (i.e. in
> few packets), and that definitely limits the value of the option-based
> extensibility mechanism.
> 
>     > There was at least one implementation of Ethernet (MIT? IIRC) that put
>     > the Ethernet header at the *back end* of the packet on the wire - i.e.,
>     > it became a trailer rather than a header. 
> 
> Ah, no. That was Berzerkley. (See RFC 893.) (Gratuitous comment suppressed... ;-)
> 
>     > This would have required, among other things, redefining the IP header
>     > so that the checksum was kept in a trailer - since you couldn't finish
>     > computing the checksum until all of the data had come in.
> 
> ??? The IP checksum covers only the IP header, no?
> 
> 
>     > Essentially you would end up with a circuit-switched network that had
>     > an IP datagram interface ... In this architecture, IP is an interface
>     > spec at the edges only, and what goes on inside is hidden and could be
>     > anything. I wonder if today's routers play such tricks....
> 
> That's exactly how today's networks actually operate. Things like Frame Relay
> and MPLS avoid processing IP headers on many hops - although on a local basis
> only (i.e. not system-wide).
> 
> I do forsee IP becoming an interface-spec at the edges, with something new
> being used _inside_ the network, i.e. router-router (much like an RJ11 analog
> jack is an old interface to a wholly different/modern internals), but then
> again this is hardly a new idea - the Nimrod deployment plan used the same
> concept! So my crystal ball may be a bit out of focus, timewise... :-)
> 
> At the moment IP is in fact still used for the generic router-router
> interface, but I do think the day is drawing closer when something else will
> (slowly, admittedly) replace it in that role.
> 
> 	Noel
> 



From johnl at iecc.com  Fri Nov 13 19:52:31 2009
From: johnl at iecc.com (John Levine)
Date: 14 Nov 2009 03:52:31 -0000
Subject: [ih] trailer encapsulation, was IPv4 address size debate
In-Reply-To: <20091113213410.E06336BE681@mercury.lcs.mit.edu>
Message-ID: <20091114035231.38638.qmail@simone.iecc.com>

>    > There was at least one implementation of Ethernet (MIT? IIRC) that put
>    > the Ethernet header at the *back end* of the packet on the wire - i.e.,
>    > it became a trailer rather than a header. 
>
>Ah, no. That was Berzerkley. (See RFC 893.) (Gratuitous comment suppressed... ;-)

Trailer encapsulation was part of 4.2BSD, and it was a significant win
on the VAX, which had fairly slow memory and tiny 512 byte pages.  The
data part of the packets was padded to a multiple of 512 bytes so it
could be moved around both within the kernel and into user space by
adjusting page table entries rather than by copying.

R's,
John



From jack at 3kitty.org  Fri Nov 13 21:24:45 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 13 Nov 2009 21:24:45 -0800
Subject: [ih] IPv4 address size debate
In-Reply-To: <4AFE153C.2030209@tamu.edu>
References: <20091112064657.7865628E137@aland.bbn.com>
	<a0624084dc721a7890546@[168.122.15.96]> <4AFC5C4A.8020509@bennett.com>
	<4896FFDF-6BF4-4983-B2AF-E055062DCE0E@google.com>
	<1258134989.3379.76.camel@localhost>  <4AFE153C.2030209@tamu.edu>
Message-ID: <1258176285.3379.145.camel@localhost>

Well said.  Engineering is *always* about getting the job done with
minimal use of resources, and you always identify and focus on the most
expensive resources to drive the design.  The numbers have changed over
the decades, but the fundamental task remains the same.  

In addition to processor speed and circuit capacity, the other major
variable is cost.  That 1MHz computer back in 1980 cost a million plus
dollars - 1980 dollars.  The 3 GHZ machine on my desk today cost me $200
a few months ago.  For $1M I could get a whole bunch of them!  I think
the challenge now is how to use *lots* of cheap processors (and memory)
to do what you need to do.

When I was involved in IMP/X.25 networking, it was always the case that
the cost of the hardware (which we were selling) was insignificant
compared to the annual cost of the circuits.  It was common to do a cost
analysis which showed that the cost of a network (the boxes) would be
recovered in a year or so by savings on the communications lines.  So
the ongoing operational costs are just as important in the design
process as the costs of the equipment.  It all goes into the design
process.

It would be interesting to see someone do an analysis of the changes
over time in computing and communication capacity, with cost (upfront
and recurring) and inflation factored in.  Or maybe it's been done.
Which is relatively cheaper now and back then - computing or
communication?

The goal is a moving target too.

We (at least I) never envisioned carrying lots of (or even any) video
data on the Internet, and certainly not high-def TV with independent
channels (no broadcast) to millions of end users.  

Computers back then had maybe a few dozen simultaneous users, and maybe
there might be hundreds of computers on the net.   It's amazing that
this stuff still works with millions... 

OTOH, I would never have predicted in 1980 that in 2009 there would be
millions of people typing one-line messages with their thumbs on tiny
keyboards with miniscule screens.   And on a device which is actually
just as capable of providing instantaneous real-time voice
communications!  What are they thinking...?

The numbers change, the user expectations change, the underlying facts
of life change.  Engineering design has to sort through all that and
come up with a good approach that will work now and for at least a
little while in the future.  

If it's too easy to get a design to work, then your solution is probably
overengineered and therefore wasteful.  But if the parts are so cheap,
you may not care.  The process of design becomes the larger cost, and
therefore that's what you minimize...

/Jack Haverty
Point Arena, CA


On Fri, 2009-11-13 at 20:26 -0600, Guy Almes wrote:
> Jack et al.,
>    I'm very much enjoying this thread.
>    I have a question about one part of this.
> 
> Jack Haverty wrote:
> > Since I was one of the people arguing for fixed-length addresses back in
> > those days, I guess maybe it's time to explain why...
> > 
> > It all started with the network hardware, i.e., the I/O box that sat
> > between your computer and the network wire (Ethernet, IMP, whatever).
> > Your computer, whatever it was, was very slow and very expensive.  ...
> 
>    You say that the early gateways were very slow and very expensive.
>    This is true, of course.
>    But think about how this has changed between 1980 or so and the present.
>    Computers have gotten faster, perhaps by something like 10,000 or so.
>    But if you consider that a "high-end serial pipe" in the 1980-85 era 
> was about 50 Kb/s and that such a pipe is 10 Gb/s, that's a speed-up of 
> 200,000 (math right?).
>    Even adjusting for the hardware difficulties of 1980, the modern 
> 10-Gb/s interface cards are difficult to build.  Oh, and expensive.  And 
> also, with DWDM, you wish you had a whole bunch of them.
> 
>    Now I'm certainly grateful for these high-speed circuits.  The point 
> is not to complain.
>    But, to the degree that the IPv4 design tried to make things easy for 
> the limited processing hardware, that may still be the right thing.
>    (Now just what one means by "hardware friendly" is not quite the same 
> now as it seemed then, but I'll stick with the broader point.  The 
> capacity of the fibers and the demand for moving bits over them have 
> both increased faster than the processor speeds have increased.)
> 
> 	-- Guy
> 



From craig at aland.bbn.com  Sat Nov 14 04:38:14 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Sat, 14 Nov 2009 07:38:14 -0500
Subject: [ih] IPv4 address size debate
Message-ID: <20091114123814.36FC728E137@aland.bbn.com>

> Ah yes, Ethernet hacking sounds like a BSD project.  I may also be
> confusing the TCP and IP checksumming - it's been a long time.  There
> was some reason for considering trailers though.  Can't remember..

The other reason for considering trailers was that you could put the
checksum at the end, which was nice for sending (you could append
the checksum on the way out).  There's no win on receiving end unless you
split the header into a fixed-size leader that aligns the data and tells you
where the data is going and a trailer that has the variable parts of the
header (checksum can go either place with equal benefit/pain for the receiver).
There's also no win for the router unless all routable info is in the leader.

Speaking, of course, c. 1980 platforms.  Today's mileage would vary (though
less than some notes imagine).

Thanks!

Craig


From jeanjour at comcast.net  Sat Nov 14 07:16:33 2009
From: jeanjour at comcast.net (John Day)
Date: Sat, 14 Nov 2009 10:16:33 -0500
Subject: [ih] IPv4 address size debate
In-Reply-To: <1258166519.3379.112.camel@localhost>
References: <20091113213410.E06336BE681@mercury.lcs.mit.edu>
	<1258166519.3379.112.camel@localhost>
Message-ID: <a06240872c72478a56bed@[168.122.15.96]>

At 2:41 +0000 2009/11/14, Jack Haverty wrote:
>Answering a few messages...
>
>I don't recall any significant discussion of variable-length addresses.
>There was discussion of the fixed size of the address field, and
>especially of the way to split it up into class A/B/C/etc, which was I
>guess a form of variable addressing.  There weren't all that many
>computers around, but a new concern was the number of *networks* that
>could be handled (256 wasn't enough), and the number of hosts that could
>be on a particular net.  So IP4 *does* have variable-length addresses.
>Sort of.
>
>This also was I think when the need for ARP surfaced, since there wasn't
>enough "host" space left in the IP address to contain a full lower-layer
>address for the then-new LANs.  I think that the limitation to 32 bits
>may have partially been to force the issue of dealing with physical nets
>whose addresses were "too big" to just stuff into the IP address host
>part.  If the IP address had been 64 bits, you can bet that 48 of them
>would have held Ethernet MACs...it would have been too tempting.

ARP is required any time the layer below is either multiple access or 
there are multiple paths to the next hop.

It is just as well there was no room to put the MAC address in the IP 
address.  That way we avoided a mistake we didn't need to make. 
Although as long as IP names the same thing the MAC address does, 
i.e. the interface, it doesn't matter.

This is all consistent with Noel's point that IP is a subnet access 
(interface) protocol.

>
>Lastly, there was some real concern about efficiency.  A lot of traffic
>was Telnet, much of it character-at-a-time, which meant each TCP/IP
>packet often carried exactly one byte of user data, reaching an
>astounding wire efficiency of less than 5%.  So 95+% of the $$$s buying
>those expensive leased lines was for overhead.  More if you considered
>that you never wanted to run lines at 100%.  If you took an analyzer and
>snooped on the IMP/IMP circuits, it was sometimes really hard to see any
>actual user data for all the headers and control packets (TCP ACKs).
>Not so good.

Yea, I remember most people outside the Internet community i.e. in 
the commercial world, would take one look at the header overhead even 
without the Tenex insistence on character at a time and scoff.  There 
was no way they could sell that to customers that were working over 
much slower links at the time.

Snip

Take care,
John



From LarrySheldon at cox.net  Mon Nov 16 14:57:17 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 16 Nov 2009 16:57:17 -0600
Subject: [ih] We can hang up now, it's all done.
Message-ID: <4B01D8CD.7090702@cox.net>

Well, there seems to be one or two misunderstandings....

(no need to flame--humor intended.)

http://sixrevisions.com/resources/the-history-of-the-internet-in-a-nutshell/
-- 
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information:
	http://tinyurl.com/4sqczs
	http://tinyurl.com/7tp8ml
	


From dhc2 at dcrocker.net  Sun Nov 22 00:03:49 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Sun, 22 Nov 2009 00:03:49 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B01D8CD.7090702@cox.net>
References: <4B01D8CD.7090702@cox.net>
Message-ID: <4B08F065.4010406@dcrocker.net>

I must be in a very strange mood, because I think the summary is an interesting 
and pretty reasonable -- if still rough -- effort, and is fixable.

That is, I think it's arc is helpful and the details it gets wrong are fairly 
discrete, and therefore easily remedied.

d/

Larry Sheldon wrote:
> Well, there seems to be one or two misunderstandings....
> 
> (no need to flame--humor intended.)
> 
> http://sixrevisions.com/resources/the-history-of-the-internet-in-a-nutshell/ 
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From LarrySheldon at cox.net  Sun Nov 22 08:56:05 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Sun, 22 Nov 2009 10:56:05 -0600
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B08F065.4010406@dcrocker.net>
References: <4B01D8CD.7090702@cox.net> <4B08F065.4010406@dcrocker.net>
Message-ID: <4B096D25.3000608@cox.net>

Dave CROCKER wrote:

> Larry Sheldon wrote:
>> Well, there seems to be one or two misunderstandings....
>>
>> (no need to flame--humor intended.)
>>
>> http://sixrevisions.com/resources/the-history-of-the-internet-in-a-nutshell/ 

 > I must be in a very strange mood, because I think the summary is an
 > interesting and pretty reasonable -- if still rough -- effort, and is
 > fixable.
 >
 > That is, I think it's arc is helpful and the details it gets wrong are
 > fairly discrete, and therefore easily remedied.

Some comfort in that for late-to-the-game folks.

But I am sad to see no mention of Gopher and Archie (and hytelnet) which 
I believe had to have been the beginnings of the World Wide Web.

(I would make make the argument that the WWW was a standalone 
development that could not have occurred without the facility of 
networking.  The sense I am groping for here is he sense that flitting 
about the globe to one global warming conference after another is not 
the result the invention of the airplane, but is dependent upon it. 
What was the Wright brother's goal, anyway?  To fly, is my guess.  Going 
somewhere came later.)


-- 
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information:
	http://tinyurl.com/4sqczs
	http://tinyurl.com/7tp8ml
	


From lpress at csudh.edu  Sun Nov 22 09:59:48 2009
From: lpress at csudh.edu (Larry Press)
Date: Sun, 22 Nov 2009 09:59:48 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B096D25.3000608@cox.net>
References: <4B01D8CD.7090702@cox.net> <4B08F065.4010406@dcrocker.net>
	<4B096D25.3000608@cox.net>
Message-ID: <4B097C14.2030101@csudh.edu>

> But I am sad to see no mention of Gopher and Archie (and hytelnet) which 

Don't forget Veronica and Jughead.


> I believe had to have been the beginnings of the World Wide Web.


Where does anything begin?  Hypertext was preceded by linear text and 
was foreshadowed in Vannevar Bush's article "As We May Think." Folks 
like Ted Nelson and Ben Shneiderman built tools (TIES) and popularized 
the idea.  As far as I know, gopher was first on the Net, but its 
capability was a subset of a system like TIES.  This is not to put 
Gopher down -- it was both useful and a terrific demonstration of the 
potential value of the Internet -- an eye opener.

(The first time I fired up a Web browser and looked at pictures of 
dinosaurs at a college in Hawaii, I thought -- "big deal -- Gopher with 
pictures."  It is safe to say I messed the boat on that one).

It is hard to say who "invented" anything -- often it is the first 
successful entrepreneur who gets the credit.

Larry


From latzko-toth.guillaume at uqam.ca  Sun Nov 22 11:51:00 2009
From: latzko-toth.guillaume at uqam.ca (Guillaume Latzko-Toth)
Date: Sun, 22 Nov 2009 14:51:00 -0500
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B08F065.4010406@dcrocker.net>
References: <4B01D8CD.7090702@cox.net>
 <4B08F065.4010406@dcrocker.net>
Message-ID: <BLU0-SMTP1015A6B9938DE919529A0969C9F0@phx.gbl>

Hello,

It's my first post on this list, which I found 
very helpful with the dissertation I'm completing 
on the development of online chat and IRC -- 
particularly your interesting discussions on the 
origins of the "talk" command. The expertise and 
experience of Internet and networking gathered here is impressive.

At 03:03 2009-11-22, Dave CROCKER wrote:
>I must be in a very strange mood, because I 
>think the summary is an interesting and pretty 
>reasonable -- if still rough -- effort, and is fixable.

Concerning the following point in the proposed chronology:
>When Apple pulled out of the AppleLink program 
>in 1989, the project was renamed and America Online was born.

I didn't know about the link between AppleLink 
(never heard about it actually) and America 
Online. I thought that AOL was formerly known as 
Quantum Computer Services, which was previously 
known as Control Video Corporation, which had 
itself bought out the "PlayNet" (pioneer) online 
gaming service in 1985 and renamed/rebranded it as Q-Link (QuantumLink).

Somebody can corroborate this version? Any input 
that could help me get this story right would be appreciated.

Regards,


------------
Guillaume Latzko-Toth
Ph.D. candidate in Communication Studies
Universit? du Qu?bec ? Montr?al
http://grm.uqam.ca/?q=latzko




From jeanjour at comcast.net  Sun Nov 22 12:33:29 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 22 Nov 2009 15:33:29 -0500
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B096D25.3000608@cox.net>
References: <4B01D8CD.7090702@cox.net> <4B08F065.4010406@dcrocker.net>
	<4B096D25.3000608@cox.net>
Message-ID: <a06240895c72f5047efef@[10.0.1.20]>

The web was a bad version of NLS.  But I believe it was done in 
complete ignorance of what Englebart had done in the early 70s.  Had 
they known about it, they might have done a better job.



>But I am sad to see no mention of Gopher and Archie (and hytelnet) 
>which I believe had to have been the beginnings of the World Wide 
>Web.
>
>(I would make make the argument that the WWW was a standalone 
>development that could not have occurred without the facility of 
>networking.  The sense I am groping for here is he sense that 
>flitting about the globe to one global warming conference after 
>another is not the result the invention of the airplane, but is 
>dependent upon it. What was the Wright brother's goal, anyway?  To 
>fly, is my guess.  Going somewhere came later.)
>
>
>--
>Requiescas in pace o email              Two identifying characteristics
>                                              of System Administrators:
>Ex turpi causa non oritur actio        Infallibility, and the ability to
>                                              learn from their mistakes.
>Eppure si rinfresca
>
>ICBM Targeting Information:
>	http://tinyurl.com/4sqczs
>	http://tinyurl.com/7tp8ml
>



From brian at platohistory.org  Sun Nov 22 13:09:25 2009
From: brian at platohistory.org (Brian Dear)
Date: Sun, 22 Nov 2009 13:09:25 -0800
Subject: [ih] We can hang up now, it's all done.
Message-ID: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>

The SixRevisions article, as well as The Guardian's recent online  
coverage of the "history of the Internet", both get numerous things  
wrong.  The fundamental problem is that you can't do a "history of the  
Internet" and then talk about the earliest examples of various online  
phenomena, because many of the online firsts did NOT happen on the  
Internet or its precursors like ARPANET.

? "1979: MUD - The earliest form of multiplayer games"
This is simply wrong.   The PLATO system had a thriving community of  
game players and game developers who created multiplayer games years  
before "MUD" was developed.  "MUD" is in fact not even the first  
MUD.   A multiplayer spacewar game was developed by Rick Blomme on  
PLATO III around 1969.  Then on PLATO IV starting in 1972 a whole rash  
of multiplayer games popped up, like Dogfight, Fishwar, and other "big  
board" games (the whole notion of online multiplayer Big Boards, where  
you could go see who was waiting to play a game with you, started on  
PLATO).   In the following three years games became even more  
sophisticated, like the famous Airfight by Brand Fortner, a genuine  
shoot'em'up dogfight airplane game supporting 16 players, that was the  
inspiration for Bruce Artwick (both Fortner and Artwick attended the U  
of Illinois) who went on to create on of the biggest games in history  
--- Microsoft Flight Simulator.   Then there were a whole slew of  
mutliuser dungeon type games, including pedit5, oubliette, Avatar,  
Moria, Emprise, dnd, and so on.  None of it on Internet or ARPANET.

* 1978: The first bulletin board system
This may be technically true but it ignores the real point that in  
1973 the Institute for the Future had its FORUM system on ARPANET, and  
at the same time PLATO Notes came out, the a full-fledged message  
board system.  PLATO Notes inspired Ray Ozzie (now Chief Software  
Architect of Microsoft) to create Lotus Notes.

? 1982: The first emoticon.
The real history is that emoticons were far richer and more  
graphically complex BEFORE 1982.  It's one o those weird Darwinian  
twists, where the earlier organism was far more complex but lived in a  
single environment and couldn't exist anywhere but.  On PLATO, you  
could superimpose one typed character onto another, or even a bunch of  
characters, and in so doing create very sophisticated emoticons.  See platopeople.com/emoticons.html 
  for screen shots.

? 1985: Virtual communities
Way way inaccurate, and again, probably copied from The Guardian's  
piece which also pushed this myth.  The WELL (which I have been a  
member of since 1986) was a relative latecomer to the world of online  
communities if you compare it to PLATO, which in 1973 had notesfiles  
(message forums), chat rooms, and instant messaging.  The WELL  
wouldn't exist for another dozen years.

As for writing a dissertation on the development of online chat and  
IRC, if you want to be accurate you better include PLATO because it  
pre-dates AIM, IRC, and the Unix "talk" command.   Go research the  
history of PLATO's TERM-talk (1973) and Talk-o-Matic (1973) if you  
want to know about the earliest history of instant messaging and multi- 
user chat rooms.

- Brian


Brian Dear
PLATO History Project
La Jolla, California





From jeanjour at comcast.net  Sun Nov 22 16:32:35 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 22 Nov 2009 19:32:35 -0500
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
Message-ID: <a0624089cc72f6ca29508@[10.0.1.20]>

And along these lines, Brian can correct me because even though PLATO 
was a block down Springfield Ave, I personally didn't have that much 
contact with them.  Others in our group did.

The earliest AIM, messaging I am aware of was Jim Calvin's Tenex hack 
that we used on the ARPANet in 1972.  I still have transcripts of 
some of those evenings or did.  We called it teleconferencing in 
those days, but it was basically AIM.  I could go back and look but 
Jim had hacked the Tenex command that let you share "screens." (The 
early version let everyone speak at once and the characters would be 
interleaved. After he got it running, he quickly started adding all 
sorts of features.  (I may even have the documentation somewhere). 
We had been using almost nightly to chat and discuss "big ideas" and 
I believe that people got wind of it and it was included in the ICCC 
72 demo of the ARPANet.  After that there were a spate of papers on 
"teleconferencing" at some conferences.  Again, it was messaging, not 
what we call teleconferencing today.

Also in early 1976, we used a PLATO plasma screen to which a touch 
panel was added interfaced to an LSI/11 as a single use "intelligent 
terminal."  The LSI/11 was running a stripped down version of UNIX 
that we created called EUNIX.  It was either an early X-Windows or an 
early PC depending on your point of view.  The first version was used 
with a land use planning system that displayed maps of the 6 counties 
around Chicago down to the township (6  by 6 sections) and section 
level (a square mile) with land use data stored on 2 databases on 
either coast and accessed over the ARPANET.  There was a keyboard for 
major text entry but interface was primarily driven by touching the 
screen.  Data could be searched, displayed, combined and otherwise 
manipulated and displayed in graphs and maps.

A version was also created for the DoD that was used in DC and Hawaii.

Take care,
John

At 13:09 -0800 2009/11/22, Brian Dear wrote:
>The SixRevisions article, as well as The Guardian's recent online 
>coverage of the "history of the Internet", both get numerous things 
>wrong.  The fundamental problem is that you can't do a "history of 
>the Internet" and then talk about the earliest examples of various 
>online phenomena, because many of the online firsts did NOT happen 
>on the Internet or its precursors like ARPANET.
>
>* "1979: MUD - The earliest form of multiplayer games"
>This is simply wrong.   The PLATO system had a thriving community of 
>game players and game developers who created multiplayer games years 
>before "MUD" was developed.  "MUD" is in fact not even the first 
>MUD.   A multiplayer spacewar game was developed by Rick Blomme on 
>PLATO III around 1969.  Then on PLATO IV starting in 1972 a whole 
>rash of multiplayer games popped up, like Dogfight, Fishwar, and 
>other "big board" games (the whole notion of online multiplayer Big 
>Boards, where you could go see who was waiting to play a game with 
>you, started on PLATO).   In the following three years games became 
>even more sophisticated, like the famous Airfight by Brand Fortner, 
>a genuine shoot'em'up dogfight airplane game supporting 16 players, 
>that was the inspiration for Bruce Artwick (both Fortner and Artwick 
>attended the U of Illinois) who went on to create on of the biggest 
>games in history --- Microsoft Flight Simulator.   Then there were a 
>whole slew of mutliuser dungeon type games, including pedit5, 
>oubliette, Avatar, Moria, Emprise, dnd, and so on.  None of it on 
>Internet or ARPANET.
>
>* 1978: The first bulletin board system
>This may be technically true but it ignores the real point that in 
>1973 the Institute for the Future had its FORUM system on ARPANET, 
>and at the same time PLATO Notes came out, the a full-fledged 
>message board system.  PLATO Notes inspired Ray Ozzie (now Chief 
>Software Architect of Microsoft) to create Lotus Notes.
>
>* 1982: The first emoticon.
>The real history is that emoticons were far richer and more 
>graphically complex BEFORE 1982.  It's one o those weird Darwinian 
>twists, where the earlier organism was far more complex but lived in 
>a single environment and couldn't exist anywhere but.  On PLATO, you 
>could superimpose one typed character onto another, or even a bunch 
>of characters, and in so doing create very sophisticated emoticons. 
>See platopeople.com/emoticons.html for screen shots.
>
>* 1985: Virtual communities
>Way way inaccurate, and again, probably copied from The Guardian's 
>piece which also pushed this myth.  The WELL (which I have been a 
>member of since 1986) was a relative latecomer to the world of 
>online communities if you compare it to PLATO, which in 1973 had 
>notesfiles (message forums), chat rooms, and instant messaging.  The 
>WELL wouldn't exist for another dozen years.
>
>As for writing a dissertation on the development of online chat and 
>IRC, if you want to be accurate you better include PLATO because it 
>pre-dates AIM, IRC, and the Unix "talk" command.   Go research the 
>history of PLATO's TERM-talk (1973) and Talk-o-Matic (1973) if you 
>want to know about the earliest history of instant messaging and 
>multi-user chat rooms.
>
>- Brian
>
>
>Brian Dear
>PLATO History Project
>La Jolla, California



From brian at platohistory.org  Sun Nov 22 17:26:02 2009
From: brian at platohistory.org (Brian Dear)
Date: Sun, 22 Nov 2009 17:26:02 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <a0624089cc72f6ca29508@[10.0.1.20]>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<a0624089cc72f6ca29508@[10.0.1.20]>
Message-ID: <1F4994B2-64A2-4623-8B63-7A943E93459F@platohistory.org>

I've had folks tell me they built, or they heard about others who  
built, talk-like programs in the 60s, to let two people talk live,  
character by character, back and forth.  (There may have been one on  
PLATO III in the '60s, I'll have to dig through my oral history  
transcripts.)  It doesn't surprise me in the least that others had  
hacked together simple talk programs on other systems.  Heck, people  
have been yakkin' over the wires since the days of the telegraph.

One thing I've learned is that when it comes to software and hardware,  
somebody else always had the idea earlier, and whenever one cites X as  
the first date of an instance of Y, someone else will come along with  
an earlier example, and then a third person -- and it sometimes takes  
years -- identifies an even earlier example.  For example, lots of  
people often cite Vannevar Bush's 1940s article as the original idea  
of hypertext.  I would argue that Edward Thorndike offered just as  
compelling a vision in 1912.

My point with the PLATO citations is that as far as I'm concerned,  
these were the first uses of these online activities at a significant  
scale, thousands of users.   What is hard for many folks to grasp is  
the scale of PLATO -- relative to all of the users connected to  
ARPANET, PLATO had more users for at least a decade.

- Brian



On 22 Nov 2009, at 16:32, John Day wrote:

> And along these lines, Brian can correct me because even though  
> PLATO was a block down Springfield Ave, I personally didn't have  
> that much contact with them.  Others in our group did.
>
> The earliest AIM, messaging I am aware of was Jim Calvin's Tenex  
> hack that we used on the ARPANet in 1972.  I still have transcripts  
> of some of those evenings or did.  We called it teleconferencing in  
> those days, but it was basically AIM.  I could go back and look but  
> Jim had hacked the Tenex command that let you share "screens." (The  
> early version let everyone speak at once and the characters would be  
> interleaved. After he got it running, he quickly started adding all  
> sorts of features.  (I may even have the documentation somewhere).  
> We had been using almost nightly to chat and discuss "big ideas" and  
> I believe that people got wind of it and it was included in the ICCC  
> 72 demo of the ARPANet.  After that there were a spate of papers on  
> "teleconferencing" at some conferences.  Again, it was messaging,  
> not what we call teleconferencing today.
>
> Also in early 1976, we used a PLATO plasma screen to which a touch  
> panel was added interfaced to an LSI/11 as a single use "intelligent  
> terminal."  The LSI/11 was running a stripped down version of UNIX  
> that we created called EUNIX.  It was either an early X-Windows or  
> an early PC depending on your point of view.  The first version was  
> used with a land use planning system that displayed maps of the 6  
> counties around Chicago down to the township (6  by 6 sections) and  
> section level (a square mile) with land use data stored on 2  
> databases on either coast and accessed over the ARPANET.  There was  
> a keyboard for major text entry but interface was primarily driven  
> by touching the screen.  Data could be searched, displayed, combined  
> and otherwise manipulated and displayed in graphs and maps.
>
> A version was also created for the DoD that was used in DC and Hawaii.
>
> Take care,
> John
>
> At 13:09 -0800 2009/11/22, Brian Dear wrote:
>> The SixRevisions article, as well as The Guardian's recent online  
>> coverage of the "history of the Internet", both get numerous things  
>> wrong.  The fundamental problem is that you can't do a "history of  
>> the Internet" and then talk about the earliest examples of various  
>> online phenomena, because many of the online firsts did NOT happen  
>> on the Internet or its precursors like ARPANET.
>>
>> * "1979: MUD - The earliest form of multiplayer games"
>> This is simply wrong.   The PLATO system had a thriving community  
>> of game players and game developers who created multiplayer games  
>> years before "MUD" was developed.  "MUD" is in fact not even the  
>> first MUD.   A multiplayer spacewar game was developed by Rick  
>> Blomme on PLATO III around 1969.  Then on PLATO IV starting in 1972  
>> a whole rash of multiplayer games popped up, like Dogfight,  
>> Fishwar, and other "big board" games (the whole notion of online  
>> multiplayer Big Boards, where you could go see who was waiting to  
>> play a game with you, started on PLATO).   In the following three  
>> years games became even more sophisticated, like the famous  
>> Airfight by Brand Fortner, a genuine shoot'em'up dogfight airplane  
>> game supporting 16 players, that was the inspiration for Bruce  
>> Artwick (both Fortner and Artwick attended the U of Illinois) who  
>> went on to create on of the biggest games in history --- Microsoft  
>> Flight Simulator.   Then there were a whole slew of mutliuser  
>> dungeon type games, including pedit5, oubliette, Avatar, Moria,  
>> Emprise, dnd, and so on.  None of it on Internet or ARPANET.
>>
>> * 1978: The first bulletin board system
>> This may be technically true but it ignores the real point that in  
>> 1973 the Institute for the Future had its FORUM system on ARPANET,  
>> and at the same time PLATO Notes came out, the a full-fledged  
>> message board system.  PLATO Notes inspired Ray Ozzie (now Chief  
>> Software Architect of Microsoft) to create Lotus Notes.
>>
>> * 1982: The first emoticon.
>> The real history is that emoticons were far richer and more  
>> graphically complex BEFORE 1982.  It's one o those weird Darwinian  
>> twists, where the earlier organism was far more complex but lived  
>> in a single environment and couldn't exist anywhere but.  On PLATO,  
>> you could superimpose one typed character onto another, or even a  
>> bunch of characters, and in so doing create very sophisticated  
>> emoticons. See platopeople.com/emoticons.html for screen shots.
>>
>> * 1985: Virtual communities
>> Way way inaccurate, and again, probably copied from The Guardian's  
>> piece which also pushed this myth.  The WELL (which I have been a  
>> member of since 1986) was a relative latecomer to the world of  
>> online communities if you compare it to PLATO, which in 1973 had  
>> notesfiles (message forums), chat rooms, and instant messaging.   
>> The WELL wouldn't exist for another dozen years.
>>
>> As for writing a dissertation on the development of online chat and  
>> IRC, if you want to be accurate you better include PLATO because it  
>> pre-dates AIM, IRC, and the Unix "talk" command.   Go research the  
>> history of PLATO's TERM-talk (1973) and Talk-o-Matic (1973) if you  
>> want to know about the earliest history of instant messaging and  
>> multi-user chat rooms.
>>
>> - Brian
>>
>>
>> Brian Dear
>> PLATO History Project
>> La Jolla, California



From lpress at csudh.edu  Sun Nov 22 17:41:55 2009
From: lpress at csudh.edu (Larry Press)
Date: Sun, 22 Nov 2009 17:41:55 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
Message-ID: <4B09E863.3080402@csudh.edu>


> * 1978: The first bulletin board system
> This may be technically true but it ignores the real point that in  
> 1973 the Institute for the Future had its FORUM system on ARPANET, and  
> at the same time PLATO Notes came out, the a full-fledged message  
> board system.  PLATO Notes inspired Ray Ozzie (now Chief Software  
> Architect of Microsoft) to create Lotus Notes.


EIES from New Jersey Institute of Technology also existed in the mid 1970s.

Larry







From jeanjour at comcast.net  Sun Nov 22 17:50:20 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 22 Nov 2009 20:50:20 -0500
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <1F4994B2-64A2-4623-8B63-7A943E93459F@platohistory.org>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<a0624089cc72f6ca29508@[10.0.1.20]>
	<1F4994B2-64A2-4623-8B63-7A943E93459F@platohistory.org>
Message-ID: <a062408a0c72f9870d94e@[10.0.1.20]>

Absolutely.  I totally agree with you.  The "historians" have not 
done a very thorough job of understanding the bigger picture of what 
was going on.

My point was that while Jim Calvin's started out as hack, it very 
quickly became (within a matter of weeks) a sophisticated application 
and moved off the hack.  As I indicated, there was  a command 
language and a protocol defined for it.  Not sure how many people 
were using it over the whole net.  There was probably no way to know.

Also, thanks to some who seem to be more concerned with *their* 
supposed firsts, there has been an over emphasis on this aspect of 
things.  When what I remember most about those early years was the 
free flow of ideas and how ideas were bouncing around various groups. 
What was more interesting was how the interaction was leading to new 
understanding.

Again, something that seems to be too subtle for most of these "historians."

To wit, the above mentioned hack by Calvin was then used among a 
group of us to help Jim design the enhancements and I don't remember 
that any of our names really got associated with it nor did we care. 
;-)

At 17:26 -0800 2009/11/22, Brian Dear wrote:
>I've had folks tell me they built, or they heard about others who 
>built, talk-like programs in the 60s, to let two people talk live, 
>character by character, back and forth.  (There may have been one on 
>PLATO III in the '60s, I'll have to dig through my oral history 
>transcripts.)  It doesn't surprise me in the least that others had 
>hacked together simple talk programs on other systems.  Heck, people 
>have been yakkin' over the wires since the days of the telegraph.
>
>One thing I've learned is that when it comes to software and 
>hardware, somebody else always had the idea earlier, and whenever 
>one cites X as the first date of an instance of Y, someone else will 
>come along with an earlier example, and then a third person -- and 
>it sometimes takes years -- identifies an even earlier example.  For 
>example, lots of people often cite Vannevar Bush's 1940s article as 
>the original idea of hypertext.  I would argue that Edward Thorndike 
>offered just as compelling a vision in 1912.
>
>My point with the PLATO citations is that as far as I'm concerned, 
>these were the first uses of these online activities at a 
>significant scale, thousands of users.   What is hard for many folks 
>to grasp is the scale of PLATO -- relative to all of the users 
>connected to ARPANET, PLATO had more users for at least a decade.
>
>- Brian
>
>
>
>On 22 Nov 2009, at 16:32, John Day wrote:
>
>>And along these lines, Brian can correct me because even though 
>>PLATO was a block down Springfield Ave, I personally didn't have 
>>that much contact with them.  Others in our group did.
>>
>>The earliest AIM, messaging I am aware of was Jim Calvin's Tenex 
>>hack that we used on the ARPANet in 1972.  I still have transcripts 
>>of some of those evenings or did.  We called it teleconferencing in 
>>those days, but it was basically AIM.  I could go back and look but 
>>Jim had hacked the Tenex command that let you share "screens." (The 
>>early version let everyone speak at once and the characters would 
>>be interleaved. After he got it running, he quickly started adding 
>>all sorts of features.  (I may even have the documentation 
>>somewhere). We had been using almost nightly to chat and discuss 
>>"big ideas" and I believe that people got wind of it and it was 
>>included in the ICCC 72 demo of the ARPANet.  After that there were 
>>a spate of papers on "teleconferencing" at some conferences. 
>>Again, it was messaging, not what we call teleconferencing today.
>>
>>Also in early 1976, we used a PLATO plasma screen to which a touch 
>>panel was added interfaced to an LSI/11 as a single use 
>>"intelligent terminal."  The LSI/11 was running a stripped down 
>>version of UNIX that we created called EUNIX.  It was either an 
>>early X-Windows or an early PC depending on your point of view. 
>>The first version was used with a land use planning system that 
>>displayed maps of the 6 counties around Chicago down to the 
>>township (6  by 6 sections) and section level (a square mile) with 
>>land use data stored on 2 databases on either coast and accessed 
>>over the ARPANET.  There was a keyboard for major text entry but 
>>interface was primarily driven by touching the screen.  Data could 
>>be searched, displayed, combined and otherwise manipulated and 
>>displayed in graphs and maps.
>>
>>A version was also created for the DoD that was used in DC and Hawaii.
>>
>>Take care,
>>John
>>
>>At 13:09 -0800 2009/11/22, Brian Dear wrote:
>>>The SixRevisions article, as well as The Guardian's recent online 
>>>coverage of the "history of the Internet", both get numerous 
>>>things wrong.  The fundamental problem is that you can't do a 
>>>"history of the Internet" and then talk about the earliest 
>>>examples of various online phenomena, because many of the online 
>>>firsts did NOT happen on the Internet or its precursors like 
>>>ARPANET.
>>>
>>>* "1979: MUD - The earliest form of multiplayer games"
>>>This is simply wrong.   The PLATO system had a thriving community 
>>>of game players and game developers who created multiplayer games 
>>>years before "MUD" was developed.  "MUD" is in fact not even the 
>>>first MUD.   A multiplayer spacewar game was developed by Rick 
>>>Blomme on PLATO III around 1969.  Then on PLATO IV starting in 
>>>1972 a whole rash of multiplayer games popped up, like Dogfight, 
>>>Fishwar, and other "big board" games (the whole notion of online 
>>>multiplayer Big Boards, where you could go see who was waiting to 
>>>play a game with you, started on PLATO).   In the following three 
>>>years games became even more sophisticated, like the famous 
>>>Airfight by Brand Fortner, a genuine shoot'em'up dogfight airplane 
>>>game supporting 16 players, that was the inspiration for Bruce 
>>>Artwick (both Fortner and Artwick attended the U of Illinois) who 
>>>went on to create on of the biggest games in history --- Microsoft 
>>>Flight Simulator.   Then there were a whole slew of mutliuser 
>>>dungeon type games, including pedit5, oubliette, Avatar, Moria, 
>>>Emprise, dnd, and so on.  None of it on Internet or ARPANET.
>>>
>>>* 1978: The first bulletin board system
>>>This may be technically true but it ignores the real point that in 
>>>1973 the Institute for the Future had its FORUM system on ARPANET, 
>>>and at the same time PLATO Notes came out, the a full-fledged 
>>>message board system.  PLATO Notes inspired Ray Ozzie (now Chief 
>>>Software Architect of Microsoft) to create Lotus Notes.
>>>
>>>* 1982: The first emoticon.
>>>The real history is that emoticons were far richer and more 
>>>graphically complex BEFORE 1982.  It's one o those weird Darwinian 
>>>twists, where the earlier organism was far more complex but lived 
>>>in a single environment and couldn't exist anywhere but.  On 
>>>PLATO, you could superimpose one typed character onto another, or 
>>>even a bunch of characters, and in so doing create very 
>>>sophisticated emoticons. See platopeople.com/emoticons.html for 
>>>screen shots.
>>>
>>>* 1985: Virtual communities
>>>Way way inaccurate, and again, probably copied from The Guardian's 
>>>piece which also pushed this myth.  The WELL (which I have been a 
>>>member of since 1986) was a relative latecomer to the world of 
>>>online communities if you compare it to PLATO, which in 1973 had 
>>>notesfiles (message forums), chat rooms, and instant messaging.  
>>>The WELL wouldn't exist for another dozen years.
>>>
>>>As for writing a dissertation on the development of online chat 
>>>and IRC, if you want to be accurate you better include PLATO 
>>>because it pre-dates AIM, IRC, and the Unix "talk" command.   Go 
>>>research the history of PLATO's TERM-talk (1973) and Talk-o-Matic 
>>>(1973) if you want to know about the earliest history of instant 
>>>messaging and multi-user chat rooms.
>>>
>>>- Brian
>>>
>>>
>>>Brian Dear
>>>PLATO History Project
>>>La Jolla, California



From lpress at csudh.edu  Sun Nov 22 18:00:14 2009
From: lpress at csudh.edu (Larry Press)
Date: Sun, 22 Nov 2009 18:00:14 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <1F4994B2-64A2-4623-8B63-7A943E93459F@platohistory.org>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>	<a0624089cc72f6ca29508@[10.0.1.20]>
	<1F4994B2-64A2-4623-8B63-7A943E93459F@platohistory.org>
Message-ID: <4B09ECAE.3030302@csudh.edu>



Brian Dear wrote:

 > I've had folks tell me they built, or they heard about others who
 > built, talk-like programs in the 60s, to let two people talk live,

Messaging and email capabilities existed within the community of users 
of timesharing systems in those days -- I worked on the Q32 TSS at SDC 
and we could send each other messages (I think the command was called 
"mail") and we could also chat, though it was not called that.


> of hypertext.  I would argue that Edward Thorndike offered just as  
> compelling a vision in 1912.

Have you got a reference on that?  (Preferably online).

Lar



From marty at martylyons.com  Sun Nov 22 18:21:42 2009
From: marty at martylyons.com (Marty Lyons)
Date: Sun, 22 Nov 2009 18:21:42 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <a0624089cc72f6ca29508@[10.0.1.20]>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<a0624089cc72f6ca29508@[10.0.1.20]>
Message-ID: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>


On Nov 22, 2009, at 4:32 PM, John Day wrote:

> The earliest AIM, messaging I am aware of was Jim Calvin's Tenex  
> hack that we used on the ARPANet in 1972.

I have a paper on this very topic that I'm hoping to soon submit to  
IEEE Annals, which I first wrote for a graduate class here at the  
University of Washington in 2006.  I was fortunate enough to be able  
to track down many of the authors of early terminal to terminal  
communications.   As best as I was able to determine, the first  
instance of a terminal to terminal interaction appears to be ".SAVED/ 
WRITE" which was part of CTSS in 1965, and authored by Tom Van Vleck,  
Noel Morris, and Robert R. Fenichel.

In 1965, on the SDS-940, Deutsch and Lampson wrote the "LINK" command  
to allow two terminals to directly communicate.  "DIAL" appeared in  
1966 on the Q-32 as noted by R. Linde and P. Chaney.  DTSS in 1968  
(until it was removed from service) allowed linked terminals, which  
was authored by Sidney Marshall.

Dan Murphy noted a local terminal-terminal feature on TENEX in 1970,  
and in 1970 (or 1974, the date is unsure), Bob Frankston implemented  
"send_message" on Multics.  The "write" command appeared in Unix in  
1971.   As John notes, TENEX appears to be the first to have  
implemented a true inter-system chat, in 1972.

The first instance of this type of capability in a commercial system  
appears to be IBM's CP/67 Release 3 (approximately November 1970) in  
the CP "MSG" command.   David Tuttle and Lynn Wheeler, two of the  
principal authors of the code were kind enough to share their  
recollections in personal email (I'm not sure if either of them is on  
the list).  At that time, the "MSG" command was intra-system only.

PLATO had the first multi-user chat with "Talkomatic" in the fall of  
1973 (written by Doug Brown).  PLATO also supported direct inter-user  
local messaging with "term talk".

Shortly afterwards, remote messaging appears in Multics in 1974 with  
"net_atalk" (written by Kenneth T. Pogran).   And in January of 1975  
(VM Release 2 PLC 11), IBM VM supported remote system chat using the  
"RSCS CMD / TELL" commands over bisync connections (noted by Melinda  
Varian).   The "talk" command in Unix with remote system support seems  
to have arrived in 1983.

So in terms of ARPANET connected inter-system messaging, TENEX in  
1972, Multics in 1974, and Unix in 1983 seems to be how things evolved.

If anyone would like a copy of the current paper, please drop me a  
note.   It's quite "rough around the edges" since it was an academic  
work, produced under deadline, and could easily have filled twice the  
length; it became apparent even while writing it the whole thing would  
need to be reworked for clarity.   I'm hoping the Annals submission  
will be much more readable.

Marty

(an EIES programmer from NJIT in the early '80s -- thanks to Larry for  
remembering us :)


From jeanjour at comcast.net  Sun Nov 22 18:25:09 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 22 Nov 2009 21:25:09 -0500
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B09ECAE.3030302@csudh.edu>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<a0624089cc72f6ca29508@[10.0.1.20]>
	<1F4994B2-64A2-4623-8B63-7A943E93459F@platohistory.org>
	<4B09ECAE.3030302@csudh.edu>
Message-ID: <a062408a2c72fa18ffc77@[10.0.1.20]>

Yes, most definitely.  I think you will find that many of the 
timesharing systems of the period had a mail command of some sort. 
The overall game in the early ARPANET was simply to re-create on the 
Net everything we had on an OS.  This was really the gist of the 
proposals that USING made including good ole NETED, a network common 
editor.  Moving these things from a single computer to a network, in 
some sense doing them one level removed, often lead to new insights 
although most of them were never written down.

Also it should be noted that in most of these early implementations 
the mail box was a file not a directory.  Mail was appended to the 
file, rather than creating a new file for each piece of mail.




At 18:00 -0800 2009/11/22, Larry Press wrote:
>Brian Dear wrote:
>
>>  I've had folks tell me they built, or they heard about others who
>>  built, talk-like programs in the 60s, to let two people talk live,
>
>Messaging and email capabilities existed within the community of 
>users of timesharing systems in those days -- I worked on the Q32 
>TSS at SDC and we could send each other messages (I think the 
>command was called "mail") and we could also chat, though it was not 
>called that.
>
>>of hypertext.  I would argue that Edward Thorndike offered just as 
>>compelling a vision in 1912.
>
>Have you got a reference on that?  (Preferably online).
>
>Lar



From lpress at csudh.edu  Sun Nov 22 18:38:45 2009
From: lpress at csudh.edu (Larry Press)
Date: Sun, 22 Nov 2009 18:38:45 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<a0624089cc72f6ca29508@[10.0.1.20]>
	<AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
Message-ID: <4B09F5B5.6010400@csudh.edu>



Marty Lyons wrote:

> "DIAL" appeared in  
> 1966 on the Q-32 as noted by R. Linde and P. Chaney.

If DIAL was the chat-like command to send a message to a specific user 
in which you had to know the ID number of the TTY they were using 
(instead of a user name), I think it already existed in 1965 when I 
started using the Q32.

> (an EIES programmer from NJIT in the early '80s -- thanks to Larry for  
> remembering us :)

I remember it fondly -- we did a "teleconference on teleconferencing" 
which ran for some time and was written up in a document that I still 
have -- totally cool and inspiring even at 10 CPS on a TTY.

Lar


From jeanjour at comcast.net  Sun Nov 22 19:15:20 2009
From: jeanjour at comcast.net (John Day)
Date: Sun, 22 Nov 2009 22:15:20 -0500
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<a0624089cc72f6ca29508@[10.0.1.20]>
	<AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
Message-ID: <a062408a6c72fad12af35@[10.0.1.20]>

>
>
>Dan Murphy noted a local terminal-terminal feature on TENEX in 1970, 
>and in 1970 (or 1974, the date is unsure), Bob Frankston implemented 
>"send_message" on Multics.  The "write" command appeared in Unix in 
>1971.   As John notes, TENEX appears to be the first to have 
>implemented a true inter-system chat, in 1972.

If I remember right, it was the advent of FTP mail on multics that 
generated the need to add append as a permission to the usual read, 
write, execute. (Or at least I remember Pogran telling me something 
that gave me that impression. And I am pretty sure it was Pogran and 
not Padlipsky for some reason. MAP was telling me other things!  ;-) 
)  Multics was always concerned about security and as I noted 
earlier, the mailbox in FTP viewed as a file not a directory.  They 
didn't want to give the mail program "write" access, but "append" was 
right.

If my remembrance is correct then it must have been 74 because mail 
wasn't put into FTP until March 1973.  If it was there for a mutlics 
only command then it could have been 71.

Take care,
John


From spedraja at gmail.com  Sun Nov 22 23:58:28 2009
From: spedraja at gmail.com (SPC)
Date: Mon, 23 Nov 2009 08:58:28 +0100
Subject: [ih] We can hang up now, it's all done. (Sergio Pedraja)
Message-ID: <f7f1e0d30911222358j33dd6bdco96220e7745b70f74@mail.gmail.com>

I consider myself very young to speak properly about facts I heared years
later. I use to keep information about Classic Computing and ARPANET in
particular for two reasons: my own interest, and the preparation of my
end-of-degree work. But this is another story.

I put an aye in the brief resume list object of this discussion. And, well,
it only this, a brief list. And this kind of works use to forget EVER
something important for someone, with two characteristics: something more
important in perspective now and not in the moment of its assembly; or
something important now for someone in the context of its way in the life.

I prefer to see these matters in a positive perspective: for example, I
should encounter *very* useful a brief list with some main hits chained with
other previous and derivatives. The MUD case, for example, could be a good
example. I can't doubt about the antecedents of this application, but it
would be useful for me to emphasize MUD (perhaps because it's more well
known in comparison) and link it with the PLATO system mention.

And of course, it's the fact of the inexistence of the perfect chronological
list :-)

Regards
Sergio Pedraja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091123/f11e7cba/attachment.htm>

From jnc at mercury.lcs.mit.edu  Mon Nov 23 06:35:48 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 23 Nov 2009 09:35:48 -0500 (EST)
Subject: [ih] We can hang up now, it's all done.
Message-ID: <20091123143548.D47036BE591@mercury.lcs.mit.edu>

    > From: Marty Lyons <marty at martylyons.com>

    > I have a paper on this very topic 

To try and extend the record a bit, ITS had an early one, too - the 'ITS
Reference Manual 1.5' (1969) records a ":SEND" command, but I don't know how
much earlier than that it was actually done. Since ITS was done by people
familiar with CTSS, no doubt the CTSS one was the progenitor.

If you want a copy of that ITS manual, it's available as a (scanned) document
from MIT. There's a link to it on the Wikipedia ITS page:

  http://en.wikipedia.org/wiki/Incompatible_Timesharing_System

(One cannot of course depend on any Wikipedia article, but if you don't know
much about ITS it's a good place to start; at the moment it's more-or-less as
I left it, when I worked on it.)

Later ITS had much more complex intercommunication tools. I remember one
(whose name I forget) where one's screen was divided into two (or more?)
parts, and what one typed appeared in one half, and the other person's typing
in the other half. No idea when that dates from, either, though.

	Noel


From johnl at iecc.com  Mon Nov 23 09:34:17 2009
From: johnl at iecc.com (John Levine)
Date: 23 Nov 2009 17:34:17 -0000
Subject: [ih] Instant messaging, was We can hang up now, it's all done.
In-Reply-To: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
Message-ID: <20091123173417.43564.qmail@simone.iecc.com>

>The first instance of this type of capability in a commercial system  
>appears to be IBM's CP/67 Release 3 (approximately November 1970) in  
>the CP "MSG" command.

When I was in high school I was able to use the dial-in time-sharing
service from Applied Logic, a local service bureau that ran first on a
PDP-6 and later PDP-10 in Princeton NJ, using heavily modified
versions of DEC's operating system later known as TOPS-10.

They had a TALK command at least as early as 1968 that let you type
from one terminal to another, which would be a candidate for first
commercial offering.  I recall using it to ask the operator to set
aside printouts so I could bike over after school and pick them up.

R's,
John


From dhc2 at dcrocker.net  Mon Nov 23 11:29:38 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 23 Nov 2009 11:29:38 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B09F5B5.6010400@csudh.edu>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>	<a0624089cc72f6ca29508@[10.0.1.20]>	<AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
	<4B09F5B5.6010400@csudh.edu>
Message-ID: <4B0AE2A2.4010902@dcrocker.net>



Larry Press wrote:
> I remember it fondly -- we did a "teleconference on teleconferencing" 
> which ran for some time and was written up in a document that I still 
> have -- totally cool and inspiring even at 10 CPS on a TTY.


That was run at ISI in the Summer of 1976 (maybe 1975) as I recall.  My 
soon-to-be professor at USC's Annenburg School of Communications put it 
together.  And yes, it was a very interesting discussion.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From dhc2 at dcrocker.net  Mon Nov 23 11:33:33 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 23 Nov 2009 11:33:33 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>	<a0624089cc72f6ca29508@[10.0.1.20]>
	<AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
Message-ID: <4B0AE38D.2050500@dcrocker.net>



Marty Lyons wrote:
> On Nov 22, 2009, at 4:32 PM, John Day wrote:
>> The earliest AIM, messaging I am aware of was Jim Calvin's Tenex hack 
>> that we used on the ARPANet in 1972.
...
>      As
> best as I was able to determine, the first instance of a terminal to 
> terminal interaction appears to be ".SAVED/WRITE" which was part of CTSS 
> in 1965, and authored by Tom Van Vleck, Noel Morris, and Robert R. 
> Fenichel.


That timeframe matches the various stories I've heard over the years.

By 1969 it was a pretty common feature in anything that supported two or more 
simultaneous users.  I remember using a talk-like feature on a small proprietary 
t/s system my brother was working on then.  (I don't remember whether this was 
the effort that Vint also worked on.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From mc at hack.org  Mon Nov 23 11:49:44 2009
From: mc at hack.org (Michael Widerkrantz)
Date: Mon, 23 Nov 2009 20:49:44 +0100
Subject: [ih] We can hang up now, it's all done.
References: <20091123143548.D47036BE591@mercury.lcs.mit.edu>
Message-ID: <86fx85qaw7.fsf@brain.hack.org>

jnc at mercury.lcs.mit.edu (Noel Chiappa), 2009-11-23 15:35 (+0100):

> If you want a copy of that ITS manual, it's available as a (scanned) document
> from MIT. There's a link to it on the Wikipedia ITS page:
>
>   http://en.wikipedia.org/wiki/Incompatible_Timesharing_System

Thanks to work by David Carter the document is also available as plain
text and some other formats here:

  http://www.sigfs.org/its-reference/

Incidentally, I was the one who asked a librarian at the AI lab to scan
the document in the first place. I'm sorry I don't remember the name of
the person who did this. Thanks, anyway.

> (One cannot of course depend on any Wikipedia article, but if you
> don't know much about ITS it's a good place to start; at the moment
> it's more-or-less as I left it, when I worked on it.)

Bj?rn Victor has some additional material on getting ITS to run on the
KLH-10 emulator here:

  http://victor.se/bjorn/its/

and some additional material on UP, an ITS machine!

  http://up.update.uu.se/

Although the web server doesn't seem to answer just this moment. Bj?rn
has written a web server in MacLisp.

Paul Svensson has also written a web server, but in MIDAS, IIRC. His
machine used to be available as

  http://sv.svensson.org/

but it doesn't answer any longer, although it does reply to ping.

-- 
M.C. Widerkrantz, http://hack.org/mc/
Plain text e-mail, please. OpenPGP welcome.



From dhc2 at dcrocker.net  Mon Nov 23 12:03:16 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 23 Nov 2009 12:03:16 -0800
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B097C14.2030101@csudh.edu>
References: <4B01D8CD.7090702@cox.net>
	<4B08F065.4010406@dcrocker.net>	<4B096D25.3000608@cox.net>
	<4B097C14.2030101@csudh.edu>
Message-ID: <4B0AEA84.40709@dcrocker.net>



Larry Press wrote:
>> But I am sad to see no mention of Gopher and Archie (and hytelnet) which 
> Don't forget Veronica and Jughead.
>> I believe had to have been the beginnings of the World Wide Web.
> 
> Where does anything begin?  Hypertext was preceded by linear text and 
> was foreshadowed in Vannevar Bush's article "As We May Think." Folks 
> like Ted Nelson and Ben Shneiderman built tools (TIES) and popularized 
> the idea.  As far as I know, gopher was first on the Net, 

I usually characterize gopher as the way-station between anonymous FTP and the 
web.  In other words, an open-access means of publishing things.

Bush did a mind-altering think-piece.  Nelson did some core research. 
Engelbart[1] produced a running service that was relied on for doing on-going 
work.  All of these fed into the Web and office tools we now use, whether the 
later developers knew it or not.

In terms of a distributed, running open-access publication service on the Net, 
Anonymous FTP was the beginning of the Web.

Archie should probably be credited as the first of the search services, in 
parallel to the publishing service.



Larry Press wrote:
 >> * 1978: The first bulletin board system
 >> This may be technically true but it ignores the real point that in
 >> 1973 the Institute for the Future had its FORUM system on ARPANET,
...
 > EIES from New Jersey Institute of Technology also existed in the mid 1970s.


EIES and Forum were separate follow-on efforts, after the first remote 
conferencing system was developed to assist in management of the 1972 gas crisis.


d/

[1] Remember that the public demonstration of Engelbart's work was 1968. My 
understanding is that most of his work from then to the early 70s was porting to 
a new platform, and refining.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From LarrySheldon at cox.net  Mon Nov 23 12:23:35 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 23 Nov 2009 14:23:35 -0600
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B0AE38D.2050500@dcrocker.net>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>	<a0624089cc72f6ca29508@[10.0.1.20]>	<AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
	<4B0AE38D.2050500@dcrocker.net>
Message-ID: <4B0AEF47.5030609@cox.net>

Dave CROCKER wrote:
> 
> 
> Marty Lyons wrote:
>> On Nov 22, 2009, at 4:32 PM, John Day wrote:
>>> The earliest AIM, messaging I am aware of was Jim Calvin's Tenex hack 
>>> that we used on the ARPANet in 1972.
> ...
>>      As
>> best as I was able to determine, the first instance of a terminal to 
>> terminal interaction appears to be ".SAVED/WRITE" which was part of 
>> CTSS in 1965, and authored by Tom Van Vleck, Noel Morris, and Robert 
>> R. Fenichel.
> 
> 
> That timeframe matches the various stories I've heard over the years.
> 
> By 1969 it was a pretty common feature in anything that supported two or 
> more simultaneous users.  I remember using a talk-like feature on a 
> small proprietary t/s system my brother was working on then.  (I don't 
> remember whether this was the effort that Vint also worked on.)

I'm sure my remebery is of a period in the late 70's or 80's, but the 
UNIVAC EXEC 8 OS had terminal-to-console, console-to-console, and 
console-to-terminal (and I think terminal-to-terminal).

And then in the latter years, there was Sperrylink.

-- 
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information:
	http://tinyurl.com/4sqczs
	http://tinyurl.com/7tp8ml
	


From dhc2 at dcrocker.net  Mon Nov 23 13:13:16 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 23 Nov 2009 13:13:16 -0800
Subject: [ih] emoticons
In-Reply-To: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
Message-ID: <4B0AFAEC.5060502@dcrocker.net>



Brian Dear wrote:
> ? 1982: The first emoticon.
> The real history is that emoticons were far richer and more graphically 
> complex BEFORE 1982.  


Could be interesting to try to amass anecdotes about early efforts in this area.

Around 1973 I was using a Tenex system -- probably ISI's -- for an IM chat with 
my brother (I was on the West Coast and he as still at Arpa in DC) and whatever 
it was that he typed, I decided to feign being extremely upset about it.  I 
remember being really amused at my cleverness and had a huge grin as I typed my 
supposed how upset I was, to him.

He immediately typed back massive apologies and regret, and it dawned on me that 
he couldn't see my smile.

He and I then chatted about communication of affect over a typing channel and 
came up with some symbols, like -U- for a smile and -M- for a smirk (or perhaps 
that was a frown.)

I suspect there are many equivalent stories.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From dhc2 at dcrocker.net  Mon Nov 23 13:14:35 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 23 Nov 2009 13:14:35 -0800
Subject: [ih] virtual communities
In-Reply-To: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
Message-ID: <4B0AFB3B.8070608@dcrocker.net>



Brian Dear wrote:
> ? 1985: Virtual communities
> Way way inaccurate, and again, probably copied from The Guardian's piece 
> which also pushed this myth.  The WELL (which I have been a member of 
> since 1986) was a relative latecomer to the world of online communities 
> if you compare it to PLATO, which in 1973 had notesfiles (message 
> forums), chat rooms, and instant messaging.  The WELL wouldn't exist for 
> another dozen years.


net-based mailing lists were active by around 74 or 75, initially for discussion 
about email.  it was immediately clear that each list created a community of 
interest.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From LarrySheldon at cox.net  Mon Nov 23 13:30:21 2009
From: LarrySheldon at cox.net (Larry Sheldon)
Date: Mon, 23 Nov 2009 15:30:21 -0600
Subject: [ih] virtual communities
In-Reply-To: <4B0AFB3B.8070608@dcrocker.net>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<4B0AFB3B.8070608@dcrocker.net>
Message-ID: <4B0AFEED.9050709@cox.net>

Dave CROCKER wrote:
> 
> 
> Brian Dear wrote:
>> ? 1985: Virtual communities
>> Way way inaccurate, and again, probably copied from The Guardian's 
>> piece which also pushed this myth.  The WELL (which I have been a 
>> member of since 1986) was a relative latecomer to the world of online 
>> communities if you compare it to PLATO, which in 1973 had notesfiles 
>> (message forums), chat rooms, and instant messaging.  The WELL 
>> wouldn't exist for another dozen years.
> 
> 
> net-based mailing lists were active by around 74 or 75, initially for 
> discussion about email.  it was immediately clear that each list created 
> a community of interest.

When did USENET arise?  I'm pretty sure it was UUCP-based (not IP-based) 
when I first heard of it in the WELL days, but I don't know the dates.

-- 
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information:
	http://tinyurl.com/4sqczs
	http://tinyurl.com/7tp8ml
	


From AMaitland at Commerco.Com  Mon Nov 23 13:36:55 2009
From: AMaitland at Commerco.Com (Alan J Maitland)
Date: Mon, 23 Nov 2009 14:36:55 -0700
Subject: [ih] Instant messaging, was We can hang up now, it's all  done.
In-Reply-To: <20091123173417.43564.qmail@simone.iecc.com>
References: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
	<20091123173417.43564.qmail@simone.iecc.com>
Message-ID: <6.2.3.4.2.20091123133004.04a97560@MS1.MailSys.Net>

I had access to an HP2000F (an HP1000 with Time Shared Basic) in high 
school (around the mid 1970s) via a 10 baud teletype (not quite 
Internet ready, but I'll always remember paper tape dot fights with 
fondness).  I seem to recall a TELL or TELLOP style command on that system.

Also, the NYU physics department HP3000CX (first released circa 1972 
or 1974 depending on which release you would count) certainly did 
have both TELL (session to session messaging) and TELLOP (session to 
operator messaging) commands in 1978, though I think that was part of 
the MPE FOS from its earliest days.

Although the HP3000 gravitated to a more commercial focus over time 
(HPMail, then HPDesk - email messaging as well as other accounting 
and manufacturing apps), it did have some interesting scientific 
applications which trace back to the 1970s.  One of those which comes 
to mind (specialized imaging software) ended up also getting ported 
over to the DEC VAX, though it continued to be offered and supported 
on both platforms.

I really enjoy this list because it triggers so many fond 
memories.  I think it just remarkable how far things have come during 
the past 35 years or so.

Best,

Alan

At 10:34 AM 11/23/2009, John Levine wrote:
> >The first instance of this type of capability in a commercial system
> >appears to be IBM's CP/67 Release 3 (approximately November 1970) in
> >the CP "MSG" command.
>
>When I was in high school I was able to use the dial-in time-sharing
>service from Applied Logic, a local service bureau that ran first on a
>PDP-6 and later PDP-10 in Princeton NJ, using heavily modified
>versions of DEC's operating system later known as TOPS-10.
>
>They had a TALK command at least as early as 1968 that let you type
>from one terminal to another, which would be a candidate for first
>commercial offering.  I recall using it to ask the operator to set
>aside printouts so I could bike over after school and pick them up.
>
>R's,
>John



From randy at psg.com  Mon Nov 23 15:06:17 2009
From: randy at psg.com (Randy Bush)
Date: Tue, 24 Nov 2009 08:06:17 +0900
Subject: [ih] virtual communities
In-Reply-To: <4B0AFEED.9050709@cox.net>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<4B0AFB3B.8070608@dcrocker.net> <4B0AFEED.9050709@cox.net>
Message-ID: <m2einodeom.wl%randy@psg.com>

> When did USENET arise?  I'm pretty sure it was UUCP-based (not IP-based) 
> when I first heard of it in the WELL days, but I don't know the dates.

From: Steven Bellovin <smb at cs.columbia.edu>
Subject: Re: [ih] virtual communities
To: Randy Bush <randy at psg.com>
Date: Mon, 23 Nov 2009 17:50:48 -0500

We had it running in late '79 (first my 150 line shell script, then a C
version that was never released past UNC and Duke), and announced it
(with Steve Daniel's code) in Jan '80 at what became Usenix -- see
http://www.usenix.org/about/history/ Yes, it was dial-up only; UNC and
Duke used home-built autodialers.  I forget the design of the Duke one,
though it came first; I had a cleaner design, which I had the dept's
electronic tech to build: it did software timing of the DTR line to
drive a relay opening/closing the phone line of a phone whose handset
was sitting in an acoustic coupler.  DN-11s were pricey and you had to
rent the compatible dialer from the telco; other autodial modems were
very rare back then, not all that long after Carterphone.  Building our
own was much cheaper and didn't involve getting the faculty to pay for
an extra monthly bill, and the 60 hz clock interrupt on our 11/45 had
just enough precision to do sofwtare-controlled pulse dialing --
slightly out of spec (which I think was 60/40 make/break at 10
pulses/second; we did 67/33, i.e., 4 ticks/2 ticks) but it worked.

Yes, Plato Notes was earlier, but it was captive to an organization and
closed; Usenet was always open to all comers.  In fact, eventually
someone wrote a gateway from Notes to it.

Mark Horton at Berkeley started feeding in ARPANET mailing lists and
relaying between the two networks around '81 or '82; I forget.

Feel free to forward.


From johnl at iecc.com  Mon Nov 23 21:32:22 2009
From: johnl at iecc.com (John Levine)
Date: 24 Nov 2009 05:32:22 -0000
Subject: [ih] We can hang up now, it's all done.
In-Reply-To: <4B0AEA84.40709@dcrocker.net>
Message-ID: <20091124053222.17555.qmail@simone.iecc.com>

>I usually characterize gopher as the way-station between anonymous
>FTP and the web.  In other words, an open-access means of publishing
>things.

For me, the aha moment was when I saw a gopher menu that had entries
from five different servers, making the location of stuff if not
totally irrelevant, at least separate from the navigation.

Anonymous FTP was (and is) plenty useful, but first you tell it where
you want to go, and then what you want once you're there.

R's,
John


From mbaer at cs.tu-berlin.de  Tue Nov 24 17:21:55 2009
From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=)
Date: Wed, 25 Nov 2009 02:21:55 +0100
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <4B0C86B3.3020106@cs.tu-berlin.de>

Hi all,

I was wondering if anyone here knows closely of the precise history of
how the raw message facility of the Arpanet came about and in which ways
it relates to early voice (NVP) and TCP experiments in the mid-1970s. I
gather from the 1822 report (and a couple of other BBN reports from
around 1974 to 1978) that hosts could send uncontrolled messages (one
packet messages at that) that would be delivered without paranoid error
control IMP-to-IMP and without RFNMs and retransmissions. However (!),
BBN would control whether or not hosts could use that facility in the
first place. From the 1822 report (as of 1976,
http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf):

"Uncontrolled use of these messages will degrade the
performance of the network for all users.  Therefore,
ability to use these messages will be regulated by the
Network Control Center and will require prior arrange-
ment for each experiment."
(p. 3-36)

My questions are:

1. What experiments or actual applications did people do with the raw
messages? The papers on early network voice stuff indicate that three or
four host sites where playing around with that. What about TCP?

2. How does this Arpanet feature relate to TCP and the ARPA agenda from
around 1973/1974 of pushing development of TCP? Am I right in thinking
that the first TCP experiments must have involved using the raw messages
facility?

3. How did BBN actually control sites' use of the feature? And, what
were the experiences with congestion (as in congesting intermediary
nodes, as well as in overwhelming the destination IMP/host)?

4. How did those experiments (provided the link that I am here assuming
exists) feed into actual TCP developments?

5. Last, the TCP/IP split is often ascribed somewhat to common sense
(proper modularization, see e.g. IEN 2), and particularly the canonical
example of interactive voice. But how does the actual availability of a
"best effort" transport facility at Arpanet (the raw message facility)
relate to the later notion of an IP protocol (which, too, provides an
effective service guarantee of zero; and comes with all the congestion
problems that will require the hosts to well behave)?

Thanks for any suggestions, pointers and accounts on this. Also, I am
told Bob Kahn would be a good person to ask on this, maybe someone here
can reach out to him on this.

Best,
Matthias

-- 
Matthias B?rwolff
www.b?rwolff.de



From vint at google.com  Tue Nov 24 17:53:36 2009
From: vint at google.com (Vint Cerf)
Date: Tue, 24 Nov 2009 20:53:36 -0500
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <d97c701ca6d72$1a463af0$4ed2b0d0$@com>

Danny has a good bit of this story. V

----- Original Message -----
From: internet-history-bounces at postel.org
<internet-history-bounces at postel.org>
To: internet history <internet-history at postel.org>
Sent: Tue Nov 24 20:21:55 2009
Subject: [ih] Arpanet raw messages, voice, and TCP

Hi all,

I was wondering if anyone here knows closely of the precise history of
how the raw message facility of the Arpanet came about and in which ways
it relates to early voice (NVP) and TCP experiments in the mid-1970s. I
gather from the 1822 report (and a couple of other BBN reports from
around 1974 to 1978) that hosts could send uncontrolled messages (one
packet messages at that) that would be delivered without paranoid error
control IMP-to-IMP and without RFNMs and retransmissions. However (!),
BBN would control whether or not hosts could use that facility in the
first place. From the 1822 report (as of 1976,
http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf):

"Uncontrolled use of these messages will degrade the
performance of the network for all users.  Therefore,
ability to use these messages will be regulated by the
Network Control Center and will require prior arrange-
ment for each experiment."
(p. 3-36)

My questions are:

1. What experiments or actual applications did people do with the raw
messages? The papers on early network voice stuff indicate that three or
four host sites where playing around with that. What about TCP?

2. How does this Arpanet feature relate to TCP and the ARPA agenda from
around 1973/1974 of pushing development of TCP? Am I right in thinking
that the first TCP experiments must have involved using the raw messages
facility?

3. How did BBN actually control sites' use of the feature? And, what
were the experiences with congestion (as in congesting intermediary
nodes, as well as in overwhelming the destination IMP/host)?

4. How did those experiments (provided the link that I am here assuming
exists) feed into actual TCP developments?

5. Last, the TCP/IP split is often ascribed somewhat to common sense
(proper modularization, see e.g. IEN 2), and particularly the canonical
example of interactive voice. But how does the actual availability of a
"best effort" transport facility at Arpanet (the raw message facility)
relate to the later notion of an IP protocol (which, too, provides an
effective service guarantee of zero; and comes with all the congestion
problems that will require the hosts to well behave)?

Thanks for any suggestions, pointers and accounts on this. Also, I am
told Bob Kahn would be a good person to ask on this, maybe someone here
can reach out to him on this.

Best,
Matthias

-- 
Matthias B?rwolff
www.b?rwolff.de



From ronda.netizen at gmail.com  Tue Nov 24 17:59:49 2009
From: ronda.netizen at gmail.com (Ronda Hauben)
Date: Tue, 24 Nov 2009 20:59:49 -0500
Subject: [ih] virtual communities
In-Reply-To: <4B0AFEED.9050709@cox.net>
References: <3290D267-16FC-4DFC-BC58-1D9E29154E0C@platohistory.org>
	<4B0AFB3B.8070608@dcrocker.net> <4B0AFEED.9050709@cox.net>
Message-ID: <ecb9aa080911241759j40d21059lbf3d2c448c80ed89@mail.gmail.com>

Hi larry

For some of the history of Usenet, see:

    See Part II THE EVOLUTION OF USENET: THE POOR MAN'S ARPANET

                     http://www.columbia.edu/~rh120/ch106.x02

                                        and
               ON THE EARLY DAYS OF USENET:
           THE ROOTS OF THE COOPERATIVE ONLINE CULTURE
            http://www.columbia.edu/~rh120/ch106.x10


These are chapters in the book "Netizens: On the History and Impact of
Usenet and the Internet'
by Michael Hauben and Ronda Hauben, put onlne in 1994 and published in a
print edition by
IEEE Computer Society in 1997.

The url for the online version is http://www.columbia.edu/~rh120

cheers

Ronda


On Mon, Nov 23, 2009 at 4:30 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:

>  Dave CROCKER wrote:
>
>>
>>
>> Brian Dear wrote:
>>
>>> ? 1985: Virtual communities
>>> Way way inaccurate, and again, probably copied from The Guardian's piece
>>> which also pushed this myth.  The WELL (which I have been a member of since
>>> 1986) was a relative latecomer to the world of online communities if you
>>> compare it to PLATO, which in 1973 had notesfiles (message forums), chat
>>> rooms, and instant messaging.  The WELL wouldn't exist for another dozen
>>> years.
>>>
>>
>>
>> net-based mailing lists were active by around 74 or 75, initially for
>> discussion about email.  it was immediately clear that each list created a
>> community of interest.
>>
>
> When did USENET arise?  I'm pretty sure it was UUCP-based (not IP-based)
> when I first heard of it in the WELL days, but I don't know the dates.
>
> --
>



-- 
Netizens: On the History and Impact of Usenet and the Internet

http://www.columbia.edu/~hauben/netbook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091124/3d9492e6/attachment.htm>

From lpress at csudh.edu  Tue Nov 24 19:13:43 2009
From: lpress at csudh.edu (Larry Press)
Date: Tue, 24 Nov 2009 19:13:43 -0800
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <4B0C86B3.3020106@cs.tu-berlin.de>
References: <4B0C86B3.3020106@cs.tu-berlin.de>
Message-ID: <4B0CA0E7.2050901@csudh.edu>

> 1. What experiments or actual applications did people do with the raw


You can see a 1978 demo at:

http://www.youtube.com/watch?v=MGat1jRQ_SM

Larry




From jack at 3kitty.org  Tue Nov 24 23:28:55 2009
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 24 Nov 2009 23:28:55 -0800
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <4B0C86B3.3020106@cs.tu-berlin.de>
References: <4B0C86B3.3020106@cs.tu-berlin.de>
Message-ID: <1259134135.3284.62.camel@localhost>

Hi Matthias,

Good questions.  I was at BBN in the 1978-1990 timeframe, part of Frank
Heart's division which among other things did the Arpanet and much of
the early TCP implementations.  I did the first PDP-11 Unix
implementation and others working with me did the initial HP3000,
PDP-11/44, Vax-unix, TAC, and others, as well as the "core gateways".
Bill Plummer (who I know monitors this list sometimes) did the PDP-10
TCP from his perch in "Division 4".

As far as I can remember, none of those implementations used the Arpanet
raw message facility.  There was a lot of effort put into dealing with
RFNM counting, but nothing I remember did anything with raw messages.

The raw messages were motivated primarily by the packet voice work,
where it was more important to get a packet through quickly than to get
all the packets through too late to deliver as voice.  The ARPANet
standard RFNM-machinery was appropriate only for getting all packets
delivered ... eventually.

I remember that there was significant concern in the "Arpanet group"
about protecting the network from raw messages used improperly by hosts.
A sending host could easily keep the network flooded with packets that
were being discarded at the destination IMP if the host at that end
wouldn't take them.  That concern about network disruption probably
helped keep using raw messages off the list of features to use in TCP
(and gateway) mechanisms.

The only exception might have been using them to send control messages
to get around a "blocked" path - e.g., so that the "gateway NOC" could
at least tell a gateway to reboot if it had gotten stuck to the point
that regular Arpanet traffic to it was RFNM-blocked.  Can't remember if
that was ever implemented though.

Somebody else will have to comment about the voice work - that's where
I'd expect that the raw messages might have been used.  A lot of the
voice work was on the Wideband Net rather than the ARPAnet.

The NOC at BBN had quite a lot of control over network hosts, and could
shut off particular interfaces (physical ports) on an IMP if some host
was severely misbehaving.  I'm not sure how often that was needed,
probably not much.  I believe it was used at some point shortly after a
new release of BSD Unix which had a demon program that methodically
PINGed all known gateways to maintain a connectivity/delay map of the
Internet.  This caused lots of one-packet Arpanet messages to get
sprayed across the Arpanet - a traffic pattern very unlike the
traditional Telnet or FTP sessions.  That pattern caused internal uproar
and the only way to shut it down was to turn off the IMP ports of the
offending hosts - which weren't really doing anything "illegal" but
nonetheless caused disruptions to other host traffic.

I don't recall the "raw message" discussions feeding much at all into
TCP.  However, it did motivate the creation of UDP, and the split of
TCP2 into TCP/IP version 4.

There was much discussion at the time about where the functions of
reliability, congestion control, priority, etc., should be implemented.
In the Arpanet, much of that was performed by the IMP-IMP internal
machinery - essentially hosts saw virtual circuits.  Gateway (and TCP)
implementations were allowed to freely discard IP packets, and the
responsibility for reliability etc. was placed on the hosts.  At first
it was largely irrelevant, since most Internet paths were
host-LAN-ARPANET-LAN-host, and the Arpanet was the "weak link" in terms
of capacity, but the internal Arpanet mechanisms compensated so the
hosts' behavior wasn't that critical.  

Later after gateway-gateway circuits were introduced it became a
different game, but I think by then the implementations were
sophisticated enough to handle it.  At least that's what we surmised.
There really wasn't enough instrumentation available to see what was
happening - e.g., how many of the packets a host sends on a TCP
connection actually make it to the other end, how many are
retransmitted, how many duplicates are received, etc.

In the 90s, when I was at Oracle, I put some instrumentation into the
corporate worldwide net and took a look.  There were lots of anomalies.
E.G., an FTP would be running fine, then there would be disruption
(circuit glitch, congestion dropped packets, etc.), and then things
would settle back down.  But after the glitch, the FTP throughput, on
the same connection, was cut in half compared to the original, and most
packets were being received twice at the destination.  The host
algorithms to do retransmission timer backoff or whatever had settled
into a new stable state where everything worked fine as seen by the user
- but the network traffic had doubled.  Not so good on a very expensive
line from the US to Singapore!  We had some discussions with the
computer vendors about the quality of their host network software...they
didn't have a clue it was happening.

That was more than a decade ago, but has anything changed?   So, maybe
the jury is still out on whether or not the "well behaved host" approach
of the Internet is working as well as the "keep the hosts out of the
network machinery" approach of the Arpanet.

HTH,
/Jack


On Wed, 2009-11-25 at 02:21 +0100, Matthias B?rwolff wrote:
> Hi all,
> 
> I was wondering if anyone here knows closely of the precise history of
> how the raw message facility of the Arpanet came about and in which ways
> it relates to early voice (NVP) and TCP experiments in the mid-1970s. I
> gather from the 1822 report (and a couple of other BBN reports from
> around 1974 to 1978) that hosts could send uncontrolled messages (one
> packet messages at that) that would be delivered without paranoid error
> control IMP-to-IMP and without RFNMs and retransmissions. However (!),
> BBN would control whether or not hosts could use that facility in the
> first place. From the 1822 report (as of 1976,
> http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf):
> 
> "Uncontrolled use of these messages will degrade the
> performance of the network for all users.  Therefore,
> ability to use these messages will be regulated by the
> Network Control Center and will require prior arrange-
> ment for each experiment."
> (p. 3-36)
> 
> My questions are:
> 
> 1. What experiments or actual applications did people do with the raw
> messages? The papers on early network voice stuff indicate that three or
> four host sites where playing around with that. What about TCP?
> 
> 2. How does this Arpanet feature relate to TCP and the ARPA agenda from
> around 1973/1974 of pushing development of TCP? Am I right in thinking
> that the first TCP experiments must have involved using the raw messages
> facility?
> 
> 3. How did BBN actually control sites' use of the feature? And, what
> were the experiences with congestion (as in congesting intermediary
> nodes, as well as in overwhelming the destination IMP/host)?
> 
> 4. How did those experiments (provided the link that I am here assuming
> exists) feed into actual TCP developments?
> 
> 5. Last, the TCP/IP split is often ascribed somewhat to common sense
> (proper modularization, see e.g. IEN 2), and particularly the canonical
> example of interactive voice. But how does the actual availability of a
> "best effort" transport facility at Arpanet (the raw message facility)
> relate to the later notion of an IP protocol (which, too, provides an
> effective service guarantee of zero; and comes with all the congestion
> problems that will require the hosts to well behave)?
> 
> Thanks for any suggestions, pointers and accounts on this. Also, I am
> told Bob Kahn would be a good person to ask on this, maybe someone here
> can reach out to him on this.
> 
> Best,
> Matthias
> 



From latzko-toth.guillaume at uqam.ca  Wed Nov 25 13:34:53 2009
From: latzko-toth.guillaume at uqam.ca (Guillaume Latzko-Toth)
Date: Wed, 25 Nov 2009 16:34:53 -0500
Subject: [ih] Instant messaging
In-Reply-To: <6.2.3.4.2.20091123133004.04a97560@MS1.MailSys.Net>
References: <AFF4778F-FD92-4632-92AF-CEF83EF13BC8@martylyons.com>
	<20091123173417.43564.qmail@simone.iecc.com>
	<6.2.3.4.2.20091123133004.04a97560@MS1.MailSys.Net>
Message-ID: <BLU0-SMTP841C4B674DBBE7BF5CB0849C9C0@phx.gbl>

At 16:36 2009-11-23, Alan J Maitland wrote:
>I really enjoy this list because it triggers so 
>many fond memories.  I think it just remarkable 
>how far things have come during the past 35 years or so.

It's a pleasure and quite fascinating for me to 
see the excitement about the topic of online chat 
and the early days of instant messaging. Some of 
you mentioned that they had interesting documents 
on the subject; I would be very grateful if they 
could send them to me if they are not available online.

I was not myself very happy with some rough 
"shortcuts" found in the chronology published in 
Six Revisions. In particular with this one:
>Also in 1988, Internet Relay Chat (IRC) was 
>first deployed, paving the way for real-time 
>chat and the instant messaging programs we use today.

In a way, it's not completely untrue, in the 
sense that the wide diffusion of IRC probably 
contributed a lot to make Internet chat become 
mainstream. However, as Brian Dear said before, 
IRC was by far not the first system of its kind, 
and did not really *paved the way* to online chat 
as did EMISARI Party-Line (1971), PLATO 
Talkomatic (1973), CompuServe CB Simulator 
(1980), and BITNET Relay (1985) before it.

What IRC did even less is "paving the way for... 
the instant messaging programs". Simply because 
IRC and IM systems belong, IMHO, to two very 
different classes of computer-mediated 
communication devices. IRC belongs to the 
"conference management" type, while IM is more a 
"copresence" management system. While the former 
kind of chat systems are meant to create 
synchronous (pseudo-)anonymous social spaces or 
"places" (chatrooms) designed to foster 
sociability and encourage serendipity in social 
contacts, IM systems correspond to a very 
different communication pattern, centered around 
inviduals and their personal networks.

Furthermore, IM comprises other functions than 
the near-synchrounous transmission of brief 
messages (so called "instant messages"), such as 
the notification of recipient about the delivery 
of a new message and presence/availability 
awareness and management associated with the 
"contact list". Indeed, the instant message as a 
communicational genre or format should be 
distinguished from instant messaging (IM) as a 
practice or social media. Obviously, these 
distinctions were not clear in the 60s and 70s: 
the technology was there, social uses had yet to emerge.

As far as I know, the first implementation of IM 
is due to Anthony DellaFera and colleagues 
(1988), who figured out the specifications of the 
"notification system" in the frame of the Athena 
Project at MIT [see: 
http://www.rfrench.org/papers/usenix.pdf ]. This 
effort led to what is deemed the first IM system, 
Zephyr, deployed at MIT and a few other 
universities. The fundamental principle 
underlying this class of devices is that the flux 
of messages is centered around a person (via 
his/her identifyier), rather than around a place 
(a server address). It?s up to the system to 
locate the recipient in the distributed environment.

If you would like to read more about the 
distinction between "conference" and "copresence" 
chat systems, and how the latter "paradigm" tends 
to takeover these days, I can send you the draft 
of a paper I have submitted to the Bulletin of 
Science & Technology Studies. All comments would be welcome.

Best,
Guillaume


------------
Guillaume Latzko-Toth
Ph.D. candidate in Communication Studies
Universit? du Qu?bec ? Montr?al
http://grm.uqam.ca/?q=latzko




From braden at ISI.EDU  Wed Nov 25 14:24:23 2009
From: braden at ISI.EDU (Bob Braden)
Date: Wed, 25 Nov 2009 14:24:23 -0800
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <mailman.3.1259179202.11074.internet-history@postel.org>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
Message-ID: <4B0DAE97.8060402@isi.edu>


My memory was that BBN included type 3 (Uncontrolled or "raw") messages 
in the IMP protocol as an experiment, which they then considered too 
dangerous to use . BBN disabled them at (almost?) all hosts (almost?) 
all the time, I believe.  TCP/IP used standard reliably-delivered IMP 
traffic. But the facility must have been enabled for the packet voice 
experiments shown in that marvelous video.

My memory on this point is hazy, but probably Vint can correct me. When 
Barry Leiner became (D)ARPA Program Manager for the Internet research 
program, he became determined that BBN should try using Type 3 IMP-IMP 
packets for normal TCP/IP flows. He complained to the ICCB/IAB that BBN 
was resisting.  He insisted that the experiment be tried for 24 hours. 
Unfortunately I don't recall that the experiment ever happened;
it is more than possible that BBN stone-walled his demand.

Bob Braden
'



From richard at bennett.com  Wed Nov 25 15:05:06 2009
From: richard at bennett.com (Richard Bennett)
Date: Wed, 25 Nov 2009 15:05:06 -0800
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <4B0DAE97.8060402@isi.edu>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu>
Message-ID: <4B0DB822.7010200@bennett.com>

I've discussed this issue recently with a key member of the IMP team at 
BBN and he (unsurprisingly) has a very different recollection of the 
facts. A datagram mode was added to the IMP and to X.25 switches fairly 
early. Datagrams appeared on research networks well before TCP/IP was 
defined; CYCLADES had them in 1972.

The BBN people have not been able to tell me whether the NWG ever took 
advantage of the datagram mode in the IMP; that was outside their 
department.

RB

Bob Braden wrote:
>
> My memory was that BBN included type 3 (Uncontrolled or "raw") 
> messages in the IMP protocol as an experiment, which they then 
> considered too dangerous to use . BBN disabled them at (almost?) all 
> hosts (almost?) all the time, I believe.  TCP/IP used standard 
> reliably-delivered IMP traffic. But the facility must have been 
> enabled for the packet voice experiments shown in that marvelous video.
>
> My memory on this point is hazy, but probably Vint can correct me. 
> When Barry Leiner became (D)ARPA Program Manager for the Internet 
> research program, he became determined that BBN should try using Type 
> 3 IMP-IMP packets for normal TCP/IP flows. He complained to the 
> ICCB/IAB that BBN was resisting.  He insisted that the experiment be 
> tried for 24 hours. Unfortunately I don't recall that the experiment 
> ever happened;
> it is more than possible that BBN stone-walled his demand.
>
> Bob Braden
> '
>

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC



From vint at google.com  Wed Nov 25 15:45:30 2009
From: vint at google.com (Vint Cerf)
Date: Wed, 25 Nov 2009 18:45:30 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <4B0DB822.7010200@bennett.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
Message-ID: <98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>

the type 3 packets were explicitly used for real-time packet voice and  
later packet video experiments. This would have been in the 1975 time  
frame (but Danny Cohen and Steve Casner would know for sure as they  
were at ISI; Lincoln Labs was also involved and we used their packet  
digitizers/compressors. Duane Adams managed the packet voice activity  
during the time I was at DARPA so I am copying him too. I don't seem  
to have steve casner's email but I think he is now at PARC.

vint




On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:

> I've discussed this issue recently with a key member of the IMP team  
> at BBN and he (unsurprisingly) has a very different recollection of  
> the facts. A datagram mode was added to the IMP and to X.25 switches  
> fairly early. Datagrams appeared on research networks well before  
> TCP/IP was defined; CYCLADES had them in 1972.
>
> The BBN people have not been able to tell me whether the NWG ever  
> took advantage of the datagram mode in the IMP; that was outside  
> their department.
>
> RB
>
> Bob Braden wrote:
>>
>> My memory was that BBN included type 3 (Uncontrolled or "raw")  
>> messages in the IMP protocol as an experiment, which they then  
>> considered too dangerous to use . BBN disabled them at (almost?)  
>> all hosts (almost?) all the time, I believe.  TCP/IP used standard  
>> reliably-delivered IMP traffic. But the facility must have been  
>> enabled for the packet voice experiments shown in that marvelous  
>> video.
>>
>> My memory on this point is hazy, but probably Vint can correct me.  
>> When Barry Leiner became (D)ARPA Program Manager for the Internet  
>> research program, he became determined that BBN should try using  
>> Type 3 IMP-IMP packets for normal TCP/IP flows. He complained to  
>> the ICCB/IAB that BBN was resisting.  He insisted that the  
>> experiment be tried for 24 hours. Unfortunately I don't recall that  
>> the experiment ever happened;
>> it is more than possible that BBN stone-walled his demand.
>>
>> Bob Braden
>> '
>>
>
> -- 
> Richard Bennett
> Research Fellow
> Information Technology and Innovation Foundation
> Washington, DC
>



From jeanjour at comcast.net  Wed Nov 25 16:14:15 2009
From: jeanjour at comcast.net (John Day)
Date: Wed, 25 Nov 2009 19:14:15 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
Message-ID: <a062408f5c73378914a44@[10.0.1.20]>

Yea, that jibes with my recollection.

And "datagrams" were in the first version of X.25 in 76, or was that 
Fast Select?


At 18:45 -0500 2009/11/25, Vint Cerf wrote:
>the type 3 packets were explicitly used for real-time packet voice 
>and later packet video experiments. This would have been in the 1975 
>time frame (but Danny Cohen and Steve Casner would know for sure as 
>they were at ISI; Lincoln Labs was also involved and we used their 
>packet digitizers/compressors. Duane Adams managed the packet voice 
>activity during the time I was at DARPA so I am copying him too. I 
>don't seem to have steve casner's email but I think he is now at 
>PARC.
>
>vint
>
>
>
>
>On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>
>>I've discussed this issue recently with a key member of the IMP 
>>team at BBN and he (unsurprisingly) has a very different 
>>recollection of the facts. A datagram mode was added to the IMP and 
>>to X.25 switches fairly early. Datagrams appeared on research 
>>networks well before TCP/IP was defined; CYCLADES had them in 1972.
>>
>>The BBN people have not been able to tell me whether the NWG ever 
>>took advantage of the datagram mode in the IMP; that was outside 
>>their department.
>>
>>RB
>>
>>Bob Braden wrote:
>>>
>>>My memory was that BBN included type 3 (Uncontrolled or "raw") 
>>>messages in the IMP protocol as an experiment, which they then 
>>>considered too dangerous to use . BBN disabled them at (almost?) 
>>>all hosts (almost?) all the time, I believe.  TCP/IP used standard 
>>>reliably-delivered IMP traffic. But the facility must have been 
>>>enabled for the packet voice experiments shown in that marvelous 
>>>video.
>>>
>>>My memory on this point is hazy, but probably Vint can correct me. 
>>>When Barry Leiner became (D)ARPA Program Manager for the Internet 
>>>research program, he became determined that BBN should try using 
>>>Type 3 IMP-IMP packets for normal TCP/IP flows. He complained to 
>>>the ICCB/IAB that BBN was resisting.  He insisted that the 
>>>experiment be tried for 24 hours. Unfortunately I don't recall 
>>>that the experiment ever happened;
>>>it is more than possible that BBN stone-walled his demand.
>>>
>>>Bob Braden
>>>'
>>>
>>
>>--
>>Richard Bennett
>>Research Fellow
>>Information Technology and Innovation Foundation
>>Washington, DC



From richard at bennett.com  Wed Nov 25 16:16:52 2009
From: richard at bennett.com (Richard Bennett)
Date: Wed, 25 Nov 2009 16:16:52 -0800
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
Message-ID: <4B0DC8F4.7000309@bennett.com>

That really is ironic. If the circuit-switched service in ARPA and X.25 
was good for anything at all, it should have been good for voice, but 
I'm guessing you guys tried voice over datagram over circuits and found 
it didn't work worth crap, probably because of high loss rates and 
excessive queuing inside the ARPANET. I also wonder of the type 3 
service didn't have the effect of boosting the priority of voice packets 
in some way.

Vint Cerf wrote:
> the type 3 packets were explicitly used for real-time packet voice and 
> later packet video experiments. This would have been in the 1975 time 
> frame (but Danny Cohen and Steve Casner would know for sure as they 
> were at ISI; Lincoln Labs was also involved and we used their packet 
> digitizers/compressors. Duane Adams managed the packet voice activity 
> during the time I was at DARPA so I am copying him too. I don't seem 
> to have steve casner's email but I think he is now at PARC.
>
> vint
>
>
>
>
> On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>
>> I've discussed this issue recently with a key member of the IMP team 
>> at BBN and he (unsurprisingly) has a very different recollection of 
>> the facts. A datagram mode was added to the IMP and to X.25 switches 
>> fairly early. Datagrams appeared on research networks well before 
>> TCP/IP was defined; CYCLADES had them in 1972.
>>
>> The BBN people have not been able to tell me whether the NWG ever 
>> took advantage of the datagram mode in the IMP; that was outside 
>> their department.
>>
>> RB
>>
>> Bob Braden wrote:
>>>
>>> My memory was that BBN included type 3 (Uncontrolled or "raw") 
>>> messages in the IMP protocol as an experiment, which they then 
>>> considered too dangerous to use . BBN disabled them at (almost?) all 
>>> hosts (almost?) all the time, I believe.  TCP/IP used standard 
>>> reliably-delivered IMP traffic. But the facility must have been 
>>> enabled for the packet voice experiments shown in that marvelous video.
>>>
>>> My memory on this point is hazy, but probably Vint can correct me. 
>>> When Barry Leiner became (D)ARPA Program Manager for the Internet 
>>> research program, he became determined that BBN should try using 
>>> Type 3 IMP-IMP packets for normal TCP/IP flows. He complained to the 
>>> ICCB/IAB that BBN was resisting.  He insisted that the experiment be 
>>> tried for 24 hours. Unfortunately I don't recall that the experiment 
>>> ever happened;
>>> it is more than possible that BBN stone-walled his demand.
>>>
>>> Bob Braden
>>> '
>>>
>>
>> -- 
>> Richard Bennett
>> Research Fellow
>> Information Technology and Innovation Foundation
>> Washington, DC
>>
>

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC



From jeanjour at comcast.net  Wed Nov 25 17:02:15 2009
From: jeanjour at comcast.net (John Day)
Date: Wed, 25 Nov 2009 20:02:15 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <4B0DC8F4.7000309@bennett.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<4B0DC8F4.7000309@bennett.com>
Message-ID: <a062408f9c7338354cff4@[10.0.1.20]>

Not priority at all.  The lines were flaky enough that the 
reliability required by the connections (for both the ARPANET and 
X.25) created with hop-by-hop retransmissions at the data link layer 
created sufficient delay and jitter that you couldn't do voice. 
There was no way to get a connection-oriented unreliable service.

After all, the argument for packet switching (made by Baran) was that 
data was not like voice.  Data required reliability, short 
connections, and was bursty.  So a network was built do that.


At 16:16 -0800 2009/11/25, Richard Bennett wrote:
>That really is ironic. If the circuit-switched service in ARPA and 
>X.25 was good for anything at all, it should have been good for 
>voice, but I'm guessing you guys tried voice over datagram over 
>circuits and found it didn't work worth crap, probably because of 
>high loss rates and excessive queuing inside the ARPANET. I also 
>wonder of the type 3 service didn't have the effect of boosting the 
>priority of voice packets in some way.
>
>Vint Cerf wrote:
>>the type 3 packets were explicitly used for real-time packet voice 
>>and later packet video experiments. This would have been in the 
>>1975 time frame (but Danny Cohen and Steve Casner would know for 
>>sure as they were at ISI; Lincoln Labs was also involved and we 
>>used their packet digitizers/compressors. Duane Adams managed the 
>>packet voice activity during the time I was at DARPA so I am 
>>copying him too. I don't seem to have steve casner's email but I 
>>think he is now at PARC.
>>
>>vint
>>
>>
>>
>>
>>On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>
>>>I've discussed this issue recently with a key member of the IMP 
>>>team at BBN and he (unsurprisingly) has a very different 
>>>recollection of the facts. A datagram mode was added to the IMP 
>>>and to X.25 switches fairly early. Datagrams appeared on research 
>>>networks well before TCP/IP was defined; CYCLADES had them in 1972.
>>>
>>>The BBN people have not been able to tell me whether the NWG ever 
>>>took advantage of the datagram mode in the IMP; that was outside 
>>>their department.
>>>
>>>RB
>>>
>>>Bob Braden wrote:
>>>>
>>>>My memory was that BBN included type 3 (Uncontrolled or "raw") 
>>>>messages in the IMP protocol as an experiment, which they then 
>>>>considered too dangerous to use . BBN disabled them at (almost?) 
>>>>all hosts (almost?) all the time, I believe.  TCP/IP used 
>>>>standard reliably-delivered IMP traffic. But the facility must 
>>>>have been enabled for the packet voice experiments shown in that 
>>>>marvelous video.
>>>>
>>>>My memory on this point is hazy, but probably Vint can correct 
>>>>me. When Barry Leiner became (D)ARPA Program Manager for the 
>>>>Internet research program, he became determined that BBN should 
>>>>try using Type 3 IMP-IMP packets for normal TCP/IP flows. He 
>>>>complained to the ICCB/IAB that BBN was resisting.  He insisted 
>>>>that the experiment be tried for 24 hours. Unfortunately I don't 
>>>>recall that the experiment ever happened;
>>>>it is more than possible that BBN stone-walled his demand.
>>>>
>>>>Bob Braden
>>>>'
>>>>
>>>
>>>--
>>>Richard Bennett
>>>Research Fellow
>>>Information Technology and Innovation Foundation
>>>Washington, DC
>>>
>>
>
>--
>Richard Bennett
>Research Fellow
>Information Technology and Innovation Foundation
>Washington, DC



From jnc at mercury.lcs.mit.edu  Wed Nov 25 17:36:22 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 25 Nov 2009 20:36:22 -0500 (EST)
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <20091126013622.886B56BE5B5@mercury.lcs.mit.edu>

    > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>

    > I gather from the 1822 report .. that hosts could send uncontrolled
    > messages (one packet messages at that) that would be delivered without
    > paranoid error control IMP-to-IMP and without RFNMs and retransmissions.

This is probably not very useful/interesting, but I looked at the MIT/Proteon
router ARPANet interface code (which dates from circa 1981/2, if memory
serves), and it had no capability to send Uncontrolled (type 0, subtype 3)
mesaages. (It would correctly process any it received, though.)

    > What experiments or actual applications did people do with the raw
    > messages?

Note that Uncontrolled messages could not be longer than 1 IMP-IMP frame
(which was 1008 _bits_, IIRC). That's because to send a message longer than 1
IMP-IMP frame, the sending IMP had to first allocate a re-assembly buffer at
the destination IMP. Doing so would obviously be in conflict with the whole
goal of Uncontrolled messages (fast/cheap transmission), but a maximum packet
size of ~120 bytes would obviously not have been that much use for TCP/IP in
general.

	Noel


From vint at google.com  Wed Nov 25 21:32:41 2009
From: vint at google.com (Vint Cerf)
Date: Thu, 26 Nov 2009 00:32:41 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <4B0DC8F4.7000309@bennett.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<4B0DC8F4.7000309@bennett.com>
Message-ID: <88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>

Richard, ARPANET was not circuit switched in the traditional sense of  
the word. Packets were dynamically routed. There was end/end RFNM for  
flow control (that actually inhibited use of things like the TCP/IP  
window in the NCP protocol). Buffer space was reserved at the far end  
to deal with reassembly lockup. "get a block" "got a block" handshake  
assured that no multi-packet message would be initiated without  
adequate space in the destination IMP.  There was no priority for type  
3 packets. there was priority for ARPANET (IMP level) control packets.


On Nov 25, 2009, at 7:16 PM, Richard Bennett wrote:

> That really is ironic. If the circuit-switched service in ARPA and X. 
> 25 was good for anything at all, it should have been good for voice,  
> but I'm guessing you guys tried voice over datagram over circuits  
> and found it didn't work worth crap, probably because of high loss  
> rates and excessive queuing inside the ARPANET. I also wonder of the  
> type 3 service didn't have the effect of boosting the priority of  
> voice packets in some way.
>
> Vint Cerf wrote:
>> the type 3 packets were explicitly used for real-time packet voice  
>> and later packet video experiments. This would have been in the  
>> 1975 time frame (but Danny Cohen and Steve Casner would know for  
>> sure as they were at ISI; Lincoln Labs was also involved and we  
>> used their packet digitizers/compressors. Duane Adams managed the  
>> packet voice activity during the time I was at DARPA so I am  
>> copying him too. I don't seem to have steve casner's email but I  
>> think he is now at PARC.
>>
>> vint
>>
>>
>>
>>
>> On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>
>>> I've discussed this issue recently with a key member of the IMP  
>>> team at BBN and he (unsurprisingly) has a very different  
>>> recollection of the facts. A datagram mode was added to the IMP  
>>> and to X.25 switches fairly early. Datagrams appeared on research  
>>> networks well before TCP/IP was defined; CYCLADES had them in 1972.
>>>
>>> The BBN people have not been able to tell me whether the NWG ever  
>>> took advantage of the datagram mode in the IMP; that was outside  
>>> their department.
>>>
>>> RB
>>>
>>> Bob Braden wrote:
>>>>
>>>> My memory was that BBN included type 3 (Uncontrolled or "raw")  
>>>> messages in the IMP protocol as an experiment, which they then  
>>>> considered too dangerous to use . BBN disabled them at (almost?)  
>>>> all hosts (almost?) all the time, I believe.  TCP/IP used  
>>>> standard reliably-delivered IMP traffic. But the facility must  
>>>> have been enabled for the packet voice experiments shown in that  
>>>> marvelous video.
>>>>
>>>> My memory on this point is hazy, but probably Vint can correct  
>>>> me. When Barry Leiner became (D)ARPA Program Manager for the  
>>>> Internet research program, he became determined that BBN should  
>>>> try using Type 3 IMP-IMP packets for normal TCP/IP flows. He  
>>>> complained to the ICCB/IAB that BBN was resisting.  He insisted  
>>>> that the experiment be tried for 24 hours. Unfortunately I don't  
>>>> recall that the experiment ever happened;
>>>> it is more than possible that BBN stone-walled his demand.
>>>>
>>>> Bob Braden
>>>> '
>>>>
>>>
>>> -- 
>>> Richard Bennett
>>> Research Fellow
>>> Information Technology and Innovation Foundation
>>> Washington, DC
>>>
>>
>
> -- 
> Richard Bennett
> Research Fellow
> Information Technology and Innovation Foundation
> Washington, DC
>



From vint at google.com  Wed Nov 25 21:34:57 2009
From: vint at google.com (Vint Cerf)
Date: Thu, 26 Nov 2009 00:34:57 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <a062408f5c73378914a44@[10.0.1.20]>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<a062408f5c73378914a44@[10.0.1.20]>
Message-ID: <CA45FC8C-401A-4FBE-8AFC-3C93C672C791@google.com>

+ remi despres
+steve casner

John, I am pretty sure that X.25 did not have datagrams in the same  
sense as Cyclades/Cigale or even ARPANET. There was a fast select but  
I thought it came later rather than earlier in the X.25 story?

v

On Nov 25, 2009, at 7:14 PM, John Day wrote:

> Yea, that jibes with my recollection.
>
> And "datagrams" were in the first version of X.25 in 76, or was that  
> Fast Select?
>
>
> At 18:45 -0500 2009/11/25, Vint Cerf wrote:
>> the type 3 packets were explicitly used for real-time packet voice  
>> and later packet video experiments. This would have been in the  
>> 1975 time frame (but Danny Cohen and Steve Casner would know for  
>> sure as they were at ISI; Lincoln Labs was also involved and we  
>> used their packet digitizers/compressors. Duane Adams managed the  
>> packet voice activity during the time I was at DARPA so I am  
>> copying him too. I don't seem to have steve casner's email but I  
>> think he is now at PARC.
>>
>> vint
>>
>>
>>
>>
>> On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>
>>> I've discussed this issue recently with a key member of the IMP  
>>> team at BBN and he (unsurprisingly) has a very different  
>>> recollection of the facts. A datagram mode was added to the IMP  
>>> and to X.25 switches fairly early. Datagrams appeared on research  
>>> networks well before TCP/IP was defined; CYCLADES had them in 1972.
>>>
>>> The BBN people have not been able to tell me whether the NWG ever  
>>> took advantage of the datagram mode in the IMP; that was outside  
>>> their department.
>>>
>>> RB
>>>
>>> Bob Braden wrote:
>>>>
>>>> My memory was that BBN included type 3 (Uncontrolled or "raw")  
>>>> messages in the IMP protocol as an experiment, which they then  
>>>> considered too dangerous to use . BBN disabled them at (almost?)  
>>>> all hosts (almost?) all the time, I believe.  TCP/IP used  
>>>> standard reliably-delivered IMP traffic. But the facility must  
>>>> have been enabled for the packet voice experiments shown in that  
>>>> marvelous video.
>>>>
>>>> My memory on this point is hazy, but probably Vint can correct  
>>>> me. When Barry Leiner became (D)ARPA Program Manager for the  
>>>> Internet research program, he became determined that BBN should  
>>>> try using Type 3 IMP-IMP packets for normal TCP/IP flows. He  
>>>> complained to the ICCB/IAB that BBN was resisting.  He insisted  
>>>> that the experiment be tried for 24 hours. Unfortunately I don't  
>>>> recall that the experiment ever happened;
>>>> it is more than possible that BBN stone-walled his demand.
>>>>
>>>> Bob Braden
>>>> '
>>>>
>>>
>>> --
>>> Richard Bennett
>>> Research Fellow
>>> Information Technology and Innovation Foundation
>>> Washington, DC
>



From jeanjour at comcast.net  Thu Nov 26 05:50:32 2009
From: jeanjour at comcast.net (John Day)
Date: Thu, 26 Nov 2009 08:50:32 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<4B0DC8F4.7000309@bennett.com>
	<88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>
Message-ID: <a06240801c73435bb28df@[10.0.1.20]>

As with most early attempts they don't quite fit the categories that 
coalesce later.  The ARPANET was not as pure connection as X.25, but 
not pure datagram either.  Although, I remember one evening around 
74-75 Danthine sitting in my living room insisting that the ARPANET 
was not a datagram network!  ;-)  But then that was Danthine.

Did the Xmas lock up occur because they were multi-packet control 
messages and not subject to the end-to-end RFNM in NCP?

If I remember right, weren't there also hop-by-hop RFNMs in the 
IMP-IMP protocol?

Which brings up another question.  I had always thought that X.25 
originated mostly with the French PTT.  I have heard stories that the 
Telenet guys had a strong hand in its design.  What is the case?

At 0:32 -0500 2009/11/26, Vint Cerf wrote:
>Richard, ARPANET was not circuit switched in the traditional sense 
>of the word. Packets were dynamically routed. There was end/end RFNM 
>for flow control (that actually inhibited use of things like the 
>TCP/IP window in the NCP protocol). Buffer space was reserved at the 
>far end to deal with reassembly lockup. "get a block" "got a block" 
>handshake assured that no multi-packet message would be initiated 
>without adequate space in the destination IMP.  There was no 
>priority for type 3 packets. there was priority for ARPANET (IMP 
>level) control packets.
>
>
>On Nov 25, 2009, at 7:16 PM, Richard Bennett wrote:
>
>>That really is ironic. If the circuit-switched service in ARPA and 
>>X.25 was good for anything at all, it should have been good for 
>>voice, but I'm guessing you guys tried voice over datagram over 
>>circuits and found it didn't work worth crap, probably because of 
>>high loss rates and excessive queuing inside the ARPANET. I also 
>>wonder of the type 3 service didn't have the effect of boosting the 
>>priority of voice packets in some way.
>>
>>Vint Cerf wrote:
>>>the type 3 packets were explicitly used for real-time packet voice 
>>>and later packet video experiments. This would have been in the 
>>>1975 time frame (but Danny Cohen and Steve Casner would know for 
>>>sure as they were at ISI; Lincoln Labs was also involved and we 
>>>used their packet digitizers/compressors. Duane Adams managed the 
>>>packet voice activity during the time I was at DARPA so I am 
>>>copying him too. I don't seem to have steve casner's email but I 
>>>think he is now at PARC.
>>>
>>>vint
>>>
>>>
>>>
>>>
>>>On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>>
>>>>I've discussed this issue recently with a key member of the IMP 
>>>>team at BBN and he (unsurprisingly) has a very different 
>>>>recollection of the facts. A datagram mode was added to the IMP 
>>>>and to X.25 switches fairly early. Datagrams appeared on research 
>>>>networks well before TCP/IP was defined; CYCLADES had them in 
>>>>1972.
>>>>
>>>>The BBN people have not been able to tell me whether the NWG ever 
>>>>took advantage of the datagram mode in the IMP; that was outside 
>>>>their department.
>>>>
>>>>RB
>>>>
>>>>Bob Braden wrote:
>>>>>
>>>>>My memory was that BBN included type 3 (Uncontrolled or "raw") 
>>>>>messages in the IMP protocol as an experiment, which they then 
>>>>>considered too dangerous to use . BBN disabled them at (almost?) 
>>>>>all hosts (almost?) all the time, I believe.  TCP/IP used 
>>>>>standard reliably-delivered IMP traffic. But the facility must 
>>>>>have been enabled for the packet voice experiments shown in that 
>>>>>marvelous video.
>>>>>
>>>>>My memory on this point is hazy, but probably Vint can correct 
>>>>>me. When Barry Leiner became (D)ARPA Program Manager for the 
>>>>>Internet research program, he became determined that BBN should 
>>>>>try using Type 3 IMP-IMP packets for normal TCP/IP flows. He 
>>>>>complained to the ICCB/IAB that BBN was resisting.  He insisted 
>>>>>that the experiment be tried for 24 hours. Unfortunately I don't 
>>>>>recall that the experiment ever happened;
>>>>>it is more than possible that BBN stone-walled his demand.
>>>>>
>>>>>Bob Braden
>>>>>'
>>>>>
>>>>
>>>>--
>>>>Richard Bennett
>>>>Research Fellow
>>>>Information Technology and Innovation Foundation
>>>>Washington, DC
>>>>
>>>
>>
>>--
>>Richard Bennett
>>Research Fellow
>>Information Technology and Innovation Foundation
>>Washington, DC



From mbaer at cs.tu-berlin.de  Thu Nov 26 06:19:39 2009
From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=)
Date: Thu, 26 Nov 2009 15:19:39 +0100
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <20091126013622.886B56BE5B5@mercury.lcs.mit.edu>
References: <20091126013622.886B56BE5B5@mercury.lcs.mit.edu>
Message-ID: <4B0E8E7B.2000205@cs.tu-berlin.de>



Noel Chiappa wrote:
>     > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>
>
>     > I gather from the 1822 report .. that hosts could send uncontrolled
>     > messages (one packet messages at that) that would be delivered without
>     > paranoid error control IMP-to-IMP and without RFNMs and retransmissions.
>
> This is probably not very useful/interesting, but I looked at the MIT/Proteon
> router ARPANet interface code (which dates from circa 1981/2, if memory
> serves), and it had no capability to send Uncontrolled (type 0, subtype 3)
> mesaages. (It would correctly process any it received, though.)
>   

Thanks, this is by no means "not very useful/interesting", in fact it is
one of the only data points on the issue I have yet come across.

>     > What experiments or actual applications did people do with the raw
>     > messages?
>
> Note that Uncontrolled messages could not be longer than 1 IMP-IMP frame
> (which was 1008 _bits_, IIRC). That's because to send a message longer than 1
> IMP-IMP frame, the sending IMP had to first allocate a re-assembly buffer at
> the destination IMP. Doing so would obviously be in conflict with the whole
> goal of Uncontrolled messages (fast/cheap transmission), but a maximum packet
> size of ~120 bytes would obviously not have been that much use for TCP/IP in
> general.
>   

I don't understand this. Even the 1974 Cerf/Kahn specification of TCP
knew of "breaking up messages into segments", because "the local network
may limit the maximum transmission size" and which are, in turn,
packaged into an internetwork packet. While hosts were eventually
expected to accept IP packets of at least 576 bytes, they sure can cope
with smaller packets, too (even, say, just the header). Why then would
126 bytes foreclose experimenting with TCP/IP?

I am aware that the uncontrolled mesages could not be multi-packet
messages. And, unlike ordinary single-packet messages they would not be
subject to the source-destination-IMP ack/retransmit facility. This is
precisely the reason why I would sort of consider them an early variant
(or at least a conceptual anticipation) of the later IP packets. And,
surely it must have been more fun playing around with higher level
end-to-end reliability in a network that actually does drop a packet
sometimes.

It would really by interesting to learn more about the ICCB/IAB versus
BBN clash on dropping TCP onto uncontrolled Arpanet messages, as alluded
to in the earlier Bob Braden email.

Matthias

> 	Noel
>   

-- 
Matthias B?rwolff
www.b?rwolff.de



From mbaer at cs.tu-berlin.de  Thu Nov 26 06:32:16 2009
From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=)
Date: Thu, 26 Nov 2009 15:32:16 +0100
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <a06240801c73435bb28df@[10.0.1.20]>
References: <mailman.3.1259179202.11074.internet-history@postel.org>	<4B0DAE97.8060402@isi.edu>
	<4B0DB822.7010200@bennett.com>	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>	<4B0DC8F4.7000309@bennett.com>	<88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>
	<a06240801c73435bb28df@[10.0.1.20]>
Message-ID: <4B0E9170.9070908@cs.tu-berlin.de>



John Day wrote:
> As with most early attempts they don't quite fit the categories that
> coalesce later.  The ARPANET was not as pure connection as X.25, but
> not pure datagram either.  Although, I remember one evening around
> 74-75 Danthine sitting in my living room insisting that the ARPANET
> was not a datagram network!  ;-)  But then that was Danthine.

>From the 1977 McQuillan/Walden paper, which surely must be one of the
most comprehensive and informed account on the Arpanet design, it
becomes fairly clear that it really was both -- at the IMP-IMP level it
was datagram (though with an error control, ack, and retransmit scheme
applied to every packet exchanged between any two IMPs), and at the
source-IMP-to-destination-IMP it was VC, featuring flow control,
reassembly of messages from a sequence of packets that may well have
arrived unordered and with duplicates in it (because individual packets
could take different paths, IMP-IMP retransmissions could delay
packets), etc.

>
> If I remember right, weren't there also hop-by-hop RFNMs in the
> IMP-IMP protocol?

That would be the error check, ack, and retransmit in case of missing
ack scheme, not a RFNM.



-- 
Matthias B?rwolff
www.b?rwolff.de



From vint at google.com  Thu Nov 26 06:38:55 2009
From: vint at google.com (Vint Cerf)
Date: Thu, 26 Nov 2009 09:38:55 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <a06240801c73435bb28df@[10.0.1.20]>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<4B0DC8F4.7000309@bennett.com>
	<88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>
	<a06240801c73435bb28df@[10.0.1.20]>
Message-ID: <618FE524-6831-4269-8D40-C67E6E0B4820@google.com>

1. ARPANET was a peculiar amalgam. It had a datagram interface for  
HOST MESSAGES (potentially multipacket objects, up to 8 IMP packets of  
1008 bits each). But it reserved space for multi-packet messages at  
the destination IMP before sending one - acting sort of like a  
connection setup - and did IMP-level retransmission of packets at link  
layer. The ROUTE of the packets was indeterminate in the sense that it  
was NOT set during "connection" (ie space reservation) set up. Dynamic  
alternate routing was a feature. No new MESSAGE (from the host) was  
permitted until the host received a Request for Next Message (RFNM)  
from its serving IMP. The IMPS did not themselves use RFNM between  
each other (unless a FAKE HOST was sending the message and even then,  
the RFNM went to the sending fake host, not between intermediate  
IMPs). MESSAGES were delivered in sequenced order, so in that sense,  
ARPANET acted as if it were offering a virtual circuit service. There  
was no retransmission from host to host with the NCP protocol because  
this reliability was provided by the ARPANET IMPs. I don't remember  
now whether lack of a RFNM triggered a retransmission from the  
originating IMP but it seems likely this was the case given that NCP  
didn't have a retransmission philosophy.

2. Larry Roberts pressed hard for a virtual circuit form of interface  
for Telenet because he felt that he could not "sell" datagram service.  
He thought he could sell "virtual circuit" service (sequenced  
delivery) as a substitute for dedicated circuits, but at a lower  
price. We debated this when I urged him to try TCP/IP but this was in  
the 1975 time frame and TCP was still unsplit from IP and very  
experimental. He engaged with Remi in France, and two others in the UK  
(John <something> at BT) and Canada (David? Horton at Datapac) to  
develop what became X.25.

3. The XMAS lockup was a consequence of a memory failure in the  
Harvard IMP that caused its "distance vector table" to report that it  
was zero hops from everywhere in the ARPANET so everyone sent all  
their traffic to Harvard and it crashed for lack of memory. I don't  
think this was a reassembly lockup since Harvard IMP was not the  
destination, just the intermediate hop.

On Nov 26, 2009, at 8:50 AM, John Day wrote:

> As with most early attempts they don't quite fit the categories that  
> coalesce later.  The ARPANET was not as pure connection as X.25, but  
> not pure datagram either.  Although, I remember one evening around  
> 74-75 Danthine sitting in my living room insisting that the ARPANET  
> was not a datagram network!  ;-)  But then that was Danthine.
>
> Did the Xmas lock up occur because they were multi-packet control  
> messages and not subject to the end-to-end RFNM in NCP?
>
> If I remember right, weren't there also hop-by-hop RFNMs in the IMP- 
> IMP protocol?
>
> Which brings up another question.  I had always thought that X.25  
> originated mostly with the French PTT.  I have heard stories that  
> the Telenet guys had a strong hand in its design.  What is the case?
>
> At 0:32 -0500 2009/11/26, Vint Cerf wrote:
>> Richard, ARPANET was not circuit switched in the traditional sense  
>> of the word. Packets were dynamically routed. There was end/end  
>> RFNM for flow control (that actually inhibited use of things like  
>> the TCP/IP window in the NCP protocol). Buffer space was reserved  
>> at the far end to deal with reassembly lockup. "get a block" "got a  
>> block" handshake assured that no multi-packet message would be  
>> initiated without adequate space in the destination IMP.  There was  
>> no priority for type 3 packets. there was priority for ARPANET (IMP  
>> level) control packets.
>>
>>
>> On Nov 25, 2009, at 7:16 PM, Richard Bennett wrote:
>>
>>> That really is ironic. If the circuit-switched service in ARPA and  
>>> X.25 was good for anything at all, it should have been good for  
>>> voice, but I'm guessing you guys tried voice over datagram over  
>>> circuits and found it didn't work worth crap, probably because of  
>>> high loss rates and excessive queuing inside the ARPANET. I also  
>>> wonder of the type 3 service didn't have the effect of boosting  
>>> the priority of voice packets in some way.
>>>
>>> Vint Cerf wrote:
>>>> the type 3 packets were explicitly used for real-time packet  
>>>> voice and later packet video experiments. This would have been in  
>>>> the 1975 time frame (but Danny Cohen and Steve Casner would know  
>>>> for sure as they were at ISI; Lincoln Labs was also involved and  
>>>> we used their packet digitizers/compressors. Duane Adams managed  
>>>> the packet voice activity during the time I was at DARPA so I am  
>>>> copying him too. I don't seem to have steve casner's email but I  
>>>> think he is now at PARC.
>>>>
>>>> vint
>>>>
>>>>
>>>>
>>>>
>>>> On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>>>
>>>>> I've discussed this issue recently with a key member of the IMP  
>>>>> team at BBN and he (unsurprisingly) has a very different  
>>>>> recollection of the facts. A datagram mode was added to the IMP  
>>>>> and to X.25 switches fairly early. Datagrams appeared on  
>>>>> research networks well before TCP/IP was defined; CYCLADES had  
>>>>> them in 1972.
>>>>>
>>>>> The BBN people have not been able to tell me whether the NWG  
>>>>> ever took advantage of the datagram mode in the IMP; that was  
>>>>> outside their department.
>>>>>
>>>>> RB
>>>>>
>>>>> Bob Braden wrote:
>>>>>>
>>>>>> My memory was that BBN included type 3 (Uncontrolled or "raw")  
>>>>>> messages in the IMP protocol as an experiment, which they then  
>>>>>> considered too dangerous to use . BBN disabled them at  
>>>>>> (almost?) all hosts (almost?) all the time, I believe.  TCP/IP  
>>>>>> used standard reliably-delivered IMP traffic. But the facility  
>>>>>> must have been enabled for the packet voice experiments shown  
>>>>>> in that marvelous video.
>>>>>>
>>>>>> My memory on this point is hazy, but probably Vint can correct  
>>>>>> me. When Barry Leiner became (D)ARPA Program Manager for the  
>>>>>> Internet research program, he became determined that BBN should  
>>>>>> try using Type 3 IMP-IMP packets for normal TCP/IP flows. He  
>>>>>> complained to the ICCB/IAB that BBN was resisting.  He insisted  
>>>>>> that the experiment be tried for 24 hours. Unfortunately I  
>>>>>> don't recall that the experiment ever happened;
>>>>>> it is more than possible that BBN stone-walled his demand.
>>>>>>
>>>>>> Bob Braden
>>>>>> '
>>>>>>
>>>>>
>>>>> --
>>>>> Richard Bennett
>>>>> Research Fellow
>>>>> Information Technology and Innovation Foundation
>>>>> Washington, DC
>>>>>
>>>>
>>>
>>> --
>>> Richard Bennett
>>> Research Fellow
>>> Information Technology and Innovation Foundation
>>> Washington, DC
>



From vint at google.com  Thu Nov 26 06:46:15 2009
From: vint at google.com (Vint Cerf)
Date: Thu, 26 Nov 2009 09:46:15 -0500
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <4B0E8E7B.2000205@cs.tu-berlin.de>
References: <20091126013622.886B56BE5B5@mercury.lcs.mit.edu>
	<4B0E8E7B.2000205@cs.tu-berlin.de>
Message-ID: <6A9908F6-A9E4-4CA8-8267-E95F67427F9C@google.com>


On Nov 26, 2009, at 9:19 AM, Matthias B?rwolff wrote:

>
>
> Noel Chiappa wrote:
>>> From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>
>>
>>> I gather from the 1822 report .. that hosts could send uncontrolled
>>> messages (one packet messages at that) that would be delivered  
>>> without
>>> paranoid error control IMP-to-IMP and without RFNMs and  
>>> retransmissions.
>>
>> This is probably not very useful/interesting, but I looked at the  
>> MIT/Proteon
>> router ARPANet interface code (which dates from circa 1981/2, if  
>> memory
>> serves), and it had no capability to send Uncontrolled (type 0,  
>> subtype 3)
>> mesaages. (It would correctly process any it received, though.)
>>
>
> Thanks, this is by no means "not very useful/interesting", in fact  
> it is
> one of the only data points on the issue I have yet come across.
>
>>> What experiments or actual applications did people do with the raw
>>> messages?
>>
>> Note that Uncontrolled messages could not be longer than 1 IMP-IMP  
>> frame
>> (which was 1008 _bits_, IIRC). That's because to send a message  
>> longer than 1
>> IMP-IMP frame, the sending IMP had to first allocate a re-assembly  
>> buffer at
>> the destination IMP. Doing so would obviously be in conflict with  
>> the whole
>> goal of Uncontrolled messages (fast/cheap transmission), but a  
>> maximum packet
>> size of ~120 bytes would obviously not have been that much use for  
>> TCP/IP in
>> general.
>>
>
> I don't understand this. Even the 1974 Cerf/Kahn specification of TCP
> knew of "breaking up messages into segments", because "the local  
> network
> may limit the maximum transmission size" and which are, in turn,
> packaged into an internetwork packet. While hosts were eventually
> expected to accept IP packets of at least 576 bytes, they sure can  
> cope
> with smaller packets, too (even, say, just the header). Why then would
> 126 bytes foreclose experimenting with TCP/IP?
There was a minimum size IP packet - 576 bytes - and that was too big
for the 1008 bit IMP packet size. So we did NOT try to run uncontrolled
messages in support of TCP/IP.
>
> I am aware that the uncontrolled mesages could not be multi-packet
> messages. And, unlike ordinary single-packet messages they would not  
> be
> subject to the source-destination-IMP ack/retransmit facility. This is
> precisely the reason why I would sort of consider them an early  
> variant
> (or at least a conceptual anticipation) of the later IP packets. And,
> surely it must have been more fun playing around with higher level
> end-to-end reliability in a network that actually does drop a packet
> sometimes.
we had no problem with that: packet radio, packet satellite and  
ethernets
as well as Bill Plummer's Flakeway gateway provided us with plenty of
opportunity to deal with packet loss.
>
> It would really by interesting to learn more about the ICCB/IAB versus
> BBN clash on dropping TCP onto uncontrolled Arpanet messages, as  
> alluded
> to in the earlier Bob Braden email.
I don't remember this "clash" as well as Bob seems to, so can't  
comment further.
>
> Matthias
>
>> 	Noel
>>
>
> -- 
> Matthias B?rwolff
> www.b?rwolff.de
>




From jnc at mercury.lcs.mit.edu  Thu Nov 26 08:12:30 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 11:12:30 -0500 (EST)
Subject: [ih] ARPAnet Type 3 packets (datagrams)
Message-ID: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>

    > From: Vint Cerf <vint at google.com>

A few clarifications/expansions...

    > it reserved space for multi-packet messages at the destination IMP
    > before sending one - acting sort of like a connection setup

To make explicit what's implicit here, single-frame (the term I use for the
IMP-IMP packets) messages were sent as their own request, so small host-host
messages did not see that delay.

    > did IMP-level retransmission of packets at link layer.

To be clear, I believe this was hop-by-hop, not end-to-end, but this is
from memory; I'm too lazy to go pull out the IFIPS IMP paper (and in any
case, this may have changed after the paper was written, but I would
classify that as unlikely, though).

Text in the 1822 specification (5/1978 edition, pp. 3-2) appears to verify
this, because it talks about getting an 'Incomplete Transmission' instead
of a RFNM if the message was "lost in the network due to an IMP failure";
one wouldn't need such a message if the source IMP still had a copy of the
message (or frame), which it could have re-transmitted on an end-end
basis, so the source IMP's copy must have been pitched after the next-hop
IMP had (locally) acknowledged it.

    > No new MESSAGE (from the host) was permitted until the host received
    > a Request for Next Message (RFNM) from its serving IMP.

Umm, not quite; a host was allowed to have up to 8 packets 'in flight' to
a given destination at a time (basically - there are more details).
Attempting to send a 9th before the RFNM for the first has been received
would cause the IMP to block the host (i.e. shut down the hand-shake
bit-serial interface in the Host->IMP direction) until the first RFNM for
that destination arrived. One could have up to 8 packets 'in flight' at a
time to more than one destination, too.

As I recall, the IMP might block you _anyway_, even at less than 8 to a
given destination, for flow-control reasons in the net (e.g. no free
buffers), but you were _guaranteed_ to get blocked at 9.

    > The IMPS did not themselves use RFNM between each other

The wording here could be confusing. According to 1822 (5/1978 edition,
pp. 3-2/3-3), IMPs did look for the RFNM from the far end (i.e. on an
end-end basis), and on a timeout would query the destination IMP
(repeatedly so) until it saw either a RGNM or Incomplete Transmission,
giving up only after 30 seconds or so.

    > I don't remember now whether lack of a RFNM triggered a
    > retransmission from the originating IMP

My supposition is that this would have been impossible, as it seems (see
above) that the source IMP discarded its copy of the message once the next-hop
IMP had acknowledged receipt of all the frames of it. (Whether this discarding
was frame-by-frame, or message-at-a-time, I have no idea.)

    Noel


From vint at google.com  Thu Nov 26 08:25:14 2009
From: vint at google.com (Vint Cerf)
Date: Thu, 26 Nov 2009 11:25:14 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
References: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
Message-ID: <C992D62D-A6BF-48B1-96DA-B5C6BFE4FB6D@google.com>

noel, wrong on your analysis of the RFNM. RFNM refers
to MESSAGE (that is what the host sends). the Host
does not get to send anything until it gets a RFNM (or
Incomplete Transmission I guess)
from the last MESSAGE, no matter how long or short
the message was. A single packet message served
as an automatic "get a block" request. A multipacket
message does the "get a block" routine. The full
MESSAGE is sent to the IMP from the Host and the
Host is blocked until it gets a RFNM or Incomplete.
You are correct that you could have up to 8 packets in
flight but the Host is unaware of the breaking up of
MESSAGES into packets.

Vint


On Nov 26, 2009, at 11:12 AM, Noel Chiappa wrote:

>> From: Vint Cerf <vint at google.com>
>
> A few clarifications/expansions...
>
>> it reserved space for multi-packet messages at the destination IMP
>> before sending one - acting sort of like a connection setup
>
> To make explicit what's implicit here, single-frame (the term I use  
> for the
> IMP-IMP packets) messages were sent as their own request, so small  
> host-host
> messages did not see that delay.
>
>> did IMP-level retransmission of packets at link layer.
>
> To be clear, I believe this was hop-by-hop, not end-to-end, but this  
> is
> from memory; I'm too lazy to go pull out the IFIPS IMP paper (and in  
> any
> case, this may have changed after the paper was written, but I would
> classify that as unlikely, though).
>
> Text in the 1822 specification (5/1978 edition, pp. 3-2) appears to  
> verify
> this, because it talks about getting an 'Incomplete Transmission'  
> instead
> of a RFNM if the message was "lost in the network due to an IMP  
> failure";
> one wouldn't need such a message if the source IMP still had a copy  
> of the
> message (or frame), which it could have re-transmitted on an end-end
> basis, so the source IMP's copy must have been pitched after the  
> next-hop
> IMP had (locally) acknowledged it.
>
>> No new MESSAGE (from the host) was permitted until the host received
>> a Request for Next Message (RFNM) from its serving IMP.
>
> Umm, not quite; a host was allowed to have up to 8 packets 'in  
> flight' to
> a given destination at a time (basically - there are more details).
> Attempting to send a 9th before the RFNM for the first has been  
> received
> would cause the IMP to block the host (i.e. shut down the hand-shake
> bit-serial interface in the Host->IMP direction) until the first  
> RFNM for
> that destination arrived. One could have up to 8 packets 'in flight'  
> at a
> time to more than one destination, too.
>
> As I recall, the IMP might block you _anyway_, even at less than 8  
> to a
> given destination, for flow-control reasons in the net (e.g. no free
> buffers), but you were _guaranteed_ to get blocked at 9.
>
>> The IMPS did not themselves use RFNM between each other
>
> The wording here could be confusing. According to 1822 (5/1978  
> edition,
> pp. 3-2/3-3), IMPs did look for the RFNM from the far end (i.e. on an
> end-end basis), and on a timeout would query the destination IMP
> (repeatedly so) until it saw either a RGNM or Incomplete Transmission,
> giving up only after 30 seconds or so.
>
>> I don't remember now whether lack of a RFNM triggered a
>> retransmission from the originating IMP
>
> My supposition is that this would have been impossible, as it seems  
> (see
> above) that the source IMP discarded its copy of the message once  
> the next-hop
> IMP had acknowledged receipt of all the frames of it. (Whether this  
> discarding
> was frame-by-frame, or message-at-a-time, I have no idea.)
>
>    Noel



From jeanjour at comcast.net  Thu Nov 26 04:42:13 2009
From: jeanjour at comcast.net (John Day)
Date: Thu, 26 Nov 2009 07:42:13 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <BE04D52B-974A-4EFC-90B8-28C9ED7007F5@free.fr>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<a062408f5c73378914a44@[10.0.1.20]>
	<CA45FC8C-401A-4FBE-8AFC-3C93C672C791@google.com>
	<BE04D52B-974A-4EFC-90B8-28C9ED7007F5@free.fr>
Message-ID: <a062408ffc734272abedd@[10.0.1.20]>

I remember seeing text for both a "datagram" and 
Fast Select.  They may have been contributions. 
But I thought I remembered slightly more than 
placeholder text in the Orange book for datagrams.

And that something was put in under pressure but 
no one ever did it and it was taken out fairly 
soon.

But if it wasn't in the Orange book and it was 
taken out, when was it put in!?  ;-)

The only influence the researchers brought to 
that early debate (I think) was Louis convincing 
them to alight LAPB more closely to HDLC.

At 10:35 +0100 2009/11/26, R?mi Despr?s wrote:
>Le 26 nov. 2009 ? 06:34, Vint Cerf a ?crit :
>
>>
>>  + remi despres
>>  +steve casner
>
>+ Barry Wessler
>
>>  John, I am pretty sure that X.25 did not have 
>>datagrams in the same sense as Cyclades/Cigale 
>>or even ARPANET. There was a fast select but I 
>>thought it came later rather than earlier in 
>>the X.25 story?
>
>The first X.25, published in 1976 in the CCITT 
>Orange book, had only virtual circuits (VCs).
>They were soon deployed in Canada (Datapac), in 
>France (Transpac), and the US (Telenet).
>
>Four years later, datagrams were introduced in X.25.
>They were only optional, while VCs remained mandatory.
>Quite different from IMP-to-IMP packets of 
>Arpanet and Internet datagrams, they had some 
>control by customers of packet drop conditions.
>
>In my recollection, they had been added under 
>political pressure from some administrations 
>that didn't operate X.25 networks.
>Four years later, as no X.25 operator had plans 
>to implement them, they were deleted from X.25.
>
>Regards,
>
>RD
>
>>
>>  v
>>
>>  On Nov 25, 2009, at 7:14 PM, John Day wrote:
>>
>>>  Yea, that jibes with my recollection.
>>>
>>>  And "datagrams" were in the first version of 
>>>X.25 in 76, or was that Fast Select?
>>>
>>>
>>>  At 18:45 -0500 2009/11/25, Vint Cerf wrote:
>>>>  the type 3 packets were explicitly used for 
>>>>real-time packet voice and later packet video 
>>>>experiments. This would have been in the 1975 
>>>>time frame (but Danny Cohen and Steve Casner 
>>>>would know for sure as they were at ISI; 
>>>>Lincoln Labs was also involved and we used 
>>>>their packet digitizers/compressors. Duane 
>>>>Adams managed the packet voice activity 
>>>>during the time I was at DARPA so I am 
>>>>copying him too. I don't seem to have steve 
>>>>casner's email but I think he is now at PARC.
>>>>
>>>>  vint
>>>>
>>>>
>>>>
>>>>
>>>>  On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>>>
>>>>>  I've discussed this issue recently with a 
>>>>>key member of the IMP team at BBN and he 
>>>>>(unsurprisingly) has a very different 
>>>>>recollection of the facts. A datagram mode 
>>>>>was added to the IMP and to X.25 switches 
>>>>>fairly early. Datagrams appeared on research 
>>>>>networks well before TCP/IP was defined; 
>>>>>CYCLADES had them in 1972.
>>>>>
>>>>>  The BBN people have not been able to tell 
>>>>>me whether the NWG ever took advantage of 
>>>>>the datagram mode in the IMP; that was 
>>>>>outside their department.
>>>>>
>>>>>  RB
>>>>>
>>>>>  Bob Braden wrote:
>>>>>>
>>>>>>  My memory was that BBN included type 3 
>>>>>>(Uncontrolled or "raw") messages in the IMP 
>>>>>>protocol as an experiment, which they then 
>>>>>>considered too dangerous to use . BBN 
>>>>>>disabled them at (almost?) all hosts 
>>>>>>(almost?) all the time, I believe.  TCP/IP 
>>>>>>used standard reliably-delivered IMP 
>>>>>>traffic. But the facility must have been 
>>>>>>enabled for the packet voice experiments 
>>>>>>shown in that marvelous video.
>>>>>>
>>>>>>  My memory on this point is hazy, but 
>>>>>>probably Vint can correct me. When Barry 
>>>>>>Leiner became (D)ARPA Program Manager for 
>>>>>>the Internet research program, he became 
>>>>>>determined that BBN should try using Type 3 
>>>>>>IMP-IMP packets for normal TCP/IP flows. He 
>>>>>>complained to the ICCB/IAB that BBN was 
>>>>>>resisting.  He insisted that the experiment 
>>>>>>be tried for 24 hours. Unfortunately I 
>>>>>>don't recall that the experiment ever 
>>>>>>happened;
>  >>>>> it is more than possible that BBN stone-walled his demand.
>>>>>>
>>>>>>  Bob Braden
>>>>>>  '
>>>>>>
>>>>>
>>>>>  --
>>>>>  Richard Bennett
>>>>>  Research Fellow
>>>>>  Information Technology and Innovation Foundation
>>>>>  Washington, DC
>>>
>>
>>
>>
>>




From bernie at fantasyfarm.com  Thu Nov 26 09:03:12 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Thu, 26 Nov 2009 12:03:12 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
References: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
Message-ID: <4B0E6E80.18756.2BE44BA3@bernie.fantasyfarm.com>

On 26 Nov 2009 at 11:12, Noel Chiappa wrote:

>     > did IMP-level retransmission of packets at link layer.
> 
> To be clear, I believe this was hop-by-hop, not end-to-end, but this is
> from memory; I'm too lazy to go pull out the IFIPS IMP paper (and in any
> case, this may have changed after the paper was written, but I would
> classify that as unlikely, though).

That's correct: IMPs *only* buffered packets at the modem-output queue.  
There was no source-IMP buffering of data for the destination-IMP.

>     > No new MESSAGE (from the host) was permitted until the host received
>     > a Request for Next Message (RFNM) from its serving IMP.
> 
> Umm, not quite; a host was allowed to have up to 8 packets 'in flight' to
> a given destination at a time (basically - there are more details).

I don't think that hosts knew about packets -- hard to remember [and I've 
loaned out my copy of the listing] but I believe that the host just sent 
a "message" and the packetizing happened in the IMP, invisibly to the 
host.

>     > The IMPS did not themselves use RFNM between each other
> 
> The wording here could be confusing. According to 1822 (5/1978 edition,
> pp. 3-2/3-3), IMPs did look for the RFNM from the far end (i.e. on an
> end-end basis), and on a timeout would query the destination IMP
> (repeatedly so) until it saw either a RGNM or Incomplete Transmission,
> giving up only after 30 seconds or so.

And it isn't quite the same, but the "fake hosts", of course, used the 
same RFNM machinery as the real hosts.

>     > I don't remember now whether lack of a RFNM triggered a
>     > retransmission from the originating IMP
> 
> My supposition is that this would have been impossible, as it seems (see
> above) that the source IMP discarded its copy of the message once the next-hop
> IMP had acknowledged receipt of all the frames of it. (Whether this discarding
> was frame-by-frame, or message-at-a-time, I have no idea.)

That's correct.  It was up to the host to resend the message.

  /Bernie\

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From jeanjour at comcast.net  Thu Nov 26 09:34:20 2009
From: jeanjour at comcast.net (John Day)
Date: Thu, 26 Nov 2009 12:34:20 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <618FE524-6831-4269-8D40-C67E6E0B4820@google.com>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<4B0DC8F4.7000309@bennett.com>
	<88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>
	<a06240801c73435bb28df@[10.0.1.20]>
	<618FE524-6831-4269-8D40-C67E6E0B4820@google.com>
Message-ID: <a06240804c7346b9ec9e5@[10.0.1.20]>

The Xmas lockup I was referring to (which I believe I heard the 
details of the story from Ari) was that at the NMC at UCLA just 
before the left the lab on xmas eve and being 3 hours behind the East 
Coast thought this was as close to a quiet net that they would ever 
see.  So they told all the IMPs to send stat messages to the NMC. 
The IMP in front of the Sigma ended up with several partially 
reassembled messages and not enough room to finish any of them.  This 
would have been 71 or 72.

I thought it was after that reserving a message at the destination 
IMP was put in.


From jeanjour at comcast.net  Thu Nov 26 09:41:50 2009
From: jeanjour at comcast.net (John Day)
Date: Thu, 26 Nov 2009 12:41:50 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <C992D62D-A6BF-48B1-96DA-B5C6BFE4FB6D@google.com>
References: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
	<C992D62D-A6BF-48B1-96DA-B5C6BFE4FB6D@google.com>
Message-ID: <a06240805c7346dee54c1@[10.0.1.20]>

Correct and implicit in what Vint said.  A MESSAGE was at most 8 
packets.  That was where the 8 limit Noel was talking about came from.

At 11:25 -0500 2009/11/26, Vint Cerf wrote:
>noel, wrong on your analysis of the RFNM. RFNM refers
>to MESSAGE (that is what the host sends). the Host
>does not get to send anything until it gets a RFNM (or
>Incomplete Transmission I guess)
>from the last MESSAGE, no matter how long or short
>the message was. A single packet message served
>as an automatic "get a block" request. A multipacket
>message does the "get a block" routine. The full
>MESSAGE is sent to the IMP from the Host and the
>Host is blocked until it gets a RFNM or Incomplete.
>You are correct that you could have up to 8 packets in
>flight but the Host is unaware of the breaking up of
>MESSAGES into packets.
>
>Vint
>
>
>On Nov 26, 2009, at 11:12 AM, Noel Chiappa wrote:
>
>>>From: Vint Cerf <vint at google.com>
>>
>>A few clarifications/expansions...
>>
>>>it reserved space for multi-packet messages at the destination IMP
>>>before sending one - acting sort of like a connection setup
>>
>>To make explicit what's implicit here, single-frame (the term I use for the
>>IMP-IMP packets) messages were sent as their own request, so small host-host
>>messages did not see that delay.
>>
>>>did IMP-level retransmission of packets at link layer.
>>
>>To be clear, I believe this was hop-by-hop, not end-to-end, but this is
>>from memory; I'm too lazy to go pull out the IFIPS IMP paper (and in any
>>case, this may have changed after the paper was written, but I would
>>classify that as unlikely, though).
>>
>>Text in the 1822 specification (5/1978 edition, pp. 3-2) appears to verify
>>this, because it talks about getting an 'Incomplete Transmission' instead
>>of a RFNM if the message was "lost in the network due to an IMP failure";
>>one wouldn't need such a message if the source IMP still had a copy of the
>>message (or frame), which it could have re-transmitted on an end-end
>>basis, so the source IMP's copy must have been pitched after the next-hop
>>IMP had (locally) acknowledged it.
>>
>>>No new MESSAGE (from the host) was permitted until the host received
>>>a Request for Next Message (RFNM) from its serving IMP.
>>
>>Umm, not quite; a host was allowed to have up to 8 packets 'in flight' to
>>a given destination at a time (basically - there are more details).
>>Attempting to send a 9th before the RFNM for the first has been received
>>would cause the IMP to block the host (i.e. shut down the hand-shake
>>bit-serial interface in the Host->IMP direction) until the first RFNM for
>>that destination arrived. One could have up to 8 packets 'in flight' at a
>>time to more than one destination, too.
>>
>>As I recall, the IMP might block you _anyway_, even at less than 8 to a
>>given destination, for flow-control reasons in the net (e.g. no free
>>buffers), but you were _guaranteed_ to get blocked at 9.
>>
>>>The IMPS did not themselves use RFNM between each other
>>
>>The wording here could be confusing. According to 1822 (5/1978 edition,
>>pp. 3-2/3-3), IMPs did look for the RFNM from the far end (i.e. on an
>>end-end basis), and on a timeout would query the destination IMP
>>(repeatedly so) until it saw either a RGNM or Incomplete Transmission,
>>giving up only after 30 seconds or so.
>>
>>>I don't remember now whether lack of a RFNM triggered a
>>>retransmission from the originating IMP
>>
>>My supposition is that this would have been impossible, as it seems (see
>>above) that the source IMP discarded its copy of the message once 
>>the next-hop
>>IMP had acknowledged receipt of all the frames of it. (Whether this 
>>discarding
>>was frame-by-frame, or message-at-a-time, I have no idea.)
>>
>>    Noel



From jnc at mercury.lcs.mit.edu  Thu Nov 26 09:51:50 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 12:51:50 -0500 (EST)
Subject: [ih] ARPAnet Type 3 packets (datagrams)
Message-ID: <20091126175150.342A16BE57E@mercury.lcs.mit.edu>

    > From: Vint Cerf <vint at google.com>

    > noel, wrong on your analysis of the RFNM.

I think we are running into a problem which I _think_ is because the
network behavior changed over time, because if I'm understanding you
properly (and perhaps I'm not) I can't square this with what the 1822 spec
from the early TCP/IP period says?

Let me transcribe what the various documents say, as a background, to help
us sort this out. From the 1822 spec, pg. 3-6, 5/1978 edition:

  "The maximum number of messages which a Host is permitted to have 'in
  transit' on any connection [for others - 'connection' is not anything
  like a VC connection, but an 1822-specific term earlier defined
  as the combination of destination IMP, host-on-IMP, and something called
  the 'handling type', which included a priority bit - JNC]
  is eight. In other words, if a Host attempts to transmit nine
  messages on any connection, the interface will be blocked by the IMP
  during transmission of the ninth message until a RFNM (or Incomplete
  Transmission) is returned for the first message. However, this rule
  does not prohibit one Host from having eight messages in transit to
  Host 'A', eight more in transit to host 'B', etc., simultaneously."

I note from the famous Heart/Kahn/etc IFIPS paper (SJCC, 1970, pp. 551-567)
that this was not the original behaviour, and perhaps that is the source of
the confusion we are having; that paper says (pg. 553):

  "The subnet accepts only one message at a time on a given link. Ensuing
  messages on that link will be blocked from entering the subnet until
  the source IMP learns that the previous message has arrived at the
  destination Host. When a link becomes unblocked, the subnet notifies
  the source Host by sending it a special control message know as a []
  RFNM, which identifies the newly unblocked link. The source Host may
  utilize its connection into the subnet to transmit messages over other
  links, while waiting to send messages on the blocked links. Up to 63
  separate outgoing links [this was of course the limit in the 32-bit
  leader days - JNC] may exist at any Host site. ... Because the subnet
  allows only one message at a time on a given link, Hosts never receive
  messages out of order."

It seems that this rate-limiting mechanism was quickly changed, for a
variety of reasons. (Whether or not it was realized that the 'single
outstanding packet' model limited the maximum throughput to {packet-size /
RTT} I don't know - the documentation I have is not clear on this.)

The 1972 McQuillan/Crowther/etc paper (FJCC, 1972, pp. 741-754) say (pp.
743-744):

  "To replace the per-link sequence [and flow - JNC} control mechanism,
  we decided upon a sequence control mechanism based on a single logical
  'pipe' between each source and destination IMP. ... Hosts may, if they
  chose, have several messages oustanding simultaneously to a given
  destination.."

When exactly the 8 message limit came in I'm not sure; the 1972 paper doesn't
talk of it, so it must have been later. (I consulted the 'A History of the
ARPANET: The First Decade', but that is short on technical detail, and doesn't
say.)

    > RFNM refers to MESSAGE (that is what the host sends). the Host does
    > not get to send anything until it gets a RFNM (or Incomplete
    > Transmission I guess) from the last MESSAGE, no matter how long or
    > short the message was.
    > ...
    > The full MESSAGE is sent to the IMP from the Host and the Host is
    > blocked until it gets a RFNM or Incomplete. 

I read you as saying here that when a host sent a message, it didn't get
to send another message until it got a RFNM from the message it just sent.
Am I understanding you correctly? If so, this does not seem to square with
1822, which says you could send up to eight before you have to wait for
the "RFNM ... for the first message".

Of course, you _are_ correct about the behaviour earlier, but the
single-packet-per-link restriction had been removed by the time of even the
earliest TCP/IP work.


    > A single packet message served as an automatic "get a block"
    > request. A multipacket message does the "get a block" routine.

>From the 1972 FJCC paper, the original 1970 network did not have this
allocation mechanism; it was introduced after lockups appeared (the
destination IMP had frames from many different messages, but not enough
free buffers to reassmble a complete message and transmit it to the Host).

(Interestingly, it appears my memory is also buggy - I had thought that
for multi-frame messages, the buffer request was piggybacked on the first
frame, which was sent immediately, but that is not so. I must have
conflated the piggybacking that occurs elsewhere, together with the
'messages small than a frame are sent as their own request', to produce
that erroneous memory.)

More interestingly, single-frame messages _were_ acknowledged on an end-end
(i.e. source IMP - destination IMP) basis; this was because such messages
could be discarded by the destination IMP if it did not have sufficient
buffering to hold them until it could send then to the host. So only
multi-frame messages were not held at the source until the destination
acknowledged them - an interesting mix of end-end and hop-by-hop reliabilty!

	Noel


From bernie at fantasyfarm.com  Thu Nov 26 09:52:11 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Thu, 26 Nov 2009 12:52:11 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <a06240804c7346b9ec9e5@[10.0.1.20]>
References: <mailman.3.1259179202.11074.internet-history@postel.org>,
	<618FE524-6831-4269-8D40-C67E6E0B4820@google.com>,
	<a06240804c7346b9ec9e5@[10.0.1.20]>
Message-ID: <4B0E79FB.2430.2C112311@bernie.fantasyfarm.com>

On 26 Nov 2009 at 12:34, John Day wrote:

> The Xmas lockup I was referring to (which I believe I heard the 
> details of the story from Ari) was that at the NMC at UCLA just 
> before the left the lab on xmas eve and being 3 hours behind the East 
> Coast thought this was as close to a quiet net that they would ever 
> see.  So they told all the IMPs to send stat messages to the NMC. 
> The IMP in front of the Sigma ended up with several partially 
> reassembled messages and not enough room to finish any of them.  This 
> would have been 71 or 72.
> 
> I thought it was after that reserving a message at the destination 
> IMP was put in.

I don't remember that incident, but I don't think so -- I'm pretty sure 
that the "reserve 8" machinery was in the first versions of the IMP code.

  /Bernie\
-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From jnc at mercury.lcs.mit.edu  Thu Nov 26 10:00:50 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 13:00:50 -0500 (EST)
Subject: [ih] ARPAnet Type 3 packets (datagrams)
Message-ID: <20091126180050.B0C326BE57E@mercury.lcs.mit.edu>

    > From: "Bernie Cosell" <bernie at fantasyfarm.com>

    > IMPs *only* buffered packets at the modem-output queue. There was
    > no source-IMP buffering of data for the destination-IMP.

The 1972 FJCC paper does seem to indicate that this was not true of
single-frame messages, viz (pg. 743):

  "We minimize the delay for a short message by transmitting it to the
  destination immediately while keeping a copy in the source IMP. If
  there is space at the destination, it is accepted and passed on to a
  Host and a RFNM is returned; the source IMP discards the message when
  it receives a RFNM."

Did this continue to be the case, do you recall?


    >> a host was allowed to have up to 8 packets 'in flight' to a given
    >> destination at a time (basically - there are more details).

    > I don't think that hosts knew about packets

Apologies all, I was not sufficiently precise in my terminology; I was using
"packet" in the modern sense (in part because I'd just been looking at the IMP
interface code in the MIT router code :-), not in the old 'IMP subnet
transmission unit' sense.

(That's partly why I've started using the neologistic term 'frame' for the
IMP-IMP things, because that term is not ambiguous; I retain 'message' for the
host-host things, as it is also not ambiguous.)

	Noel


From jnc at mercury.lcs.mit.edu  Thu Nov 26 10:09:06 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 13:09:06 -0500 (EST)
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <20091126180906.B19406BE57E@mercury.lcs.mit.edu>

    > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>

    >> a maximum packet size of ~120 bytes would obviously not have been
    >> that much use for TCP/IP in general.

    > I don't understand this. Even the 1974 Cerf/Kahn specification of
    > TCP knew of "breaking up messages into segments"
    > ...
    > While hosts were eventually expected to accept IP packets of at
    > least 576 bytes, they sure can cope with smaller packets ...
    > Why then would 126 bytes foreclose experimenting with TCP/IP?

Do note that I didn't say 'would not work', I said "not .. that much use"!

The reason is that fragmentation turned out to just not work very well,
because packets which were fragmented were much less 'reliable' (in the
sense of eventually being delivered complete, to the application). Any
time packets were being fragmented, things seemed to just not work very
well. It is for that reason that we eventually added Path MTU Discovery,
so that fragmentation could be avoided. (Note that IPv6 left out end-end
fragmentation altogether, for the same reason.)

Why exactly fragmentation didn't work so well I don't recollect very well
(if we ever knew for sure exactly why). I suspect that the network back
then was 'lossier' (partly due to poor congestion control causing
congestion drops, partly due to flakier transmission systems). Since
end-end retransmission schemes don't work so well when loss rates go up
(typically there's a 'knee' where performance goes over a cliff), with
that many more packets involved for a given amount of data, we may have
gone over the 'knee'.

(Some hosts/routers didn't actually implement fragmention and/or re-assemblyl,
particularly the latter, as it was a PITA to code, so that was a problem too.)

Of course, with the typical data packet being relatively large (I don't
know the average packet size for FTP or email, but surely it was at least
576), with the ~120 byte (991 bits, to be accurate) Uncontrolled packets,
of which 20 at least would be the IP header, you're looking at 6 fragments
for each 576 byte data packet -> very poor performance.


    > unlike ordinary single-packet messages they would not be subject to
    > the source-destination-IMP ack/retransmit facility.

I'm not sure there was such a thing (see previous message).

Whether the frames of Uncontrolled messages were subject to the normal
IMP-IMP retransmission I don't know, and 1822 doesn't say, but my _guess_
is that they would have been (more work to treat them differently, than
just handle them like any other IMP-IMP frame).

    > surely it must have been more fun playing around with higher level
    > end-to-end reliability in a network that actually does drop a packet
    > sometimes.

ROTFLMAO! As Vint indicated, not having lost packets was _not_ a problem
we had! :-)

	Noel


From bernie at fantasyfarm.com  Thu Nov 26 10:10:11 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Thu, 26 Nov 2009 13:10:11 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <20091126180050.B0C326BE57E@mercury.lcs.mit.edu>
References: <20091126180050.B0C326BE57E@mercury.lcs.mit.edu>
Message-ID: <4B0E7E33.26027.2C21A052@bernie.fantasyfarm.com>

On 26 Nov 2009 at 13:00, Noel Chiappa wrote:

>     > From: "Bernie Cosell" <bernie at fantasyfarm.com>
> 
>     > IMPs *only* buffered packets at the modem-output queue. There was
>     > no source-IMP buffering of data for the destination-IMP.
> 
> The 1972 FJCC paper does seem to indicate that this was not true of
> single-frame messages, viz (pg. 743):

That's pretty much right, I think [I wish I could check it in the code].  
"One packet messages" were handled specially everywhere in the IMP -- I'm 
trying to remember *where* in the IMP we held the things pending the RFNM 
and I just can't at the moment..

  /Bernie\

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From vint at google.com  Thu Nov 26 10:17:18 2009
From: vint at google.com (Vint Cerf)
Date: Thu, 26 Nov 2009 13:17:18 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <20091126180050.B0C326BE57E@mercury.lcs.mit.edu>
References: <20091126180050.B0C326BE57E@mercury.lcs.mit.edu>
Message-ID: <5B80F0E0-0D3D-4F3A-9015-DA01065D8A0D@google.com>

the confusion appears to revolve around the term "message"

I am pretty sure that "message" meant an object up to about 8000 bits
from a HOST. The HOST-IMP protocol (BBN 1822) allowed one of
these at a time per logical LINK. Link construct was part of the HOST- 
IMP
protocol. The IMPs broke messages into packets  of up to 1008 bits each.

You are correct, Noel, that "get a block" "got a block" was introduced
after Bob Kahn and I demonstrated reassembly lockup (by sending
multiple messages, one each on a distinct logical link).

Single packet MESSAGES served as their own reservation requests
and were retransmitted from the source IMP if the implicit "get a  
block" failed.

at least that's what my aging memory tells me. I think I wrote a  
detailed
RFC about how the revised mechanisms worked.

vint




On Nov 26, 2009, at 1:00 PM, Noel Chiappa wrote:

>> From: "Bernie Cosell" <bernie at fantasyfarm.com>
>
>> IMPs *only* buffered packets at the modem-output queue. There was
>> no source-IMP buffering of data for the destination-IMP.
>
> The 1972 FJCC paper does seem to indicate that this was not true of
> single-frame messages, viz (pg. 743):
>
>  "We minimize the delay for a short message by transmitting it to the
>  destination immediately while keeping a copy in the source IMP. If
>  there is space at the destination, it is accepted and passed on to a
>  Host and a RFNM is returned; the source IMP discards the message when
>  it receives a RFNM."
>
> Did this continue to be the case, do you recall?
>
>
>>> a host was allowed to have up to 8 packets 'in flight' to a given
>>> destination at a time (basically - there are more details).
>
>> I don't think that hosts knew about packets
>
> Apologies all, I was not sufficiently precise in my terminology; I  
> was using
> "packet" in the modern sense (in part because I'd just been looking  
> at the IMP
> interface code in the MIT router code :-), not in the old 'IMP subnet
> transmission unit' sense.
>
> (That's partly why I've started using the neologistic term 'frame'  
> for the
> IMP-IMP things, because that term is not ambiguous; I retain  
> 'message' for the
> host-host things, as it is also not ambiguous.)
>
> 	Noel



From bernie at fantasyfarm.com  Thu Nov 26 10:27:01 2009
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Thu, 26 Nov 2009 13:27:01 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <a06240801c73435bb28df@[10.0.1.20]>
References: <mailman.3.1259179202.11074.internet-history@postel.org>,
	<88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>,
	<a06240801c73435bb28df@[10.0.1.20]>
Message-ID: <4B0E8225.31430.2C310925@bernie.fantasyfarm.com>

On 26 Nov 2009 at 8:50, John Day wrote:

> Which brings up another question.  I had always thought that X.25 
> originated mostly with the French PTT.  I have heard stories that the 
> Telenet guys had a strong hand in its design.  What is the case?

The first X.25-ness I recall was a spec from Bell-Canada that looked like 
it was a broken attempt to full-duplexize the IBM HDLC protocol.  I [and 
maybe together with Dave Walden] wrote a few critiques of it for IEEE 
Trans/communications and I think it got heavily revised before it was 
implemented.

  /Bernie\
-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       





From craig at aland.bbn.com  Thu Nov 26 10:47:50 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Thu, 26 Nov 2009 13:47:50 -0500
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <20091126184750.3809028E137@aland.bbn.com>

> Why exactly fragmentation didn't work so well I don't recollect very well
> (if we ever knew for sure exactly why).  I suspect that the network back
> then was 'lossier' (partly due to poor congestion control causing
> congestion drops, partly due to flakier transmission systems). Since
> end-end retransmission schemes don't work so well when loss rates go up
> (typically there's a 'knee' where performance goes over a cliff), with
> that many more packets involved for a given amount of data, we may have
> gone over the 'knee'.

The Mogul and Kent paper at SIGCOMM '87 and then the Floyd and Romanow paper
at the London SIGCOMM (don't recall year) pretty much nailed this.

The problem is that you lose a fragment and all the other fragments are now
worthless.  Mogul and Kent showed that certain packets would reliably fragment
in ways such that a fragment was always lost.   Floyd and Romanow showed that
what I call the "dead fragments walking" would then cause downstream loss
of fragments of other packets, causing more mayhem.

Thanks!

Craig


From jnc at mercury.lcs.mit.edu  Thu Nov 26 11:40:15 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 14:40:15 -0500 (EST)
Subject: [ih] ARPAnet Type 3 packets (datagrams)
Message-ID: <20091126194015.4B3406BE57E@mercury.lcs.mit.edu>

    > From: "Bernie Cosell" <bernie at fantasyfarm.com>

    > I'm pretty sure that the "reserve 8" machinery was in the first
    > versions of the IMP code.

Looking carefully at the 1972 FJCC paper, I'm not sure this is correct:
although the paper is not 100% explicit aboutwhat changes are made, but it
seems to strongly _imply_ that the reservation-before-sending-any-frames
mechanism was added after the intial deployment. (And so my previous
message, where I said "the original 1970 network did not have this
[buffer] allocation mechanism", was a bit speculative/aggressive.)

Here's what the 1972 paper says, though.


The failure mode that it describes (pp. 742-743) is only indirectly due to
lack of buffers at the destination IMP for partially-assembled
messages. (Although it does not say whether those buffers were allocated
before the time the first frame arrived - although the implication, from much
later statements, is that they were allocated when the first frame of a
multi-frame message arrived, not _prior_ to any frames from a given
amulti-frame message entering the subnet.)

Rather, the immediate problem was that i) the destination IMP had no free
buffers, since all its buffer space was reserved for partially-assembled
messages, and ii) its _neighbour_ IMP's buffers were filled with frames from
_other_ multi-frame messages (no frames from which were being held in the
destination IMP - perhaps because it had no free buffers to hold them, and
thus refused to acknowledge them if they were sent).

Since the neighbour IMP could not discard any of those frames (since it had
already acknowledged them to _its_ upstream neigbours), that meant that the
missing frames needed for the partial messages being held at the destination
IMP could not get through the intermediate IMP. Of course, without those
missing frames,the destination IMP could not re-assemble those messages and
send them to the host, freeing the buffers, and until it did that, it couldn't
take any of the frames that were filling the buffers of the intermediate
IMP.... Deadlock!

However, the paper does not say explicitly that this behaviour was
actually _observed in service_, it merely talks about "messages ..
entering the network for which network buffering is not available and
which could congest the network and lead to reassembly lockup"; i.e. it
could be speaking of a theoretical failure mode. Later on it says
"simulations and experiments artificially loading the network", so again
there is no reference to 'the network failed when X happened, in actual
service'.

(What a clever failure mode, BTW! It resulted, basically, from the hop-by-hop
reliability, combined with a failure to keep an adequate level of free buffers
at each IMP. Note that there is no way for the intermediate IMP to be able to
do anything about the problem, since it has no way of knowing which frames the
destination IMP needs, in order to be able to free up buffers. Only end-end
flow-control can solve this problem...)


Anyway, at the end it says:

  "our solution also utilizes a request mechanism from source IMP to
  destination IMP. Specifically, no multi-[frame] message is allowed
  to enter the network until storage for the message has been allocated at
  the destination IMP. As soon as the source IMP takes in the first
  [frame] of a multi-[frame] messsage, it sends a small control [request]
  to the destination IMP requesting that reassembly storage be reserved
  at the destination for this message. It does not take in further [frames]
  from the Host until it receives an allocation [reply]."

This does strongly imply that the end-end allocation mechanism was added
_later_, in response to this problem.

It is quite interesting, because it seems that all the buffering at the source
was in the source Host, not the source IMP! In other words, messages queued
for output at the host to _other_ destinations had to wait until the space
reservation go-ahead was received from the destination IMP for the _first_
message!

I wonder if this was ever changed, so that each multi-frame message to a
new destination didn't add an RTT to the queing delay of _all_ packets
queued for output behind it? Of course, this would have required more
buffering in the IMP. (Do I recall something about the first IMPs having a
minimal amount of memory, but it being expanded over time?) 

	Noel


From jnc at mercury.lcs.mit.edu  Thu Nov 26 11:53:24 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 14:53:24 -0500 (EST)
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <20091126195324.33E086BE57E@mercury.lcs.mit.edu>

    > From: Craig Partridge <craig at aland.bbn.com>

Ah, thanks for the in-fill. A few comments:

    > The problem is that you lose a fragment and all the other fragments
    > are now worthless.

The _theory_ was that if the packet were retransmitted exactly as-was,
then in a lossy environment, if the losses were stochastic (and as you
point out, often they weren't), you'd expect to often get the missing
fragment from the first instantiation out of whatever set of fragments
from the retransmitted instantiation made it through.

However, in addition to the problems you note below, many hosts could not/
did not retransmit an identical packet. Either they used a new IP ID
(since the tranport layer didn't _know_ the old one, if it was allocated
by the internetwork layer), or TCP created a new segment covering a
slightly different part of the sequence number space (common with TELNET,
since more input or output may have been buffered during the timeout
interval; some data may have been in an earlier packet and gotten ACK'd),
etc.

So then all the old fragments were useless (and took up buffer space in
the destination host, needed to be timed out there, yadda-yadda).

    > Floyd and Romanow showed that what I call the "dead fragments
    > walking" would then cause downstream loss of fragments of other
    > packets, causing more mayhem.

Oh, right, congestive collapse... We saw a lot of that, back in the day!

	Noel


From Danny.Cohen at Sun.COM  Thu Nov 26 11:55:16 2009
From: Danny.Cohen at Sun.COM (Danny Cohen)
Date: Thu, 26 Nov 2009 11:55:16 -0800
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <a06240801c73435bb28df@[10.0.1.20]>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<4B0DC8F4.7000309@bennett.com>
	<88AEFEB5-ED65-49EE-BEA1-CFA8C4C8E2A1@google.com>
	<a06240801c73435bb28df@[10.0.1.20]>
Message-ID: <4B0EDD24.5030808@sun.com>

John,

Regarding your:
       "I had always thought that X.25 originated mostly with the French 
PTT. 
        I have heard stories that the Telenet guys had a strong hand in 
its design. 
        What is the case?"

Suggest you ask Barry Wessler <Wessler at aol.com>, one of the TELENET guys.
---Danny



From mbaer at cs.tu-berlin.de  Fri Nov 27 06:17:07 2009
From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=)
Date: Fri, 27 Nov 2009 15:17:07 +0100
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <4B0E6E80.18756.2BE44BA3@bernie.fantasyfarm.com>
References: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
	<4B0E6E80.18756.2BE44BA3@bernie.fantasyfarm.com>
Message-ID: <4B0FDF63.7010506@cs.tu-berlin.de>

Please see also the very bottom of this email.

Bernie Cosell wrote:
>
>>     > No new MESSAGE (from the host) was permitted until the host received
>>     > a Request for Next Message (RFNM) from its serving IMP.
>>
>> Umm, not quite; a host was allowed to have up to 8 packets 'in flight' to
>> a given destination at a time (basically - there are more details).
>>     
>
> I don't think that hosts knew about packets -- hard to remember [and I've 
> loaned out my copy of the listing] but I believe that the host just sent 
> a "message" and the packetizing happened in the IMP, invisibly to the 
> host.
>   

Just to add yet another take on this point, normal (local) and distant
hosts didn't know about packets (Very Distant Hosts would, though,
having to implement a reliable transmission package, see section F in
the 1822 report); but still, an IMP would block the Host-IMP interface
after having received the first 1000 or so bits of a message, issue a
storage allocation request to the destination IMP, and only upon having
this allocation let the Host continue send over the rest of the message
(pp. 3-3 to 3-5 in the 1822 report).

The Technical Information Report 89 (The Interface Message Processor
Program) as of 1978 even goes so far and speaks outright of packets,
even though this is probably just due to convenience rather than
technical strictness:

"As soon as the source IMP takes in the first packet of a multi-packet
message, it sends a small control message to the destination IMP
requesting that reassembly storage be reserved at the destination for
this message. It does not take in further packets from the Host until it
receives an allocation message in reply. The destination IMP queues the
request and sends the allocation message to the source IMP when enough
reassembly storage is free; at this point the source IMP sends the
message to the destination." (p. 4)


>   
>>     > I don't remember now whether lack of a RFNM triggered a
>>     > retransmission from the originating IMP
>>
>> My supposition is that this would have been impossible, as it seems (see
>> above) that the source IMP discarded its copy of the message once the next-hop
>> IMP had acknowledged receipt of all the frames of it. (Whether this discarding
>> was frame-by-frame, or message-at-a-time, I have no idea.)
>>     
>
> That's correct.  It was up to the host to resend the message.
>   

But NCP would never do that either, would it? The maximum thing that
would happen if something went wrong was going back to checkpoints in
file transfers (see e.g. RFC 542, NIC 17759), right?

Matthias


From vint at google.com  Fri Nov 27 07:02:49 2009
From: vint at google.com (Vint Cerf)
Date: Fri, 27 Nov 2009 10:02:49 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <4B0FDF63.7010506@cs.tu-berlin.de>
References: <20091126161230.1DA3D6BE56B@mercury.lcs.mit.edu>
	<4B0E6E80.18756.2BE44BA3@bernie.fantasyfarm.com>
	<4B0FDF63.7010506@cs.tu-berlin.de>
Message-ID: <2503627F-AE95-48CE-BE5B-FE70FF339B08@google.com>

1. if the HOST message was small enough to fit in a single IMP packet,  
the whole packet was sent as an implicit request for storage. Either  
you got a RFNM back or I guess Incomplete Transmission. I don't  
remember but don't think that the source IMP held a copy of the packet  
for retriansmission.

2. If the HOST sent a message that was longer than a single IMP packet  
(1008 bits) the IMP halted bit transfers on the interface (except for  
the VDH case which was much more complex) using the bit level controls  
on the physical interface) until it got back an 8 packet reservation.  
There were only two reservations: 1 packet and 8 packets, regardless  
of the actual length of the HOST message.

3. NCP did NOT retransmit; it relied on the IMPs.

vint


On Nov 27, 2009, at 9:17 AM, Matthias B?rwolff wrote:

> Please see also the very bottom of this email.
>
> Bernie Cosell wrote:
>>
>>>> No new MESSAGE (from the host) was permitted until the host  
>>>> received
>>>> a Request for Next Message (RFNM) from its serving IMP.
>>>
>>> Umm, not quite; a host was allowed to have up to 8 packets 'in  
>>> flight' to
>>> a given destination at a time (basically - there are more details).
>>>
>>
>> I don't think that hosts knew about packets -- hard to remember  
>> [and I've
>> loaned out my copy of the listing] but I believe that the host just  
>> sent
>> a "message" and the packetizing happened in the IMP, invisibly to the
>> host.
>>
>
> Just to add yet another take on this point, normal (local) and distant
> hosts didn't know about packets (Very Distant Hosts would, though,
> having to implement a reliable transmission package, see section F in
> the 1822 report); but still, an IMP would block the Host-IMP interface
> after having received the first 1000 or so bits of a message, issue a
> storage allocation request to the destination IMP, and only upon  
> having
> this allocation let the Host continue send over the rest of the  
> message
> (pp. 3-3 to 3-5 in the 1822 report).
>
> The Technical Information Report 89 (The Interface Message Processor
> Program) as of 1978 even goes so far and speaks outright of packets,
> even though this is probably just due to convenience rather than
> technical strictness:
>
> "As soon as the source IMP takes in the first packet of a multi-packet
> message, it sends a small control message to the destination IMP
> requesting that reassembly storage be reserved at the destination for
> this message. It does not take in further packets from the Host  
> until it
> receives an allocation message in reply. The destination IMP queues  
> the
> request and sends the allocation message to the source IMP when enough
> reassembly storage is free; at this point the source IMP sends the
> message to the destination." (p. 4)
>
>
>>
>>>> I don't remember now whether lack of a RFNM triggered a
>>>> retransmission from the originating IMP
>>>
>>> My supposition is that this would have been impossible, as it  
>>> seems (see
>>> above) that the source IMP discarded its copy of the message once  
>>> the next-hop
>>> IMP had acknowledged receipt of all the frames of it. (Whether  
>>> this discarding
>>> was frame-by-frame, or message-at-a-time, I have no idea.)
>>>
>>
>> That's correct.  It was up to the host to resend the message.
>>
>
> But NCP would never do that either, would it? The maximum thing that
> would happen if something went wrong was going back to checkpoints in
> file transfers (see e.g. RFC 542, NIC 17759), right?
>
> Matthias




From jnc at mercury.lcs.mit.edu  Fri Nov 27 07:25:55 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 27 Nov 2009 10:25:55 -0500 (EST)
Subject: [ih] ARPAnet Type 3 packets (datagrams)
Message-ID: <20091127152555.C3C5B6BE56A@mercury.lcs.mit.edu>

    > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>

    > The Technical Information Report 89 .. as of 1978 even goes so far and
    > speaks outright of packets, even though this is probably just due to
    > convenience rather than technical strictness

It's more likely due to the fact that terminology had not yet taken its
modern meanings; the term "packet", to them, meant strictly an IMP-IMP frame,
as that term always had in the context of the ARPANET.


    >> It was up to the host to resend the message.

    > But NCP would never do that either, would it? The maximum thing that
    > would happen if something went wrong was going back to checkpoints in
    > file transfers 

Well, one would have to look at each NCP to be sure, but yeah, I would expect
that every NCP that got a Transmission Incomplete (of any subtype), would have
treated that as a fatal error on the connection. In _theory_ it was probably
possible for the host to save a local copy of the message, and not discard it
until it got a RFNM, and have it available to retransmit if it got a TI, but
I'd be stunned if any NCP actually did so. If nothing else, the RFNM/TI
process was not end-end, so even if you got a TI subtype 3, there was probably
no guarantee that the destination IMP had not in fact actually delivered the
packet to the host before crashing and restarting, so resending could create a
duplicate, and NCP had no sequence numbers of its own to weed out
duplicates...

BTW, I'm not sure if a TI is what an IMP sent to the source host, when it
didn't get a RFNM from the destination IMP, and could not get a reply even
after timing out and re-querying the destination IMP (which was what we were
discussing there) - it might have returned a 'Destination IMP Dead' error
(type 7, subtype 0).

	Noel


From mbgreen at seas.upenn.edu  Fri Nov 27 10:31:54 2009
From: mbgreen at seas.upenn.edu (Michael Greenwald)
Date: Fri, 27 Nov 2009 10:31:54 -0800
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <20091126180906.B19406BE57E@mercury.lcs.mit.edu>
References: <20091126180906.B19406BE57E@mercury.lcs.mit.edu>
Message-ID: <4B101B1A.4000409@seas.upenn.edu>

Noel,

[I don't have much time to read this list, unfortunately (seems 
fascinating), but in my Thanksgiving weekend skim I came across your note].

I'm not sure if this is what you are asking about/trying to remember:

On Multics the issue with fragmentation was that other hosts did not 
retransmit using the same IP ID, so we wasted "lots" of memory (relative 
to those days) holding onto fragments of incomplete packets.  (On 
multics transmission side we were careful to reuse the IP ID for all 
protocols we had implemented, and the network_ DIM exposed the IP ID to 
allow other user implemented IP protocols to also retransmit and force 
the IP ID to be the same as the original.  But too many other 
implementations retransmitted using new IP IDs so on reassembly side we 
could be hurting when lots of fragments were dropped.) Also, in the face 
of losses, it was much more efficient for TCP to send unfragmented 
packets: retransmissions only resent the lost packet, while with a 
fragmented packet, retransmission resent all fragments, even those that 
had arrived.  I also had some bad experience with highly lossy lines --- 
the implementation wasn't optimized for lots of lost fragments --- so 
when the # of incomplete pkts started getting large, the lookup to find 
a match was relatively slow (this would have been easy to fix, but it 
wasn't a priority).  Finally, it could happen that we took an extra 
process switch per fragment, so fragmented packets were painfully 
expensive.  There were probably other reasons, but these stand out in my 
memory as what convinced/prejudiced me at the time to believe that TCP 
should try hard to avoid sending fragmented IP packets.

Finally, I don't remember if by the time of the NCP cutoff there really 
were hosts out there that didn't implement reassembly or routers that 
didn't fragment, whether or not it was a PITA.  Early on, yes, (there 
was some bakeoff circa '79 or even 80 when I think only Multics & UCLA 
had both frag& reassembly working correctly), but I can't recall any 
specific host or router that didn't interoperate because it didn't 
implement reassembly or fragmentation respectively.  Could be my memory 
that's incorrect, though.

On 11/26/09 10:09 AM, Noel Chiappa wrote:
>     > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>
>
>     >> a maximum packet size of ~120 bytes would obviously not have been
>     >> that much use for TCP/IP in general.
>
>     > I don't understand this. Even the 1974 Cerf/Kahn specification of
>     > TCP knew of "breaking up messages into segments"
>     > ...
>     > While hosts were eventually expected to accept IP packets of at
>     > least 576 bytes, they sure can cope with smaller packets ...
>     > Why then would 126 bytes foreclose experimenting with TCP/IP?
>
> Do note that I didn't say 'would not work', I said "not .. that much use"!
>
> The reason is that fragmentation turned out to just not work very well,
> because packets which were fragmented were much less 'reliable' (in the
> sense of eventually being delivered complete, to the application). Any
> time packets were being fragmented, things seemed to just not work very
> well. It is for that reason that we eventually added Path MTU Discovery,
> so that fragmentation could be avoided. (Note that IPv6 left out end-end
> fragmentation altogether, for the same reason.)
>
> Why exactly fragmentation didn't work so well I don't recollect very well
> (if we ever knew for sure exactly why). I suspect that the network back
> then was 'lossier' (partly due to poor congestion control causing
> congestion drops, partly due to flakier transmission systems). Since
> end-end retransmission schemes don't work so well when loss rates go up
> (typically there's a 'knee' where performance goes over a cliff), with
> that many more packets involved for a given amount of data, we may have
> gone over the 'knee'.
>
> (Some hosts/routers didn't actually implement fragmention and/or re-assemblyl,
> particularly the latter, as it was a PITA to code, so that was a problem too.)
>
> Of course, with the typical data packet being relatively large (I don't
> know the average packet size for FTP or email, but surely it was at least
> 576), with the ~120 byte (991 bits, to be accurate) Uncontrolled packets,
> of which 20 at least would be the IP header, you're looking at 6 fragments
> for each 576 byte data packet -> very poor performance.
>
>
>     > unlike ordinary single-packet messages they would not be subject to
>     > the source-destination-IMP ack/retransmit facility.
>
> I'm not sure there was such a thing (see previous message).
>
> Whether the frames of Uncontrolled messages were subject to the normal
> IMP-IMP retransmission I don't know, and 1822 doesn't say, but my _guess_
> is that they would have been (more work to treat them differently, than
> just handle them like any other IMP-IMP frame).
>
>     > surely it must have been more fun playing around with higher level
>     > end-to-end reliability in a network that actually does drop a packet
>     > sometimes.
>
> ROTFLMAO! As Vint indicated, not having lost packets was _not_ a problem
> we had! :-)
>
> 	Noel
>
>   



From jnc at mercury.lcs.mit.edu  Thu Nov 26 08:48:33 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 26 Nov 2009 11:48:33 -0500 (EST)
Subject: [ih] Arpanet raw messages, voice, and TCP
Message-ID: <20091126164833.8A8B66BE59B@mercury.lcs.mit.edu>

    > From: =?ISO-8859-1?Q?Matthias_B=E4rwolff?= <mbaer at cs.tu-berlin.de>

    >> a maximum packet size of ~120 bytes would obviously not have been
    >> that much use for TCP/IP in general.

    > I don't understand this. Even the 1974 Cerf/Kahn specification of
    > TCP knew of "breaking up messages into segments"
    > ...
    > While hosts were eventually expected to accept IP packets of at
    > least 576 bytes, they sure can cope with smaller packets ...
    > Why then would 126 bytes foreclose experimenting with TCP/IP?

Do note that I didn't say 'would not work', I said "not .. that much use"!

The reason is that fragmentation turned out to just not work very well,
because packets which were fragmented were much less 'reliable' (in the
sense of eventually being delivered complete, to the application). Any
time packets were being fragmented, things seemed to just not work very
well. It is for that reason that we eventually added Path MTU Discovery,
so that fragmentation could be avoided. (Note that IPv6 left out end-end
fragmentation altogether, for the same reason.)

Why exactly fragmentation didn't work so well I don't recollect very well
(if we ever knew for sure exactly why). I suspect that the network back
then was 'lossier' (partly due to poor congestion control causing
congestion drops, partly due to flakier transmission systems). Since
end-end retransmission schemes don't work so well when loss rates go up
(typically there's a 'knee' where performance goes over a cliff), with
that many more packets involved for a given amount of data, we may have
gone over the 'knee'.

(Some hosts/routers didn't actually implement fragmention and/or re-assemblyl,
particularly the latter, as it was a PITA to code, so that was a problem too.)

Of course, with the typical data packet being relatively large (I don't
know the average packet size for FTP or email, but surely it was at least
576), with the ~120 byte (991 bits, to be accurate) Uncontrolled packets,
of which 20 at least would be the IP header, you're looking at 6 fragments
for each 576 byte data packet -> very poor performance.


    > unlike ordinary single-packet messages they would not be subject to
    > the source-destination-IMP ack/retransmit facility.

I'm not sure there was such a thing (see previous message).

Whether the frames of Uncontrolled messages were subject to the normal
IMP-IMP retransmission I don't know, and 1822 doesn't say, but my _guess_
is that they would have been (more work to treat them differently, than
just handle them like any other IMP-IMP frame).

    > surely it must have been more fun playing around with higher level
    > end-to-end reliability in a network that actually does drop a packet
    > sometimes.

ROTFLMAO! As Vint indicated, not having lost packets was _not_ a problem
we had! :-)

	Noel


From jeanjour at comcast.net  Thu Nov 26 09:44:27 2009
From: jeanjour at comcast.net (John Day)
Date: Thu, 26 Nov 2009 12:44:27 -0500
Subject: [ih] ARPAnet Type 3 packets (datagrams)
In-Reply-To: <145ABB39-06B8-4F9B-8C41-B5060AD6FC48@free.fr>
References: <mailman.3.1259179202.11074.internet-history@postel.org>
	<4B0DAE97.8060402@isi.edu> <4B0DB822.7010200@bennett.com>
	<98C47587-CCED-479A-A2B6-42AF7EDD919F@google.com>
	<a062408f5c73378914a44@[10.0.1.20]>
	<CA45FC8C-401A-4FBE-8AFC-3C93C672C791@google.com>
	<BE04D52B-974A-4EFC-90B8-28C9ED7007F5@free.fr>
	<a062408ffc734272abedd@[10.0.1.20]>
	<145ABB39-06B8-4F9B-8C41-B5060AD6FC48@free.fr>
Message-ID: <a06240806c7346e687171@[10.0.1.20]>

At 15:03 +0100 2009/11/26, R?mi Despr?s wrote:
>Le 26 nov. 2009 ? 13:42, John Day a ?crit :
>
>>  I remember seeing text for both a "datagram" 
>>and Fast Select.  They may have been 
>>contributions. But I thought I remembered 
>>slightly more than placeholder text in the 
>>Orange book for datagrams.
>>
>>  And that something was put in under pressure 
>>but no one ever did it and it was taken out 
>>fairly soon.
>>
>>  But if it wasn't in the Orange book and it was 
>>taken out, when was it put in!?  ;-)
>
>* CCITT Recommendation X.25 (1976) Orange Book - No datagram
>* CCITT Recommendation X.25 (1980) Yellow Book - Datagram added
>* CCITT Recommendation X.25 (1984) Red Book - Datagram deleted

Okay, then what I remember seeing were 
contributions.  Was the "datagram" in the Yellow 
Book, a datagram or Fast Select?

>
>>
>>  The only influence the researchers brought to 
>>that early debate (I think) was Louis 
>>convincing them to alight LAPB more closely to 
>>HDLC.
>
>In my recollection, X.25 was technically 
>finalized before all variants of HDLC were 
>stabilized in ISO.
>Harmonization being found necessary, in 
>particular by IBM which was then leader on the 
>subject in ISO, the layer 2 of X.25 (LAPB) was 
>eventually aligned with the HDLC-Asynchronous 
>Balanced Mode.

So was that done for the Yellow Book as well?

Take care,
John

>Regards,
>RD
>
>>
>>  At 10:35 +0100 2009/11/26, R?mi Despr?s wrote:
>>>  Le 26 nov. 2009 ? 06:34, Vint Cerf a ?crit :
>>>
>>>>
>>>>  + remi despres
>>>>  +steve casner
>>>
>>>  + Barry Wessler
>>>
>>>>  John, I am pretty sure that X.25 did not 
>>>>have datagrams in the same sense as 
>>>>Cyclades/Cigale or even ARPANET. There was a 
>>>>fast select but I thought it came later 
>>>>rather than earlier in the X.25 story?
>>>
>>>  The first X.25, published in 1976 in the 
>>>CCITT Orange book, had only virtual circuits 
>>>(VCs).
>>>  They were soon deployed in Canada (Datapac), 
>>>in France (Transpac), and the US (Telenet).
>>>
>>>  Four years later, datagrams were introduced in X.25.
>>>  They were only optional, while VCs remained mandatory.
>>>  Quite different from IMP-to-IMP packets of 
>>>Arpanet and Internet datagrams, they had some 
>>>control by customers of packet drop conditions.
>>>
>>>  In my recollection, they had been added under 
>>>political pressure from some administrations 
>>>that didn't operate X.25 networks.
>>>  Four years later, as no X.25 operator had 
>>>plans to implement them, they were deleted 
>>>from X.25.
>>>
>>>  Regards,
>>>
>>>  RD
>>>
>>>>
>>>>  v
>>>>
>>>>  On Nov 25, 2009, at 7:14 PM, John Day wrote:
>>>>
>>>>>  Yea, that jibes with my recollection.
>>>>>
>>>>>  And "datagrams" were in the first version 
>>>>>of X.25 in 76, or was that Fast Select?
>>>>>
>>>>>
>>>>>  At 18:45 -0500 2009/11/25, Vint Cerf wrote:
>>>>>>  the type 3 packets were explicitly used 
>>>>>>for real-time packet voice and later packet 
>>>>>>video experiments. This would have been in 
>>>>>>the 1975 time frame (but Danny Cohen and 
>>>>>>Steve Casner would know for sure as they 
>>>>>>were at ISI; Lincoln Labs was also involved 
>>>>>>and we used their packet 
>>>>>>digitizers/compressors. Duane Adams managed 
>>>>>>the packet voice activity during the time I 
>>>>>>was at DARPA so I am copying him too. I 
>>>>>>don't seem to have steve casner's email but 
>>>>>>I think he is now at PARC.
>>>>>>
>>>>>>  vint
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On Nov 25, 2009, at 6:05 PM, Richard Bennett wrote:
>>>>>>
>>>>>>>  I've discussed this issue recently with a 
>>>>>>>key member of the IMP team at BBN and he 
>>>>>>>(unsurprisingly) has a very different 
>>>>>>>recollection of the facts. A datagram mode 
>>>>>>>was added to the IMP and to X.25 switches 
>>>>>>>fairly early. Datagrams appeared on 
>>>>>>>research networks well before TCP/IP was 
>>>>>>>defined; CYCLADES had them in 1972.
>>>>>>>
>>>>>>>  The BBN people have not been able to tell 
>>>>>>>me whether the NWG ever took advantage of 
>>>>>>>the datagram mode in the IMP; that was 
>>>>>>>outside their department.
>  >>>>>>
>>>>>>>  RB
>>>>>>>
>>>>>>>  Bob Braden wrote:
>>>>>>>>
>>>>>>>>  My memory was that BBN included type 3 
>>>>>>>>(Uncontrolled or "raw") messages in the 
>>>>>>>>IMP protocol as an experiment, which they 
>>>>>>>>then considered too dangerous to use . 
>>>>>>>>BBN disabled them at (almost?) all hosts 
>>>>>>>>(almost?) all the time, I believe. 
>>>>>>>>TCP/IP used standard reliably-delivered 
>>>>>>>>IMP traffic. But the facility must have 
>>>>>>>>been enabled for the packet voice 
>>>>>>>>experiments shown in that marvelous video.
>>>>>>>>
>>>>>>>>  My memory on this point is hazy, but 
>>>>>>>>probably Vint can correct me. When Barry 
>>>>>>>>Leiner became (D)ARPA Program Manager for 
>>>>>>>>the Internet research program, he became 
>>>>>>>>determined that BBN should try using Type 
>>>>>>>>3 IMP-IMP packets for normal TCP/IP 
>>>>>>>>flows. He complained to the ICCB/IAB that 
>>>>>>>>BBN was resisting.  He insisted that the 
>>>>>>>>experiment be tried for 24 hours. 
>>>>>>>>Unfortunately I don't recall that the 
>>>>>>>>experiment ever happened;
>>>  >>>>> it is more than possible that BBN stone-walled his demand.
>>>>>>>>
>>>>>>>>  Bob Braden
>>>>>>>>  '
>>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>>  Richard Bennett
>>>>>>>  Research Fellow
>>>>>>>  Information Technology and Innovation Foundation
>>>>>>>  Washington, DC
>>>>>
>>>>
>>>>
>>>>
>>>>
>>




From touch at ISI.EDU  Sun Nov 29 12:53:51 2009
From: touch at ISI.EDU (Joe Touch)
Date: Sun, 29 Nov 2009 12:53:51 -0800
Subject: [ih] reminder from the list manager about posting problems
Message-ID: <4B12DF5F.9080005@isi.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

Please remember to:
	
	- trim your "reply-all" lists down
	it's usually sufficient to reply just to the list

	- send directly to the list, not cc'd

Posts with too many recipients or cc'd/bcc'd are typically held for
review to avoid blast cross-postings. Following the above rules will
avoid triggering the traps.

Joe (as list admin)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksS318ACgkQE5f5cImnZrtlFQCgjZf9ZXxLhZvwBuNr6G7pCdOB
D6oAniDvghEYh0woWzcw3+Ii/Yp8mwB6
=HVRs
-----END PGP SIGNATURE-----


From louie at transsys.com  Sun Nov 29 13:53:35 2009
From: louie at transsys.com (Louis Mamakos)
Date: Sun, 29 Nov 2009 16:53:35 -0500
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <20091126164833.8A8B66BE59B@mercury.lcs.mit.edu>
References: <20091126164833.8A8B66BE59B@mercury.lcs.mit.edu>
Message-ID: <36C6C90B-46B1-4211-96EE-A8082A29024E@transsys.com>


On Nov 26, 2009, at 11:48 AM, Noel Chiappa wrote:
> 
> Why exactly fragmentation didn't work so well I don't recollect very well
> (if we ever knew for sure exactly why). I suspect that the network back
> then was 'lossier' (partly due to poor congestion control causing
> congestion drops, partly due to flakier transmission systems). Since
> end-end retransmission schemes don't work so well when loss rates go up
> (typically there's a 'knee' where performance goes over a cliff), with
> that many more packets involved for a given amount of data, we may have
> gone over the 'knee'.


We encountered a particular syndrome related to poorly designed 
network interface hardware; though this was in early Ethernet network
interfaces, and not 1822 LH/DH interfaces.  When generated, IP fragments
tended to have very small inter-packet gap times since the fragmentation
operation happend pretty "close" to the network interface, as compared
to sequentially generated data from the application.

One fairly painful manifestation of this that I experienced was in the
phase-2 NSFNET backbone, with T-1 trunks to upgrade from the 56kb/s
trunks between the "fuzzballs" on the phase-1 backbone.  The phase-2
NSFNET routers were built out of IBM RT hardware, and the Ethernet
interfaces to the co-located subscriber site used the early 3Com 3C501
PC-AT Ethernet controller.  Ah, what a wretched piece of hardware this
was!  It had minimal on-board buffering, using the same buffer for receiving
a frame as well as transmitting an outgoing packet.  A train of larger,
back-to-back packets on a busy interface was just about worst-case.  We
customers donated the later 3C503 cards to the cause to make this 
stop hurting as much.

There was a similar issue with NFS over UDP, with 8kbyte IP packets,
where the same retransmitted packet would never complete because
fragment 4 or so would never reliably be received because of the
small inter-packet gap.  In this case, reusing the same IP ID field on
the retransmitted packets was of no help at all.

Of course, these days the hardware is more powerful and not so performance
constrained, and the CPU in the end systems have more MIPS available to 
service the hardware.  The bottlenecks have moved elsewhere, now that
we've got multiple CPU's all trying help.  

Certainly in later years, all sorts of interesting bugs related to firewalls
and packet filtering attempts came to light..

Louis Mamakos
 


From richard at bennett.com  Sun Nov 29 14:10:31 2009
From: richard at bennett.com (Richard Bennett)
Date: Sun, 29 Nov 2009 14:10:31 -0800
Subject: [ih] Arpanet raw messages, voice, and TCP
In-Reply-To: <36C6C90B-46B1-4211-96EE-A8082A29024E@transsys.com>
References: <20091126164833.8A8B66BE59B@mercury.lcs.mit.edu>
	<36C6C90B-46B1-4211-96EE-A8082A29024E@transsys.com>
Message-ID: <4B12F157.4080503@bennett.com>

An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091129/9a772edc/attachment.htm>