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

From: Peter Musgrave <[email-masked]>
Date: Sun, 17 Oct 2010 10:54:30 -0400

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

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?

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.

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

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)

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sun, 17 Oct 2010 13:17:49 -0400

Peter - 

Thanks for your efforts on implementing these different encodings.

Some comments Inline...

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

> 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):

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. 
> 
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Oct 2010 09:32:06 -0500

> Before I start to measure and summarize I want to make sure I have

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/

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 20 Oct 2010 07:00:27 -0400

Hi Vijay,

I will log a simple example (INV, OK, ACK, BYE, OK) through a B2BUA and then
provide that as an example in indexed ascii/IPFIX. I can also include the
'large' data set I ran through.

I'm not keen to add it to the mailing list as an attachment - so I'll set up
something on the WG WIki page. I'll include the Java source for those who
are interested.

Should be be up by the end of the week.

Regards,

Peter Musgrave
(as individual)