I thought that in the java case the problem only occurred because
TCP_NODELAY was set?
Perhaps/probably, since they were sending something in five spearate
peices and so were "semistuck" until cwnd grew to five packets from the
initial three.
However, had it not set TCP_NODELAY, the first of the five small things
would be send, and the next four buffered, but I don't think the next
four were >=MSS and so would have awaited the "remote" ACK anyway.
I suspect that if an application wanted to have multiple, sub-MSS
requests outstanding at a time (eg netperf TCP_RR with --enable-burst
and then test-specific -b option might be one way to see it, but maybe
not (1)) it would still run into issues with the mapping of the
byte-based ABC to the packet based cwnd.
Also, even if the TCP connection stalls for the ACK, why does it take
multiple miliseconds for the ACK to come back over the localhost?
If the entire request has not been sent, it has then not been received,
so there can be no application level response from the receiver, hence
no piggy-backed ACK that way.
If the traffic received thusfar is small, perhaps it does not trigger a
piggy-back of the ACK on a window update.
So, unless the small traffic triggers some other immediate ACK
heuristic, we'll be waiting for the standalone ACK timer to expire.
rick jones
(1) the TOT in subversion at http://www.netperf.org/svn/netperf2/trunk
actually has a user-level slow start in it rather than an initial first
burst. This was my attempt to make sure that when -D (TCP_NODELAY) was
set that every request would still be a distinct TCP segment -
otherwise, the slow-start in TCP might coalesce the separate sub-MSS
segments. I've seen evidence, perhaps anecdotal, that that heuristic
was successful prior to a 2.6.15 kernel and might not be successful on a
2.6.15 kernel.
-
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
