FlexNet Info for U.S. Hams

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (n5pvl @ May 29 2002,06:15)</td></tr><tr><td id="QUOTE">I do not generally belittle Amateur tcpip, but I do generally tend to point out it's limitations. ( No good for long-haul RF links, much more overhead per packet, very little Ham-related software for it, not easy or intuitive to set up, and so on. )

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Tell me why it's not good for long haul RF links and how is flex net better. [/QUOTE]<span id='postcolor'>

I see that you are new to packet radio, and have not been exposed to these issues. I will give you a short explanation here, despite the fact that to do so is off-topic. The discussion here is about FlexNet, not Amateur tcpip. In future, please post questions about Amateur tcpip to the "Baud Rate Race" thread.

Amateur tcpip pretty well needs speed to survive. Partly because of the additional overhead Amateur tcpip packets carry, and partly because of attitudes most people who have been exposed to the Internet, 300 baud tcpip is generally agreed to be useless. If nobody wants to use it, "useless" is a good descriptor.

HF radio, the only reliable method Hams have to send data over any appreciable distance, is limited by the FCC to 300 baud. In actuality, you do not get 300 baud from 300 baud HF systems. What you usually get is throughput in the 30-56 baud range, with a few notable exceptions. The FCC's limitation is, in turn, based upon the laws of physics, which are not likely to be revised anytime soon. It's basically a question of bandwidth. The spectrum is shared with others, doing other things. You can't hog it all up for one purpose, and even if you could, it would still not be enough.

FlexNet is better simply because it is not limited to one protocol. (tcpip) The software associated with AX25 packet retains its viability at lower speeds, and since it is not limited to one protocol, advanced HF protocols such as CLOVER and PACTOR2 are usable with it. This is the advantage ( should be obvious ) of being inclusive rather than exclusive, and of being viable over a wider range of speed.

Essentially: You can do tcpip and all that it is capable of ( using radio, of course ) over a FlexNet network. - But Amateur tcpip network can only accomodate tcpip, and so is severely limited.
[/QUOTE]<span id='postcolor'>

I guess I don't understand what Layer of networking Flexnet resides. I draw the anaogly of TCP/IP because it's what I know. TCP/IP for the most part does not care how it get's from here to there. That job is done by the data-link. TCP/IP over Ethernet,Token Ring,AX.25,V.35,ATM, whatever.

Is Flexnet a higher level protocol like TCP/IP or is it a lower level protocol like AX.25/Ethernet,Token Ring?

My packet knowledge comes from APRS and digiing through the ISS. I have very little knowledge about how to do real networking with TNC2 clones.

(This is not a TCP/IP vs Flexnet, I just want to get a better understanding what it is. I would try it but there does not seem to be any *nix Flexnet software and I have no extra junk hardware to try it on.)

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (n5pvl @ May 29 2002,06:15)</td></tr><tr><td id="QUOTE">
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">The packet overhead should not be a huge problem with a 100kbps backbone[/QUOTE]<span id='postcolor'>

You are right about that. Unfortunately, 100kbps backbone does not grow up magically from the earth. It must be developed, and building that infrastructure involves the participation and support of many Hams. Higher speed digital RF is more difficult and expensive to do, by several orders of magnitude, than low/medium speed digital RF.

So that is what gets used first, and most often. Successful packet networks start off with the low/medium speed stuff that most Hams already have access to, and high-speed links are added incrementally, as possible. In the end, you end up with high-speed. Many have tried starting off with high-speed equipment in the first place, but only one group managed that trick... They had lots of money to play with, not a common condition in the Amateur Radio community. When the money dried up, so did the network.
[/QUOTE]<span id='postcolor'>

Accrording to what I read in CQ, it's going to be here very soon. Software defined radio's are the solution to that problem.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (n5pvl @ May 29 2002,06:15)</td></tr><tr><td id="QUOTE">
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Little ham-related software? Are you kidding me? [/QUOTE]<span id='postcolor'>

Nope. Take a look in the "Packet Radio" section of QRZ's downloads area. Over 300 files, maybe two or three related to Amateur tcpip. Compared to the great diversity of software available for AX25, there effectively is no Amateur tcpip software out there at all.

I am aware of perhaps a dozen or so programs using tcpip that were written to address the needs of Amateur Radio operators. The IP software included with operating systems CAN be used on the air by Hams at the baud rates available to Hams, but none of them are designed to - and it shows.
[/QUOTE]<span id='postcolor'>

What? We will be able to use any of the existing programs for everyday services. Think BIND,Sendmail,IRC and telnet. They all work fine and dandy over slow links.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (n5pvl @ May 29 2002,06:15)</td></tr><tr><td id="QUOTE">
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE"> Difficult to setup? It would not be any harder than a cable modem or DSL, it's good ole TCP/IP. Heck, DHCP 'em if want. [/QUOTE]<span id='postcolor'>

You are forgetting that Hams use Ham Radio, with all of the special obligations and restrictions that implies. If you run tcpip over FlexNet, you have two basic parameters to set that are not IP related, MYCALL and TXDELAY. If you use any of the tcpip-only software, there are literally dozens of RF-link related parameters to set, none of which are intuitive.

Try obtaining a copy of JNOS or TNOS, for example, then attempt to set one of them up, knowing what you know, without asking for help from other Hams who have managed to get it to work. Just use the docs. Good luck!

Same goes for the LINUX implementations. Dozens of parameters to set, dozens of obscure, counter-intuitive applets to discover and figure out. Remember that I am talking about using it with Ham Radio here, not in an office LAN. Some Hams enjoy that kind of tinkering and trouble-shooting ( I am in that group ) but most do not, and you need wide-scale participation in order to build network.
[/QUOTE]<span id='postcolor'>

Use your call sign as the hardware address in whatever you are using as a link protocol. That's how it's done now with AX.25. TCP/IP does not know or care what link protocol you are using.

This is why I want to know more about Flexnet. If it can used as a better link protocol than AX.25, I want to use it.


</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (n5pvl @ May 29 2002,06:15)</td></tr><tr><td id="QUOTE">
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
I still don't get this "Amateur TCP/IP" stuff, I don't care who coined the phrase.
[/QUOTE]<span id='postcolor'>

Amateur tcpip is tcpip over Amateur Radio. Seems pretty well self-explanitory to me... What part of it is hard to understand?

By definition, there is no "professional" Amateur Radio activity, on the air. It is all done on an amateur basis, by law. That is part of our charter with the FCC.

* A reminder of my request to post further non-FlexNet questions on the "Baud Rate Race" thread, where tcpip is more "on topic".
[/QUOTE]<span id='postcolor'>

I'll call it ATCP/IP right after I start calling Linux, GNU/Linux.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (n5pvl @ May 29 2002,06:15)</td></tr><tr><td id="QUOTE">
P.S.. I disagree with your charaterization of yourself as a "Ya-hoo" in relation to packet radio. You seem pretty civilized to me, and have not disrupted this thread with your comments and questions.

Charles, N5PVL[/QUOTE]<span id='postcolor'>

I feel like a Ya-hoo. I can't get my mind around what Flexnet is. It's kinda like explaining FTP to someone who uses "Windows File Sharing".

This is my last post on the subject, sorry for the off-topic discussion and thanks for the info.

 

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
Use your call sign as the hardware address in whatever you are using as a link protocol. That's how it's done now with AX.25. TCP/IP does not know or care what link protocol you are using.

This is why I want to know more about Flexnet. If it can used as a better link protocol than AX.25, I want to use it.
[/QUOTE]<span id='postcolor'>

Well... Yes and no. FlexNet is an AX25 stack, optimised for use in the Packet Radio environment. ( Shared, noisy spectrum ) Here's an article I found which speaks your language much better than I do. Still, there is a lot of Packet Radio terminology tossed in there. I'd appreciate your comments. Is this the info you are looking for?

-------------


TCP/IP on FlexNet - Just Another Layer

Gunter Jost, DK7WJ/K7WJ
Lichtenbergstrasse 77, D-64289 Darmstadt, Germany
Translated by: Don Rotolo, N2IRZ
c/o RATS, PO Box 93, Park Ridge NJ 07656 USA





Abstract:

The goals and outcome of a project to optimize TCP/IP transport over the FlexNet AX.25 network is described. A number of optimizations, and their implementations, are described and discussed. These include header compression, resend minimization, packet age tracking and ACK consolidation, as well as platform considerations and potential uses.





Not long ago, TCP/IP was an exotic mode of operation in Amateur Radio, reserved for specialists. Since then, it has become one of the most popular protocols used in the digital modes, due to the wealth of interesting applications employing it. The project described here attempts to make TCP/IP usage in the FlexNet packet network as simple as possible.

This doesn’t mean that we can dispose of the de-facto AX.25 standard. No, TCP/IP is merely a useful expansion, or just another layer, that can be handled by FlexNet.

This also includes the reconnection of disconnected links without the intervention of the operator, including re-routing to faster links. TCP/IP can be seen as an end-to-end layer (Layer 4 in ISO jargon), in contrast to other packet systems that are hop-to-hop layers, namely to the real ends of a logical circuit (user/user or user/server). TCP/IP strengthens the robustness of the AX.25 connection to the entry node, allowing one to change user ports during a running connection, without which the connection must be newly established. Instead of creating our own Layer 4 specification (plans have existed for some time), we find that TCP/IP offers exactly that, and is available for most modern operating systems. TCP/IP is the standard protocol of the Internet, and there is a considerable amount of software available.

TCP/IP and FlexNet make up a homogeneous unit, in that FlexNet nodes need no further expansions or changes, because they are already fully transparent to all frame types offered by the protocol, which are passed on a virtual AX.25 L2 connection. The protocols are passed along cleanly, as long as AX.25 (on the RF path) and TCP/IP (end-to-end) run at the layers they are expected to be at.

In our first look it was quickly seen that TCP/IP, as presently used in Amateur Radio, was given the (not undeserved) reputation of being slow and inefficient. This isn't the fault of the protocol, but of the implementations. It was clear where the crank needed to be turned. Quite simply, it shouldn't be like that, so we began this project. Today, a few thousand lines of source code that were implemented and tested on the first platform (Windows 95) are ready for use.

The idea of placing TCP/IP services directly on the network as AX.25 shouldn't be ignored. This is an interesting concept, but it should be pointed out that a careful TCP/IP implementation will return more than it costs.

Minimizing Protocol Overhead

TCP/IP packets contain a header of approx. 40 bytes. For a 256 byte packet, this is an overhead of some 16%, and, when the required ACKs are considered, more than 30% overhead increase as compared to an AX.25 connection. This also assumes an optimal protocol implementation, as well as no unnecessary retries. If you lengthen the packets to 1500 bytes (a typical value on Ethernet and similar implementations), the overhead sinks to a more reasonable 5%. A lengthening of AX.25 frames to 1500 bytes, as is often suggested, isn’t practical. The frame failure rate would become unreasonably large: If an RF link of 256 byte frames is 90% failure free (a realistic (unfortunately) number), this value would decrease to only 40% error-free frames for 1500 byte packets. Sporadic interference such as radar impulses further worsen this value. For this reason, AX.25 segmentation was defined some time ago, so that a large IP packet could be broken into many 256-byte packets. In this way, each frame contains only its own additional overhead bytes, contributing to efficiency. A requirement for this to function is that each packet arrives in the correct order, which can only be safely realized through a VC (Virtual Circuit) connection. The FlexNet AX.25 header compression feature [implemented some time ago - IRZ] functions in any case only with such a static connection and is a source of further reduced overhead.

These improvements are most efficient when there is a relatively large amount of data to be sent (enough to permit segmentation). If this isn’t the case, such as in an interactive Telnet session, the value becomes somewhat less. The worst case is when each byte requires its own packet, with its 40 byte overhead. In these cases one needs some other mechanism. Luckily, there is a standardized header compression scheme, as seen in RFC 1144 [1], and implementation was relatively simple. Using the Van Jacobson scheme [2], the 40-byte header of a static TCP connection can be reduced to 3-8 bytes. the only assumption for this to work is, like the FlexNet header compression scheme, the connection path between both ends is static, i.e. a VC. This protocol was defined for relatively slow telephone connections. If you replace the concept of "Serial Line" with "AX.25 virtual circuit", you can see just how well the protocol would fit with AX.25 encapsulation. The compression and its control occurs on the AX.25 level for up to 250 TCP connections, as well as traffic forwarded through a router. With a Link Reset, the status tables on both sides of the path are re-initialized. This requires that both ends of the path know of these Link Resets, but not all AX.25 implementations do this, which can lead to problems in this area.

Thinking instead of Pumping

A general problem with end-to-end protocols is that the transport shell has only limited possibilities for influence. This is less important for a static TCP connection, where the timers regulate the connection fairly well on the basis of the transport capacity, but nonetheless, an orgy of unnecessary retries can occasionally be observed.

The goal of this project was to develop an IP router not only for usage under Windows 95, but for usage under DOS or on the RMNC platform. This gave us a reason to invest a little more work early on, to save work in the later cross-platform portings. Finally, we still have to co-exist with users and servers operating with network implementations that are sub-optimal.

With AX.25 these problems, once separated from channel control, are mostly resolved. The network nodes decouple both sides of a connection completely, and traditional digipeating is no longer practiced. With this philosophy, to an end-to-end approach such as IP becomes an attractive proposition.

IP is a connectionless protocol, and the TCP placed upon it is laid out such that packets can take any possible path from one end to the other, arriving in any order. For this reason, it is possible to route individual IP packets in a connectionless manner. An IP router might never see all of the packets of a particular connection. It is also true that when you encapsulate something within AX.25, it cannot be assumed that traffic from one side of a connection travels over the same path as traffic from the other side. Only at the endpoints can you be sure of seeing all packets of a TCP connection.

An IP router also has possibilities for optimization. If a router knows of congestion, for example the outgoing path in use is slower than the incoming path (not an unusual condition in a Packet network), it can analyze packets in transit stored in memory and eliminate all unnecessary resends, by simply erasing any doubled packets. A time stamp can also be put onto each packet. Packets that remain in the router for some time, say a minute (because of congestion, or a broken link) can be erased, hopefully resulting in a TCP retry from the sending station that might be routed along a better path. Implementation of this requires an analysis of the complete IP and TCP headers, so that the order of packets can be determined. This can also be used to consolidate ACKs for a specific TCP connection, passing only the latest to the endpoint.

Through such actions, congestion created by unnecessary resends can be dealt with instead of becoming worse. With traditional implementations, traffic is brought to a complete halt in such situations. Through controlled 'packet loss', as well as the deletion of doubled or aged packets, the net is much better able to deal with changes, slowing the data to match the path's capacity.

This behavior functions very effectively and completes the usual improvements, with the router sending an ICMP-source-quench as well as requesting the sender to throttle back. The retention of the originator is during this not clearly specified, thus such flow control actions can lead to very different results.

Naturally, both partners should adjust their TCP timers properly, but luckily this functions quite well, even with the Microsoft stacks.

The proper adjustment of TCP/IP parameters is critical, above all when one wants to reach destinations via different networks. The Microsoft stack is a "black box", and hardly any parameters can be adjusted. So, we need to make all optimizations in the module which knows the existing transport layer the best: The AX.25 coupler.

Instead of simply pumping TCP/IP packets into an AX.25 connection or, even worse, into AX.25 UI frames, as is done with present implementations (such as xNOS and LinuX), the packets remain in the IP coupler's (e.g., router's) memory until they can actually be sent. This is comparable to the behavior of the FlexNet coupling to Layer 1, and contrasts with solutions such as KISS, which only generates frames that can be sent immediately. The known side effects of a KISS connection, i.e. multiple SABMs or RRs in a single transmit cycle, simply don’t occur with FlexNet.

In FlexNet, ACKs are sent only for the latest packet, any ACKs belonging to earlier packets need not (and are not) sent. A carryover of this concept to the IP-AX.25 coupling brings some improvements. When the AX.25 connection is being established, during which no data can be passed, running TCP/IP packets are buffered, and so can cause unnecessary retries. The same happens with a user station that is blocked in a half-duplex connection for extended periods. During this time is it possible for many TCP packets to pass to the user station, each of which is ACK'd individually by the user's local TCP stack. Instead of sending each of these ACKs, the FlexNet coupler can discard all of them except for the last one. Implementing this requires a close coupling of the layers, but FlexNet already has the call in it's API, so that little accommodation is needed here. Naturally, the coupler must analyze and compare the packets at the TCP level, to be able to discard the proper packets. In the ideal case, a user station sends a maximum of one AX.25 I-frame during its time slot per active TCP connection, instead of the many L2 RRs and TCP ACKs as with the traditional solutions. The improvements thus realized are somewhat greater than those obtained from header reduction alone. While header reduction remains important, one cannot ignore the gains in efficiency from eliminating doubled or aged TCP packets.

In a typical HTTP session, many TCP connects are started, transferring only a few kilobytes of data before being closed again. TCP timers have no chance to adjust, and many unnecessary retres occur. This is especially true in a slow half-duplex environment which is typical for a user station. The situation is less dramatic when users have few, long-lasting connections, e.g. a single FTP transfer.

For AX.25, FlexNet was able to make such optimizations directly in the L2 code, because of the tight coupling to L1. This avoids the need for the L1 process to have to analyze each L2 frame and decide what should be passed ahead or not. Unfortunately, it isn't so easy on the TCP level. Here, you must watch the status of possibly many running TCP connections, which requires a lot of memory and efficient algorithms. However, some coding efficiencies result because TCP compression needs quite similar data structures, which can be partially be used for these optimizations.

All this naturally increases demands upon memory space and CPU capacity. As long as the network runs at data rates below 100 kB/s, and PCs continue to increase in capacity, no further effort is needed. This is especially true on the user side, where nowadays there is more than enough computing capacity. A fast 486-class machine with 16 MB of RAM running Windows 95 is sufficient to support a throughput of 76,800 baud TCP/IP through FlexNet. For a router it would help to install a faster CPU, but reasonable performance with a 486 was measured.

Anachronisms

All the improvements described above assume IP transport over AX.25 Virtual Circuits, which should provide a reliable path between two points of an IP network. Using Datagram mode (AX.25 UI frames), each packet loss on the wireless portion of a TCP connection causes a TCP retry, which has to travel the whole way, end to end. (Remember the problems we had with L2 digipeating? Same applies here). Since this has not been generally learned and understood, an IP router must also be able to deal with the Datagram mode, where IP packets are sent as AX.25 UI frames. With this, one becomes stuck on the problem that only IP packets with a gross length of 256 bytes or less can be carried. AX.25 segmentation is not usable, as it depends upon the packets traversing the network in their original order.

To resolve this problem, we have available so-called IP fragmentation, which divides an IP packet into multiple smaller packets and gives (in contrast to AX.25 segmentation) each fragment it's own complete IP header. Each packet is thus autonomous, and are reassembled in order only at the destination. This allows each packet to traverse the network through any available path, forbidding reassembly in routers or gateways. One problem is that when one fragment is lost, the entire packet (a series of fragments) must be re-sent. This scheme is clearly at best a temporary patch, especially when one must deal with the realities of the RF medium and the relatively high failure rate of the links. For compatibility reasons, when Datagram mode is the only way to deliver a packet, IP fragmentation must be implemented in the router.

IP Routing

IP routing is, in one regard, in competition with established AX.25 routing, especially in the FlexNet environment. In that IP addresses are mated to a callsign (dynamic address allocation for users is a subject for separate discussion), FlexNet routing is sufficient to reach a specified destination. One useful addition could be to define a layered hierarchical routing, such as AX.25 routing in the local area and IP routing for the wide area, analogous to protocol layering. An obstacle to this is that our network is not yet fully developed to offer fast connections with transit times of less than a minute over its entire range.

One argument in favor of IP routers at network facilities is that the user is freed from some work - he simply sends packets to the router, and it handles the rest. At the moment this merely means that the sysop's work, in which he might not have much interest, is delegated. The user shouldn't become dependent upon this system, however, he must retain the possibility of establishing a connection with a destination directly. This means that PID transparency, reversible callsign fields and a functional AX.25 router remain important. The network can be considered a cloud, its internal operation the user need not know to reach a destination.

With more and more users operating TCP/IP (perhaps in part due to this project), and TCP/IP is understood to be the end-to-end layer on a well-constructed AX.25 network, we can then reconsider the optimal bundling of traffic via dedicated routers. The infrastructure is, in the form of many LinuX systems, more and more available. All that was missing were the protocols and their implementation.

If the TCP traffic is optimized as discussed above, then routers can reduce network loading considerably. Routing, however, remains in the background. In any case, this is an exciting direction for development and there is considerable room for new ideas.

Until then, and possibly also after that, the user is better served with making a direct connection himself, as far as the network allows.

Which platform is the right one?

While we lean towards additions to some specific operating system, the rest of the world wants missionaries. Indisputably LinuX, for example, is an outstanding server/operating system. The average user, however, wants to simply buy something from Microsoft. You just can't beat Windows 95 or NT when you want to develop a user application.

For Windows 3.x, ETHEREMU from Thomas Sailer, HB9JNX, could be installed. It emulates an ethernet card and allows it to communicate via Trumpet Winsockets. The AX.25 routes are input using text mode commands.

TCP/IP is already integrated with Windows 95. Of course data transfer via Ethernet or "DFU-Network", using SLIP or PPP protocol, is provided. Until now, what was missing was a coupler that could encapsulate TCP/IP packets within AX.25. Some solutions already exist, but are generally difficult to configure, for example NOS in a DOS-box. Others try to use protocols such as SLIP, which has the disadvantage of removing the possibility of being able to have normal AX.25 connections. Besides, one needs special, and not quite inexpensive, hardware.

In the meantime, PC/FlexNet runs under Windows 95, all that’s missing is the coupler that hands the IP packets over to FlexNet. Microsoft makes this possible only via the installation of a "Network Card", however the concept is, at least in the German translation, somewhat misleading. Of course, all of the optimizations described have been implemented, using Windows 95 as a test platform. Although the timing of the TCP stacks is really set up for a fast wire connection, it keeps stations on the RF channel fairly civilized and sends practically no unnecessary packets. A list box is used for AX.25 route inputs, and it also serves as a status and statistics display. No special TNC hardware is required, and running multiple IP sessions in parallel with AX.25 sessions presents no problems. However, this is a solution mainly for users, i.e. network clients.

As a server system, Windows 95 is somewhat strained. While there are some simple FTP and HTTP servers that function well, the entire system in not stable enough for use as a general-purpose server. One negative is that there is (still) no possibility of forwarding IP between multiple ports, as well as AX.25 to ethernet ports. This is the domain of LinuX, but NT is close behind. LinuX is already available with AX.25, so the next development point lies with NT. Having a large installed user base for 95 and NT doesn't hurt, either.

Uses

As already mentioned, applications and services are sufficiently available. Much that is developed for the Internet is also usable in Amateur Radio. Regardless, that shouldn’t prevent someone from developing an amateur-specific program. Services such as databases or special applications like DX-Clusters are easier to access and service using TCP/IP instead of AX.25. Thanks to TCP port addressing, it’s no problem to offer and try various applications and services on the same server with the same AX.25 callsign.

A further field for new applications is for image and speech transfer. While these demands today seem somewhat utopian, voice mailboxes are already using the network to transfer their messages via store & forward. It isn’t a much larger step to make it possible for the user to have a direct digital connection into the system. The software already exists, though this is mostly designed for the relatively high speed of the Internet. If you don’t need real-time and full duplex, and can deal with PTT (amateurs know this already) one can get very good results. Modern codecs allow speech to be compressed to less than 300 bytes/sec with little loss in quality. This bandwidth is already available in most of the network. In the future, a Windows application will be introduced. With specific servers it should also be possible to have roundtable discussions like on the local FM repeater.

Image transmission also remains in the range of possibility, especially with the quality codecs available for moving picture transmission. Naturally the existing available bandwidth won’t work for decent quality video, but you don't really need it to admire someone's photograph. Convenient video conference systems are realizable in the foreseeable future.

All this carries with it the ability to increase the play value of the network, and through that, justify the spectrum being used. Naturally, our packet-oriented data transfer system isn't set up for real-time uses. The protocols and applications to be used require careful consideration of our unique requirements and conditions, but there is a lot of room for experimentation here.

Unquestionably, a careful optimization of all parts of the transfer chain is needed. What is lost in one component, whether in hardware or in software, cannot be recovered. For example, while increasing the baud rate is a good idea, it is not the only possibility for improving the network. Clearly, TCP/IP can bring to Amateur Radio much more than just a wireless Internet.

---------------

This article was written a while back. Since then, Flex32 ( Win98/ME/2k/XP ) has been released, so it is a bit out of date.

There are more "Intro" articles on my web site, if you would like more info. Push the "homepage" button at the end of one of my posts, then the "FlexNet" button situated in the middle of the page.

There are links in there to all the significant FlexNet-related web sites I am aware of.

Charles, N5PVL

 

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (ke4pjw @ May 29 2002,14:41)</td></tr><tr><td id="QUOTE">I guess I don't understand what Layer of networking Flexnet resides. I draw the anaogly of TCP/IP because it's what I know. TCP/IP for the most part does not care how it get's from here to there. That job is done by the data-link. TCP/IP over Ethernet,Token Ring,AX.25,V.35,ATM, whatever.

Is Flexnet a higher level protocol like TCP/IP or is it a lower level protocol like AX.25/Ethernet,Token Ring?[/QUOTE]<span id='postcolor'>
To answer this question for you. From my understanding
(I have never played or seen Flexnet) Flexnet resides as an additional layer ontop AX.25 much likes TCP/IP or probably more like NetRom does. It is not a link layer, AX.25 is the link layer.

Hate to change gears but I haven often wondered if it possible to modify the KISS driver to send Raw IP to the TNC? Get rid of the AX.25 link layer crap and the callsigns use Raw IP, have your call in Hex as the MAC...??

Might be interesting, definetly would have less overhead than TCP/IP over AX.25.

 

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
Hate to change gears but I haven often wondered if it possible to modify the KISS driver to send Raw IP to the TNC?  Get rid of the AX.25 link layer crap and the callsigns use Raw IP, have your call in Hex as the MAC...??
[/QUOTE]<span id='postcolor'>

Only one way to find out... Give it a try and see what happens!

Lots of tcpip folks at TAPR, and they have several reflectors dedicated to those kind of issues. - Or why not start a new thread here at QRZ ?  

There are also a few knowlegable folks hanging out at :

rec.radio.amateur.radio.misc

I don't really know enough about the nut's 'n bolts of tcpip to make a relevant comment on your idea. I can tell you, though, that whether something like that is technically possible is only half of the merry-go-round.

Speaking from the side I do know ( digital Amateur Radio ) I would wonder how well pure IP transmissions would do on a shared, busy, noisy bit of radio spectrum.

My guess is that the advantage to be had from the reduced overhead would be balanced or perhaps overcome by the reduced link performance. ( Re-Sends )

I think you'd be better off using FlexNet, for that and a number of other reasons.  ( Big surprise, right? )

Then again, I am thinking link performance, not ideology.

Seriously though, I do not believe in shooting new ideas down, or discouraging experimentation. We can all opine until the cows come home, and all that discussion would just be so much hot air, compared to a simple experiment to see if your idea works in fact.

I'd say ignore all discouraging comments and just try it out!

Never let hot air discourage you from investigating a cool idea.

Charles, N5PVL

 

Sorry to be gone so long... I've been working on a new packet networking web site.

USPN Website

Mainly I've been doing (and re-doing) the HTML. Check it out, leave me a note, let me know what you think.

Imagine!   A web site dedicated to amateur packet radio networkers in the U.S.!

Charles,  N5PVL