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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 30 Oct 2009 08:48:26 -0700

Hi Tom,

Thanks for reading the revised draft.

> Hi Ali,
> 
> When reading through the draft http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-
> mcast-rtp-01 <http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01>  ,
> including your editor comments, I understand that despite the cookie exchange solution, it
> does not allow to have a "stateless" server (that is, the server needs to remember the
> ports). You indeed correctly pointed out that RTCP SR messages are unsollicited, so they
> cannot be linked to a received cookie. I do not think it makes sense to "forbid" the
> server (RS in the considered use cases) to send RTCP SR at any moment in time. Hence, as

Yes, sender reports pose a problem at this time (the server needs to remember the port). There may be a nice solution to it, but we don't have any for now.

> the RS needs to remember anyhow the ports and thus must keep state, the cookie would no
> longer be needed from that perspective. Is that an appropriate conclusion? Port mapping

That is where we are now. But I am not sure whether the WG will make that conclusion. 

> response message (exchange) is then no longer needed anymore, although I understand this
> message is also a kind of confirmation of reception of the port mapping request message.

Yes, response serves as a confirmation of the request.
 
> You also mention that NAT tolerance is a design criterium. How was that taken into account
> in the proposed messaging flow?

We have not gotten into its details yet. But, yes, nat friendliness is desired/required.
 
> 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.

> 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.
 
> 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.

> 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.
 
> As you know, in the DVB retransmission solution for linear TV (hence SSM sessions), it is
> allowed to use a different SSRC even though session muxing is used (as the UNICAST
> retransmission session is associated with a SSM session), "overruling" RFC 4588 on that
> aspect. This then allows making P2=P3, with no ambiguities for the RS in resolving which
> incoming RTCP message belongs to which session (either the unicast retransmission session
> or the unicast feedback channel of the SSM session).  This solution requires no port
> signaling at all and is NAT friendly.

Yes, I am aware of that. I will try to get an answer from MMUSIC folks, too. In fact, I cc'ed mmsuic hoping that someone will clarify this requirement in RFC 4588.

Thanks again,
-acbegen
 
> Regards
> Tom

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 30 Oct 2009 10:08:50 -0600

As an FYI, and thanks to Ali who suggested it, we have also added this draft on the agenda for the MMUSIC WG session in Hiroshima.

Jean-François

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ali C. Begen (abegen)
> Sent: Friday, October 30, 2009 9:48 AM
> To: VAN CAENEGEM Tom; [email-masked]
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Comments onhttp://tools.ietf.org/html/draft-
> begen-avt-ports-for-ucast-mcast-rtp-01
> 
> Hi Tom,
> 
> Yes, sender reports pose a problem at this time (the server needs
> to remember the port). There may be a nice solution to it, but we
> don't have any for now.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Yes, I am aware of that. I will try to get an answer from MMUSIC
> folks, too. In fact, I cc'ed mmsuic hoping that someone will
> clarify this requirement in RFC 4588.
> 
> Thanks again,
> -acbegen
> 
> > Regards
> > Tom
> >
> >
> >
> >
> >
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 30 Oct 2009 14:15:59 -0700

> > 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
> > 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
> 
> 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.
> > 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