Date: Sun, 28 Nov 93 04:30:14 PST From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V93 #126 To: Ham-Digital Ham-Digital Digest Sun, 28 Nov 93 Volume 93 : Issue 126 Today's Topics: ATM on Amateur Radio? Ham Radio - Internet gateway wb7tpy gateway (3 msgs) Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 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: Sat, 27 Nov 1993 21:38:26 GMT From: swrinde!gatech!udel!darwin.sura.net!ra!atkinson@network.ucsd.edu Subject: ATM on Amateur Radio? To: ham-digital@ucsd.edu In article im@hydra.CARLETON.CA (Ian McEachern VE3PFH) writes: >First off there is nothing saying that Amateur Radio ATM will need >26 Mbps, or anything on that order to do something usefull. No, but the overhead due to ATM cell size and header structure is high. On top of that, one has ATM Adaptation Layer overhead (again not trivial) and then one has to have some way to format the user data. This WILL consume much more bandwidth than is taken up at present. >The telco standards people are looking to map ATM cells onto T1 >carriers right now, and when that is done there is talk that >they'll map ATM cells onto DS0's too! None of which means that it makes any sense, particularly from a bandwidth perspective. IP/T3 has much more useful bandwidth than IP/ATM/T3. The same is true whether one has T3 or T1 or DS0 or some lower bandwidth. >Secondly there could be some interesting benefits to a Ham implementation >of ATM. Can you imagine a data standard that could pass both voice, data >and video with appropriate handling? IP can do this today over low-bandwidth channels. With the implementation and deployment of real-time flow support and resource reservation (e.g. as proposed in the RSVP protocol specification), it should be even better suited for this. Of course, ATM is much more sexy to talk about even if it isn't as good a solution technically... >Expand your mind abit further and imagine an ATM switch on the Phase 4 >Ham satellite, to switch your packets quickly over to the beam >on europe, to download the latest version of GRINOS, while simultaneously >enjoying a ragchew with a group of VK's in the outback, through >the beam pointed towards Auz. ATM switches have real problems with cell loss and congestive collapse. The features that you describe all are a function of the bandwidth available much more than which link protocol (ATM is after all a kind of link/subnet protocol) is in use. ATM is a very high overhead approach to those problems. Running normal IP would be a much more appropriate solution. >I think the big benefit of something like ATM will be integrating >voice and data in the ham world! IP can do this now with less bandwidth than ATM would require. The machines on my desk move audio, video, and data between three continents in real-time just fine, sharing bandwidth with ftp and telnet and smtp sessions. One can't do it very well at 9600 baud with ANY technology though. Compressed voice and full-motion video still require a whole lot of bandwidth by Ham standards. ATM is mostly hype at this point, consider what the ATM specifications really say before claiming that ATM is a likely solution to any problem. In general, the Ham community garnered its good reputatioin by applying science to its problems. Let's keep up that tradition. ------------------------------ Date: 25 Nov 1993 06:45:56 GMT From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa Subject: Ham Radio - Internet gateway To: ham-digital@ucsd.edu In article rcrw90@email.mot.com (Mike Waters) writes: |In the US a packet message is "third party traffic" for the relaying |stations no matter *who* originates it. If a ham originates the message |then only the link from the first station to the BBS or relay is non "third |party". You're right. Maybe not only in the USA. |On the other hand ham radio can well be used to supplement other services. |Emergency response is one of the most obvious of these. I also want to emphasize this point - |Personally I think we should be able to carry much of Netnews via ham radio |for example (or at least FIDO!). As far as I know that is not done today. We're running our own NetNews groups in Japanese called ampr.*. There are some other local newsgroups here. |There are Internet/PBBS gateways for E-mail though, although they tend to |be somewhat awkward to use. Quite a few PBBS operators in Japan do not want to see messages of non-licensees. I am against this attitude so I don't run nor recommend people to run PBBS nodes. |Another use I have seen is for a yacht in the South Pacific to submit an |article via packet to a (nonprofit) club magazine in Ft. Lauderdale. |Appeared to work very well and was much faster than the mail in that part |of the world. A practical use of ham radio - ham radio people must support non-profit activities, I believe. Otherwise, airwave bandwidth for ham radio people should be reallocated for other public services. // Kenji -- Kenji Rikitake (More available!) Persuade me you may, but I won't be persuaded. -- Aristophanes ------------------------------ Date: 25 Nov 1993 06:54:22 GMT From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa Subject: wb7tpy gateway To: ham-digital@ucsd.edu In article <2d08eo$mi4@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) writes: |The real problem here is that the inter-network router somehow "forgot" |that BBS network domains have an implied "ampr.org" at the end of them. |As in w0rli@w0rli.or.usa.na.ampr.org ... It's all up to ampr.org domain administrator (namely Brian Kantor) to accept this or not. // Kenji -- Kenji Rikitake (More available!) Persuade me you may, but I won't be persuaded. -- Aristophanes ------------------------------ Date: 25 Nov 1993 06:51:58 GMT From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa Subject: wb7tpy gateway To: ham-digital@ucsd.edu In article <2ctoto$h25@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) writes: |What routing information? The requirement of including regional/geographic information into the mailing address. This will not work. |These are NOT routes we are talking about ... |they are locations ... Locations are geographic information :) |I think all the bbs authors understand that a location is |not a route, and address is not a route nor a location, |etc. etc. People tend to interpret location info can be used for routing. This doesn't work. See "The Internet Message - Closing The Book with Electronic Mail", by Marshall T. Rose for how OSI X.400 failed by not specifying resolution mechanism between addresses and routes. // Kenji -- Kenji Rikitake (More available!) Persuade me you may, but I won't be persuaded. -- Aristophanes ------------------------------ Date: 25 Nov 1993 06:59:56 GMT From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa Subject: wb7tpy gateway To: ham-digital@ucsd.edu In article <2ctpip$h25@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) writes: |If people would simply STOP trying to connect the two networks, |the problem would just go away. I disagree. At least some part of ham radio community want to communicate with Internet. And I see no ethical issues on connecting these networks, although laws must be changed. |Now folks want to connect them. yes. |There is certainly no problem creating some new top level domain |for the bbs network - but why bother? We have one already: it |is ampr.org ... so what is the problem with using that at the gates? |Anything that came from the bbs net gets appended .ampr.org when it |moves to the internet. Same thing the other way: the .ampr.org gets |dropped once the traffic is inside that net. In near future PBBS systems should be re-written to keep ampr.org INSIDE the network. Mail addresses should be treated as is. |Is there some problem with this concept? I think it's ok as long as ampr.org domain administrator agrees. |w0rli@w0rli.or.usa.noam.ampr.org - no big deal for any router to handle. No. :) |Oh yes, I know about the issues with tcp/ip - but tcp/ip within the bbs net |is yet a different issue. One still needs the hierarchical location |information, since many services do indeed use those identifiers as routing |hints (ROUTING HINTS, not ROUTES ...) and we would like to continue to do |so. Well, in fact. parsing identifiers to obtain routing information is acceptable. // Kenji -- Kenji Rikitake (More available!) Persuade me you may, but I won't be persuaded. -- Aristophanes ------------------------------ Date: 23 Nov 93 16:35:18 CST From: timbuk.cray.com!hemlock.cray.com!andyw@uunet.uu.net To: ham-digital@ucsd.edu References , <2cp3dk$lls@unicorn.ccc.nottingham.ac.uk>, <2ctp3q$h25@wvhpadm1.mentorg.com> Subject : Re: wb7tpy gateway In article <2ctp3q$h25@wvhpadm1.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) writes: > [...] > And that Namibia is in Africa and not in North America. > And is never addressed with one of those really stupid internet > TWO letter designations. At least we got one thing right in > the bbs network: we used the THREE letter country codes ... Err, the site that ended up with a pile of xxx.usa.na messages was in Namibia, and it's official domain name *did* end in .na Actually, since the guy had to pay for all those messages to get delivered over a long distance UUCP connection, and then pay again while they bounced (until he at least stopped that), I thought he was more than reasonable about the whole affair.. > And any reasonable router should be able to tell the difference > between USA.NA and something in Namibia - or does Namibia have > a USA sub-domain ? And here we have it, the "left to right" parsing thinking that brought you the # fields in PBBS addresses. If someone wants to call a domain in Namibia "usa" then they are entitled to. Sigh.. -- andyw N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Sat, 27 Nov 1993 21:25:15 GMT From: swrinde!gatech!europa.eng.gtefsd.com!paladin.american.edu!darwin.sura.net!ra!atkinson@network.ucsd.edu To: ham-digital@ucsd.edu References , <1993Nov22.191806.11611@hplabsz.hpl.hp.com>, <2ctnrt$ocf@newsserv.cs.sunysb.edu> Subject : Re: ATM on Amateur Radio? In article <2ctnrt$ocf@newsserv.cs.sunysb.edu> rick@cs.sunysb.edu (Rick Spanbauer) writes: > You're confining yourself with how ATM might apply to > existing amateur packet. Bandwidth allocation similar > to ATM might make sense in a full duplex system where a > hub would have to decide how to split up its forward > channel bandwidth among the client nodes. > > Rick Spanbauer, WB2CFV ATM/RF doesn't make much sense. We've been looking into it for hypothetical use with Navy radios and very rapidly concluded that ATM/RF lost big. If even one ATM cell has a bit error at the receiver, the entire AAL frame has to be retransmitted. Consider that IP/AAL5 uses 9180 as the MTU size, that there are 48 octets of user data per 53 octet ATM cell, that the typical bit error rate of an RF channel is high, and the bandwidth costs of solid ECC. By contrast, IP/RF works reasonably well and is currently used by a large number of non-commercial, commercial and government users. A lower overhead and technically superior solution for bandwidth reservation would be to use a resource reservation protocol (e.g. RSVP, which is being proposed for use with IP). ATM doesn't handle bandwidth reservation very effectively -- though the marketing droids tout bandwidth reservation as an advantage. ATM also has potentially severe problems with switch congestion and cell loss. The main way that real ATM users are coping with this switch problem is the traditional telco solution (over-engineer the network big-time) and this is expensive to do. In short, wise folks will soon understand that ATM is mostly hype at this point, that it is NOT a panacea, and that it probably can't be usefully extended very far outside its design objective (connecting fiber optic circuits together for telephone companies and for high- bandwidth fiber-optic computer communications circuits). Ran atkinson@itd.nrl.navy.mil (who until very recently was working on ATM full-time) employed by, but not speaking officially for the Information Technology Division, Naval Research Laboratory... ------------------------------ Date: 25 Nov 1993 11:28:14 -0000 From: pipex!uknet!warwick!unicorn.nott.ac.uk!unicorn.nott.ac.uk!not-for-mail@uunet.uu.net To: ham-digital@ucsd.edu References <2ctp3q$h25@wvhpadm1.mentorg.com>, <1993Nov23.163518.13551@hemlock.cray.com>, <2d08eo$mi4@wvhpadm1.mentorg.com>k Subject : Re: wb7tpy gateway In article <2d08eo$mi4@wvhpadm1.mentorg.com> Hank_Oredson@mentorg.com writes: >In even simpler terms: once the application has parsed off the >very last field (NA) and then looks at the next field (USA), it >can certainly notice that there ARE no sub-domains USA.NA in >Namibia ... or is the Internet addressing scheme to stupid to >allow for things like this? A quick DNS trawl courtesy of nslookup reveals: na. SOA rain.psg.com hostmaster.ns.psg.com. (9307100 345600 7200 2592000 691200) (snip) na. MX 10 kudu.ru.ac.za na. MX 20 hippo.ru.ac.za na. MX 100 rip.psg.com na. MX 150 m2xenix.psg.com * MX 10 kudu.ru.ac.za * MX 20 hippo.ru.ac.za * MX 100 rip.psg.com * MX 150 m2xenix.psg.com So, all mail to Namibia should go through South Africa anyway. What happens then depends on what ru.ac.za does with it.. hopefully, it'd be sensible enough to bounce anything @n9zzz.#zz.usa.na. If it doesn't, something's broke somewhere.. Mike -- +- Mike Knell, University of Nottingham, UK -=- M.Knell@unicorn.nott.ac.uk --+ | --THIS SPACE TEMPORARILY BLANK-- | AMPR: g7gpa@hobbes.g7gpa.ampr.org | | (until I can think of a decent joke)| AX25: g7gpa@g7gpa.gb7bad.#23.gbr.eu | |UNDER the overpass! OVER the underpass! Around the future and BEYOND REPAIR!| ------------------------------ End of Ham-Digital Digest V93 #126 ****************************** ******************************