Oumer Teyeb wrote:
Hi,
Alexey Kuznetsov wrote:
Condition triggering start of fast retransmit is the same.
The behaviour while retransmit is different. FACKless code
behaves more like NewReno.
Ok, that is a good point!! Now at least I can convince myself the
CDFs for the first retransmissions showing that SACK leads to earlier
retransmissions than no SACK are not wrong....and I can even convince
myself that this is the real reason behind sack/fack's performance
degredation for the case of no timestamps,:-)... ...
Actually, then the increase in the number of retransmissions and the
increase in teh download time from no SACK - SACK for timestamp case
seems to make sense also...my reasoning is like this...if there is
timestamps, that means there is reordering detection...hence the number
retransmissions are reduced because we avoid the time spent in fast
recovery.... when we introduce SACK on top of timestamps, we enter fast
retransmits earlier than no SACK case as we seem to agree, and since the
timestamp reduces the number of retransmission once we are in fast
recovery, the retransmissions we see are basically the first few
retransmissions that made us enter the false fast retransmits, so we
have a little increase in the retransmissions and a little increase in
the download times... but when no timestamps are used, there is no
reordering detection and so SACK leads to less number of retransmissions
because it retransmits selectively, but it doesnt improve the download
time because it enters fast retransmit eralier than the no SACK and in
this case the fast retransmits are very costly because they are not
detected lead to window reduction.... am I making sense?:-).... still
the DSACK case is puzzling me....
Regards,
Oumer
-
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
