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

Reply via email to