On 03/03/2014 07:22 PM, John Heffner wrote:
Running with such a large window scale and no timestamps (PAWS protection) is generally not a great idea, but I don't think is part of the issue here. If you look where things really go wrong, the receiver is sending anomalous SACK blocks that will trigger the SACK renege handling path. Reneging triggers go-back-n behavior, so we see the spurious retransmits from there on.
What triggers go-back-n when SACK is not in use? I ask because at least once I have seen the same sort of thing without SACK enabled on the connection. The total quantity of retransmissions is roughly the same, but spread-out - looks like cwnd shrinks considerably and re-grows in the no-SACK case. Not sure I still have that trace though :(
rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html