[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: improving download speeds with altq?



Moritz,
You're a little confused, but I'm trying to do a very similar thing.
(the below is simplified, but explains your problem)

What actually happens is that for every "download" tcp packet a small
(zero data) tcp packet is sent back to acknowgedge the packet arrived.
[ NB. this is *not* just what is usually meant by an 'ACK' packet ]
Without this acknowledgement packet, the source doesn't think the
packet arrived, and will (after a time) retransmit the original
packet and start waiting again for an acknowledgement.

So, what happens when your upstream gets full? You start dropping
packets of course, but if those packets are the ack packets for a
1.5kb packet that has already been downloaded, the upstream server
will wait a while (throttling back the transfer rate) and then
retransmit that original 1.5kb packet.
Your client now sees this duplicate packet as a duplicate and 
drops it, but not before re-sending an appropriate ack again.
And this cycles.

Usually (especially as the small ack packets have a better chance of not
being dropped over your larger 1.5kb upload packets) any lost acks
just reduce the download rate for a tiny time, but when the upstream
is totally full, enough acks for the download may be dropped to
actually have a big impact. That's what you are seeing.

The solution is to use ALTQ to give small packets (<200 bytes) a higher
priority over larger packets.

It's a similar problem if you try surfing when your upload (or download)
is maxed out - the small DNS request (or reply) gets dropped and
despite retries, the browser times out before a valid reply makes it
back.
Result - site not found.

The same ALTQ rule would fix that problem too (or you could just pick
out
UDP/53 as a special, hi priority case)

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto                                       Tel. 07855 805 271
http://www.devitto.com                         mailto:dom_(_at_)_devitto_(_dot_)_com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 


-----Original Message-----
From: owner-misc_(_at_)_openbsd_(_dot_)_org [mailto:owner-misc_(_at_)_openbsd_(_dot_)_org] On Behalf
Of gtgbr_(_at_)_gmx_(_dot_)_net
Sent: Thursday, December 12, 2002 5:50 PM
To: misc_(_at_)_openbsd_(_dot_)_org
Subject: improving download speeds with altq?


Hi,


my Internet connection is 768/128 kbps ADSL - every time my upstream is
used up, the download speed drops down to ~20-30% ... the ACK packets
(if I understood this correctly) don't get out through the upstream fast
enough. I wish to give those ACK packets highest priority over all other
traffic.

I've been trying to solve this with altq for weeks now, and no matter
what I try, either nothing is happening or things get worse. I blame my
lack of understanding for QoS to play a big part in this misery - all
documentation I came across assumes that the reader already understands
all those principles/techniques of QoS (Token Bucket Regulator, RED,
HFSC, RSVP, ....), and I often simply don't understand what those docs
are talking about. If anybody knows some links to papers that explain
all those things from ground up, this would be very appreciated.

My experiments were mostly about CBQ, hoping that the control class
includes those ACK packets without data payload, but it seems that I'm
wrong - is what I'm trying to do possible at all?

Thanks a lot for your help,


Moritz

P.S.: I'm using OpenBSD 3.2, i.e. no altq-in-pf, yet.