Re: [midcom] WG scope/deliverables

[Lloyd Wood <l.wood at eim.surrey.ac.uk>]

On Wed, 31 Jan 2001, Ed Gerck wrote:

> You miss at least one other possibility.  If it is possible to develop
> an addressing scheme that works in a heterogeneous network, then
> we can have point-to-point functionality across system borders and
> do not require a homogeneous address space to do so.   Now, if you
> look into the science of Thermodynamics (for example) you will see that
> this involves a meta-problem that was already solved two centuries ago.

Explain.

> NATs are a consequence of a choice rather than makers of a choice.
> The choice is to use heterogeneous networks.

NATs fake a homogeneous address space for disjoint/overlapping
*homogeneous networks*. You just layer IP over the top of the
heterogeneous networks - so we already have that addressing scheme you
want.

NATs are primarily a consequence of heterogeneous administration with
short-term local-optimisation goals that dictate use of homogeneous
network technology. (Address space shortages are also a result of
heterogeneous administration of a homogeneous and limited resource. As
are most things.)

Considered use of truly heterogeneous networks does not offer the
local optimisation NATs do (more translation, gateway maintenance),
and is rejected.


> I contend that the reasons for this choice can be found in Nature

well, yes. everything can be found in nature.

> -- for example, to adapt to local needs
> without imposing more expensive non-local changes.  This is not an Internet
> phenomenon, it is IMO the reflection of a more general principle.

Oh, right. Since we're waffling;

http://pespmc1.vub.ac.be/SUBOPTIM.html

and Gleick's 'Faster' (and Vinge's 'Deepness in the Sky', for that
matter) make some interesting statements and predictions about the
system-wide dangers of local optimisations. The zeroth law of
thermodynamics does not, IMO; entropy analogies can be highly
misleading.

It's useful to reflect on why we should be designing protocols with a
lot of overhead, redundancy, and slack in them. Contrast the success,
adaptability, longevity and utility of the ever-so-slack http with
that of the bit-efficient gopher. The lack of slack in the ATM header.
Or the slack in the GSM control channel that led almost by accident to
SMS.

If there's no slack, there's no serendipity, no escaping the local
minimum by subverting it. 

That doesn't have much to do with anything other than the work
required to handle the protocol reliably in NAT, though.

L.

IETF: optimising everything into a dead-end local minimum since 1986.

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>