[rrg] Four SILOS (Cultures) for .NET Research & Development

"IPv3.com" <ipv3.com@gmail.com> Fri, 23 April 2010 16:33 UTC

Return-Path: <ipv3.com@gmail.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1056B3A68DF for <rrg@core3.amsl.com>; Fri, 23 Apr 2010 09:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_80=2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti+AoM1-o7Ej for <rrg@core3.amsl.com>; Fri, 23 Apr 2010 09:33:32 -0700 (PDT)
Received: from mail-qy0-f196.google.com (mail-qy0-f196.google.com [209.85.221.196]) by core3.amsl.com (Postfix) with ESMTP id F383C3A6957 for <rrg@irtf.org>; Fri, 23 Apr 2010 09:33:31 -0700 (PDT)
Received: by qyk34 with SMTP id 34so5474935qyk.10 for <rrg@irtf.org>; Fri, 23 Apr 2010 09:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=RWQU3JgU/ArxU4qa5yuI0mmW9oHYE2u3cEvwec0Jvoc=; b=BXIXbrmTz/+gnTWbVuAL7vU/hcXdbvz2RacnPd11mR3s0DKHEKv+b6Y03NnwR/yeTH izQd4XcqmlY4FRJGaBia+fWMR2Eb75A+RA+MiNeVPp2Hs687UCOhpEj9YcAe48pHVImz 18FDH9Zel++SxDixCU5DJvclxPDcSLpnsLwJ8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MZC5s6n2QgKBvIfB1C1Rluft1RxT3qX3gBAXJw7iPnHbjQofFpbmz/nWc13b/ZYoIA SV70jvkqf7FRnzDTN/sRWW7gDNqchs2PE5SclI1aatN0RGDDK6Hem6pvp7y8stlUah6Y JQIL6mIuDhRF5SsQv/hNxwsqtIPYHWQX7FXJ0=
MIME-Version: 1.0
Received: by 10.229.189.212 with SMTP id df20mr354970qcb.21.1272040397784; Fri, 23 Apr 2010 09:33:17 -0700 (PDT)
Received: by 10.229.248.83 with HTTP; Fri, 23 Apr 2010 09:33:17 -0700 (PDT)
Date: Fri, 23 Apr 2010 11:33:17 -0500
Message-ID: <u2z113c8ba81004230933u851394eelef2448f6c651445b@mail.gmail.com>
From: "IPv3.com" <ipv3.com@gmail.com>
To: rrg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [rrg] Four SILOS (Cultures) for .NET Research & Development
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Apr 2010 16:38:01 -0000

1. The first 160 bits of a packet are generally used to determine the
fate of those bits and some that follow.

2. The first 4 bits of those 160 bits are currently almost always 0100 (4).

3. Those 4 bits could be "viewed" under a different light, as
Source(S) & Destination(D) Address bits.

4. Debating Societies could be established for SDSD vs. SSDD or SSSS
with companion DDDD bits in later bits.

5. When a S & D bit are paired, full inter-working is allowed if all
values are allowed.

6. When SD bits are aggregated Best Practice can (artificially)
restrict values to 00 & 11, to prevent 01 & 10 firewall jumping.

7. Four bits can also be used for SILOs XXSD with XX creating FOUR
disjoint universes. 00 01 10 11

8. With SILOs the first 2 bis of the 160 then signal a Universe or Culture.

9. Four Distinct Cultures can Provide Humans with Choice, Diversity &
other places to go to avoid/escape Tribes, genders, religions, etc.

===================================
00 - UNIX
01 - ISOC, IETF, IRTF, IANA, ICANN, NANOG, RIRs...
10 - FCC, NTIA, NIST, LEOs...
11 - UN, ITU...
===================================

The UNIX Culture writes Code. The other Cultures each have their own
unique "style". The first 160 bits commonly delivered
to many Internet users can be shaped in many ways. Most humans would
not desire to have 2**158 "standards". It may be
interesting to see how the above FOUR Cultures shape the remaining 158 bits.

People may be surprised that the running systems can be "viewed"
differently and evolved, on-the-fly, as long as hardware,
software & operational procedures are properly orchestrated. Three
simple examples are: Reducing the 16-bit Length Field
to 10 bits, Turning OFF (Deprecating) Fragmentation freeing the Second
Word, and lastly Re-Engineering the 8-bit TTL
Field to be useful for Source & Destination Addressing or Mode Setting
for the TWO 32-bit Address Fields (Words 4&5).

There are many more examples, given 158 bits to "debate". One thing
for sure, IF you desire to place 128 bits in the 158
there are only 30 bits left. It is hard to touch 16 of those in the
Checksum. That leaves 14 bits. With 10 for Length, one is
down to 4. One could debate a long time if those 4 should be split 2
for TTL & 2 for Protocol. Is Protocol needed/desired?

Backing up, are 64-bits of Addressing desired? Could one of the
Address Fields be 64-bits for Destination and other bits
be used for a HANDLE to ID the Source ? Would a full 64-bit symmetric
HANDLE be needed ? Could the HANDLE size
expand over time as systems Deprecate ?

Backing way up, does the overall Architecture allow Maintenance &
Updates & Flag Days on Network Elements ?

Returning to the global view, how do the Four Cultures (SILOs) plan,
design, evolve ?

In the UNIX Culture (00) the next two bits could be SD or SS with the
Destination bits some place else. To simplify Code
and ASICs, the SD could be restricted to two values 00 and 11. That
limits the first four bits to 0000 or 0011.

The ISOC Culture (01) could wander around and start with SD set to 00.
Then someone could edict 10 AND note that the
160 bits become 320 bits. No concern can be given to performance or
bandwidth or the unwieldy management. With SILOs
people can walk away and note 0100 and 0110 are in play, to be
determined. The world awaits the outcomes.

...history has shown that Running Code tends to capture market share...