Re: [sip-clf] draft-salgueiro-sipclf-indexed-ascii /draft-niccolini-sipclf-ipfix Tuning for Implementation

Gonzalo Salgueiro <gsalguei@cisco.com> Sun, 17 October 2010 17:16 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE6C3A6BA1 for <sip-clf@core3.amsl.com>; Sun, 17 Oct 2010 10:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.009
X-Spam-Level:
X-Spam-Status: No, score=-10.009 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlnYaIVFbfo6 for <sip-clf@core3.amsl.com>; Sun, 17 Oct 2010 10:16:26 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id EF20B3A6A93 for <sip-clf@ietf.org>; Sun, 17 Oct 2010 10:16:24 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9HHHpbV004649; Sun, 17 Oct 2010 13:17:51 -0400 (EDT)
Received: from rtp-gsalguei-8714.cisco.com (rtp-gsalguei-8714.cisco.com [10.116.61.53]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9HHHoW5019637; Sun, 17 Oct 2010 13:17:50 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <AANLkTimW+RNgTonsURmgALMHnCJ=GFMnL7T9kmPtPF2b@mail.gmail.com>
Date: Sun, 17 Oct 2010 13:17:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <564FC90B-0879-4B24-8AF9-C53DDEF82E02@cisco.com>
References: <AANLkTimW+RNgTonsURmgALMHnCJ=GFMnL7T9kmPtPF2b@mail.gmail.com>
To: Peter Musgrave <peter.musgrave@magorcorp.com>
X-Mailer: Apple Mail (2.1081)
Cc: List SIP-CLF Mailing <sip-clf@ietf.org>
Subject: Re: [sip-clf] draft-salgueiro-sipclf-indexed-ascii /draft-niccolini-sipclf-ipfix Tuning for Implementation
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Oct 2010 17:16:41 -0000

Peter - 

Thanks for your efforts on implementing these different encodings.

Some comments Inline...

On Oct 17, 2010, at 10:54 AM, Peter Musgrave wrote:

> Hi all, 
> 
> I have running ipfix and indexed ascii logging for 1000's of messages. 
> 
> Before I start to measure and summarize I want to make sure I have tuned each properly. 
> 
> ASCII
> =====
> 
> I have made some assumptions about indexed ASCII (and I may have exceeded the groups intent here):
> - the length fields will be dropped. Pointers only
> - src/dest do not have protocol 
> - to/from and to_tag/from_tag
> 

No issues with any of these previously discussed changes.

> I would suggest we re-add protocol in the sent/received flags field. How about u, t, l for received udp, tcp, tls and U, T, L for sent?

Moving it from src/dst field to the flags field seems a logical choice since we only need one protocol value for the whole message. We can implement a separate flag for protocol or we can combine it with the send/receive flag as you mention. I'm open to either.

> 
> In looking at the output I think it would aid manual examination to put the response code immediately after the CSeq. This makes it very easy to see which lines are requests responses (especially for those who crush out the pointer line and want the more "apache-like" view of the info. 

Moving the response code after the CSeq makes good sense to me.

> 
> It might be worth discussing whether a user which nukes every pointer line can still make sense enough of the activity...I think they might need a few of the fields in the Flags. Could this be moved to the next "line" ?

We have the benefit of flexibility to move fields as desired. Let's get group consensus on whether we need to move the entire flags field or simply individual flag(s) from the pointer line.

Regards,

Gonzalo


> 
> IPFIX
> =====
> 
> The recommended templates provided have IPv4 addresses. I'll assume this is ok for comparison purposes (as my sample logs are all IP4). 
> 
> I will double-check my output against Hadriel's wireshark plugin. He did find that I can't count bytes - but I think I have corrected the output. 
> 
> Are there any other changes I should include?
> 
> Cheers, 
> 
> Peter Musgrave
> (as individual)
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf