Re: calculate saving ratio of *link bandwidth*

George Michaelson wrote:
>
> You're asking how to reconcile an IP/octet count such as SNMP counts on
> interfaces, or netflow/netramet/nnstat counts, against the applications
> only view?
>
> Thats around 10% isn't it? similar in fact to the back-channel load of
> ACK and the initial request, if you are a fetch-pays customer on a network
> and serve outbound (uncharged) data in terms of what you pay.

Well, 10% is a _very_ rough estimate. If you'll humour me with a gross
oversimplification (to the point of inaccuracy, and perhaps a step
farther), you need about 8 packets to handle basic connection overhead,
and then 2 per data packet.

Exactly what number of data packets we're talking about will depend on
the MTU/MRU path between the proxy and the clients, and on the number of
bytes passed to each write() call.

But yeah..if you're not overly concerned with accuracy, 10% isn't a bad
figure. Sometimes it'll be too high, sometimes it'll be too low. It
depends greatly on network conditions both external to your system (data
feed rates into your proxy from the servers the clients are trying to
fetch from...that affects the size chunks that squid is going to spit
out as an application) and can also vary considerably on the client side
depending on how congested the clients want to make their uplinks.

> Why similar? because the majority of the back=data is pure ACK and other TCP
> overhead so its within an order of scale to the overheads on top of the served
> data.

The ACK data's easy to calculate...but only of you can first calculate
how many data packets went (and make the assumption none of them got
lost).

>
> DNS adds a bit more. If you don't do DNS, you save traffic.
>
> This is an intersting area. We're running a mirror (the cousin to a cache)
> and we notice marked parallels in the curve-shapes between bothe methods
> of count, but clear differences too!
>
> Anyway, I'd suggest you do some monitoring like netflow/snmp/nnstat/netramet
> to get your handle on the overhead costs of TCP+FTP and TCP+HTTP and then
> use the hitrate, and measured object size to determine the overall packet
> savings.

Mmmm. Packet-based logging. We use it. Variance between application logs
and packet-logs (per day) is interesting, due to the variable
packet-lengths (from conditions already mentioned). There should be a
paper on this somewhere. If there isn't, one should be written.

D

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ 
------END GEEK CODE BLOCK------