[governance] Uni.X to Uni.X .NETworking - PPSSSDDD

[Jim Fleming]

Uni.X to Uni.X .NETworking - PPSSSDDD

Taking an 8-bit code-bloat protocol field and boiling it down to basics one
can
not only mine some new address bits (SSSDDD) they can also reduce the need
for governance of the code-bloat fields.

In research systems, ICMP is 1, TCP is 6 and UDP is 17. There is no NOP
protocol
with the data in the same header. Religious zealots view that as a protocol
layer violation.
When looking at Uni.X to Uni.X .NETworking as a process to process
communication
or better yet, an object to object message mechanism, layering does not
matter. The 160 bit
message is a data structure. There are many data structures in a system.
They do not require
governance. People writing the code design them and maintain them.

With 2 bits for the PP field they could be assigned based on prior order:

00 - NOP
01 - ICMP (was 1)
10 - TCP (was 6)
11 - UDP (was 17)

The labels TCP and UDP might be better as TCP-like and UDP-like to indicate
Reliable Stream
and Datagram. In theory, a variety of TCP-like protocols could be used, if
negotiated via ICMP.
ICMP is commonly called a signalling channel or protocol.

The NOP protocol impacts the way the 10 Length bits and 16 Check-Sum bits
are handled.
Those 26 bits form a 2+24 arrangement with 2 bits indicating the number of
bytes in the other
24 that are valid. Zero to three bytes can be encoded, each with 8 bits.
Those bytes then stream
into upper layer protocols to form more complex protocols. Three bytes can
encode keystrokes
in IM Instant Message sessions. It is hard to reduce more than 160 bits, but
the fixed fields make
it easier to consider various compression schemes, but those would become
less useful as time
goes on and more address bits are activated. There is no free lunch on the
time-space trade-offs
and the bandwidth required. Vendors now look carefully at who is paying for
what traffic and
attempt to optimize their bottom line. A smaller, more light-weight solution
may have a better
chance of not being a burden and survive some of the de-peering that is
coming.

_______________________________________________
governance mailing list
governance at lists.cpsr.org
https://ssl.cpsr.org/mailman/listinfo/governance