Re: Weird TCP SACK problem. in Linux...

[Oumer Teyeb <oumer@kom.aau.dk>]

Hi Alexy, Is there anything linux specific about the DSACK 
implementation that might lead to increase in the number of 
retransmissions, but leads to improvment in download time when 
timestamps are not used (and the reverse effect  when timestamps are 
used, less retransmissions but bigger download times)?  because I 
couldnt figure it out,....also is there anywhere where the reordering 
response of tcp linux described? (it seem dupthreshold is dynamically 
adjusted based on the reordering history... but I was not able to find 
out how...)...
 
Oumer Teyeb wrote:

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html