Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00

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:HKaplan@acmepacket.com] 
Sent: Wednesday, March 28, 2012 6:56 AM
To: Aamer Akhter (aakhter)
Cc: Hendrik Scholz; <ipfix@ietf.org>
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
p.s. why are your drafts in OPSAWG?

On Mar 28, 2012, at 12:56 AM, Aamer Akhter (aakhter) wrote:

> 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: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf

> Of Hadriel Kaplan
> Sent: Tuesday, March 27, 2012 5:41 PM
> To: Hendrik Scholz
> Cc: <ipfix@ietf.org>
> 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
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix