Subject: RE: Asymmetric, thin and long (satellite) links

From: [email-masked]
Date: Thu, 2 Sep 1999 13:22:49 -0400

Markus,

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.

Some TCP traffic, like bulk FTP transfers, can tolerate a more asymmetric network, as their forward:return bit ratio is
quite high (about 47:1, using 1500-byte packets), since there's almost no return traffic except ACKs at about 1 per two
data packets. However, HTTP traffic is *much* less asymmetric (my measurements have shown a mean ratio of about 8.5:1):
there's significant return traffic arising from the receiver's GET requests for each Web page, AND for each little page
part (in-line images, even the little buttons). Each GET request is around 350 bytes on average. For asymmetric network
with much higher bitrate asymmetry, the _return_ channel becomes the bottleneck link: the return traffic (GETs, ACKs)
can't get back to the sender fast enough to keep it pumping. The sender spends some of its time sitting and waiting for
the next ACK or GET.

Let me give an example, taken from some actual ADSL performance tests I did a few years ago.
Forward channel:	1.5 Mbps
Return channel:	64Kbps
bitrate ratio = 1.5 Mbps: 64Kbps = 23.4:1

Measured ratio of forward:return HTTP traffic: 8.5:1

The result was that my return link was nearly always saturated, but the forward link was only about 30% full (500Kbps
average).

These effects of asymmetry are *in addition to* other effects of long delay networks, which tcpsat has so well
enumerated, and for which they have spelled out mitigating practices.

= Peter
------------------------------------
Peter Warren
Principal Member of Technical Staff
Network Infrastructure Laboratory
GTE Laboratories
40 Sylvan Rd.
Waltham, MA 02451

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Markus Buchhorn
>Sent: Thursday, September 02, 1999 1:17 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Asymmetric, thin and long (satellite) links
>
>
>
>Hi All
>
>I've had a question from a colleague in Australia facing an interesting
>problem. Due to the high-expense of cable under the Pacific it
>appears that
>one ISP is suggesting (or has in fact set it up) to put http downstream
>traffic over a satellite link, nationally and internationally.
>This would
>mean that requests go over terrestrial lines and responses
>come back over
>satellite (to be reinjected onto terrestrial links locally).
>
>http may not be the only traffic to face this modification,
>but it would
>certainly be the highest impact. (ftp and email would cover a lot, then
>there's the various multimedia streaming/realtime protocols,
>DNS, ICQ?, ...)
>
>Besides the obvious impact of increased rtt's, or
>bandwidth*delay products,
>(you can't go under the Pacific for less than 200ms rtt, or to
>geosynch and
>back for much under 500ms) what other issues leap to mind,
>regarding tcp
>performance on assymetric services and very-long/thin pipes?
>Malcolm asked
>if there are any "classic" papers that cover this. I don't know of any
>(although I'm looking at RFC2488 and its excellent references to start
>with) but I see that the PILC charter has a couple of
>milestone documents
>due about now:
>
> May 99 Submit Internet-Draft on long-thin networks (based on
>draft-montenegro-pilc-ltn-01.txt) submitted to the IESG for
>publication.
>
> Jun 99 Draft on asymmetric network paths.
>
>neither of which I can find online yet - so somebody here is presumably
>working on this as I type :-)
>
>[oh - just found the first one at
>http://mirror.aarnet.edu.au/ietf/internet-drafts/draft-monteneg
ro-pilc-ltn-0
2.txt - sorry]

>From Malcolm:
>[on Monday 6 Sep] we want to
>discuss issues of routing web traffic over satellite circuits.  (It would
seem
>that currently XXXXXXXX is routing our http traffic over satellite,
perhaps in
>one direction only)
>
>I have a feeling that there are a few classic papers about the problems of
>using tcp over satellite circuits, and the disadvantages of running tcp over
>asymmetric paths.

Any help, comments, advice, references, brickbats or bouquets appreciated !
By Monday would be great :-), but any time thereafter too would be very
useful.

Thanks !

Cheers,
	Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: [email-masked], snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429

---

From: Geoff Huston <[email-masked]>
Date: Fri, 03 Sep 1999 06:54:25 +1000

At 01:22 PM 9/2/99 -0400, [email-masked] wrote:
>The impact of such an asymmetric situation depends on several things, but 
>one first-order effect is related to the type
>(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

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.