HellO! > IsLost (SeqNum): > This routine returns whether the given sequence number is > considered to be lost. The routine returns true when either > DupThresh discontiguous SACKed sequences have arrived above > 'SeqNum' or (DupThresh * SMSS) bytes with sequence numbers greater > than 'SeqNum' have been SACKed. Otherwise, the routine returns > false.
It is not used. The metric is just distance between snd.una and the most forward sack. It can be changed, but, to be honest, counting "discontiguous SACked sequences" looks really weird and totally unjustified. You can look for function tcp_time_to_recover() and replace tcp_fackets_out(tp) > tp->reordering with something like tp->sacked_out+1 > tp->reordering. It is not so weird as rfc recommends, but it should make some difference. > so you are saying, it doesnt matter whether I disable FACK or not, it is > basically set by default? Condition triggering start of fast retransmit is the same. The behaviour while retransmit is different. FACKless code behaves more like NewReno. > and it is disabled only when reordering is detected (and this is done > either through timestamps or DSACK, right?)... > so if neither DSACK and timestamps are enabled we are unable to detect > disorder, so basically there should be no difference between SACK and > FACK, cause it is always FACK used... and that seems to make sense from > the results I have Yes. But FACKless tcp still retransmits less aggressively. > the # of retransmissions increases as shown in the second figure? isnt > that odd? shouldnt it be the other way around? The most odd is that I see no correlation between #of retransmits and download time in you graphs. Actually, the correlation is negative. :-) > Also why does the # retransmissions in the timestamp case increases when > we use SACK/FACK as compared with no SACK case? Excessive retransmissions still happen. Undoing just restores cwnd and tries to increase reordering metric to avoid false retransmits. > This one , I dont think I understood you. Could you please make it a bit > more clearer? 1. Suppose, some segments, but not all, were delayed. 2. Senders sees dupack with a SACK. It is the first, SACK allows to open window for one segment, you send one segment with snd.nxt. 3. Receivers receives it before delayed segments arrived. 4. When senders sees this SACK, it assumes that all the delayed segments are lost. > OK ...but if timestamps are enabled, then I just couldnt figure out the > use of DSACK, can it tell us something more than we can find using > timestamps?? It depends. Normally, no. If the network is fast, timestamps are just too coarse to detect redundant retransmissions. Plus, the heuristcs based on timestamps essentially relies on a bug in our timestamps processing code. Another side could have it fixed. :-) Alexey - 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
