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

[Magnus Westerlund <[e-mail]>]

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