Re: [AVT] Port mappings, NAT, and RAMS

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

Hi Tom,

Let's get the input from the WG on these points. I believe going for a more general solution that will be applicable to both RAMS and NACK is more desirable.

BR,
-acbegen



> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> Sent: Monday, June 29, 2009 9:17 AM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni Even; avt at ietf.org
> Subject: RE: Port mappings, NAT, and RAMS
> 
> 
>  Ali,
> 
> See some comments below (TOM).
> 
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: vrijdag 26 juni 2009 17:41
> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
> avt at ietf.org
> Subject: RE: Port mappings, NAT, and RAMS
> 
> Hi Tom,
> 
> [snip]
> > The reason why we need pubports is that it indicates "explicitly" the
> > port the client wants to use to receive the burst is the port it used
> > to send the RAMS-R/pubports message. I believe we need this explicit
> > indication, ow, we will be making an implicit assumption. Note that
> > the rams-r/pubports is in the primary session and burst/ret packets
> > are in the retransmission session, which is different than the
> primary.
> >
> > As far as I can see, not everybody agrees on this point, but we need
> > to make a decision here before we mandate anything.
> >
> > TOM: I agree with your last line, but I do not completely agree when
> > you mention "implicit" assumption, especially for option 3, where
> > RAMS-R (or
> > NACK) and the Pub-port message are in the same compound message. If we
> 
> > "define" that if no pub-report message is sent by the RR, the
> > information towards the Retransmission server is exactly the same as
> > when an RTP receiver sends an RTCP compound message made up of an RTCP
> 
> > NACK/RAMS-R together with a pub-port message where the ports are
> "zero"
> 
> We "may" be able to say it from RAMS-R but not for NACK since we are not
> defining it, we will be overloading its meaning, IMO. And as you/Bill
> pointed out in other emails, I also believe that this is more general
> problem than just RAMS. We need something like pubports for NACKs as
> well.
> 
> 
> TOM: indeed, that is why IMO we should define this problem and solution
> in a separate draft which applies to any system architecture where a
> unicast session from a FT is coupled to a ssm session with that same FT.
> 
> 
> > -as currently proposed in the RAMS draft now.  I agree that this is
> > not true for option 4, where pub-port and RAMS-R or NACK are separate
> > messages, but I do not favour the solution of option 4 for the same
> > reason you mention in your reply (a new failure mode). So, if option 4
> 
> > is -for that reason- no longer considered, I do not see a problem with
> 
> > defining this rule/clause as expressed above. In other words, there is
> 
> > no need for a pub-report message in this scenario and this results NOT
> 
> > in an "assumption" what-so-ever.
> >
> >
> > > supports RTP/RTCP muxing itself, and if it knows the RS supports
> > > RTP/RTCP muxing too (as indicated in the declarative sdp received by
> 
> > > the
> > > RR)
> > >
> > > -Don't we also allow that for option 3, the port P2 actually equals
> > > port P4? This is a kind of hybrid of session and SSRC multiplexing
> > > of the primary multicast RTP stream and the
> > > retransmission/acceleration session
> > > :  on the unidirectional RTP layer, the primary MC packets and the
> > > unicast retransmission packets are clearly session muxed, but the
> > > RTCP
> >
> > > "return" channel for both streams have exactly the same transport
> > > addresses, but are distinguished by means of a different SSRC.  In
> > > that
> >
> > How? Since SSM and retransmission sessions are session muxed, they
> > have the same SSRC. When a client is sending a receiver report, how do
> 
> > we identify which session it belongs to? So, I believe P2 should be
> > different than P4.
> >
> > TOM: you are right. But notice this: RFC 4588 mandates that when
> > session muxing is used for retransmission, than the SSRC should be the
> same.
> > However the RFC 4588 does not give arguments why it needs to be like
> > that. So I ask you: what would or can happen if there is a different
> > SSRC used?  If there are no convincing arguments why we must stick to
> 
> Good question. If we don't use the same SSRC in session-muxed RTP
> sessions, it will introduce correlation problems. Receiver/XR reports
> coming from a larger number of receivers will be difficult to identify
> and match at the server side. There will be SSRC collisions, which will
> complicate things further.
> 
> TOM: the big difference with when the RFC 4588 was being discussed and
> developed, is that now we are capable of advertising in SDP the SSRC of
> the media server, that is in this case the retransmission server SSRC
> used in the retransmission session. In fact for RAMS, we need to define
> the SSRC of the ssm RTP session, so we can as well do it for the
> retransmission session. Perhaps we should consider this different SSRC
> possibility (hence violating RFC 4588) as part of a new draft, the one I
> mentioned above.
> 
> 
> > the same SSRC, then, if we have a good use case to depart from that
> > "rule" -and the use case we are discussing here is IMO indeed a valid
> > use case- I do not see why we should be limited by such a "rule". The
> > "valid" use case is here that RAMS and Retransmission for SSM sessions
> 
> > operates fine through any NAPT and without any dedicated RTCP message.
> 
> -acbegen