Vern,
Thanks for your thoughtful comments. I think we can work most of them in
without much discussion, but I have a few replies below:
>...
>I think an additional mechanism should be documented, which is acking every
>packet. This is fully allowed by the existing standards, and results in
>the congestion window opening appreciably faster.
>
I agree that acking every packet gets the window open faster and that is
good, but we should check with the asymmetric folks and see if this causes
any problems in the return path. See below.
>> ... Ku band
>> transponders are typically around 50 MHz. Furthermore, one
>> satellite may carry a few dozen transponders.
>
>A few dozen transponders isn't enough then to fill the 12 GHz bandwidth.
>Is there excess capacity, or am I missing something?
>
RF bandwidth is parceled out by international treaty, there are a lot of
uses for it and a lot of demand, so you just don't get very much. Check
out http://www.ntia.doc.gov/osmhome/osmhome.html
>>...
>> Another common situation arises when both
>> the incoming and outgoing traffic are sent using a satellite
>> link, but the uplink has less available capacity than the
>> downlink. This asymmetry can have an impact on TCP performance.
>
>I was confused whether this is referring to the incoming and outgoing
>using the *same* satellite link, and the asymmetry comes from uplink/
>downlink capacity asymmetries; or if they're using different satellite
>links.
>
It could be the same satellite link; some systems use a terrestrial (phone)
line for the return link. Transmission subsystems are expensive (cost,
complexity, power, safety) compared to receiver subsystems and so the
return link capacity may be smaller or non-existant (requiring the use of a
terrestrial link for ACKs). Acking every packet could be a problem for
some systems.
>> ...
>You might mention that caching can avoid needing to do it at all.
We debated covering caching and decided to restrict ourselves to TCP issues
only, but a mention might not hurt.
>> ...
>> satellite links. There are some situations where FEC cannot be
>> expected to solve the noise problem (such as military jamming, deep
>> space missions, noise caused by rain fade, etc.).
>
>It's not obvious why deep space missions have this problem. It's clear
>for the others that you can suffer from large outage blocks, rendering
>FEC ineffective. Is that the same problem with deep space?
>
For deep space, the distances are so large and signal is so weak that there
are going to be errors even with the best FEC. The received signal power
from Voyager at Jupiter was around 3 X 10E-16 W (that is a very weak signal
and it's hard to separate it from the noise).
>> ...
>> Mechanism Use Section Where
>> +------------------------+-------------+------------+--------+
>> | Path-MTU Discovery | Recommended | 3.1 | S |
>> | FEC | Recommended | 3.2 | L |
>> | TCP Congestion Control | | | |
>> | Slow Start | Required | 4.1.1 | S |
>> | Congestion Avoidance | Required | 4.1.1 | S |
>> | Fast Retransmit | Recommended | 4.1.2 | S |
>> | Fast Recovery | Recommended | 4.1.2 | S |
>> | TCP Large Windows | | | |
>> | Window Scaling | Recommended | 4.2 | S,R |
>> | PAWS | Recommended | 4.2 | S,R |
>> | RTTM | Recommended | 4.2 | S,R |
>> | TCP SACKs | Recommended | 4.3 | S,R |
>> +------------------------+-------------+------------+--------+
>> Table 1
>
>IMHO, add:
>
>> | Ack every packet | Recommended | 4.X | R |
>
Mark and I went around on this early on and wound up moving acknowledgement
issues to the research issues draft. I would tend to go along with you
with the caveat that asymmetric systems should consider the impact on their
return channel. Also, if everyone started acking every packet, would this
hurt the network?
We are also considering taking out Fast Recovery as a recommended
mechanism. There could be some problems when using large windows and SACK
makes it moot.
r/
Dan
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST