RE: a new way to do anonymity

[Johnathan Corgan <jcorgan@aeinet.com>]

-----BEGIN PGP SIGNED MESSAGE-----

>   There are many, many analogies you can draw about a network of this
>   type to an ATM (asynchronous transfer mode) network.  
>
>Thank you for the analogy.  It's always good not to reinvent the wheel
>when you don't need to.

Exactly.  Anywhere we can "stand on the shoulders" of others reduces wasted
time and effort.

>When you set up a mapping on a packet forwarder, this is exactly the
>kind of initialization that would be required.  It is also at this
>point that keying would be negotiated, etc.

Encrypt-Telnet to a switch process.  Use text based command line sequence
to check outbound paths, bandwidth available, negotiate quality of service,
execute digital payment arrangements, etc.  Conclude the transaction and
get bumped to your next hop, where it happens all over again.

Done right, it could probably be automated.  It seems like a lot of effort,
but if you remember that once an initial session is established with your
Pipe-net Service Provider (tm), a given circuit can be relatively long-lived.

>Now here's an important detail that needs to get done right.  Is the
>forwarding for fixed length packets, variable length packets, or
>streams?  Is this decision global or local?  What are the latency and
>aggregatation effects?  How important are these for different classes
>of data?  (telnet v. voice, e.g.)

One of the lessons learned in the years-long debate between the telco folks
pushing synchronous time-division multiplexing point to point circuit switches 
and the data folks pushing variable length packet-switched broadcast medium
networks is that fixed length packets can give you both TDM and statistical
multiplexing.  So, at the bottom most session layer, moving bits around in
fixed chunks allows you to do things easier like bandwidth pre-allocation,
aggregation, circuit based congestion control, and negotiated quality of
service agreements to end points in the network.

To learn from the efforts that have come from the thousands of people working
on ATM, we could take a look at what has emerged as the "ATM Adaptation Layer."

AAL specifies methods to encapsulate various data formats and quality of service
requirements onto this fixed length, continuous stream of data packets.  There
is one for voice traffic, which requires fixed bandwitdth and very little relative
latency, another for LAN type data packets, which have bursty bandwidth requirements 
and variable packet sizes.  Your comment above is accurate in that the
requirements involved in a Telnet session are vastly different from say, PGP
Phone over TCP.

The good part about all this is that a lot of the thinking, testing, prototyping,
and standardization has already been done.  The standards exist today for adapting
variable bandwidth, variable packet length, variable latency data packets onto
a continous stream of fixed length packets moving through a switched network.

This reminds me of the old days of Packet Radio which used intelligent repeaters
that you would access (via command line), determine your next repeater, then
log into it, etc.  I once established virtual circuit from Connecticut to Florida
over 2 meter packet that took 25 or so hops, and had a transit delay of a half
an hour.  Primitive, kludgy, unreliable, and essentially useless, but totally cool.

An opportunity presents itself here to establish this Pipe-net style service
network, that would greatly expand the ability for network users to essentially
bypass all the crap which appears to be coming down on us from our friendly 
representatives in Washington, who are trying so hard to "protect" us from 
ourselves. 

>I'd suggest just getting something running first, to get some
>prototyping experience.

Of course.  What I've outline is a pretty ambitious goal.  I'd be happy to see
primitive switch implementations that do nothing more than forward TCP streams.
Its a start and we would learn a lot along the way.  Alas, I don't do Unix; my
programming expertise is in (gasp) the Windows environment.  So it looks like
I could start looking at the requirements implementation of a Winsock interface
that made all this stuff transparent to an end user.  Important consideration.

I suppose the IRC folks could add their experience to the mix.  In a very real
way, IRC _is_ a packet switched unicast/multicast stream service on top of the
'net.  Do we have any IRC op types onboard here?

==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan@aeinet.com                    -Isaac Asimov
WWW:                     ftp://ftp.netcom.com/pub/jc/jcorgan/home.html


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzhqMU1Diok8GKihAQGRxAP/dWIvYMuqX5c1y/Mlmc73WQlQ/1263vqb
YzGMvgTFEP0p/jZZstb8tMOyHY2KKp7WWLXV94jd8/KhdQgYFtGHphVm93WP3Bu8
hRK8kV5UEtANQ/JycVHG6HU3MMxLhE+Yh+M/CFLBwBZZYYglnV3DLqBHv4kq+5Tg
/7ZiTjnHRDk=
=ee6L
-----END PGP SIGNATURE-----