Re: [MMUSIC] Comments on http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Tom,

There are a few different things we are discussing. Let me attempt doing a summary. Feel free to make corrections, suggestions. See below.

> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.com]
> Sent: Monday, November 02, 2009 6:35 AM
> To: Ali C. Begen (abegen); avt at ietf.org
> Cc: mmusic at ietf.org
> Subject: RE: Comments on http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-
> rtp-01
> 
> 
> Ali,
> 
> Picking in on your last comment/statement:
> 
> 
> "Correlating SSRC-muxed streams is a lot more complicated than
> correlating session-muxed streams. Section 5.3 of 4588 provides some
> guidelines on how to do it and also mentions an ambiguity, which could
> be addressed by taking some precautions at the receiver in unicast
> retransmissions, but the same is not necessarily true for multicast
> retransmissions (something DVB-IPI supports).
> 
> If we can figure out a nice and solid solution to this, I'll take it.
> But this seems questionable (at least to me)."
> 
> 
> TOM: just for clarity...the (DVB IPI) multicast retransmissions must be
> on a different RTP session than the original multicast.

Yes, using the same multicast session for both primary distribution and retransmissions would be a terrible idea. Now, suppose the client is supporting both mcast and ucast retransmissions. So, there are 3 RTP streams involved in this picture:

S1- Primary multicast stream (SSRC1)
S2- Multicast retransmission stream (SSRC2)
S3- Unicast retransmission stream (SSRC3)

We all agree that S1 and S2 will be on different RTP sessions (different mcast destination addresses). By definition, S3 is in a different RTP session, anyway. So, these streams are session-muxed, which would normally mean SSRC1=SSRC2=SSRC3.

If all SSRCs are the same, client-side association is fairly easy (RFC 4588 section 5.3). Now, the trouble here is whether we can use the same RTCP port on the feedback target to send the receiver reports and other RTCP messages. What happens if we do? In short, the server will have to figure out which stream the client is referring to in its report/message (because they will all look the same - same port, same SSRCs). If the feedback target also dumps the RTCP reports to another box that analyzes them offline, it will be complicated AFAICT.

Now, if we use different SSRCs for all these 3 streams (although they are session-muxed), we can probably use the same port on the server since the server or other RTCP-processing units can differentiate the reports from each other. OTOH, the server, RTCP-processing units and client are now supposed to figure out the stream associations. I believe the most handsome solution to this problem is RFC 5576 (section 7). The potential problem is not every client will be supporting 5576 and they could probably support the most straightforward session-muxing option only.

But, I'd like to hear WG's input (both from MMUSIC and AVT) on this.

> TOM: I am not clear on what you are asking/proposing here.. Do you mean
> a "nice and solid solution to" how an RR can associate original and
> retransmission streams when they are both SSRC and session multiplexed?
> .. And how this possibility can be mapped into the port mapping proposal
> for multicast/unicast sessions?

See above. We can shape the port mapping proposal based on how we assign the RTCP ports on the server and whether we can mandate support for 5576. However, I feel like the solution should be more general than that.

Cheers, acbegen.
 
> Thanks
> tom
> 
> 
> 
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: vrijdag 30 oktober 2009 22:16
> To: VAN CAENEGEM Tom; avt at ietf.org
> Cc: mmusic at ietf.org
> Subject: RE: Comments on
> http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01
> 
> > > The NAT friendly solution IMO is that the port mapping request
> > > messages for RTP and RTCP is sent along with a RAMS-R FB by the RR
> > > to the RS whereas a port mapping request for RTP
> >
> > But this message (since it includes RAMS-R) needs to go to port P2 on
> > RS (rtcp port for the primary mcast session) instead of port P3.
> >
> > TOM: I meant two separate RTCP messages, the RAMS-R sent to port P2,
> > and the port mapping request is sent to port P3. Not a neat solution
> > either, I agree.
> 
> I see.
> 
> > > is sent along with a NACK FB by the RR to the RS. This is not to
> > > inform the RS of the ports it should use each time -as it needs to
> > > remember that anyhow and keep state based on the 1st received port
> > > maping request by the RR- but to open the NAPT in between. The
> > disadvantage is of course the higher messaging load for the RS (and
> RR).
> > >
> > > I realise the draft wants to provide an answer on how an RR can
> > > indicate the UDP ports it wishes to use for RTP unicast sessions
> > > without any session-signaling protocol involved, but I do not think
> > > all design criteria can be met. I think we can drop the cookie, and
> > > just keep the port mapping response/request message (without
> > > cookie), meaning the RS needs to keep state of the port allocated to
> 
> > > each RR based on acknowledged port mapping request messages, and
> > > when
> > receiving RTCP Byes in the retransmission session, it can drop the
> > "state".
> >
> > This is an interesting proposal but we are giving up from the
> > stateless server idea. Are we willing to do that? In order to keep the
> 
> > server stateless, we might break another rule, if we have to, and
> > re-consider our earlier proposal - PubPorts (where port numbers are
> > directly transmitted in the RTCP message). That will satisfy our
> > requirements except that it introduces layer violation.
> >
> > TOM: don't you still face the same issue, that RTCP SR get sent by the
> 
> > RS unsollicited, so the RS needs to remember from previous received
> > pubport message, which port to use for the RTCP SR?
> 
> Yes, sender reports seem to require state on the server.
> 
> > > In my opinion, the ideal solution is still that we can make the P2
> > > and
> >
> > > P3 ports on the RS equal, where a single message (RAMS-R or NACK) by
> 
> > > an RR will allow the response (RTP burst or RTP retransmission
> > > packet)
> >
> > > to pass through NAT, provided the RR supports the RTP/RTCP
> >
> > Yes, your proposal above requires this.
> >
> > TOM: not really, but making P2=P3 on top of that definitely takes away
> 
> > many complexities and "overhead".
> 
> Sure, it does but also brings up other issues mentioned below.
> 
> > > port muxing.  I realise this would require the RS to use an SSRC in
> > > the unicast retransmission session that is different from the one
> > > used
> >
> > > in the primary SSM session- allowing the RS to distinguish RTCP
> > messages based on the media SSRC in the RTCP messages.
> > > However, using a different SSRC when retransmission session muxing
> > > is used, is forbidden
> >
> > Correct.
> >
> > > by RFC 4588. But there is no justification in RFC 4588 why this was
> > > disallowed, and further inquiries have made me believe that there is
> 
> > > really no hard reason why this constraint was imposed.
> >
> > I believe the reason is to allow for easier monitoring and processing
> > of RTCP reports. If a session and its retransmission session use
> > different SSRCs, how do we correlate them at the monitoring (RTCP
> > processing) agent? There can be multiple primary sessions and their
> > retransmission sessions running on the same client at the same time.
> >
> > TOM: the agent needs the SDP  -or any other signaling info- to start
> > the monitoring process. This may include SSRC information. If not, the
> 
> > RFC
> > 4588  indicates how association can be done for ssrc-multiplexed
> > scheme, and I cannot see why  the described approach cannot be mapped
> > to the session-multiplexed scheme where the original and the
> > retransmission stream have a different SSRC.
> 
> Correlating SSRC-muxed streams is a lot more complicated than
> correlating session-muxed streams. Section 5.3 of 4588 provides some
> guidelines on how to do it and also mentions an ambiguity, which could
> be addressed by taking some precautions at the receiver in unicast
> retransmissions, but the same is not necessarily true for multicast
> retransmissions (something DVB-IPI supports).
> 
> If we can figure out a nice and solid solution to this, I'll take it.
> But this seems questionable (at least to me).
> 
> Cheers, acbegen