RE: [AVT] Session and entity handling in draft-ietf-avt-mib-rtp-bis-00

["Alan Clark" <[e-mail]>]

This first pass at the updated RTP MIB was basically a synchronization with
the RTCP XR MIB and a general update to the SNMP definitions/ syntax to
align with current practice.  I did not attempt (yet) to work through the
logic in the manner that Magnus has started to do however I'm pleased that
he has got the ball rolling.  I'll be at VON this week but will collate any
comments sent to the list and should have time to review/ respond at the
weekend.  I will be at the Dallas meeting all day on Tuesday and would
welcome a discussion/ editing session after the AVT meeting if anyone is
interested.

Regards

Alan


 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
> Sent: Monday, March 13, 2006 12:28 PM
> To: Magnus Westerlund; Alan Clark; Amy Pendleton; IETF AVT WG
> Subject: RE: [AVT] Session and entity handling in 
> draft-ietf-avt-mib-rtp-bis-00
> 
> I was planning to jump deep into this before Dallas. However, 
> Magnus raises a fundamental issue, and I do have a question 
> before taking the jump-dive. This work is supposed to be an 
> update to RFC 2959, and synchronize it to RFC 3550. To what 
> extent the fundamental issues raised by Magnus apply to the 
> original design of RFC 2959, or do they belong only to 
> changes in RTP? 
> 
> BTW, a log of changes relative baselined to changes relative 
> to RFC 2959, and continued with each further version would be 
> useful for such discussions. 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:[e-mail]]
> > Sent: Monday, March 13, 2006 6:50 PM
> > To: Alan Clark; Amy Pendleton; IETF AVT WG
> > Subject: [AVT] Session and entity handling in 
> > draft-ietf-avt-mib-rtp-bis-00
> > 
> > Hi,
> > 
> > I have looked at the RTP MIB draft and do have some 
> comments on it. I 
> > will dedicate this email for a fundamental issue.
> > This will be a long mail as I think we need to review some 
> information 
> > before diving into the discussion.
> > 
> > We need to look at the roles entities have in the 
> connection scenarios 
> > that RTP can be used in. It will include normal participants A, B, 
> > etc.
> > And one or more Monitoring entities identified with an M.
> > 
> > A. The point to point case.
> > 
> >        +---+      +---+     +---+
> >        | A |<---->| M |<--->| B |
> >        +---+      +---+     +---+
> > 
> > In this there is a unicast session with participants A and 
> B and the 
> > RTP monitor M that sits in between an sees all traffic 
> going between A 
> > and B. In this scenario A and B are both senders and 
> receivers. M is 
> > only a monitor and have no active part and is not visible 
> within the 
> > RTP session.
> > 
> > B. Multi-party session using ASM multicast.
> > 
> >                  +-----+
> >        +---+     /       \    +---+
> >        | A |----/         \---| B |
> >        +---+   /   Multi-  \  +---+
> >               +    Cast     +
> >        +---+   \  Network  /  +---+
> >        | C |----\         /---| M |
> >        +---+     \       /    +---+
> >                   +-----+
> > 
> > 
> > When using multicast there can be a number of participants A, B, C. 
> > The number of participants may of almost arbitrary size (0 to 2 
> > billion+).
> > The monitor (M) simple joins the multicast network to monitor the 
> > data.
> > Any of the participants may in addition to be receivers 
> also take on a 
> > role of sender.
> > 
> > 
> > C. Multi-party sessions using Relay (MCU)
> > 
> >        +---+      +------------+      +---+
> >        | A |<---->| Multipoint |<---->| B |
> >        +---+      |  Control   |      +---+
> >                   |   Unit     |
> >        +---+      |   (MCU)    |      +---+
> >        | C |<---->|     M      |<---->| D |
> >        +---+      +------------+      +---+
> > 
> > If the MCU only relays this will be an emulation of the multicast 
> > scenario in B above. Here the monitor may be the MCU itself 
> or it may 
> > be an external node. And one could end up with many 
> different cases. 
> > Lets review two:
> > 
> > C1:
> > 
> >        +---+      +---+      +------------+      +---+
> >        | A |<---->| M1|<---->| Multipoint |<---->| B |
> >        +---+      +---+      |  Control   |      +---+
> >                              |   Unit     |
> >        +---+      +---+      |   (MCU)    |      +---+
> >        | C |<---->| M2|<---->|            |<---->| D |
> >        +---+      +---+      +------------+      +---+
> > 
> > There are different monitoring entities the path between A 
> and the MCU
> > (M1)  and C and the MCU (M2).
> > 
> > C2:
> > 
> >        +---+      +---+      +------------+      +---+
> >        | A |<---->|   |<---->| Multipoint |<---->| B |
> >        +---+      |   |      |  Control   |      +---+
> >                   | M |      |   Unit     |
> >        +---+      |   |      |   (MCU)    |      +---+
> >        | C |<---->|   |<---->|            |<---->| D |
> >        +---+      +---+      +------------+      +---+
> > 
> > Here the same monitor (M) sits between participant A and C and the 
> > MCU.
> > 
> > D. Multi-party using unicast and full mesh:
> > 
> >        +---+         +---+
> >        | A |<------->| B |
> >        +---+  \   /  +---+
> >                \ /
> >                 V
> >               +---+
> >               | C |
> >               +---+
> > 
> > In this scenario each and everyone participant has a list 
> of unicast 
> > addresses to all the other participants and replicate each 
> sent packet 
> > to all the other participants. Thus achieving a joint RTP 
> session. Any 
> > monitor can located in a number of different places. Either 
> seeing the 
> > full mesh traffic or not.
> > 
> > Lets look at the six cases above and then review the way the 
> > RtpSessionEntry tries to identify the RTP session. It is using a 
> > single source and single destination address and port tuple. This 
> > clearly does not identify the session on an address plane in all of 
> > the above cases.
> > As I see it only Scenario B (multicast) is well defined 
> with a single 
> > destination address. I don't think the source address has any major 
> > importance in defining an RTP session.
> > 
> > Lets also look at what information that exist in the RtpSenderEntry 
> > and RtpRcvrEntry. Both contains address information to pinpoint the 
> > location of the source of data reported in the entry.
> > 
> > An RTP session is the sum of all participants that consider 
> that their 
> > SSRC is part of the sessions joint SSRC number space. This 
> is normally 
> > realized for each participant by defining a receiver 
> address and port 
> > tuple to receive traffic on. The transmissions into the 
> session goes 
> > either to a single address (unicast, multicast, relay) or multiple 
> > addresses (full mesh). However that address is in many cases 
> > participant dependent.
> > 
> > So I think we need to ask ourselves the question; is address 
> > information at all useful on the session level to identify the RTP 
> > session?
> > 
> > To me it looks like only the multicast address used as destination 
> > address is useful. We should consider if one in all the other cases 
> > need to find a session based on the address information 
> present in the 
> > sender and receiver entries identifying the participants? Or using 
> > another type of session identifiers, like signalling 
> session bindings 
> > put in by the relevant participants.
> > 
> > If the sender of media or reports uses another address port 
> tuple than 
> > it receives data on then there will be more difficult to correlate 
> > this information. And we may need to consider how to build 
> sufficient 
> > information to achieve this.
> > 
> > In this context I can see that an Monitor would need to 
> have a way of 
> > being configured for a particular session for it to 
> monitor. Thus it 
> > would need the address filtering rules that allows it to find the 
> > traffic relevant to the session. I don't see how a single 
> filter rule 
> > would be sufficient to allow the monitor to work well. If there are 
> > multiple flows that are relevant the monitor would need to identify 
> > them all.
> > 
> > We should also consider that the RTP MIB can be implemented 
> in either 
> > an receiver, a media sender or a monitor. This creates 
> further issues 
> > for the information to store. First of all I think we 
> should consider 
> > how to store information about who it was that built the actual 
> > information for a particular session.
> > 
> > Secondly we need to consider the different relevance of entries 
> > depending on the role of the one writing the entry into the 
> MIB. Here 
> > I think the SenderEntry is a good case. A sender entry can 
> be written 
> > by any of roles in the session.
> > Lets look how the relevance of the information varies 
> depending on who 
> > did it.
> > 
> > 1. The writer of the entry is the sender of this actual 
> media stream. 
> > Thus this the actual report on the transmission.
> > 
> > 2. The writer of the entry is any receiver (sender of 
> another stream, 
> > receiver or monitor). In this case it is an observation of 
> the media 
> > stream from the position of the entity writing the entry.
> > 
> > I don't see that this distinction is indicated by the 
> entries or the 
> > table. I don't know what the best solution is here.
> > But either include some flag in the entry to indicate the 
> role of the 
> > entry writer or include the SSRC on the session level to 
> allow one to 
> > determine the cases where the writer of the MIB records is also the 
> > generator of the data.
> > 
> > I also think there is need to consider what data entity 
> stores. Also 
> > this may not be sufficiently described in the current document.
> > 
> > I think we have at least three levels of completeness of 
> the data an 
> > entity writes into its database.
> > 
> > A. Only report what I self has sent. In other words write a 
> > SenderEntry if I am a media sender.
> > 
> > B. Write information on all media streams to the MIB. Thus I would 
> > write SenderEntries for all media senders I see.
> > 
> > C. Write received RTCP Reports to the MIB. In this case the entity 
> > write ReceiverEntries for all receivers it sees, i.e.
> > for those who it sees RTCP RRs from.
> > 
> > To me it seems that in most cases an session participant that 
> > implements the MIB should handle A and B. A monitor is normally the 
> > only one that handles C. Some exception to this last would be media 
> > senders that anyway keeps extensive information on all 
> participants. 
> > Like an RTCP SSM distribution source (draft-ietf-avt-rtcpssm)
> > 
> > So lets get the discussion going. This email brings up three issues:
> > 
> > 1. How do we identify the session and handles addresses in relevant 
> > way
> > 
> > 2. One should make a separation between first hand information and 
> > observations.
> > 
> > 3. The level of implementation and how it is scoped.
> > 
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> > Multimedia Technologies, Ericsson Research EAB/TVA/A
> > 
> ----------------------------------------------------------------------
> > Ericsson AB                | Phone [phone]
> > Torshamsgatan 23           | Fax   [phone]
> > S-164 80 Stockholm, Sweden | mailto: [e-mail]
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> > 
> 


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt