Closing out Argus-2.0.0 feature set.

[Peter Van Epp]

> Gentle people,
>    In preparation for a late October/early November
> release, I'd like to freeze the code for argus-2.0.0
> at the end of this week for new features.
> 
>    Bug fixes will go on until the end of time, but
> new features can stop.  New client code as well as
> mods to existing client code can be considered until
> towards the end of the month, as it can be released
> as contrib code rather than core client code if it
> comes in in the last week of October.
> 
>    I've decided to put user data capture into the
> next release, as we will not have sufficient time
> to get any clients for the feature.
> 
>    This leaves RTP protocol support and multicast
> protocol support to be done this week.   
> 
>    I suspect that the true release date will be
> the end of November, but I'm going for early Nov
> if at all possible.
> 
>    Comment/opinion/reaction/attitude is always
> welcome, so please do!
> 
> Carter
> 
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 17A
> New York, New York  10022
> 
> carter at qosient.com
> Phone +1 212 813-9426
> Fax   +1 212 813-9426
> 

	One thing I've thought of but don't think we have discussed is decode
of 803.1p an 1q tagged frames for vlans and QOS. We are using the 1p VLANs
internally and probably will be using them to replace the current MPOA over
ATM link on our link to the net. Is such support already there (I'd expect it
needs to be for QOS support in future). We are talking about a wireless IP 
phone pilot that will probably need 1Q as well.
	As well from a testing standpoint I managed to get tcpreplay modified
to do full duplex (even if performance sucked probably because I used the 
same file for both sides) on Friday. I figure on taking a page from the RISC
CPU guys book and tossing the timing issue back to a preprocessor which will
have to reorder the input tcpdump file to make sure that responses don't 
get on the wire ahead of requests (by padding with none flow related packets 
much like instruction reordering in a RISC CPU) when playing back at full speed
rather than try and do that inside tcpreplay. I still need to get time sync 
between the two files right (time 0 needs to start at the earliest time stamp 
in the two files) but that is a lot easier (since it is only once at startup)
than trying to figure out interpacket timeing as the files unroll. The upshot
of that is I have at least the tools for full duplex testing (but I think time
is going to get sucked down performance testing on hardware for the next little
while). 
	From bonnie disk I/O benchmarks (confirmed mostly by iozone although 
I didn't have time to complete that) I ran on Friday it currently appears that 
IDE disks are twice as fast (~20 megabyte per second) than SCSI (~11 megs). 
But I have the loan of some 10,000 RPM 36 gig SCSI drives and I'll see what 
that does.  I think Carter may be correct that the GX vs BX chipset on the 
motherboard is the secret, but I won't know until I borrow an Adaptec 2940 
SCSI controller to move between the machines hopefully next week.  Then there
are raid controllers ...  I also understand from the Beowolf community that 
there is a Supremicro mother board with a non Intel glue chipset that kicks 
both the GX and BX's ass. I'll have to see about borrowing or buying one of 
those too.
	Then there is a request from linux.sccurity.com about whether I'd like
to write them an article on why argus is a wonderful idea after someone in 
comp.unix.security asked about experiences with argus.
	So many questions so little time :-). 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada