> > http://www.cs.washington.edu/homes/cardwell/tcp_perf/
>
> Thanks. You could nail this for sure by tracing at the receiver
> and so demonstrating that it's in fact delaying its ack.
Ah, good idea. I added a trace from the receiver side. This trace is
definitely more convincing.
> > Any initial thoughts on whether this is a bug or a feature?
>
> It strikes me as clearly the wrong thing to do, as I don't see any
> advantage in delaying and a significant performance lose by doing so.
> I couldn't find anything in 793 or 1122 that indicates it's a spec
> violation, though.
Yeah, i think it's just yet another weird corner case for which the
older RFCs don't give much guidance.
> If you can make the receiver traces, then I'll see if I can find some
> cycles to write it up for the known-problems I-D.
Do you think it would be worth tweaking the congestion control I-D too? I
think phrases like "out-of-order data segments should be acknowledged
immediately, in order to trigger the fast retransmit algorithm" are
re-enforcing the traditional concern about immediate ACKs for data
segments _above_ holes. If any sort of consensus forms that data segments
that fall into holes are definitely "out-of-order" (a la the Solaris
interpretation), it might be good to insert a reminder here, too.
neal