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

[Roni Even <Even.roni at huawei.com>]

Hi guys,
My view is that this is not a general NACK problem but only for the case of
SSM and retransmission with similar box architecture to the RAMS solution.
If you have another case please explain
Roni

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Tuesday, June 30, 2009 10:19 AM
> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
> avt at ietf.org
> Subject: Re: [AVT] Port mappings, NAT, and RAMS
> 
> 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
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt