[ih] vm vs. memory

[Paul Vixie]

"egads, what i have i done?" --me

omnibus: there are four replies here.

---

John Levine wrote:
> In article<59EF79D0.2060906 at redbarn.org>  you write:
>>> Hmm... what are the redeeming qualities of NAT ?
>> every other attempt to add rapid renumbering and transparent multihoming
>> has been rejected. NAT, by not trying to do those things and by not
>> saying it would do those things, snuck under the defenses.
>
> There's also the fact that for most practical purposes, NAT just
> works, and IPv6 still doesn't.

to be clearer, ipv6 is not a salve for the ills addressed by NAT. there 
was some hope early on that ipv6 would offer an alternative to the pi/pa 
split, but ultimately every proposal was shot down in favour of a 
marketing slogan to get deployment to happen, somehow, anyway: "ipv6: no 
magic, just more bits."

with ipv6, nat is still required. but we use "ULA" so that if two 
companies both using ipv6 nat merge, neither has to renumber. that is a 
small upgrade from ipv4 where both companies used net-10, and it is not 
significant in internet history.

---

Toerless Eckert wrote:
 > Yes, these are the classical arguments.

[vixie]
 >> 1. the internal structure should not be visible or guessable.
 >>
 >> 2. reachability should be prevented by more than just firewalls.
 >>
 >> 3. you can add and drop transit providers as often as you want.

 > IMHO, arguments 1. and 2. have mostly failed, especially
 > in large enterprises.

you are wrong, by being outside the facts. your observations here are 
examples of absurdist reductionism, reminding me of the time someone 
explained to me why ipv6 added only three effective bits to those 
available to an endpoint, compared to ipv4. your criticism may look good 
on a whiteboard, but it completely fails to impress anybody who ever 
built a real network.

(that was the gentle version, edited after several hours of mellowing.)

 > Argument 3 (i think you mean access providers) is more interesting.

on this, we agree.

 > If it was me, would have just evolved and improved on rfc1928.

me too, which is why <http://family.redbarn.org/~vixie/proxynet.pdf>, 
but it was not accepted for publication, because by 1995, the world was 
converging on SOCKS.

---

Brian E Carpenter wrote:
 > On 25/10/2017 01:12, Paul Vixie wrote:
 >>
 >> vm is an example of something that started as a workaround but ...
 >
 > I disagree with that evaluation. It started in practice with the
 > famous "one-level storage system" paper from Manchester**, with the
 > specific goal of making a small high-speed memory look like a much
 > larger one. I don't think it was viewed as a work-around, but rather
 > as a brilliant engineering solution to the high cost of high-speed
 > memory, vastly easier to use than explicit overlays.

john levine already answered this, as well or better than i could have.

---

Noel Chiappa wrote:
 >      >  From: Paul Vixie
 >
>> every other attempt to add rapid renumbering and transparent
>> multihoming has been rejected. NAT, by not trying to do those
>> things and by not saying it would do those things, snuck under the
>> defenses.
 >
 > Bearing in mind that this is the Internet-_History_ list, and not the
 > Internet-_Architecture_ list, I will say just a little bit.

thank you for restricting your comments to matters of history.

> If you want your system to be able to do 'rapid re-numbering' and
> 'transparent multi-homing' (and I'm not sure quite what you mean by
> that ... you need to list those as requirements when you sit down and
> do the basic architecure - including the routing and addressing
> architecture ...

mr. chiappa, let me first say that you have always been something of a 
hero to me, largely due to your now-famous anti-RIP screed from decades 
ago. you were right in everything you said, and noone ever said it 
better. it therefore alarms me mildly to be disagreeing with you here.

the internet wasn't a wanted system. it's the perfect example of an 
airplane that would have to be launched unready, and then continuously 
rebuilt during flight. noone knew back-in-the-day what it would have to 
do. someone codified this with a famous aphorism, "we don't know what 
the world's digital infrastructure will look like 200 years from now, 
but we know it will be called The Internet."

there were no requirements, only vague ideas about interoperability and 
lack of central control. it was therefore never possible, ever, 
anywhere, to authoritatively "list those as requirements when you sit 
down". we never sat down, and we never will.

> I've thought extensively about how to do 'hard multi-homing' (as I'll
> name that particular flavour), and it's doable, but it needs to be
> built in up front.

i wish you well on your journey; let us all know how that works out for 
you. my own belief is that whatever we do next (ever), will be done from 
the network as it then exists, and that "up front" never happened, and 
never shall happen. i'll quote from my thesis, which Keio graciously 
allowed me to publish only in paper form so that it's weaknesses would 
be difficult to mine. (source code was in Lout:)

> @Section @Title {Rebuilding The Airplane In Flight} @Begin @DP
> All of the work described in this thesis was accomplished continuously with
> Internet and DNS service.  Each protocol change was introduced gradually and
> optionally such that previously existing client or server was adversely
> affected.  At times it was necessary to support incorrect existing practices
> by other implementers due to the size of the installed base.  In situations
> where the existing specification was ambiguous new features had to be encoded
> in a way that avoided this ambiguity or that required implementers of new
> features to do additional work to differentiate among ambiguous cases.
> @PP
> Neither the Internet nor the DNS can be stopped and restarted, nor upgraded
> as a whole unit.  New features must always be introduced in a way that is
> backward compatible and thus ``roll out'' incrementally.  This is similar in
> concept to rebuilding an airplane while in flight except with multiple teams
> working on different parts of the airplane at the same time and without an
> agreed upon plan for the new design.  In real terms this means that features
> such as those described in this document can take decades to fully design and
> deploy.  For this work it took 17 years.
> @End @Section

see also: <http://queue.acm.org/detail.cfm?id=1242499>

-- 
P Vixie