In my personal experience, JNOS first, and Linux in second place, have been a fairly good match to the radio channel characteristics for e-mail and web browsing over AX.25 packet radio.
How is that? Well, JNOS has "tweaked timers", or better stated, the ability of setting channel access parameters, TSS and TCP windows that can access properly the 1200 baud packet radio link. Not so well suited, but fairly appropiate are the Linux AX.25 parameters. I feel that the Linux AX.25 state machine had problems the last time I used it, specially with retries and already passed frames. JNOS state machine does not suffer from that. But something is clear to me: it is IMPOSSIBLE to pass TCP traffic coming from a LAN, keeping LAN access parameters, timers, segment and window sizes without grinding the radio link to HALT with endless retries and repeats. TCP windows sizes up to 32767 may be acceptable on a LAN, but not on a 2 meters voice radio or a 3 kHZ HF radio. Such cases should be handled by a router that can segment the traffic into the proper parameters and queue lenghts when entering the radio based bandwidth deprived sections of a link. And I mean with this something that is NOT a WLAN or a professional microwave relay. One of the frustrations I have had with TCPIP native Windows support is that there is no clear tweaking possible with the beforementioned parameters, and it keeps the agressive and unbearable LAN timers and packet sizes. Even on 2 meters 1200 baud links, it creates havoc. Maybe I have not learned enough about it, but using Linux TCPIP support, and with JNOS on any OS it can run I have not faced such problems. But it is clear to me that you CANNOT expect that a bandwidth bottleneck like a radio link, particularly a HF radio, to perform as a 10 or 100 Mb/s (say) wired LAN. Otherwise, mating a LAN with a radio link without the appropiate traffic downsizing is doomed to failure. Using a radio link in such cases also requires a bit of judicious use of such a resource. And I mean by that eliminating unnecesary traffic like one paragraph Word attachments (20 kB vs 1 kB text), sending Office documents or databases without compression, bitmapped images, etc. It is a rather long list of taboos if you want to have a viable, snappy data link over such a bandwidth deprived channel. There is no problem with RFC821 or RFC822, it is just a matter of what kind of channel access parameters are used. If they are matched to the channel properties, it may be OK, but otherwise, it will be entirely flawed. 73, Jose, CO2JA ---- Rick wrote: > It could be that either I am misreading the information, or the information is too old and was superseded by a change in the proposed 3G MIL-STD-188-141B Appendix C, messaging protocol. I am referring to one of E. Johnson's documents where he writes: > > "The use of standard > internet applications (such as E-mail) over wireless transmission media (specifically HF) creates > heightened technical challenges which are not met adequately by existing HF communications > protocols. The existing protocols do not provide effective channel access mechanisms, and, as a > result, tend to break down due to collisions and congestion under heavy network loads. The > current ALE and data link standards use very different modulation formats (8-ary FSK vs. serial > tone PSK), resulting in a performance mismatch between the linking subsystem and the message > delivery subsystem. Current HF ARQ protocols require complicated methods for matching the > waveform and/or data rate to the channel conditions." > > They list various BW waveforms and 8FSK is not among them as they appear to all be PSK ary forms. > > Do the 3G protocols still support the 8FSK125 waveform and this is used for the initial signaling and linking and then you switch over to the other PSK modes? If they do, then what is he saying in his above statement? > > 73, > > Rick, KV9U __________________________________________ Participe en Universidad 2008. 11 al 15 de febrero del 2008. Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.universidad2008.cu
