Subject: SV: How asymmatric are paths?

From: [email-masked]
Date: Fri, 3 Dec 1999 11:25:06 +0100

Just to be picky,

DVB (Digital Terrestrial TV) can provide a channel with 30 Mbps
at IFA we used an 11 Mbps channel where 3 Mpbs was used
for a radio broadcast from Deutche Telecom. So we "only" had
8 Mbps to play with.

Anyway, with MS OS we could not manage more than 1 Mbps
with a homemade SACK-filter we managed to get 8 Mbps on a 
Linux OS.

the bandwidth asymmetry should then be: 8M/9.6k = 833 or larger
if a different DVB mode is used.

/Jonas

> ----------
> Från: 	Göran L Johansson[SMTP:[email-masked]]
> Skickat: 	 den 2 december 1999 11:30
> Till: 	[email-masked]
> Angående: 	RE: How asymmatric are paths?
> 
> We have been involved in developing a wireless system consisting of
> Digital Audio Broadcast (~1.2 Mbps) downlink and GSM uplink (9.6 kbps).
> This work has been within the MEMO project (http://memo.lboro.ac.uk/),
> which is part of the ACT project in EU's fourth frame work. This system
> has been thouroughly tested and is in small-scale commercial use
> (Teracom http://www.rd.teracom.se/). The asymmetry is about 1:125.
> 
> Since this system has large bandwidth-delay product it is vital to include
> the SACK and Timestamp options. Since these options are not compressed
> in standard (Van Jacobson) TCP/IP header compression we end up with
> relatively large ACK packets. Thus we see that the return path limits the
> throughput, even though the asymmetry is just 1:100.
> 
> At IFA 99 (Internationale Funkausstellung in Berlin) there was a
> demonstration
> of IP access over GSM and terrestial DVB. They managed to utilise ~8 Mbps 
> out of ~30. The demonstration was made by Teracom and was a deliverable in
> the MEMO project. To achieve this speed we believe they maintained a queue
> to the GSM link and selected which acks to drop in it.
> 
> Our conclusion was that we need a compression method capable of handling
> Timestamp and SACK options. Since it is a wireless system we believe
> that the compression method should also be more robust against losing
> compressed packets compared to VJ. This is part of the motivation behind
> our suggestion of ACK Compression.
> 
> Göran Johansson
>

---

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 03 Dec 1999 15:51:31 +0100

We did some experiments with Globecast in London (ESA and Delta Communication).

Given DVB (Digital Video Broadcast) components (e.g. modems, packet gateways)
work at bit rates higher than 30 Mbps) and the return link is dial-up modem
(9.6 kbps, 28.8 kbps, or whatever) the basic assymetry is big (if you consider
it credible to use all the space capacity for a few users).

But, when we were doing practical experiments we observed several
things which lead to much greater assymetry:

(1) Sharing of the return path - such systems often use asymetric
routing, with a dialup return path.

So the modem connection was to a terrestrial ISP - and the
ISPs we used didn't always have congestion free return paths.
If we had been doing duplex communication through the ISP,
then the down-load rate may well have been limited. But given
we had a high-speed DVB satellite link connection for down-load
I wonder why you'd pay for good terrestrial infrastructure AND
a satellite link?

(2) Some users (most) actually also want to send while the down-load
is in progress - not all of the modem link was available.

Protocol encapsulation (UDLR) should also have eaten into the bandwidth,
not least because it inhibits classic TCP header compression.  We didn't
use it because the proxy/server we used was at the hub site. To be general
we should perhaps have done this.

You said practical - it's important to realise the COST of transferring
huge volumes of data via satellite in unicast may prove unattractive.

Gorry Fairhurst

--

Gorry Fairhurst
University of Aberdeen, Scotland, UK
http://www.erg.abdn.ac.uk/users/gorry