[TUHS] Re: Research Datakit notes

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

Just as the topic of TUHS isn't 'how _I_ could/would build a _better_ OS', but
'history of the OS that was _actually built_' (something that many posters
here seem to lose track of, to the my great irritation), so too the topic
isn't 'how to build a better network' - or actually, anything network-centric.

I'll make a few comments on a couple of things, though.


    > From: steve jenkin

    > packet switching won over Virtual Circuits in the now distant past but
    > in small, local and un-congested networks without reliability
    > constraints, any solution can look good. ... Packet switching
    > hasn't scaled well to Global size, at least IMHO.

The internetworking architecture, circa 1978, has not scaled as well as would
have been optimal, for a number of reasons, among them:

- pure scaling effects (e.g. algorithms won't scale up; subsystems which
  handle several different needs will often need to be separated out at a larger
  scale; etc)

- inherent lack of hindsight (unknown unknowns, to use Rumsfeld's phrase; some
  things you only learn in hindsight)

- insufficiently detailed knowledge of complete requirements for a
  global-scale network (including O+M, eventual business model, etc)

- limited personnel resources at the time (some things we _knew_ were going to
  be a problem we had to ignore because we didn't have people to throw at the
  problem, then and there)

- rapid technological innovation (and nobody's crystal ball is 100% perfect)

It has been possible to fix some aspects of the ca. 1978 system - e.g. the
addition of DNS, which I think has worked _reasonably_ well - but in other
areas, changes weren't really adequate, often because they were constrained by
things like upward compatibility requirements (e.g. BGP, which, among numerous
other issues, had to live with existing IP addressing).

Having said all that, I think your assertion that virtual circuits would have
worked better in a global-scale network is questionable. The whole point of
networks which use unreliable datagrams as a fundamental building block is
that by moving a lot of functionality into the edge nodes, it makes the
switches a lot simpler. Contemporary core routers may be complex - but they
would be much worse if the network used virtual circuits.

Something I suspect you may be unaware of is that most of the people who
devised the unreliable datagram approach of the internetworking architecture
_had experience with an actual moderately-sized, operational virtual circuit
network_ - the ARPANET. (Yes, it was basically a VC network. Look at things
like RFNMs, links {the specific ARPANET mechanism referred to by this term,
not the general concept}, etc.) So they _knew_ what a VC network would
involve.

So, think about the 'core routers' in a network which used VC's. I guess a
typical core router tese days uses a couple of OC768 links. Assume an average
packet size of 100 bytes (probably roughly accurate, with the bimodal
distribution between data and acks). With 4 OC768's, that's 4*38.5G/800 =
~155M packets/second. I'm not sure of the average TCP connection length in
packets these days, but assume it's 100 packets or so (that's a 100KB Web
object). That's still roughly _1 million cicuit setups per second_.

If the answer is 'oh, we'll use aggregation so core routers don't see
individual connections - or their setup/tear-down' - well, the same
can be done with a datagram system; that's what MPLS does. Work
through the details - VCs were not preferred, for good reasons.


    > Ethernet only became a viable LAN technology with advent of Twisted
    > pair: point to point + Switches.

It's really irritating that a lot of things labelled 'Ethernet' these days
_aren't_ _real_ Ethernet (i.e. a common broadcast bus allocated via CSMA-CD).

They use the same _packet format_ as Ethernet (especially the 48-bit
globally-unique address, which can usefully be blown into things at
manufacture time), but it's not Ethernet. In some cases, they also retain the
host interface<->network physical interface - but the thing on the other side
of the interface is totally different (such as the hub-based systems commmon
now - as you indicate, it's a bunch of small datagram packet switches plugged
together with point-point links).

Interfaces are forever; like the screw in light-bulb. These days, it's likely
an LED bulb on one side, powered by a reactor on the other - two technologies
which were unforseen (and unforseeable) when the interface was defined, well
over 100 years ago.

	Noel