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

["Jean-Francois Mule" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Ali C. Begen (abegen)
> Sent: Friday, October 30, 2009 9:48 AM
> To: VAN CAENEGEM Tom; [e-mail]
> Cc: [e-mail]
> Subject: Re: [MMUSIC] Comments onhttp://tools.ietf.org/html/draft-
> begen-avt-ports-for-ucast-mcast-rtp-01
> 
> 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
> >
> >
> >
> >
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic