Catching up on this list...
>That's a good point! But I guess that the relationship between
>offered load and loss rate would be different from that in a
>shared point-to-point link.
If so, the essential similiarity between CDMA and hardwired links is
still there: in both cases, most packet losses are caused by
congestion, not noise. So the default TCP strategy of attributing all
packet losses to congestion is still the right thing to do in both
cases, and I don't see the benefit of a "link level error" control
message.
Even for radio links where this isn't true, I still feel pretty
strongly that TCP should not have to be "educated" about noise-induced
errors on wireless links when there exists a much more focused,
effective and cleanly-layered solution to the problem: link-level ARQ
and FEC. If the link layer is going to the effort to generate a "link
level error" message to tell TCP to retransmit, why shouldn't it just
retransmit the packet itself?
>Except that it would be desirable to throttle back the TCP sender
>(i.e., do end-to-end flow control) when little/nothing is getting
>through to the receiver without having the sender timeout/retransmit, etc.
Throttling a TCP sender due to noise bursts or fades is really no
different than throttling a sending TCP due to a burst of competing
traffic on a conventional point-to-point link or a link outage. It's
the same problem, really, so the same mechanisms ought to apply.
>I'd have to go back and look at the paper to be sure, but off the top
>of my head I believe they played tricks with the receiver-advertised
>window. During periods of disconnection, an agent at the base station
>[...]
>A pretty intricate hack...
And ugly, too. I really turn blue when I see people playing these
sorts of tricks. It doesn't work for UDP, and even for TCP it cannot
be as effective as properly designed and implemented link level ARQ
and FEC.
I also envision a near future world where IPSEC is ubiquitous, thus
defeating such egregious layering violations. (This is a good reason
to deploy IPSEC, totally aside from security!)
>a hop is needed. But I guess it is also true most systems hop far
>more frequently than the etiquette rules require them to. And I am
>not sure what non-ISM systems do.
Faster hopping is a good idea, as that minimizes the interleaving span
and thence the delay that others have to implement to deal with
hopping collisions. Some military systems actually hop multiple times
per *symbol* (channel bit) for maximum anti-jam capability, but this
entails inefficiencies of its own. Hopping somewhere between once per
symbol and once per packet is probably a reasonable region for
civilian systems.
Re non-ISM systems, I can only speak for IS-95 CDMA which is direct
sequence spread, not hopped. So interference looks more like
continuous low-level wideband noise rather than strong bursts. But
that noise continuously varies due to user activity, power control
changes, etc.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST