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

["VAN CAENEGEM Tom" <Tom.Van_Caenegem at alcatel-lucent.be>]

 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