Mark Allman's response points to the work done at Berkeley by Balakrishnan, et al, which is quite good. It contradict's
Goeff's conclusion, below, that the situation for TCP is "substantially unaltered in an asymmetric hybrid satellite /
cable system."
That work (at least the 1997 version, which is the only one I found) deals primarily with bulk FTP-over-TCP transfers.
My claims, repeated below from my email of 9/2, add to this by looking at the more specific case of HTTP-over-TCP
transfers, which are quite different from bulk (FTP) TCP transfers, and which suffer more from highly asymmetric links.
I tried to make that clear, but perhaps I failed. Let me try again:
First, why should we care? HTTP traffic makes up as much as 60% - 75% of all Internet data (as reported in 1997 and 1998
reports in IEEE Networking by Kevin Thompson, et al, on Wide-Area Internet Traffic Patterns and Characteristics). While
this percentage may vary somewhat around the globe, it indicates that HTTP must be taken into account here. HTTP has
much more return traffic than bulk TCP transfers, due to the volume of return channel request packets for each little
Web page part. Now suppose we have a highly asymmetric network: while these requests are trickling upstream on the
narrow return channel, the Web server is sitting and waiting. Also, ACKs get compressed behind these relatively big
request packets, thus messing up the inter-ACK spacing and slowing down the server even more.
Practically speaking, the network provider may not care, since he may still get pretty good throughput, relative to the
alternatives. I was merely pointing out that there *is* indeed a measureable throttling effect on the forward
(downstream) flow of HTTP data from Web server to client if the link is much more asymmetric than the data itself. In
such a case, you will not be able to fully utilize the forward pipe.
= Peter
------------------------------------
Peter Warren
Principal Member of Technical Staff
GTE Laboratories
40 Sylvan Rd.
Waltham, MA 02451
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]On
>Behalf Of Geoff Huston
>Sent: Thursday, September 02, 1999 4:54 PM
>To: [email protected]
>Cc: [email protected]
>Subject: RE: Asymmetric, thin and long (satellite) links
>
>
>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