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