Subject: RE: [TIME-LIST] RE: draft-ietf-pilc-asym-00.txt

From: Jan Kullander <[email-masked]>
Date: Wed, 20 Oct 1999 18:39:27 +0200

From: Vernon Schryver    <[email-masked]>

> > From: Jan Kullander <[email-masked]>
> 
> > > It is true that normal maximum window sizes of today limits the top
> speed 
> > > of *individual* connections with RTTs of 300ms. However, there may be 
> > > competing traffic over the reverse bottleneck link, effectively
> increasing
> > > the asymmetry and pushing the limits.
> 
> I don't understand how that might be.  Unless the sum of the advertised
> windows of the individual TCP connections amounts to at least
> bandwidth*RTT or more than 10 MByte, you cannot fill a 300 ms. by 30
> Mbit/sec pipe.  That means that your mobile phone must be advertising at
> least 1 MByte of windows if you are to fill the pipe.  Is that plausibe?
> If each connection advertises a 20 KByte window (e.g. more than Windows
> and so presumably Windows CE likes), then you would need 50 connections.
> 
We are aware that both TCP peers need bandwidth*RTT buffer space to
fully utilise the channel. However even 16 kb buffer space (which we believe
is common among Internet servers, please advise us otherwise) requires 
more bandwidth on the reverse channel than GSM offers to sustain the
uncompressed ack flow. We wanted to point out that even if the asymmetry
is limited to a non extreme level in this case, the possible sharing of the
reverse bottleneck channel exacerbates it.

> Or to put it another way, that 1 MByte of aggregate advertised TCP windows
> needs to have some connection with the buffering in the phone.  Will any
> phone be willing to devote a reasonable fraction of 1 MByte merely to TCP
> buffering?  That sounds unlikely to me.  The buffering needed for 300 ms
> voice obviously does not count.  The buffering needed for HTTP pages that
> might plausibly be shown on a mobile phone screen are not as small, but
> they still don't amount to anything close to 1 MByte per 300 ms.
> 
The receiving host could also be a laptop. We agree that MByte sized
buffering in a mobile phone seem a bit unlikely. Furthermore, we don't
see much use of it.

> > Furthermore, proxies adapted to large bw*delay accesses could be 
> > deployed to enable single TCP connections to utilise more of the 
> > downstream bit rate in your example.
> 
> Where are these proxies?  I thought people in Scandanavia and mobile phone
> people elsewhere were saying that the RTT through a mobile phone radio
> link itself is often close to 300 ms.  If that is true, then unless you
> have a proxy on the mobile phone itself, there is still have that problem
> of not being able to use the machinery proposed.  (Of course, if
> the proxy is on the phone, then you need the machinery even less.)
> 
We see no need for a proxy in the asymmetrically connected host, just
the need of large buffers as you pointed out.

The proxy we were thinking of would be located on the opposite side of
the asymmetric link (from the receiving host point of view). It could e.g.
be an ordinary workstation with an Apache web proxy and a FreeBSD 
operating system with timestamp  and SACK options enabled and large 
buffer spaces allowed.

(Automatic TCP buffer tuning as Semke, Mathis and Mahdavi described
it would probably help if the proxy were on the sending side of multiple
TCP connections to other hosts not requiring large windows).

///Göran/Haider/Jan