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

"Vijay K. Gurbani" <vkg@bell-labs.com> Mon, 18 October 2010 14:28 UTC

Return-Path: <vkg@bell-labs.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 32E583A6C81 for <sip-clf@core3.amsl.com>; Mon, 18 Oct 2010 07:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.5
X-Spam-Level:
X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
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 Z36xDQzHqo37 for <sip-clf@core3.amsl.com>; Mon, 18 Oct 2010 07:28:48 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2DC643A6C43 for <sip-clf@ietf.org>; Mon, 18 Oct 2010 07:28:48 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o9IEUGbO026138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sip-clf@ietf.org>; Mon, 18 Oct 2010 09:30:16 -0500 (CDT)
Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o9IEUGTI023355 for <sip-clf@ietf.org>; Mon, 18 Oct 2010 09:30:16 -0500 (CDT)
Message-ID: <4CBC5A66.3090802@bell-labs.com>
Date: Mon, 18 Oct 2010 09:32:06 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7
MIME-Version: 1.0
To: sip-clf@ietf.org
References: <AANLkTimW+RNgTonsURmgALMHnCJ=GFMnL7T9kmPtPF2b@mail.gmail.com>
In-Reply-To: <AANLkTimW+RNgTonsURmgALMHnCJ=GFMnL7T9kmPtPF2b@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
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: Mon, 18 Oct 2010 14:28:50 -0000

On 10/17/2010 09: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.

Peter: Thanks for your initiative.  More inline.

> 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

OK.

> 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?

I am not sure I follow (but that is due to loosing context on the above;
I need to catch up on what we decided on the list.)  In any case, I note
that Gonzalo Salgueiro responded in the affirmative to this, so I will
defer to his recollection.  Although, given that TLS can ride on top
of UDP or TCP, we may want to think of a second letter added to "L" to
denote TLS-over-TCP and TLS-over-UDP (I doubt any implementations are
using TLS-over-UDP for signaling only, but given that SCTP is starting
to appear in kernels, maybe our flags ought to be "u, t, s, lu, lt, ls,
U, T, S, LU, LT, LS").

> 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.

Interesting ... is it possible to share your indexed-ASCII corpus to
see how these fields line up?  This may help determine an answer to your
next question:

> 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" ?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/