Date: Fri, 5 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #61
To: tcp-group-digest
TCP-Group Digest Fri, 5 Mar 93 Volume 93 : Issue 61
Today's Topics:
hidden transmitter routing
Link Layer replacement (8 msgs)
Multicast
Packet, TAPR and NET
physical layer and FEC engineering (4 msgs)
vadcg
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 4 Mar 93 15:23:37 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: hidden transmitter routing
To: tcp-group@ucsd.edu
> 2. A protocol for multiple access. This one has to be designed
> with the hidden transmitter problem in mind. It also has to allow
> for stuffing into the ROM on a TNC2. While we can change the
> protocol, the large user community will not yet throw away their
> TNCs (remember P.O.T.S.). Rates are 1200 and up at VHF/UHF.
>
This is really a routing problem. RSPF is the right direction to go.
You don't need a separate protocol for this, you just run it on top of IP.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Thu, 04 Mar 1993 08:32:21 -0500
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Link Layer replacement
To: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
> Exactly. That's why I'm proposing a single link layer interface that
> you use to pass packets between the network software (IP), and the
> link layer. But we need to design _different_ methods of
>
> a) bit representation on the physical medium
>
> b) medium access
>
> c) error correction and detection
>
> d) link address
>
> Therefore while we need ONE link layer interface, we need a SET of
> Physical and MAC layers.
Again, I have to disagree. You standardize or write specifications for
PROTOCOLS, you don't need to define and foist an software interface on
people.
Again, I offer an existance proof of today's internet. We have IP
over all sorts of different media, INCLUDING SLIP, PPP and AX.25.
Just what do 10Mbps Ethernet (CMSD/CD on coax, twisted pair and
optical fiber), 100Mbps FDDI (Token Ring on single and multimode
optical fiber), PPP (1.2Kbps to >1.5Mbps async and sync serial), SMDS
(Switched Multimegabit Data Service, sort of subscriber interface to
ATM technology) have in common? Not much. We have a wide mix of
media access, performance and features. Heck, in the case of ethernet
and token ring, even though they in theory share this IEEE 802.2
"encapsulation", no one uses it on ethernet for IP, and the MAC
addresses are in different formats!
About all that they share in common, as far as we're concerned, is
they you can shove IP datagrams (and other stuff) over them. What is
to be gained in this situation by specifing a common link level
interface? Why is this different for amateur radio, other than NIH?
I think that it is a wonderful thing to design and specify media
encapsulation protocols (IP on 300bps HF/FSK with FEC, IP on 9600bps
PSK, etc). You just define how an IP datagram (or whatever you want
to carry) is encapsulated using a particular medium. It works now,
its just that hams have insisted in somehow involving the mistake
called AX.25 in most of the networking amateurs do.
You don't need, and I claim that you don't want a single link layer
interface, as you won't get one that's universally appropriate for all
the media you want to use. I just don't see the benefit and only see
the potential for painting yourself in a corner and being really sorry
about it in the future.
Louis Mamakos
wa3ymh
------------------------------
Date: Thu, 04 Mar 93 12:52 CST
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Subject: Link Layer replacement
To: tcp-group@UCSD.EDU
Louis Mamakos, WA3YMH, writes:
>I think that it is a wonderful thing to design and specify media
>encapsulation protocols (IP on 300bps HF/FSK with FEC, IP on 9600bps
>PSK, etc). You just define how an IP datagram (or whatever you want
>to carry) is encapsulated using a particular medium. It works now,
>its just that hams have insisted in somehow involving the mistake
>called AX.25 in most of the networking amateurs do.
There's been lots of experience across the Internet specifying media
encpsulation protocols from everything from FDDI down to carrier pigeons.
By and large, it consists mainly of embedding the IP frame, fragmented
as needed, in a MAC layer frame. AX.25 is just one way of doing that.
I won't defend it as a protocol, but I will note that doing so has some
significant regulatory advantages. Like many other standards, it was
widely adopted because it was the first usable one to come along.
To replace it, you'll need to come up with something that both is clearly
better - to J. Random Ham, not just to the techno-weenies - but also
addresses the concerns of the regulatory bodies, most notably being able
to easily identify just who sent a particular frame.
...Jay, K5ZC (Mr. $5000 TNC! :-)
------------------------------
Date: Thu, 4 Mar 1993 13:24:45 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Link layer replacement
To: tcp-group@UCSD.edu
There is confusion and dispute about why we would want to build a new
link layer to replace AX.25 and run under IP.
The major reason I see is that we have no protocol layer at this time
that is designed to route packets between moving targets (mobile stations)
with ever-changing paths (due to propogation) between those targets.
RSPF is a start in this direction, however there are fundamental problems
with running RSPF at the IP layer because IP simply wasn't designed for
that.
The reason we are attempting to agree on a common link layer is so that
we can implement that routing across several different radio
environments. Designing this routing scheme will be the hardest part,
even if we start with RSPF. One of the reasons I wanted to have room for
more than one kind of address is that I think this is going to be a
learning process, and whatever we design, we'll want to extend it in a
few years.
I have the list-server software at Pixar now, and will have it set up
in a few days so that we can move this discussion off of tcp-list.
Bruce Perens KD6OTD
------------------------------
Date: Thu, 4 Mar 1993 14:06:52 -0800
From: George Farris <george@ve7frg.ampr.org>
Subject: Link Layer replacement
To: tcp-group@ucsd.edu
On Mar 4, 12:52pm, Jay Maynard wrote:
} Subject: Re: Link Layer replacement
> Louis Mamakos, WA3YMH, writes:
> >its just that hams have insisted in somehow involving the mistake
> >called AX.25 in most of the networking amateurs do.
>
> To replace it, you'll need to come up with something that both is clearly
> better - to J. Random Ham, not just to the techno-weenies - but also
Why does this have to satisfy J. Random Ham? Most hams have little idea
about networking and probably don't understand the benefits of such.
All J. R. Ham wants is to plug his black box into his computer and go
which is fine but we don't need to satisfy someone who is happy with
AX.25 to begin with.
Lets concentrate on doing a good job technically. Once in place J.R.
Ham will fall into place with a new black box or stay with his old AX.25
stuff. Satisfying regulations is one thing but....
Just my opinion :-) Of course you all realize that this will likely
never come to fruit. How many times is it that this subject has been
beaten to death already?
--
==========================================================================
George Farris - VE7FRG Internet : george@ve7frg.ampr.org
Amprnet : george@ve7frg.ampr.org
Sidney, B.C. UUCP : sol.uvic.ca!ve7frg!george
(604) 656-0342 AX.25 : ve7frg@ve7vbb.bc.can.noam
------------------------------
Date: Thu, 4 Mar 1993 13:24:45 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Link layer replacement
To: tcp-group@UCSD.edu
There is confusion and dispute about why we would want to build a new
link layer to replace AX.25 and run under IP.
The major reason I see is that we have no protocol layer at this time
that is designed to route packets between moving targets (mobile stations)
with ever-changing paths (due to propogation) between those targets.
RSPF is a start in this direction, however there are fundamental problems
with running RSPF at the IP layer because IP simply wasn't designed for
that.
The reason we are attempting to agree on a common link layer is so that
we can implement that routing across several different radio
environments. Designing this routing scheme will be the hardest part,
even if we start with RSPF. One of the reasons I wanted to have room for
more than one kind of address is that I think this is going to be a
learning process, and whatever we design, we'll want to extend it in a
few years.
I have the list-server software at Pixar now, and will have it set up
in a few days so that we can move this discussion off of tcp-list.
Bruce Perens KD6OTD
------------------------------
Date: Fri, 5 Mar 93 09:53:21 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Link Layer replacement
To: "Louis A. Mamakos" <louie@NI.umd.edu>,
In atricle by "Louis A. Mamakos":
>
>
> > Exactly. That's why I'm proposing a single link layer interface that
> > you use to pass packets between the network software (IP), and the
> > link layer.
>
> Again, I have to disagree. You standardize or write specifications for
> PROTOCOLS, you don't need to define and foist an software interface on
> people.
If we don't have a well-defined software interface (e.g the format of
IP packets, or Ethernet packets, or the 802.2 LLC or the KISS protocol),
then there is no well-defined way to use a protocol.
Remember, a communications layer not only interacts with its remote
peer, but also the layer above and below (at least).
> Again, I offer an existance proof of today's internet. We have IP
> over all sorts of different media, INCLUDING SLIP, PPP and AX.25.
Yes, but the IP packet format is the same in all cases. I was arguing
for a consistent link layer packet format regardless of the MAC and
physical layers.
> What is
> to be gained in this situation by specifing a common link level
> interface? Why is this different for amateur radio, other than NIH?
Think of it this way. NOS uses KISS to send packets to/from TNCs, regardless
of whether they are running at 300, 1200, 9600 baud etc. Wouldn't it be nice
to have a similar situation after we've designed new physical and medium
access methods?
> You don't need, and I claim that you don't want a single link layer
> interface, as you won't get one that's universally appropriate for all
> the media you want to use. I just don't see the benefit and only see
> the potential for painting yourself in a corner and being really sorry
> about it in the future.
I disagree, but of course the nice thing about protocols is that if what
you have is deficient, you can always go & design a new one.
Cheers,
Warren
------------------------------
Date: Thu, 4 Mar 1993 14:06:52 -0800
From: George Farris <george@ve7frg.ampr.org>
Subject: Link Layer replacement
To: tcp-group@ucsd.edu
On Mar 4, 12:52pm, Jay Maynard wrote:
} Subject: Re: Link Layer replacement
> Louis Mamakos, WA3YMH, writes:
> >its just that hams have insisted in somehow involving the mistake
> >called AX.25 in most of the networking amateurs do.
>
> To replace it, you'll need to come up with something that both is clearly
> better - to J. Random Ham, not just to the techno-weenies - but also
Why does this have to satisfy J. Random Ham? Most hams have little idea
about networking and probably don't understand the benefits of such.
All J. R. Ham wants is to plug his black box into his computer and go
which is fine but we don't need to satisfy someone who is happy with
AX.25 to begin with.
Lets concentrate on doing a good job technically. Once in place J.R.
Ham will fall into place with a new black box or stay with his old AX.25
stuff. Satisfying regulations is one thing but....
Just my opinion :-) Of course you all realize that this will likely
never come to fruit. How many times is it that this subject has been
beaten to death already?
--
==========================================================================
George Farris - VE7FRG Internet : george@ve7frg.ampr.org
Amprnet : george@ve7frg.ampr.org
Sidney, B.C. UUCP : sol.uvic.ca!ve7frg!george
(604) 656-0342 AX.25 : ve7frg@ve7vbb.bc.can.noam
------------------------------
Date: Thu, 4 Mar 1993 14:06:52 -0800
From: George Farris <george@ve7frg.ampr.org>
Subject: Link Layer replacement
To: tcp-group@ucsd.edu
On Mar 4, 12:52pm, Jay Maynard wrote:
} Subject: Re: Link Layer replacement
> Louis Mamakos, WA3YMH, writes:
> >its just that hams have insisted in somehow involving the mistake
> >called AX.25 in most of the networking amateurs do.
>
> To replace it, you'll need to come up with something that both is clearly
> better - to J. Random Ham, not just to the techno-weenies - but also
Why does this have to satisfy J. Random Ham? Most hams have little idea
about networking and probably don't understand the benefits of such.
All J. R. Ham wants is to plug his black box into his computer and go
which is fine but we don't need to satisfy someone who is happy with
AX.25 to begin with.
Lets concentrate on doing a good job technically. Once in place J.R.
Ham will fall into place with a new black box or stay with his old AX.25
stuff. Satisfying regulations is one thing but....
Just my opinion :-) Of course you all realize that this will likely
never come to fruit. How many times is it that this subject has been
beaten to death already?
--
==========================================================================
George Farris - VE7FRG Internet : george@ve7frg.ampr.org
Amprnet : george@ve7frg.ampr.org
Sidney, B.C. UUCP : sol.uvic.ca!ve7frg!george
(604) 656-0342 AX.25 : ve7frg@ve7vbb.bc.can.noam
------------------------------
Date: Thu, 4 Mar 93 15:20:52 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: Multicast
To: tcp-group@ucsd.edu
> 4. (Maybe) A broadcast protocol for bulletin distribution.
> It might also be useful to be able to stuff this one into
> the TNC2 ROM. It could help ease the pressure on our crowded
> VHF channels.
>
This is really a "multicast" protocol. You would send it to the multicast
address "all NNTP systems" or "all BBS systems", etc.
You don't need a separate link layer for it, it should run on top of IP.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Thu, 4 Mar 93 13:30:26 MDT
From: Karl Larsen <klarsen@mercury.arl.army.mil>
Subject: Packet, TAPR and NET
To: tcp-group@ucsd.edu
It is too bad I must miss the TAPR metting this year. The
meeting will have the hams that designed the TNC-1 and 2 with the
ham that produced the NET.EXE software we all enjoy now as radio
and internet capable tcp/ip. It's certain there will be
discussions on HF packet and improved AX.25 structure.
____________________________
| Internet IP 155.148.6.2 |
| Fido 1:305/111 |
| k5di@k5di.nm.usa.na |
| Ham IP 44.30.2.5 |
| (505) 678-3145 weekdays |
|__________________________|
------------------------------
Date: Thu, 04 Mar 93 06:46:42 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: physical layer and FEC engineering
To: karn@qualcomm.com
noao!karn@qualcomm.com (Phil Karn) writes:
> I'll be there too. Friday night, at least (they were booked up for Saturday,
> gotta find alternative plans).
>
> Phil
There are several others within walking distance. Embassy Suites
602-573-0700; Clarion, 602-746-3932; Hampton Inn, 602-889-5789; Marriott
Courtyard, 602-573-0000 (I think they have weekend rates). If you have a
car, there are lot's more, of course.
Bob
Bob Nielsen W6SWE Tucson, Arizona
ax.25: w6swe@kc7cg.az.usa.na Internet: rnielsen@tapr.ampr.org
------------------------------
Date: Thu, 4 Mar 93 9:53:26 CST
From: ve4drk@muug.mb.ca (Dan Keizer)
Subject: physical layer and FEC engineering
To: brian@UCSD.EDU (Brian Kantor)
> Home of packet and all that.
let's not forgot about the venerable VADCG from Vancouver ... the truly
first ampr packet system. Those guys deserve credit too :-)
Dan.
PS: I still have 2 boards from that era ... ol' 8085 based systems! wow.
------------------------------------------------------------------------
Dan Keizer, VE4DRK ve4drk@pc.ve4drk.ampr.org [44.135.124.25]
ve4drk@muug.mb.ca VE4DRK@VE4KV (AX.25) Winnipeg, Manitoba Canada
------------------------------
Date: Thu, 4 Mar 93 08:21:13 -0800
From: brian (Brian Kantor)
Subject: physical layer and FEC engineering
To: ve4drk@muug.mb.ca
Yup, I have a working VADCG board myself. It's sitting on the shelf in the
garage right next to the TAPR Beta TNC.
But you will have to admit that packet really didn't take off until the TAPR
TNC popularized it.
- Brian
------------------------------
Date: Thu, 4 Mar 93 15:13:38 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: physical layer and FEC engineering
To: tcp-group@ucsd.edu
> It would seem to me that the upcoming TAPR meeting (in Tucson this
> weekend) would be a fine opportunity to brainstorm some of these ideas,
> waving arms and hands around. Home of packet and all that.
>
Good idea.
Could someone volunteer to write up a list of requirements for the
revision?
Something simple with:
- layer names for us to agree on. It doesn't have to be ISO,
just so that we stop talking at cross purposes.
- what goes in what layer, under *our* definition above.
- absolute requirements
-- source/dest in every packet header?
-- binary/ascii?
- a wish list
-- multicast?
-- aggregated frames?
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Thu, 4 Mar 93 10:59:06 CST
From: ve4drk@muug.mb.ca (Dan Keizer)
Subject: vadcg
To: brian@UCSD.EDU (Brian Kantor)
> But you will have to admit that packet really didn't take off until the TAPR
> TNC popularized it.
Sure, TAPR popularized it .. but I would dispute the birthplace of packet
per se. ... nothing like a good holy war hi. I just have a fair bit of
admiration for Lockhart and the VADCG guys for spearheading that development.
Dan.
------------------------------------------------------------------------
Dan Keizer, VE4DRK ve4drk@pc.ve4drk.ampr.org [44.135.124.25]
ve4drk@muug.mb.ca VE4DRK@VE4KV (AX.25) Winnipeg, Manitoba Canada
------------------------------
End of TCP-Group Digest V93 #61
******************************
******************************