David S. Miller wrote:
From: John Heffner <[EMAIL PROTECTED]>
Given that RFC2681 is Experimental (and I'm not aware of any current
efforts in the IETF to push it to the standard track), IHMO it would not
be inappropriate to make this behavior controlled via sysctl.
I have to respectfully disagree.
This is the price you pay when the network's congestion is being
measured by probing, information becomes stale over time if you don't
send any probes.
And this change of congestion state is real and happens frequently for
most end to end users.
When you're bursty application is not sending, other flows can take up
the pipe space you are not using, and you must reprobe to figure that
out.
A lot of the time doing 2861 is a good thing, since if you have a long
pause, you've lost your ack clock, and you don't want to send a
window-sized burst because you'll probably overflow a queue somewhere
and step on your own feet. Since we don't have a pacing mechanism, a
slow start is really the only way to do this.
I don't entirely buy the "staleness" argument. I don't think that *not*
doing 2861 will affect the stability of congestion control, since all of
the response mechanisms are still in place. (Most OS's don't do 2861,
and it is not a standard.) If you have a long RTT, short RTT flows can
make a big difference in congestion in a period much smaller than your
timeout. In fact, congestion information is *always* stale by the time
you get it. :)
Sometimes having cwnd validation turned on will make your applications
perform better, sometimes worse. I don't think it would be incorrect to
add a switch. One question is whether it's worth adding the switch
(i.e., do enough people care?).
Myself, I'd be interested to see some quantitative comparisons of
performance with a "real" application affected by this.
Thanks,
-John
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
