Francesco-
Thanks for the comments...
> The delay*bandwidth product is the amount of data transmitted, but
> not yet received. The amount of data "transmitted, but not yet
> acknowledged" is twice that quantity.
Correct... I just always use the RTT as "delay", which is not
correct, but the results are the same. I'll clear this section up.
> For TCP to operate efficiently, the channel characteristics
> should be such that nearly all loss is due to network
> congestion. The use of forward error correction coding (FEC)
> on a satellite link should be used to bring the performance of
> the link to at least fiber quality.
>
> Is this reasonable? What is fiber quality? Are we implying that
> tcp over satellite will only work for practically error-free
> channels? What about the Ka band, where atmospheric attenuation
> due to rain is common and most certainly causes long periods of
> degraded channel quality?
You are right, we need to tighten up the vague language in this
section.
I think the use of FEC is quite reasonable. TCP takes all drops as
indications of congestion (the conservative thing to do from the
perspective of the network as a whole). Some people have said that
we can/should design mechanisms whereby we can tell why a packet was
dropped (congestion or corruption). Personally, I remain
unconvinced this will work well (it can never completely work; who
does a machine tell when it receives a corrupted packet? it can
never be sure the right host is being told, as the packet is
corrupt). I may be wrong, it is a research area at best. In the
absence of such a mechanism, we must choose conservativly and
therefore take the drop as congestion and backoff. TCP will work in
a satellite environment with a high bit-error rate, just not
particularly well. But, that is the case for any channel with a
high BER. So, I think it is quite reasonable to _recommend_ using
FEC for good performance. To me, it is the same as recommending the
use of TCP SACKs. You will get better performance with FEC than
without. However, it is not necessary for TCP to work.
Thanks again,
allman
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:30 EST