Working Group chairs:
Spencer Dawkins: spencer@wonderhamster.org
Theo Zourzouvillys: theo@crazygreek.co.uk
Scribe: John Elwell: john.elwell@siemens-enterprise.com
Spencer and Theo welcomed our new OPS area technical advisor, Chris Lonvick (clonvick@cisco.com), replacing David Harrington, who has moved onto the IESG.
Spencer announced that he would be stepping down as co-chair, as he moves onto the IAB.
http://tools.ietf.org/html/draft-ietf-sipclf-problem-statement-01.txt
This is a major revision from the previous version. How many have read the new version? About 7 hands went up – there are probably more, because some people who have been very involved, like Hadriel Kaplan, came in after the chairs asked the question.
Vijay’s back-of-the-envelope calculation for 1000 calls/sec is about 45 Mbit/sec of generated information. Adam Roach asked that this analysis be expanded to include IPv6 if it remains in the document – Cullen pointed out that this would generate more information, but we noted that to/from sizes and transaction ID sizes are larger than what we’re seeing in the field, so this seems like a reasonable approximation for planning purposes, and Brian Rosen asserted that this is manageable for edge devices.
Would retransmitted requests also be logged (are they duplicates)? They would be logged, because the timestamp would change (so, not duplicates).
Chris asked about a threat model – although (as Robert Sparks noted) moving log entries across the wire is out of scope, Chris thinks there are still threats that are in scope if you store on disk – for example, can anyone access the records? Chris thinks we need text to describe this, and Vijay thinks there’s text in the draft to cover it.
Benoit asked if SIPCLF is only limited to SIP, or will at some time would we correlate with media message flows? This could be attempted even if the data remains on a single node, but isn’t covered by the problem statement at present.
Henning pointed out that there are two conditions for this – you need to capture the SDP, and proxy needs access to media stream, which for a simple proxy is not the case. So we would need to extend data capture considerably. Would need to do a different type of logging, a log of accepted media transactions.
Dale Worley: Might want to consider extension for SDP, as test case for extensibility.
We noted that capturing SDP would (roughly) double the data rate, and capturing media logs = “sky’s the limit”.
Dale also said that SIP diagnosis is usually more about signaling problems than media problems. Need detailed logging at SIP level, but it’s OK that we don’t have media for now.
Cullen said that signaling problems are more common than media problems, but when we do have problems with media, that’s much harder to debug than anything with signaling. We thought (back in circa 2000) that we’d be doing out-of-band management but that’s not where we ended up. Most people will be logging media information if it is a media device.
Hadriel repeated Robert’s question – “how do these calculations help me?”
Vijay: Are we sending it to disk, are we doing syslog or ipfix? Volume question is going to come up no matter what we do with the logged information…
Hadriel: Is opinion that one of the options is better than another?
Vijay: I can see the advantages of IPFIX, but don’t understand what using IPFIX does for my implementation. Also, IPFIX doesn't seem to be well known by implementers.
Hadriel: Don’t call it IPFIX – call it NETFLOW. People know what that is. The volume we’re talking about is only a fraction of that for CDRs, and we do CDRs off-box every day. We send 170 fields, and we’re not one of the largest formats. For some, writing to disk might be more of a problem than transmitting elsewhere. Also writing to disk consumes more time than formatting.
Chris agreed that writing to disk is the big part. Would like to see whether you really want to put on disk or just update counters – IPFIX doesn’t usually go to disk per-message.
http://tools.ietf.org/id/draft-niccolini-sipclf-ipfix-00.txt
Benoit Claise presented the draft, “not as a partisan, but as an educator”.
Spencer asked who read the draft? About 6 hands went up
The IETF did “NETFLOW version 10” – that’s IPFIX.
Spencer: Our charter is for logging on a single node now, but (speaking as an individual), I think we should try to avoid doing anything based on our charter that would prevent us doing things that we’ll need to do in the future.
Richard Graveman: IPFIX may be the best solution. I am more convinced now than earlier. What are the alternatives? Could say a lot of the same words for other formats. Do we need a tabular comparison?
Benoit: 3 alternatives: define a new format, use SYSLOG, use IPFIX.
Richard: Don't think define our own format is a good idea.
Benoit: I can't speak for syslog.
Spencer: Our DISPATCH session in
The OPS/Management Area is trying to keep mechanisms to a minimum – they’re suggesting IPFIX and SYSLOG for reporting.
Hadriel didn't think syslog was even on table. Our choices are ipfix or indexed-ascii.
Chair: Most discussion since
Cullen: Data modelling language is a very important consideration, but looking at what we need and extensibility model, SIP is so ossified that we could never extend it. OK, you could add new headers and new bodies, but to change SIP message in a way outside that! It’s clear to all of us that IPFIX and 10 other things that could work.
Robert: This group was chartered to start talking about content of log records, and has not done this very well. Need that conversation to start. Needs to move beyond motherhood and apple pie, and spend highly focused time talking about what the content is.
Spencer: Problem statement draft takes us in this direction – we’ve got proposed fields, and that’s something we can use as a basis for discussion.
Henning: Cultural distinction - those coming from web server environment, and those coming from the measurement / debug community. Latter more comfortable with open source and tools to play with. Different people have comfort with different things. Given these cultural differences, lower end devices will choose something looking more like an ASCII log, and higher level applications would use something like IPFIX. So we might end up with two things.
Benoit: I understand. We use SYSLOG but messages got messy with multiple NATs – so we moved to IPFIX, which could accommodate that.
Spencer: Are some of the predefined fields in IPFIX binary or ascii?
Benoit: Binary.
Henning: Summary, will see two types of format. So argument we are having is moot. If there is an RFC for text file format and if there is an RFC for ipfix file format, will implement both.
Spencer: Our charter explicitly allows us to do both.
Benoit: And for any sort of filtering, need some structure.
Vijay: Apache uses two formats. Concerning Robert's comment, these headers have been laid down since original draft. My idea of correlation was with fork trees. Another idea of correlation arises when call is between domains. Present elements cover both.
Hadriel: Agree with Henning. Two different worlds of requirements / use cases. Can we decide something this week?
Brian: If we need to do both, let's accept that. The important thing is the data, not the presentation.
Eric:
Chair: Hum for being in favor of just one format.
Someone: We haven't had the comparison.
Henning: Are there are particular issues?
Someone: There was a previous discussion that not everyone understood SYSLOG and IPFIX
.
Cullen: We have two proposals now, one is IPFIX-based, and the other is a new indexed ascii format.
Vijay: Indexed format has changed, to make it easy to skip things.
Chair: Does anyone feel they don't yet have enough information to take hums? Nobody expressed this concern.
Chair: Please hum for one format only or for two options? Strong consensus in the room for working on both options.
Spencer: We don't have a draft on framework yet. I’m presenting 'modest proposal' from slides.
Mary Barnes: I like the “modest proposal”, but you need to progress work on session-ID in DISPATCH – there was a lot of discussion on session-ID, but this has been quiet recently, and DISPATCH is on a short timeline, too (based on DISPATCH timelines for topics before IETF 78 (which will align with deadlines for IETF 78 BoFs, which are very soon).
Vijay: I am lost - do we need to spin off more work in DISPATCH concerning management framework?
Robert: That would be outside charter - would have to go to DISPATCH.
Hadriel: We brought up session-ID before, and not a lot of interest in DISPATCH at that time, but timing might have been bad.
Spencer: I have been too distracted to support the DISPATCH discussion on session-ID – my apologies.
Robert: Mary will send note to list on where solving other problems can go. Let's get back to what this WG can do - last two points on slide. Pull up RFC SIP torture test RFC, which pushes the edge cases of SIP message formats. Take the well-formed messages that appear there and render concrete records, send to mailing list tomorrow. We may learn from this.
Spencer: Great idea. In
Spencer: presented slide on work plan for IETF#78. Who is going to be contributed to getting the problem statement out by April? Only Vijay raised his hand.
Robert: Do we have volunteers for putting out example records to mailing list? By April 15? Hadriel, Vijay, Adam.
Robert: So this WG is a pilot experiment of groups coming out of DISPATCH. Within DISPATCH we had a kernel of energy. My interpretation of AD so far is that it has fallen on its face. If doesn't show signs of life soon, I will pronounce it dead.
Spencer: Is April a reasonable timeline for picking a format, and is June for completing it?
Vijay: More comfortable with May for picking a format.
Spencer: Are these dates for file format comfortable?
Robert: I don't see anything happening - people waiting to see what happens with initial actions. Let's at least update charter dates to these at least.