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

[Zeev Vax <[e-mail]>]

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:[e-mail]]
> >>> 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