Re: Should we share?

[mikebw@bilow.bilow.uu.ids.net (Mike Bilow)]

 LAM> But consider the concept, rather than the current implementation.

You have a point, but I don't think we can afford to be completely impractical.

 LAM> Having a communications subnet running below IP which could span
 LAM> multiple frequencies, modem technologies and access methods and have
 LAM> it appear as a logical "subnet" to IP might be a good thing.  

It might also be a bad thing.  IP is designed to *be* the network layer
protocol.  If you implement network layer-like features below it, IP can start
to do very funny things.  One could even argue that IP ceases to be useful, and
just adds lots of extra bits.  I understand that what you are suggesting is to
make IP the "internetworking protocol" rather than the networking protocol, and
that this is not unreasonable.

 LAM> This is what Frame Relay is today - level 2 switches running their own
 LAM> routing protocol that give IP the appearance of a multiple access
 LAM> network.  And ATM.

 LAM> The ARPANET was also built like this, with IMPs, er, PSNs acting as
 LAM> level-2 switches, carrying multiple protocols above it.

 LAM> This approach also has some desirable properties in that instability
 LAM> in the level-2 fabric need not preturb the IP routing system.  On the
 LAM> Internet today, this would would be a good thing.  The routing "flux"
 LAM> is rather high these days..  

We are still left with the need to run something above AX.25.  Whatever else we
do, AX.25 is written into the law in most places, including the United States,
and that is even worse than being written into the TNC firmware.  Most
protocols which even begin to approach the level of capability that you are
describing have not been highly successful; I would put netrom in that class.

I would remind you that ARPANET abandoned their system for good reasons.  ATM
and similar systems are attractive to common carriers who must provide for the
traversal of digital data in essentially raw form, meaning that they require
protocol independence or at least multiprotocol support.  Amprnet is an
IP-based network and will remain so.  While we might someday be using IPv6 or
IP-flavor-of-the-month, that will be a network other than Amprnet even if it is
connected to Amprnet.

 LAM> There may be good reasons to seperate this out - consider the future,
 LAM> where you have multiple applications competing for bandwidth.  You
 LAM> could logically define multple communication subnets over the same
 LAM> medium, and have different bandwidth available to each one.  Assuming
 LAM> the fabric was smart enough, you can reserve some minimal amount of
 LAM> bandwidth for each logical comm subnet - sort of like a Frame Relay
 LAM> CIR.

I can see this being a high priority for a large common carrier, say U.S.
Sprint, but I can't see any future demand for this on Amprnet.  I agree that it
would be a nice feature, but it introduces a whole added layer of management
hassles.  We are not a telephone company and do not have the organizational
resources of a telephone company.  We are going to be limited to whatever we
can make the boxes do on their own without substantial human intervention.

 LAM> This is just what you have today on your ethernet if you're bridging
 LAM> segments together.  IP (or DECnet or IPX, etc) are completely unaware
 LAM> of the Spanning Tree algorthm running in the bridges which are the
 LAM> fabric of the Ethernet LAN.

I'm not sure I would agree with your opinion on this.  First of all, no one in
the real world actually does it that way.  Ethernet segments in almost all
practical installations are connected by routers, even if their managers don't
understand that.  Novell and IPX, for example, have previously been routed
dynamically via a flavor of RIP, but sanity has prevailed and Novell is in the
process of introducing an OSPF-like protocol called NLSP.

The spanning tree algorithm is perfectly general.  You could, in theory,
implement it over mail instead of IP frames.  It applies to any system for
which a map can be drawn.

 LAM> This sort of "packet radio fabric" implementation might be what's in
 LAM> the 'TNC' of tomorrow, which presents some generic interface to the
 LAM> actual nodes on the net.

The problem is that you get into a situation of infinite regress in the quest
to be perfectly general.  The whole point of IP was that you can run lots of
different stuff over it.  If you say that we now need something interposed
between IP and the link layer so that we can run things other than IP, or so we
can simplify IP, then we just beg the question.

We have physical problems on Amprnet which are fundamentally different from any
other IP-based network.  We could try and fix that by developing a shield for
IP so that it sees something that looks like a connected Ethernet LAN.  I don't
see that as a particularly hopeful pursuit, and I think you would end up with
something that looks and works like netrom.

In my opinion, we need to start with the lowest level bit twiddling.  We need
to build basic forward error correction and redundancy into the physical layer.
 If we do this, we are no longer walking on the frontier of routing protocols,
but can do standard kinds of things.  I also believe that making TNCs that
implement a reliable physical layer would end up being cheaper, easier, and
have better payback than trying to concoct a TNC that operates like a telephone
switch.

 LAM> I think that this was what Brian was getting at in his comments a few
 LAM> days ago.

I'm never quite sure what Brian is getting at in his comments.  :-)

 LAM> We ought to be open to new ideas; ham radio is infamous for taking
 LAM> just-now-working technology, declaring it a standard, and shipping it
 LAM> to the masses before being able to develop a *good* solution, rather
 LAM> than a *working* in the lab sort of solution.  (Bell 202 modems,
 LAM> AX.25) Just because it works for 1, 10 or 100 doesn't mean it scales
 LAM> well to 10000.

This is very true.  The question remains: now what?

-- Mike