Tim Salo wrote:
> I believe that the original message was referring to all of the queues
> over the whole end-to-end path, while you are referring to only the
> local queue. Knowledge about only the local queue doesn't seem like
> it will help much, (some, but not much).
But given that the first wireless link is usually the bottleneck
(this is usually the user port of a digipeater with many users sharing
it,
the other links are usually point to point backbone links), it helps
surprisingly much 8-)
> "Very well" is subject to considerable debate. It is widely believed that
> retransmissions at the link level, such as those performed by AX.25 in
> VC mode, confuse TCP's retransmission timers and cause TCP to retransmit
> unnecessarily (i.e., to retransmit data that AX.25 has or will retransmit
> successfully). Do you have some empirical or theoretical evidence that this
> is not the case?
Well, in a typical shared user channel, there is not only considerable
variance in round trip time due to ARQ, but also due to channel access.
This also tends to confuse TCP timers.
FlexNet does some simple "queue pruning", i.e. if it sees two exact
duplicates of an IP packet, it throws one away. This helps reducing some
of the redundant retransmissions.
NB: the situation I'm seeing in my configuration is a number
of relatively unreliable wireless links, but the first and the last
link contribute by far the most to the round trip time and its variance.
> I don't believe that this is a generally accepted conclusion, at least among
> TCP researchers. The TCP community will generally say you should improve
> the performance of each link (e.g., via FEC, but not via retransmissions
> [which interact poorly with TCP retransmission timers]) so that end-to-end
> packet loss is acceptably low.
The point is that with wireless links, you can't reasonably do that.
You can improve packet loss to a certain point with FEC, but there
will still be loss due to momentary deep fades etc. You could only
mitigate that with _huge_ interleavers or _extremely_ long
(constraint length) codes, but you definitely don't want to do that
(implementation complexity, delay).
> bandwidth up to the point that it was dropped. About the only response
> the TCP community has is that you should improve the link-level performance
> so that retransmissions don't occur very often.
Yep and the answer of the wireless people is "can't do that without
ARQ" 8-)
> - use of link-level FEC is very important in wireless networks,
> including amateur packet networks,
Yep undisputedly. But it can't be the only measure, ARQ has to be
involved to some point.
> - link-level retransmissions should be avoided, (because they
> interact poorly with higher-layer retransmission strategies,
> particularly more aggressive strategies like TCP uses),
But physical laws are against that 8-) Either you use ARQ, accept
a large packet loss rate, waste radio resources, or have very large
delays. To me, the first is the least of the evils 8-) But priorities
may vary.
> - amateur radio packet protocols should more quickly integrate
> the results of current protocol practice and research,
> particularly the lessons learned in the Internet community ,and
Please feel free to suggest a new protocol, I'd be very interested
> - amateur radio should move beyond AX.25 (the CW of wireless radio
> protocols).
And amateur radio should move away from 1200baud AFSK too, the
"spark transmitter" of the modulation formats 8-)
And it should move away from transceivers requiring 200ms or
more turn around time (from rx to tx).
My point is that AX.25 + some mods (like hop2hop ack) is not as
bad as its image, and that amateur radio has some other problems
besides the link layer protocol 8-)
Tom
