On 9/27/07, Jose A. Amador <[EMAIL PROTECTED]> wrote: > In my personal experience, JNOS first, and Linux in second place, have
You probably mean "Linux kernel-mode" AX.25, since JNOS runs fine on Linux =) > been a fairly good match to the radio channel characteristics for e-mail > and web browsing over AX.25 packet radio. > (snip) > 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. Absolutely true! Two or three possibilities: Do what is sometimes done for "internet satellite" terminals and "spoof" the TCP state machine by locally generating ACKs, etc then committing to transfer the frames yourself however you see fit. This works fine for some things, terribly for other things. This is great for conditions where the TCP client and server will break if their assumptions are tested (Remember, 99.5% of modern internet apps *assume* ubiquitous high bandwidth, low delay, low loss connectivity, and the timings that go with it) Alternatively, you can create "protocol gateways" that do non-TCP over the air, with the other end acting like a "remote-controlled" TCP client. The HMTP smtp-variant can be thought of as one take on this, and it's not too hard to implement a similar thing for straight POP or HTTP. The result will work better (since neither the local-to radiobridge TCP connection nor the remote-radiobridge-to-internet TCP connection needs to have its timing fiddled with), but there are a LOT of non-trivial edge conditions to deal with if you want the thing to work with the internet "in the wild". Sadly, not reads internet RFCs every night before bed... =) (snip) > packet sizes. Even on 2 meters 1200 baud links, it creates havoc. Heh, you want a feel for exactly how bad the problem is? Try using a GSM/GPRS (others might do this too, but GSM/GPRS guarantees this ability) cellphone to make a 9600 baud "dial up" connection to an ISP modem (or whatever you have handy). Note, this is *not* whatever "high speed" connection your provider offers. This is 9600 baud, fairly long latency with occasional latency spikes due to scrambled-and-resent data frames. A lot of modern software does *not* function over this vastly better connection. I've actually seen a client (a chat client, not that it matters) successfully connect, then queue up so much XML status information that the connection *never* succeeded at passing any actual information. (snip) > 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. A: You need applications that are aware of their link resource, or else are OK with batching traffic and offloading actual delivery to some other tool. B: even 802.11b/g has to significantly adjust the timings "under the hood" in any enterprise campus location. Much of the inefficiency a large wifi location sees is due to the fact that the actual layer 3 protocol (TCP in this case) timings aren't dynamically adjustable, so layer 2 has to try to provide what layer 3 has been tuned to expect. C: Amateur radio networks aren't best modeled by the modern TCP view of the internet anyway. They're a much better approximation to the old asynchronous-bundle-delivery UUCP days (although we have learned a few things since those days; no need to be "mistake-compatible" with UUCP =) Most useful things can be turned into bundles that can be transferred to the peer whenever the peer can be reached. Unlike UUCP, however, there must be at least some ability for ad-hoc pathing-peering discovery, since HF is much different than a scheduled telco-hardline dialup link. (snip) > 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. Yes, in general, rather than trying to cram a legal ham HF/VHF link under the existing internet layer 2 protocols, which at best results in *terrible* efficiency, average throughput (whatever the peak may be), etc, it's usually better to implement application protocols that are a better fit to the channel constraints. Yes, you *can* adapt IP protocols enough so that they'll work; once you've done that, almost all applications written with the internet in mind will break anyway. Just for fun, go look up the timings embedded in the HTTP/1.1 spec, and imagine trying to meet the timeouts over a HF channel. Now note that a large subset of the internet is unreachable from a HTTP/1.0 client... specifically *every* host that uses "name-based virtual hosting", which is almost everything. Just one example. Expect to trip over hundreds more. -- Regards, Robert Thompson
