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

From: Vernon Schryver <[email-masked]>
Date: Tue, 19 Oct 1999 08:41:07 -0600 (MDT)

> From: Jan Kullander <[email-masked]>

> ...
> >On rereading this, I see that Ericsson is talking about 3000:1 ratios,
> >not merely 10 Mbit/20 Kbit, or 500:1.  In practice as opposed to theory,
> >how will you get such high ratios?  What kind of TCP windows will the
> >mobile devices be advertising to allow 30 Mbit/sec streams, particularly
> >given the RTT's that Ericsson people have talked about for GSM data
> >services?  If the RTT is a fast, direct Internet 300 ms, and the mobile
> >device advertises a 1 MByte TCP-LW window, regardless of how much you
> >compress ACKs, you won't be able to reach 30 MBit/sec downstream.  Given
> >the far larger RTT's I've seen mentioned and the likely far smaller than
> >MByte per TCP connection buffering in the mobile phone, wouldn't it be
> >wise to use far smaller assymmetries as your design limit?
>
> > 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.

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.

> 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.)

Vernon Schryver    [email-masked]