net.inet.tcp.inflight_enable

[Noritoshi Demizu]

Sorry for my late response again.

>     The bandwidth estimation works with any HZ value, but it takes a lot
>     longer to get a good estimate when HZ is low simply because the
>     granularity of the measurement is far higher.

I made another experiments with longer transfers (up to hundreds of
mega bytes).

  http://www.demizu.org/~noritosi/memo/2005/0725/

In my home, I subscrie two ISPs.  One is FTTH (100Mbit/s shared among
neighbors) and the other is ADSL (down=47Mbit/s, up=5Mbit/s, 100 meters
(300 feets) from a local carrier center).  When I ping from my home to
major servers in Japan, i observe RTT=10ms to 20ms, depending on data
size.  So, I do not think those parameters in my experiments are unusual. :-)
But I do not know whether router queue lengths in my experiments are
common.

>     But, again, this particular case is only testing short transfers.

The table in the following URL shows what I'd like to say:
http://www.demizu.org/~noritosi/memo/2005/0716/df-inflight-100hz-log.html

If RTT is closed to 1/HZ, I think it is hard to estimate the bandwidth.
At least, it would take much time to estimate bandwidth correctly.

At the begining of transfer, TCP sends only three data segments.  An
RTT later, the sender would receive an ACK for the first and the second
data segment.  So, the estimated bandwidth is around 2 MSS / RTT.
Although 2 MSS / RTT is far from real bandwidth, this value is used to
cap congestion window.  Therefore, TCP sends only limited number of data
segments per RTT.  If the number of data segments sent in each RTT is
small, estimated bandwidth will be small.  If the estimated bandwidth
is small, the number of data segments that are allowed to be sent in
each RTT is also small.  So, it will take much time to get the correct
estimation of the real bandwidth.

I think snd_bwnd should not cap congestion window if RTT is close to
1/HZ.

Regards,
Noritoshi Demizu