Subject: [IPFIX] initial draft for RTP message transport in IPFIX

From: Hendrik Scholz <[email-masked]>
Date: Mon, 26 Mar 2012 10:46:44 +0200

Hi!

Some time ago I submitted an initial draft describing the transport
of RTP media stream (quality) information in IPFIX packets.

The announcement is here:
http://www.ietf.org/mail-archive/web/i-d-announce/current/msg42805.html
and the draft is named draft-scholz-ipfix-rtp-msg-00

I believe this is part of a larger set of documents, namely the
draft-trammell-ipfix-sip-msg draft and a third yet to be written 
correlation draft to map between SIP packets/sessions in IPFIX and the 
RTP media streams as described by the -rtp-msg draft.

I would like to get your feedback on the content, esp on the
transport of the media quality.
draft-wu-xrblock-rtcp-xr-quality-monitoring-08 has a mechanism
to convey the type of MOS, the calculation algorithm and the actual
values.
Should we use the same mechanism?

There is a list of open TODOs in section 12 of the document.

Cheers,
  Hendrik

-- 
Hendrik Scholz <[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Mar 2012 20:29:45 +0000

Howdy,
I read draft-scholz-ipfix-rtp-msg-00 and have some initial comments, mostly at a high level for now instead of per-IE.

1) From a IPFIX IANA allocation perspective, it makes sense to get IANA-assigned IE numbers for things that could be exported from different vendors, instead of using PENs.  Quite a few of the IEs in this draft are fairly vendor-specific, however.  I mean in the sense that few media-monitoring vendors report the same type of information as in this draft.  I think there is some commonality across vendors, but it's a smaller list.  How do you want to handle that?  Do we get in a room and agree on a common list?

2) Some of the IEs in here imply the IPFIX records could be generated per-RTP packet.  I don't think you want to do that.  Some media-monitoring systems handle multiple millions of RTP packets per second. 

3) Some of the IEs imply there's a single SSRC for a flow - are you assuming a flow is by definition the 6-tuple of IP src/dest, port src/dest, transport type, and SSRC?  In other words, if there are two or more SSRCs in the same 5-tuple, would they be separate IPFIX flows? (they're only one "RTP" session from an RTP and SDP perspective)

-hadriel

---

From: Hendrik Scholz <[email-masked]>
Date: Tue, 27 Mar 2012 13:33:11 +0200

Hi Hadriel,

> 1) From a IPFIX IANA allocation perspective, it makes sense to get IANA-assigned IE numbers for things that could be exported from different vendors, instead of using PENs.  Quite a few of the IEs…

I'd be happy to separate the information elements into the ones that
are relevant to (or can be generated by) a larger audience and the more 
specific ones. Brian also mentioned something in this direction.

> 2) Some of the IEs in here imply the IPFIX records could be generated per-RTP packet.  I don't think you want to do that.  Some media-monitoring systems handle multiple millions of RTP packets per…

Per-RTP packet record generation is not intended but it must be
possible to generate flow records for sections (e.g. 10 seconds)
of an RTP stream. In case of transient problems a higher
granularity will show isolated issues (e.g. a short period
of packet loss).
The records should allow mediators (or collectors) to aggregate
data from multiple records into a longer RTP stream.
So as a worst-case an IPFIX recording describing a single RTP
packet is possible but should not be the default.
The same mechanism should also apply to the -sip-msg records.
It should be possible to describe the outline of a session
as well as push a single SIP message for troubleshooting applications.

> 3) Some of the IEs imply there's a single SSRC for a flow - are you assuming a flow is by definition the 6-tuple of IP src/dest, port src/dest, transport type, and SSRC?  In other words, if there a…

Yes, a separate SSRC in between two nodes should be recorded
in separate records. After all these streams would most likely
belong to separate calls.

Also note that draft-akhter-opsawg-perfmon-ipfix-02 is available
and I duplicated some of the work done by Aamer.

Cheers,
  Hendrik

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email [email-masked]   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Mar 2012 21:40:58 +0000

> belong to separate calls.

As much as I'd love for that to be the case, technically they might or might not.  For normal voice between two users it's always the case.  But RFC 3550 always supported separate SSRCs in the same RTP session and thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have both been talking about using that ability. (so for example video from multiple cameras goes in the same RTP session, with separate SSRCs)  At least that's what I believe they're thinking of.  And of course even for a normal voice call there could be an SSRC collision, changing the SSRC mid-call.

I'm ok with assuming one, just wondering what we do if we get a second one.  I think you're saying we should treat is as a separate flow from an IPFIX reporting perspective, right?

-hadriel

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Tue, 27 Mar 2012 17:56:52 -0500

Hadriel,

Multiple SSRC within the 5-tuple is how the CTS product line encodes
multiple audio/video channels. Other implementations eg. T3 series use
different 5-tuples. 

(5-tuple = ipsrc, ipdst, iprotocol, l4ports)

" we should treat is as a separate flow from an IPFIX reporting
perspective, right?"

this is exactly what is done in the implementation of:

	draft-akhter-opsawg-perfmon-ipfix
	draft-akhter-opsawg-perfmon-method

In fact, the key fields for the default RTP template (IOS configuration
follows):

    match ipv4 protocol
    match ipv4 source address
    match ipv4 destination address
    match transport source-port
    match transport destination-port
    match transport rtp ssrc

and the collect fields are:

    collect routing forwarding-status
    collect ipv4 dscp
    collect ipv4 ttl
    collect transport packets expected counter
    collect transport packets lost counter
    collect transport packets lost rate
    collect transport event packet-loss counter
    collect transport rtp jitter mean
    collect transport rtp jitter minimum
    collect transport rtp jitter maximum
    collect interface input
    collect interface output
    collect counter bytes
    collect counter packets
    collect counter bytes rate
    collect counter packets dropped
    collect timestamp interval
    collect application media bytes counter
    collect application media bytes rate
    collect application media packets counter
    collect application media packets rate
    collect application media event
    collect monitor event

If the 'rtp ssrc' is not set as a key field, the various metrics form
the differing SSRC flows are aggregated to how a IPFIX 'flow' is
defined.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Tuesday, March 27, 2012 5:41 PM
To: Hendrik Scholz
Cc: <[email-masked]>
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00

On Mar 27, 2012, at 1:33 PM, Hendrik Scholz wrote:

>> 3) Some of the IEs imply there's a single SSRC for a flow - are you 
>> assuming a flow is by definition the 6-tuple of IP src/dest, port 
>> src/dest, transport type, and SSRC?  In other words, if there are two

>> or more SSRCs in the same 5-tuple, would they be separate IPFIX 
>> flows? (they're only one "RTP" session from an RTP and SDP 
>> perspective)
> 
> Yes, a separate SSRC in between two nodes should be recorded in 
> separate records. After all these streams would most likely belong to 
> separate calls.

As much as I'd love for that to be the case, technically they might or
might not.  For normal voice between two users it's always the case.
But RFC 3550 always supported separate SSRCs in the same RTP session and
thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have both
been talking about using that ability. (so for example video from
multiple cameras goes in the same RTP session, with separate SSRCs)  At
least that's what I believe they're thinking of.  And of course even for
a normal voice call there could be an SSRC collision, changing the SSRC
mid-call.

I'm ok with assuming one, just wondering what we do if we get a second
one.  I think you're saying we should treat is as a separate flow from
an IPFIX reporting perspective, right?

-hadriel

_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Mar 2012 10:56:01 +0000

Makes sense to me.

OK, so as I said in another email, the tricky part about this will be coming up with a consistent set of metrics across vendors, because if it's just one vendor's implementation model then it really shouldn't get an IANA-allocated IE number, should it?  It's effectively proprietary and that's what PENs are for, no?  Otherwise we'll be allocating hundreds of IANA-numberspace IEs, different ones for each vendor (my company alone has around few dozen different reported fields for RTP/RTCP).

-hadriel
p.s. why are your drafts in OPSAWG?

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Wed, 28 Mar 2012 06:09:27 -0500

Hi Hadriel,

I completely agree, the cross-vendor comparison is one of the main
reasons we want to standardize the methodology not just the IEs and why
there are 2 drafts-- one for each. It is not as simple as, just do (in
the case of RTP) what RFC3550 says. :-)

Some history re OPSAWG: 

	There was actually a IPFIX version a really long time ago:
		http://tools.ietf.org/html/draft-akhter-ipfix-perfmon-01
(IE and methodology was in one doc)

	Based on the feedback from the IPFIX WG itself in one of the
meetings the IE allocation and the methodology were separated and moved
to another WG. 

	I'll paraphrase the discussion as: "IPFIX WG really only does
IPFIX structure and IE allocation, so come back when the methodology is
sorted out"

	I've been searching for a home ever since. The latest I heard
today is that it should be IPPM as they will now take passive
measurements. 

Regards,
aa

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 6:56 AM
To: Aamer Akhter (aakhter)
Cc: Hendrik Scholz; <[email-masked]>
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00

Makes sense to me.

OK, so as I said in another email, the tricky part about this will be
coming up with a consistent set of metrics across vendors, because if
it's just one vendor's implementation model then it really shouldn't get
an IANA-allocated IE number, should it?  It's effectively proprietary
and that's what PENs are for, no?  Otherwise we'll be allocating
hundreds of IANA-numberspace IEs, different ones for each vendor (my
company alone has around few dozen different reported fields for
RTP/RTCP).

-hadriel

> But RFC 3550 always supported separate SSRCs in the same RTP session 
> and thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have 
> both been talking about using that ability. (so for example video from

> multiple cameras goes in the same RTP session, with separate SSRCs)  
> At least that's what I believe they're thinking of.  And of course 
> even for a normal voice call there could be an SSRC collision, 
> changing the SSRC mid-call.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Mar 2012 00:53:16 +0000

On Mar 28, 2012, at 1:09 PM, Aamer Akhter (aakhter) wrote:

I think the WG may want to reconsider that.  It creates two documents which overlap significantly, except the IANA allocation one is less text with fewer explicit details, while the methodology has the details.  So an implementor would basically need to read both docs anyway, and creating two documents to shepherd/publish is just extra overhead for the submitter, IESG and RFC editor.  What's the real benefit?

This is the diff of the files:
http://tools.ietf.org/rfcdiff?url1=draft-akhter-opsawg-perfmon-method-02.txt;url2=draft-akhter-opsawg-perfmon-ipfix-02.txt <http://tools.ietf.org/rfcdiff?url1=draft-akhter-opsawg-perfmon-method-02.txt;url2=draft-akhter-opsawg-perfmon-ipfix-02.txt>

Seems kinda silly, no?
Just my 2 cents, looking at it from the outside.

-hadriel

---

From: Paul Aitken <[email-masked]>
Date: Thu, 29 Mar 2012 13:25:42 +0100

Aamer, Hadriel,

FYI, draft-ietf-ipfix-ie-doctors-02 says everything should be in one doc:

    Optionally, a Working Group or individual contributor may choose to
    publish an RFC detailing the new IPFIX application.  Such an RFC
    should contain discussion of the new application, the Information
    Element definitions as in Section 4, as well as suggested Templates
    and examples of the use of those Templates within the new application

P.

On 29/03/12 01:53, Hadriel Kaplan wrote:
> I think the WG may want to reconsider that.  It creates two documents 
> which overlap significantly, except the IANA allocation one is less 
> text with fewer explicit details, while the methodology has the 
> details.  So an implementor would basically need to read both docs 
> anyway, and creating two documents to shepherd/publish is just extra 
> overhead for the submitter, IESG and RFC editor.  What's the real benefit?
>
> http://tools.ietf.org/rfcdiff?url1=draft-akhter-opsawg-perfmon-method-02.txt;url2=draft-akhter-opsawg-perfmon-ipfix-02.txt 
> <http://tools.ietf.org/rfcdiff?url1=draft-akhter-opsawg-perfmon-method-02.txt;url2=draft-akhter-opsawg-perfmon-ipfix-02.txt>
>
> Seems kinda silly, no?