Hi,
Please guide me regarding some doubts on calculating the BDP

I am using the following formula,

BDP = bandwidth * RTT
= 100 mbs * 67 ms
= 13107200 byte * .067 sec
= 878182.4 bytes/sec
= 857.6 KBytes
= 860 KBytes approx

Based on that , I have done the following changes.

sysctl -w net.core.ipv4.rmem = 4096 87380 878182
sysctl -w net.core.ipv4.wmem = 4096 87380 878182


sysctl -w net.core.wmem_max = 878182
sysctl -w net.core.rmem_max = 878182

Is the following are corrects. After doing these settings , I am
receiving a transfer rate of 70 mbs using iperf , a TCP and UDP
performance measurement tool. But if i double
the value of BDP i.e if I use 1600 Kbytes of BDP , then I am
reaching the bandwidth
of 97 mbs .
My question is . is it O.K to assign a greater value (as twice
as ) , then the calculated
BDP . Or the RFCs does not allow this.

Also another doubt which bandwidth we should consider.

My speed of NIC is 1000 mbs per second, speed of the switch is
100mbs and
the leased line link which connects us to other networks is
dedicated 100mbs.
The leased line link is not shared.So , i am getting 100mbs.
Now, which bandwidth should i Consider. the speed of NIC , the speed
of switch
or the speed of leased line.
Also , regarding the RTT . Suppose I am communicating with various
links that has
RTTs of 67 ms , 56 ms , 47 ms. Which RTT should I consider.


Please Guide me.

query.cdac@gmail.com wrote:
> Hi,
> Please guide me regarding some doubts on calculating the BDP
>
> I am using the following formula,
>
> BDP = bandwidth * RTT
> = 100 mbs * 67 ms
> = 13107200 byte * .067 sec

small change, but 100Mbs (M not m!) is counted in decimal, not
power-of-two k/M/G, so 12500000 Byte/s

> = 878182.4 bytes/sec

so dimension is now bytes, not bytes/sec. OK, picky picky...

> = 857.6 KBytes
> = 860 KBytes approx
>
> Based on that , I have done the following changes.
>
> sysctl -w net.core.ipv4.rmem = 4096 87380 878182
> sysctl -w net.core.ipv4.wmem = 4096 87380 878182
>
>
> sysctl -w net.core.wmem_max = 878182
> sysctl -w net.core.rmem_max = 878182
>
> Is the following are corrects. After doing these settings , I am
> receiving a transfer rate of 70 mbs using iperf , a TCP and UDP
> performance measurement tool. But if i double
> the value of BDP i.e if I use 1600 Kbytes of BDP , then I am
> reaching the bandwidth
> of 97 mbs .
> My question is . is it O.K to assign a greater value (as twice
> as ) , then the calculated
> BDP . Or the RFCs does not allow this.

I don't think it's an RFC issue - surely one is free to tune a machine
as required?

>
> Also another doubt which bandwidth we should consider.
>
> My speed of NIC is 1000 mbs per second, speed of the switch is
> 100mbs and
> the leased line link which connects us to other networks is
> dedicated 100mbs.
> The leased line link is not shared.So , i am getting 100mbs.
> Now, which bandwidth should i Consider. the speed of NIC , the speed
> of switch
> or the speed of leased line.

In general, I believe you should use the maximum speed of the slowest
link - in your case, the leased line often cannot go at top speed and
yet will, hopefully, sometimes provide the maxiumum 100Mbs.

> Also , regarding the RTT . Suppose I am communicating with various
> links that has
> RTTs of 67 ms , 56 ms , 47 ms. Which RTT should I consider.
>

If performance is main issue, then the slowest. You might want to
consider how much buffer space you consume, if that is an issue on your
machine.

>
> Please Guide me.
>

Hope this was of some

Pete.

On Apr 23, 4:32 am, Peter Bunclark <p...@ast.cam.ac.uk> wrote:
> I don't think it's an RFC issue - surely one is free to tune a machine
> as required?

This was my first thought too.

Remember, BDP simply tells you:

"How many people to expect to be waiting in line at a bank given the
average arrival rate of persons/minute and the averate amount of time
spent in line, in minutes. It is nothing more than a restatement of a
simple theorem from queing theory called Little's Theorem:
http://en.wikipedia.org/wiki/Little's_law

I recommend thinking about the signifcance of the thereom in the
context of people waiting in line while doing your calculation. In
that case, you could infer that the goal is to make sure you have
enough buffer space to accommodate any "oustanding" packets in
transit. For example, if there were a switch between two nodes doing
a transfer, and there were a finite delay between the instant of
arrival into the switch and instant of departure out of the switch,
then BDP would tell you how much memory will be required to buffer the
packets while they queue up in the switch waiting to depart.

One important thing to keep in mind is that the process is stochastic,
so there will be a variance, so if you calculated BDP exactly, you
will probably get under utilization because instantaneous variance in
transmission rate or delay from their means will cause instantaneous
changes in requirements of the size of the queue. Depending on what
alogrithm is in place to do the flooding, you might get oscillations
in transmission rate. If the stochastic process is
"stationary" (http://en.wikipedia.org/wiki/Stationary_process),
meaning that the characteristics do not change over time, then you can
pick one BDP and use that. If not, then your BDP will have to vary
with the characteristics.

So making your buffer twice the size is good, because it reduces
problems with variance in effective transmission capacity. But one
should keep in mind that there are generally multiple buffers to
consider along the link, and it is important to think about each
segment indpendently, and ask which buffer you are trying to make big
enough.

-Le Chaud Lapin-

In article <1177361521.605149.260490@n59g2000hsh.googlegroups .com>,
Le Chaud Lapin <jaibuduvin@gmail.com> wrote:

>Remember, BDP simply tells you:
>
>"How many people to expect to be waiting in line at a bank given the
>average arrival rate of persons/minute and the averate amount of time
>spent in line, in minutes. It is nothing more than a restatement of a
>simple theorem from queing theory called Little's Theorem:
>http://en.wikipedia.org/wiki/Little's_law

That's a fine theorem, but far too fancy for what the bandwidth delay
product is about.


>One important thing to keep in mind is that the process is stochastic,
>so there will be a variance, so if you calculated BDP exactly, you
>will probably get under utilization because instantaneous variance in
>transmission rate or delay from their means will cause instantaneous
>changes in requirements of the size of the queue. Depending on what
>alogrithm is in place to do the flooding, you might get oscillations
>in transmission rate.

That is also true, but I think the famous TCP throughput sawtooth pattern
is something simpler and not really stocastic. See
http://www.google.com/search?q=tcp+throughput+sawtooth
You can see it in purely deterministic situations where a buffer in the
path overflows, such as when you use a TCP window enough larger than
2*bandwidth*delay.


>So making your buffer twice the size is good, because it reduces
>problems with variance in effective transmission capacity. But one
>should keep in mind that there are generally multiple buffers to
>consider along the link, and it is important to think about each
>segment indpendently, and ask which buffer you are trying to make big
>enough.

That's also fine and but irrelevant to why the critical window size is
2*bandwidth*delay or bandwidth*RTT. There is nothing stocastic or
related to "variance in effective transmission capacity" in that factor
of 2. As that web page says, Little's Theorem is "a quite remarkable
result" about averages, probability distributions, and so forth.
2*bandwidth*delay comes from simple, even simplistic thinking about
what happens in purely deterministic scenarios when the sender does not
put at least 2*bandwidth*delay bytes in flight. If not, the sender
will be waiting for an ack when it could have been sending.


That common operating systems involve tuning parameters that are
ostensibly about buffer sizes does not change the fact that main parameter
that being manipulated is the TCP window size. The Law of Networking
that requires that the TCP window be no larger than some buffer is the
worry about what would happen if the application does not keep up. In
theory, you can use a receive-buffer of one MSS with TCP windows of
MBytes, but in practice applications don't always keep up and so it is
best to limit the offered window to the number of bytes that the operating
system is willing to receive and buffer for the application.


Note also that `sysctl` is rarely the best way to adjust the receive
or transmit buffer sizes. It is almost always better to use
setsockopt(SO_SNDBUF) and setsockopt(SO_RCVBUF). Those system calls
far more portable than sysctl parameters, and they don't mess things
up for other applications running on the same box.


Vernon Schryver vjs@rhyolite.com