At 16:56 20/10/2005, Brian Gibbons wrote:

> >From: "Simon Byrnand" <simon@igrin.co.nz>
> > This is a good example of the not-so-obvious limitations of 128Kbit
>upstream.
> >
> > Assuming that the 128Kbit limit is here to stay for the forseeable
> > future the only choice is to do QoS on on the upstream traffic and
> > give prioritization to acks, and for good measure do something like
> > sfq as well to avoid any one stream from hogging the available bandwidth.
>
>I don't think giving outgoing ACKs priority will help much.

It helps one of the originally mentioned problems - poor download
speeds on long term connections.

>A web browser usually opens 4 sockets to a web server and sends multiple
>HTTP requests to download all the components of a web page. Often these
>components are from other web sites so more three way hand shakes and HTTP
>requests are required to download the page.
>
>An HTTP request will usually be 100 .. 200 bytes, the response may be a
>small component of the web page (e.g. a 200 to 500 byte GIF image). So you
>have sent 200 bytes to get 200 bytes back. Under this scenario the maximum
>download speed for some web pages may be not much more than your upload
>speed.
>
>If an outgoing email starts competing with the outgoing HTTP requests
>everything will grind to a halt. Rather than giving ACKs priority I would
>give outgoing HTTP requests the priority.

I don't think that its necessary to give any particular traffic
prioritization, (apart from acks) if you use some kind of round robin
scheduler like sfq, which gives "fair" access to each seperate
stream. In that case each outgoing stream gets a fair chance. We use
it for wireless links and it works amazingly well in practice - even
with 256Kbit you can do a file transfer in either direction and still
have fairly snappy interactive browsing performance, and good
performance for transfers in the opposite direction as well, and
thats not even doing ack prioritization.

A combination of prioritization of acks (to help prevent heavy
traffic use in one direction slow down the other direction) and round
robin scheduling such as linux's sfq can make a world of difference
to how usable a certain sized chunk of bandwidth is, especially when
shared across many client computers/applications....

>Amazing isn't it, we are now confronted with an Internet topology in NZ that
>is barely usable. The "headline" speeds are bullshit, in reality a 2mbit UBS
>connect probably performs at the same speed as a 256k UBS connection under
>"average business" conditions due to the fact that the bottleneck is in the
>128k upload path. Combine this with a minumum Round Trip Time increase from
>40ms (Jetstream) to 80ms (UBS) and you can see why business users are
>complaining.

Yep, there have definately been some retrograde steps... although its
a year or two since the latency was 40ms, its been 60ms for some time
now on the old Jetstream plans...

Regards,
Simon

-- 
This message is part of the NZ ADSL mailing list. 
see http://unixathome.org/adsl/ for archives, FAQ, 
and various documents. 
To unsubscribe: send mail to majordomo@lists.unixathome.org 
with "unsubscribe adsl" in the body of the message