motivation for TCP's cwnd clamp?

[Armando L. Caro, Jr.]

I have been reading through the TCP code for kernel versions 2.4 and
2.6, and have noticed that both versions not only cache cwnd state, but
also use the cached state to clamp the cwnd of subsquent TCP connections
to the same destination. I can see the benefit (under some conditions)
for caching cwnd state, and it's useful (for the conditions where
caching hurts performance) that 2.6 offers the ability to turn this off.
However, I do not understand the motivation for setting a hard clamp on
the cwnd growth based on a cached cwnd. With this feature, a single
unlucky TCP connection to a destination will hurt the performance of all
subsequent TCP connections to that destination for as long as the state
is cached. I imagine that there must be a benefit that outweighs this
disadvantage, but I don't see it. Can anyone shed light on this for me?

Thanks in advance... (please CC me on the replies, because I am not
subscribed to the list)

-- 
Armando
www.armandocaro.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/