how to aggregate multiple similar tcp flows?

[Carter Bullard]

Hey Chris,
Fix this in rc.41.  Thanks for the packet dump!!!!!  Basically a  
problem with retransmissions
that occur way out of the window.  Needed to account for winshift,  
and the possibility that
this was finally the segment we were waiting for (very large window).

ESP issue was really a fragmentation issue, and that is now fixed.

Carter


On Feb 28, 2007, at 0:50 AM, Christoph Badura wrote:

> Hey Carter,
>
> more weird output from the traces I took last week.
>
> These three flows report sloss of 0 although each had multiple  
> events where
> trains of typically 25 or 40 contingous packets were lost and  
> retransmitted
> on receipt of SACKs.
>
> Output from "racluster -n -s +sloss +dloss -r trace7s.argus":
>
> 14:28:26.545754    d        tcp      1.2.3.4.38615     ->         
> 4.3.2.1.22         7508     3841     11195264       262685    
> FIN          0 1
> loss pattern 39, 34, 25 packet trains
>
> 14:29:02.415526             tcp      1.2.3.4.38773     ->         
> 4.3.2.1.22         7470     3845     11185968       263585    
> FIN          0 0
> loss pattern 27, 39, 20, 16, 15 packet trains
>
> 14:29:34.221108             tcp      1.2.3.4.38778     ->         
> 4.3.2.1.22         7446     3828     11102864       261431    
> FIN          0 0
> loss pattern 40, 23 packet trains
>
> I would find it useful if I could distinguish these unusal losses  
> where a
> train of 20-40 kbyte worth of TCP segments is lost en-bloc from  
> more normal
> loss of single packets once in a while (possibly from loss because  
> of filling
> the pipe).
>
> I think I can liberate the raw traces for this and the ESP stuff I  
> posted
> about earlier if you want them for reqression testing.
>
> regards,
> --chris
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20070312/f62659a3/attachment.html>