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

[Roni Even <[e-mail]>]

Zeev,
I am not sure what you mean by our purpose. 
In my view the only missing part is how does the Receiver after receiving
the declarative SDP provide the transport address that he wants to use for
receiving the unicast burst or re-transmission for the SSM stream. We do not
need to address the topic of how the receiver found out this address

Roni 

> -----Original Message-----
> From: Zeev Vax [mailto:[e-mail]]
> Sent: Wednesday, July 01, 2009 7:10 PM
> To: Roni Even; 'Bill Ver Steeg (versteb)'; 'Dave Oran (oran)'
> Cc: 'VAN CAENEGEM Tom'; [e-mail]
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Thanks Roni, can we use that work for our purpose?
> 
> Zeev
> 
> -----Original Message-----
> From: Roni Even [mailto:[e-mail]]
> Sent: Tuesday, June 30, 2009 10:02 PM
> To: Zeev Vax; 'Bill Ver Steeg (versteb)'; 'Dave Oran (oran)'
> Cc: 'VAN CAENEGEM Tom'; [e-mail]
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Zeev,
> The IETF has worked on it as part of BEHAVE WG and defined ICE for SDP
> based
> systems
> Roni
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Zeev Vax
> > Sent: Wednesday, July 01, 2009 4:13 AM
> > To: Bill Ver Steeg (versteb); Dave Oran (oran); Roni Even
> > Cc: VAN CAENEGEM Tom; [e-mail]
> > Subject: Re: [AVT] Port mappings, NAT, and RAMS
> >
> > I agree IETF is the right form, but I'm not sure the AVT WG is the
> > right form as I think it is more general problem.
> >
> > Zeev
> >
> > -----Original Message-----
> > From: Bill Ver Steeg (versteb) [mailto:[e-mail]]
> > Sent: Tuesday, June 30, 2009 2:14 PM
> > To: Zeev Vax; Dave Oran (oran); Roni Even
> > Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; [e-mail]
> > Subject: RE: [AVT] Port mappings, NAT, and RAMS
> >
> > I agree that we should make a general solution for mapping unicast
> > sessions onto unicast sessions.
> >
> > We need to solve this problem using data flows that will work across
> > multiple vendors' solutions, and thus need to do it in a standards
> > forum. The IETF is the correct place to do this.
> >
> > Bill VerSteeg
> >
> > -----Original Message-----
> > From: Zeev Vax [mailto:[e-mail]]
> > Sent: Tuesday, June 30, 2009 9:07 AM
> > To: Dave Oran (oran); Roni Even
> > Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg
> > (versteb);
> > [e-mail]
> > 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:[e-mail]]
> > 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; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] 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;
> > >> [e-mail]
> > >> 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@alcatel-
> lucent.be]
> > >>> Sent: Monday, June 29, 2009 9:17 AM
> > >>> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax;
> Roni
> > >> Even; [e-mail]
> > >>> Subject: RE: Port mappings, NAT, and RAMS
> > >>>
> > >>>
> > >>> Ali,
> > >>>
> > >>> See some comments below (TOM).
> > >>>
> > >>> -----Original Message-----
> > >>> From: Ali C. Begen (abegen) [mailto:[e-mail]]
> > >>> Sent: vrijdag 26 juni 2009 17:41
> > >>> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni
> > Even;
> >
> > >>> [e-mail]
> > >>> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/avt
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/avt
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt