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

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

Bill,
If the server's sends the announcement using SDP this is not a problem
Roni

> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> Sent: Wednesday, July 01, 2009 12:15 AM
> To: Roni Even; Zeev Vax; Dave Oran (oran)
> Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt at ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Roni-
> 
> For the 2nd case, this problem also exists when the server's "request
> port number" is different than the server's "response port number".
> This
> is a very important case that breaks the port bindings in many NAT-ed
> environments, and requires a standard solution.
> 
> Bill VerSteeg
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Tuesday, June 30, 2009 10:02 AM
> To: 'Zeev Vax'; Dave Oran (oran)
> Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg
> (versteb);
> avt at ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Zeev,
> I think that this is not a general problem, I am not sure that RTCP
> should enable a general way to convey transport addresses, we will need
> to open this to discussion.
> Dave gave some probable cases but in my view the problem exists when
> there are three important conditions:
> 
> 1. No negotiation between both sides, no offer/answer like in
> declarative SDP.  (prevent the receiver to offer a transport address)
> 
> 2. The NACK /RAMS-R is going to one address while the response is
> coming
> from a different address (like request to Feedback target in SSM and
> response (may be RTP or RTCP) from retransmission server. This will
> prevent using RTP/RTCP multiplexing
> 
> 3. New one way communication (Like RTP from retransmission server and
> no
> RTP from the receiver or previous unicast RTP to this receiver
> (multicast with unicast retransmission). This prevent the receiver from
> opening a pinhole to the source or from the retransmission server to do
> SSRC multiplexing like in unicast retransmission. This is less limiting
> if you use RTP/RTCP multiplexing based on resolving of condition 2
> above
> in a way that will enable RTP/RTCP multiplexing.
> 
> 
> Roni Even
> 
> 
> 
> > -----Original Message-----
> > From: Zeev Vax [mailto:zeevvax at microsoft.com]
> > Sent: Tuesday, June 30, 2009 7:07 PM
> > To: David R Oran; Roni Even
> > Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg
> > (versteb)'; avt at ietf.org
> > Subject: RE: [AVT] Port mappings, NAT, and RAMS
> >
> > I agree this should be a separate draft and we should work on a more
> > generic mechanism.
> > Two comments I have, first being a general problem it might have been
> > solved already so I think we should research the area before
> investing
> 
> > in another draft. Second given such functionality is typically part
> of
> 
> > an application and not staying only in the lower network layers, the
> > application can solve it as part of the startup sequence or other
> data
> 
> > delivery mechanism it has.
> >
> > Zeev
> >
> > -----Original Message-----
> > From: David R Oran [mailto:oran at cisco.com]
> > Sent: Tuesday, June 30, 2009 6:10 AM
> > To: Roni Even
> > Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg
> > (versteb)'; Zeev Vax; avt at ietf.org
> > Subject: Re: [AVT] Port mappings, NAT, and RAMS
> >
> >
> > On Jun 30, 2009, at 6:55 AM, Roni Even wrote:
> >
> > > 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
> > I believe it is actually a MORE general problem than NACK or RAMS. I
> > arises from mixing SSM sessions and unicast sessions for the same
> RTP-
> 
> > based application. That's because multicast enforces port symmetry
> > among all the receivers while unicast needs per-receiver port
> > selection.
> >
> > So far we have two uses for mixing multicast and unicast:
> > retransmission-based repair, and RAMS. I suspect more uses will arise
> > in the future. I can think of a few off the top of my head:
> > - customized per-user overlays (e.g. to be alpha-blended with the
> > video) or object-level replacement
> > - network-coded error recovery streams
> > - extra media info for re-integration when switching back from
> unicast
> 
> > to multicast in a fast-forward-to-realtime capability when doing
> > "pause-live-content" style services
> > - adaptive switching between multicast and unicast based on number of
> > simultaneous receivers.
> >
> > I have a strong intuition that doing a generic mechanism to
> atomically
> 
> > signal ports for unicast sessions using the RTCP feedback machinery
> of
> 
> > the SSM session would be highly advisable.
> >
> > So, I think:
> > a) we need to solve this problem
> > b) it exists even in the absence of NATs
> > c) we need a generic mechanism
> > d) it should be documented in a separate draft, and not part of RAMs
> > or AVPF.
> >
> > If we can agree to these points, then we can have a more detailed
> > discussion of the appropriate machinery. I have opinions on that
> > subject too.
> >
> > DaveO.
> >
> >
> >
> > > 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
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt at ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt