On Tue, Apr 8, 2008 at 5:33 AM, Wenji Wu <wenji@fnal.gov> wrote:
quoted text
> > NewReno never retransmitted anything in them (except at the very end
>  > of
>  > the transfer). Probably something related to how tp->reordering behaves
>  > I suppose...
>
>  Yes, the adaptive tp->reordering will play a role here.

I remember several years ago when I first looked at chronic reordering
with a high BDP, the problem I had was that:
1) Only acks of new data can advance cwnd, and these only advance by
the normal amount per ack, so cwnd grows very slowly.
2) Reordering caused slow start to exit early, before the reordering
threshold had adapted
3) The "undo" code didn't work well because of cwnd moderation
4) There were bugs in the reordering calculation that caused the
threshold to be pulled back

Some of these shouldn't matter to you because your rtt is low, but I
thought i would be worth mentioning.  I'm not sure what is keeping
your cwnd from growing -- it always seems to be within a small range
in both cases, which is not right unless there's a bottleneck at the
sender.  The fact reno does a little better than sack seems like the
less important problem.

Also, what's the behavior when turning off reordering, in each or both
directions?

  -John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html