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

["Romascanu, Dan \(Dan\)" <[e-mail]>]

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