Subject: Re: [sip-clf] Defining Pros and Cons of ASCII/IPFIX

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Nov 2010 15:53:04 -0700

I'm sort of curios what do both means -  A proxy would write the logs twice in the two different formats? 

I suspect the pro/cons will show that these protocols are so close to the same that it would nuts to expend the energy do both. Perhaps  I will feel differently when I see the pro/cons. 

Here's the conversation I imagine having with the product marketing people that will decide if this gets prioritized high enough that we will actually implement it. Hey I need X people for Solution A and that will give customers the benefit of BLAH BLAH. Then I say, I also want on the Y people for Solution B and that will give customers the benefit of and repeat the same BLAH BLAH. At that point they will say, so if we did just one of these they would get all the benefit right? and I will say yes and that will be the end of it - they will either decide I am so stupid  to even propose this that they do neither or, if I am lucky,  they will pick one based on some complete misunderstanding. I'll get back we choose A because that solution better aligns with the RESTful architecture of cloud computing. 

On Oct 28, 2010, at 11:55 AM, Peter Musgrave wrote:

> Hi, 
> 
> How do people feel about including one/both as an issue in the pros/cons discussion and the effort to solicit wider input from implementors?
> 
> I think then if both gets continued support we can present that as input in Prague and see where it goes. 
> 
> If the pro/con idea has support then I can start the discussion with a summary of what's been said thus far...
> 
> Regards
> 
> Peter Musgrave
> (as co-chair)
> 
> On Thu, Oct 28, 2010 at 1:47 PM, Saverio Niccolini <[email-masked]> wrote:
> I am also in favor of specifying both, from a commercial perspective
> this makes a lot of sense to give people in different markets what
> they need.
> 
> Saverio
> 
> ============================================================
> Dr. Saverio Niccolini
> Manager, Real-Time Communications Group
> NEC Laboratories Europe, Network Research Division     
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.     +49 (0)6221 4342-118
> NEC*NET Phone: 800-49-33-118
> Fax:     +49 (0)6221 4342-155
> e-mail:  [email-masked]
> ============================================================
> NEC Europe Limited Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL Registered in England 2832014
> 
>  
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Hadriel Kaplan
> > Sent: 27 October 2010 19:28
> > To: Peter Musgrave
> > Cc: List SIP-CLF Mailing
> > Subject: Re: [sip-clf] Defining Pros and Cons of ASCII/IPFIX
> >
> >
> > At a recent conference I asked a SIP monitoring vendor which format
> > they thought we should specify, and surprisingly they said "do both".
> > I asked them why, and they said there was a market for both ascii and
> > binary formats - that monitoring systems would prefer binary ones, but
> > that humans prefer ascii style ones; and that in the Enterprise market
> > ascii was more dominant, while in the SP market binary was more
> > dominant.  They said we wouldn't be able to choose just one in the IETF
> > - because whichever we picked there'd still be a market for the other
> > and that market would continue the status-quo of proprietary formats or
> > settle on some de-facto one.
> >
> > In thinking about this more I think I agree with them.  It'd be like us
> > picking a Registrar database access protocol as well as the fields in
> > it - we could specify SQL or DIAMETER, but in some markets it'll be one
> > not the other no matter which one we choose. (or it'll be Active
> > Directory, etc.)
> >
> > -hadriel
> >
> > On Oct 27, 2010, at 11:23 AM, Peter Musgrave wrote:
> >
> > > Hi all,
> > >
> > > As co-chair I am looking for a way to make a determination about how
> > to meet the groups decision to move forward with just one format in a
> > WG which has good support for two formats.
> > >
> > > In my (personal) opinion I think the objective is to develop
> > something that will be widely implemented. I would like to solicit
> > input from a larger audience - but first I think we need to frame the
> > pros and cons.
> > >
> > > I would like to suggest the following:
> > >
> > > 1) Use the list and the Beijing meeting to come to a consensus on the
> > pros and cons of each and the applications which may favour one format
> > vs another.
> > >
> > > 2) Place these pros/cons on the WG Wiki [I can act as editor]
> > >
> > > 3) Solicit input from SIP Implementors - referring them to the WG
> > WIki
> > > - use the Columbia sip-implementors, sipforum list and SIPT27
> > >
> > > 4) Review the feedback and try to come to a conclusion on the list
> > (or failing that, in Prague at IETF80)
> > >
> > > I will be at SIPIT27 - so I can raise awareness of this discussion in
> > that community.
> > >
> > > How do people feel about this approach?
> > >
> > > I welcome any other/additional ways to resolve this issue.
> > >
> > > Regards,
> > >
> > > Peter Musgrave
> > > co-chair
> > >
> > >
> > >
> > > <ATT00001..c>
> >
> > _______________________________________________
> > sip-clf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sip-clf
> 
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 8 Nov 2010 07:15:50 +0800

I think that's a fair question. 

Can the advocates for both clarify? Do you mean:

1) vendor MUST implement A OR B
2) vendor MUST implement A, MAY do B
3) vendor MUST implement A AND B

Thanks, 

Peter Musgrave
(as co-chair)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Nov 2010 18:50:18 -0500

Actually, if we decide to do both (meaning define both in one or two RFC's), I think we should re-visit the ASCII format.  Because I'd argue it should be more like what Vijay originally proposed and get rid of the indexed stuff... because to me the whole value in an ascii format is for direct+easy readability and really simple grep-type searching.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Nov 2010 18:57:12 -0500

I don't think that's the same question.  His question was whether it would write the logs twice in two different formats.  I assume the answer to *that* question is vendor specific - i.e., if you support writing to both simultaneously, have at it... but we're not gonna mandate you do write the logs twice.

Of course the more interesting question is the one you asked. :)

Personally, I think we should just define two, separate RFCs: one for each format.  A vendor can support RFC XXXX, or YYYY, or both - just as for any RFC.

It's not the optimal outcome, but I don't think we'll converge on the optimal outcome... and even if we pick one, I bet the other will happen anyway as well, so we might as well specify both formats instead of leaving one to be vendor-specific.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Nov 2010 19:13:52 -0500

> Here's the conversation I imagine having with the product marketing people that will decide if this gets prioritized high enough that we will actually implement it. Hey I need X people for Solution…

Right, so this basically gets to the heart of it in my opinion.  And my guess is you'll actually end up doing both.  Why?  Because the ipfix one is Netflow v10, and Cisco likes Netflow - both the marketing people like it, and there are tools for it.  It's not as popular as Netflow v9 of course, but it'll get there eventually.  So think of it this way: Cisco makes routers and switches (or so I've heard ;) and those boxes export various Netflow versions today.  Don't you think your marketing people would want to position a "unified monitoring" approach whereby the Netflow records exported by the routers/switches can be collected and correlated to the ones from your Call Managers/Cube and such, to provide not only correlation of signaling flows but also media?  I think they would.  That looks really good in PowerPoint and Data Sheets. :)

But then they'd also want to log it in ascii format, for those customers that don't have Netflow tools or for simple lab testing type use.

This isn't much different than what vendors have to do for CDRs right now - afaict a lot of us record them in multiple formats, both binary like RADIUS or DIAMETER, as well as ascii like CSV format.  Different customers use different formats, and they have different pros/cons, but we're willing to implement multiple formats because we want to provide the info to everyone/anyone.  

I think the same thing will happen here - as a vendor, it's in your own interest to provide as many tools to troubleshoot and monitor SIP as you can, for as many customers as possible.

-hadriel

---

From: Dan Burnett <[email-masked]>
Date: Mon, 8 Nov 2010 18:51:57 +0800

+1.  Sometimes during standards work it is clear that either
1) all but perhaps a few folks/organizations agree on a particular approach, meaning that in the world of implementations the minority need to just join the party, or
2) most folks/organizations don't care at all and will just implement whatever the majority wants.

In our case neither is true.  As Hadriel points out we have two sizeable and vocal groups with different use cases and customer bases.  Each is likely to ignore the proposal that does not satisfy their constituents.  I suspect that if we had had two different groups - one to create a text standard and one to create a binary standard - that we would already today have both completed and widely adopted.  The only important requirement here is that any content in either format can be mapped to the other and back with no loss of information.  

-- dan

On Oct 28, 2010, at 1:28 AM, Hadriel Kaplan <[email-masked]> wrote:

> 
> At a recent conference I asked a SIP monitoring vendor which format they thought we should specify, and surprisingly they said "do both".  I asked them why, and they said there was a market for both ascii and binary formats - that monitoring systems would prefer binary ones, but that humans prefer ascii style ones; and that in the Enterprise market ascii was more dominant, while in the SP market binary was more dominant.  They said we wouldn't be able to choose just one in the IETF - because whichever we picked there'd still be a market for the other and that market would continue the status-quo of proprietary formats or settle on some de-facto one.
> 
> In thinking about this more I think I agree with them.  It'd be like us picking a Registrar database access protocol as well as the fields in it - we could specify SQL or DIAMETER, but in some markets it'll be one not the other no matter which one we choose. (or it'll be Active Directory, etc.)
> 
> -hadriel
> 
>> As co-chair I am looking for a way to make a determination about how to meet the groups decision to move forward with just one format in a WG which has good support for two formats. 
>> 
>> In my (personal) opinion I think the objective is to develop something that will be widely implemented. I would like to solicit input from a larger audience - but first I think we need to frame the pros and cons.
>> 
>> 1) Use the list and the Beijing meeting to come to a consensus on the pros and cons of each and the applications which may favour one format vs another. 
>> 
>> 3) Solicit input from SIP Implementors - referring them to the WG WIki
>> 4) Review the feedback and try to come to a conclusion on the list (or failing that, in Prague at IETF80)
>> 
>> I will be at SIPIT27 - so I can raise awareness of this discussion in that community. 
>>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Nov 2010 21:49:19 -0700

> I think the same thing will happen here - as a vendor, it's in your own interest to provide as many tools to troubleshoot and monitor SIP as you can, for as many customers as possible.

Right - I think that gets to the heart of it - you have the right analogy. We have to do both Radius (which can steam off box) and CSV (which writes to disk in simple and gets moved off box in batch form). Now my streaming logging is already going via syslog. And not all my products do Radius for CDR, and not all the billing system can import CVS style CDRs. It would be better for my customers if there was just one - it would be less development for everyone if there was just one. The only reasons to do two is if they both have some amazing characteristic that makes them better than the other - I'm happy to see the pro/cons and perhaps they will both have some huge pro that makes it worth doing both but I can't imagine what that is. 

For CVS and Radius, it was obvious why each would happen. CVS was trivial to implement while Radius is far from that. While on the other hand CVS provided no real interoperability and who knows what fields did what - Radius provided something that was well enough defined you could do something with it. As a streaming format, the IPFIX looks better than syslog for what we need to do but there is no way it will deprecate syslog. HTTP is better in every way possible than TFTP for loading firmware on phones yet it takes an unnatural acts to convince people to use HTTP for that - similarly the bulk of people will use syslog for streaming logging. So I know sip servers I have to deal with will be doing syslog, and I know they will be writing unstructured printf style logs to a local disk, the questions is how much more do I have to implement - I can see the advantage of having a interoperable structured format: both the indexed ascii and ipfix can be fixed to meet that need. I'm just not seeing any advantage to doing both. 

I'm not worried about the tools that read these logs being able to import either - that's easy because the systems that want the data will do what they need to get it.  I'm wondering what the systems that need to write the logs will implement. I'd love to hear from folks that are plan to build SIP servers that write whatever log files this WG will produce about the A, B, or Both issues. 

Cullen

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 02:52:27 -0500

On Nov 8, 2010, at 11:49 PM, Cullen Jennings wrote:

> For CVS and Radius, it was obvious why each would happen. CVS was trivial to implement while Radius is far from that. While on the other hand CVS provided no real interoperability and who knows what fields did what - Radius provided something that was well enough defined you could do something with it. As a streaming format, the IPFIX looks better than syslog for what we need to do but there is no way it will deprecate syslog. HTTP is better in every way possible than TFTP for loading firmware on phones yet it takes an unnatural acts to convince people to use HTTP for that - similarly the bulk of people will use syslog for streaming logging.

Right we all do syslog for exporting stuff (as well as a bunch of other means).  But unfortunately doing syslog is like saying we all do TCP.  The real data is not only proprietary in semantics, but proprietary in syntax too.  It's one big string.  

This isn't the same issue as HTTP vs. TFTP - in those choices the content being pulled is still by nature a blob. (and for some devices doing TFTP is better because it can be easily hardcoded in ROM/PROM, so I can understand why folks lean that way)

Look... it's not like I expect all SIP devices to suddenly switch to supporting SIPCLF, no matter what format we do.  Some folks just won't care.  Cisco, for example, may never care - it's Cisco, after all. (and by that I don't mean they're bad - I mean they're a big company and sell a whole "solution" and may not care about what other people do for this)  That's ok.  No one's forcing anyone to do format XYZ.  We're just offering a standardized syntax/semantics in case you want to interop with readers/collectors/whatever without asking them to do your proprietary format/info and waiting for them to change their code.

> So I know sip servers I have to deal with will be doing syslog, and I know they will be writing unstructured printf style logs to a local disk, the questions is how much more do I have to implement - I can see the advantage of having a interoperable structured format: both the indexed ascii and ipfix can be fixed to meet that need. I'm just not seeing any advantage to doing both. 

The proposal Peter suggested was to pick Ascii.  Are you ok with that?

> I'm not worried about the tools that read these logs being able to import either - that's easy because the systems that want the data will do what they need to get it.  

Then why bother with any standard format to begin with?  

You're not worried because you're Cisco, and frankly the brand name alone is sufficient to get tools to do whatever you do, without even asking.  My world is different.  I have to call monitoring vendors and get the "who's Acme Packet??", then send them docs on the formats we use, and hope they will implement support for it. :(

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Tue, 9 Nov 2010 08:18:13 +0800

I believe in de Toquville.  History repeats itself, and I see it repeating...

What will happen in SIPCLF is a repeat of H.248.

Since we cannot agree, we will agree to do both ASCII and binary (IPFIX).

Binary will be theoretically more efficient than ASCII.

Binary will be theoretically more useful for service providers.

ASCII, like the Internet, will work well enough for everyone.

Binary will die a quick death in the marketplace.

Personally, I am tired of arguing. Let us say we will do both, and the market will winnow things down to a single format.  I may be proved wrong, and that single format will be IPFIX.  Fine with me: so long as we end up with a single format, I will be happy.

That said, just ask Cullen: I have a strong track record on betting on IETF protocols.  I am willing to put USD 50 that within three years there will be one and only one format, and that format will be ASCII.  Any takers?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 09:13:15 -0500

But we're not asking for both - the point of today's meeting was to agree to pick ascii.  Some of us will also (separately) ask for a sipclf charter change or dispatch item to go do a real-time exporting mechanism for SIP message/flow information for monitoring.

-hadriel
p.s. btw, there *are* implementations of H.248 in binary - one's from a vendor right here in China.  
p.p.s. There is some delicious irony having SIP being a protocol easily read by humans and very hard to read by machines, while a logging format for troubleshooting SIP could be hard to read by humans but easily read by machines. :)

On Nov 8, 2010, at 7:18 PM, Eric Burger wrote:

> <smime.p7s><ATT00001..c>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Nov 2010 21:22:50 -0700

inline ..

> Right we all do syslog for exporting stuff (as well as a bunch of other means).  But unfortunately doing syslog is like saying we all do TCP.  The real data is not only proprietary in semantics, bu…

yah - agree and understand, but my point was we will still be doing syslog no matter what we do here

> The proposal Peter suggested was to pick Ascii.  Are you ok with that?

I'm fine with pick either but that was not the proposal. The proposal was effectively to pick both. 

> Then why bother with any standard format to begin with?  

Customers like it - it helps reduce vendor lock in among other reasons. 

> You're not worried

Oh, I'm worried. I got two solutions, both of which have Cisco authors on them, both will work, and no clear direction. That's a receipt for for all the bolts to have left hand thread and all the nuts to have right hand thread. 

> ecause you're Cisco, and frankly the brand name alone is sufficient to get tools to do whatever you do, without even asking.  My world is different.  I have to call monitoring vendors and get the "who's Acme Packet??", then send them docs on the formats we use, and hope they will implement support for it. :(

wow - the grass is greener on the other side. I'm always thinking, if only I was the SBC in the call flow this would be so easy to fix. And I have to call customers and get the "What's an SBC? Oh, you mean an Acme box".

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 10 Nov 2010 00:55:43 -0500

When Peter first proposed it I was basically thinking the same thing.  In a way, that's true in that if we go define IANA numbers for putting the field in IPFIX, then obviously one could then write the IPFIX message with such fields into a file.  But that'll be true no matter what we do, unless you're suggesting no protocol ever be allowed to encode the fields.  For example someone might submit an I-D to create IANA-defined DIAMETER AVPs for these fields; and someone may submit an I-D someday to write DIAMETER messages to a file.  How can we prevent that?  Why should we?

Having said all that, the more I'm thinking about it the more I'm thinking it's not _really_ "doing both".  Because I think Eric's right.  Those of us that need an exporting mechanism will do IPFIX, if there's some advantage to doing that for exporting such stuff.  I personally think there is, but that's really a separate topic.  But for literal local *file* format, I have no doubt Eric is right and ascii will dominate.  It's trivial to implement, and easy to read. (or will be if we get rid of the indexes)

So when you go to the Cisco marketing folks, you can tell them to use the single, ascii format we publish an RFC for. (whatever format that will be)

-hadriel