At 01:22 PM 9/2/99 -0400, [email protected] wrote:
>The impact of such an asymmetric situation depends on several things, but
>one first-order effect is related to the type
>of traffic you're trying to run over this network. You didn't specify what
>the forward (satellite) or return
>(terrestrial) channel bitrates are. In general, for such a situation, the
>ratio of forward:return _bitrates_ should not
>exceed the ratio of forward:return _bits_. In other words, the network
>asymmetry should not exceed the traffic's
>asymmetry. If it does, the return channel can become a bottleneck, and the
>forward data flow gets throttled.
Most of this work is based on a number of environmental factors:
a - unidirectional satellite bearers are far cheaper than undersea cable
bearers
at this point in time (of course this will change in the near-term
future)
b - you cannot purchase anything other than symmetric cable bearer
capacity (again this may change in the near term future)
c - public Internet traffic to and from the US (to be particular) is not
balanced, with the ration being variously 4:1 to 1.5:1
d - this implication is that there is available 'backhaul' cable capacity
that can be married with unidirectional forward haul satellite
capacity to produce a cost effective solution.
These conditions are relatively common on the western Pacific rim, where
there is both
cable and satellite capacity that meet the above 4 constraints.
The technical question is whether the pronounced asymmetry would impact on the
quality of the application or the cost effectiveness of the service (as an
inefficient
carriage system implies reduced cost efficiency of carriage). The question
relates most particularly to congestion managed traffic using TCP. The response
is that TCP uses a control loop that relies on both the inter-ack spacing
and the
window information contained in the ACK to control the sender. This reliance
is substantially unaltered in an asymmetric hybrid satellite / cable system.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:56 EST