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

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

Tom,
I do not agree that we need a solution for SSM + retransmission not in the
architecture of RAMS. Can you show me such a use and why not use RAMS.
The assumption is that the first request for retransmission is going to the
FT. If the request goes to the retransmission server, you can use RTP/RTCP
multiplexing.
Roni 

> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> Sent: Friday, June 26, 2009 1:10 PM
> To: Roni Even; Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen
> (abegen); avt at ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Roni,
> 
> See inline
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: vrijdag 26 juni 2009 11:34
> To: VAN CAENEGEM Tom; 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C.
> Begen (abegen)'; avt at ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Tom,
> What bothering me is that I do not want to make RTCP as a general
> mechanism to provide addressing information.
> 
> TOM: I understand
> 
> I still do not see this a a general problem. The case you described
> (SSM
> with retransmission), except for the RAMS case there is no other
> application that requires that, it requires co-location of the FT and
> retransmission source, you send the retransmission request to the
> feedback target and not to the retransmission server.
> 
> TOM: not sure I understand your exact point here. Do you agree that we
> need a similar solution for SSM with retransmission (-only)  AND SSM
> with RAMS (+ retransmission)?  In that case, it does not make sense to
> specify ONLY a RAMS-R with the port information, you also need to do
> that then for a NACK message. NACK is already defined, so that is why I
> think that specifying a separate RTCP message is the way out here. But
> because this is related to ssm and retransmission, it cannot be done in
> this RAMS draft only. I do agree that such message can only be used in
> the context of ssm with unicast feedback.
> 
> 
> If this was a general problem it should be addressed in the context of
> retransmission or SSM.
> 
> Roni
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> > VAN CAENEGEM Tom
> > Sent: Friday, June 26, 2009 11:52 AM
> > To: Roni Even; Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen
> > (abegen); avt at ietf.org
> > Subject: Re: [AVT] Port mappings, NAT, and RAMS
> >
> > Hi Roni,
> >
> > The problem I see here is that this is broader than RAMS: if an RTP
> > receiver in an SSM session does not make use of RAMS, but wants to
> > receive retransmissions, then integrating the "pub-port"
> functionality
> 
> > in the RAMS-R will not help here. That is why it makes most sense to
> > define a dedicated RTCP "pub-port" message that can be combined with
> > an RAMS-R or with a NACK.. Or with any other future RTCP request
> > message that may be defined and relies on the same ssm with feedback
> > target architecture..
> > And I also think that we should consider a "default" case that when
> an
> 
> > RTP receiver does not signal its ports, the retransmission server
> > understands the RTP receiver expects the retransmission/burst on the
> > port, that was used by the RTP receiver as source port to request the
> > retransmission and burst. But that should imply that the "pub-port"
> > MUST
> > always be sent in a single compound together with the NACK and/or the
> > RAMS-R message (either of these) that triggers the retransmission
> > session.
> >
> > Tom
> >
> >
> > -----Original Message-----
> > From: Roni Even [mailto:Even.roni at huawei.com]
> > Sent: vrijdag 26 juni 2009 10:31
> > To: 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C. Begen (abegen)';
> > VAN CAENEGEM Tom; avt at ietf.org
> > Subject: RE: Port mappings, NAT, and RAMS
> >
> > Hi Bill,
> > I think I was the one who started this discussion but it looks to me
> > like it is going too far since some of this work are not in the AVT
> > charter.
> >
> > The RAMS solution is based on SSM and Retransmission and if there is
> a
> 
> > problem with NATs in these drafts it should be discussed there. My
> > concern was different. The AVT solution is using SDP for specifying
> > address information. In the case of both SSM and retransmission, the
> > server can provide their address (which they may have obtained by
> > using any method they
> > chose) in the SDP. This works both for offer/answer and declarative
> > SDP.
> > I see no reason to address this topic in the RAMS draft
> >
> > The RAMS draft need to provide other addresses which are the RR RTP
> > and RTCP receive addresses. In the case of offer answer this is clear
> > by for declarative SDP the RR does not sent an SDP so cannot provide
> > receive addresses.
> >
> >
> > In the case of RFC 4588 the retransmission can be based on session or
> > SSRC multiplexing and defines how to use SDP to provide the
> addresses.
> > The difference is that RFC 4588 do not address a unicast
> > retransmission for a multicast stream which is the special case
> > described here.  In the current case the SSRC multiplexing mode of
> RFC
> 
> > 4588 is not relevant so there MUST be a way for the RR to provide its
> > receiving addresses to the RS.
> >
> > Since this solution do not work in offer/answer but is based on
> > declarative SDP there need to be other way for the RR to provide the
> > addressed
> >
> >
> > My view based on the text above about SSM and RFC 4588 is that this
> is
> 
> > a special case and not a general case and this is why I suggested to
> > add the address information to the RAMS-R message.
> >
> > Roni Even
> >
> >
> > > -----Original Message-----
> > > From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> > > Sent: Wednesday, June 24, 2009 3:37 PM
> > > To: Zeev Vax; Ali C. Begen (abegen); Roni Even; VANCAENEGEM Tom;
> > > avt at ietf.org
> > > Subject: Port mappings, NAT, and RAMS
> > >
> > >
> > > There has been some discussion around the requirement for a NAT
> > > section in the latest RAMS draft. This note is an attempt to
> clarify
> 
> > > the requirement to signal RAMS port mappings. Once we come to a
> > > consensus as to the desired behavior, we can update the draft.
> > >
> > > This text refers to a ppt document that can be found at
> > > ftp://ftpeng.cisco.com/abegen/PubPorts.pdf
> > >
> > > When using RAMS to accelerate acquisition of a multicast flow,
> there
> 
> > > are two sessions - the primary multicast session and the
> > > acceleration session. These sessions may have multiple socket
> > > contexts, depending on the use of RTP/RTP port muxing. However, the
> > > primary multicast session and the retransmission session are always
> distinct.
> > >
> > > 1- The primary multicast session - two logical flows defined by the
> > > Source address, Destination Multicast Address, RTP port (P1) and
> > > RTCP port(P2). This set of flows is shown in RED in the diagram.
> > > 2- The retransmission/acceleration session, shown in BLUE in the
> > > diagram. In the most general non-port-muxed, non-NATed case, this
> > > stream consists of 2 flows. The first (RTP) flow is defined by the
> > > 5-tuple of UDP, IP address of the FT, RTP port configured by SDP
> > (P3),
> >
> > > the IP address of the client and the RTP port dynamically chosen by
> > RR
> >
> > > (c3).
> > > The second (RTCP) flow is defined by the 5-tuple of UDP, FT
> address,
> 
> > > the RTCP port defined by SDP (P4), the IP address of the client and
> > > the RTCP port dynamically chosen by RR (c4). When RTP/RTCP port
> > muxing
> >
> > > is used, the retransmission session is collapsed onto a single
> > > 5-tuple.
> > >
> > > Note that the feedback target for the primary session is P2 on
> FT/RS.
> > > Note that the acceleration burst must flow from FT P3/P4 to C
> c3/c4.
> > > In other words, the first desired data flow on the retransmission
> > > session is "downstream".
> > >
> > > When we introduce NAT, we need to map c3 to c3' (and in the absence
> > of
> >
> > > port muxing, also c4 to c4') through the NAT device. This diagram
> > > shows the use of STUN in YELLOW to setup the port mappings, but
> > > other methods could be used.
> > >
> > >
> > >
> > > In summary, the ppt describes 4 options-
> > >
> > > Drawing 1 - No muxing - Stun request, bind for two ports and send
> > > PubPorts with RAMS-R to signal both, followed by the burst.
> > > Drawing 2 - Muxing - Stun request, bind for one port and send
> > PubPorts
> >
> > > with RAMS-R to signal a single port, followed by the burst.
> > > Drawing 3 - Muxing - No explicit STUN request/bind. Send PubPorts
> > with
> >
> > > RAMS-R to signal RS to use the src port of the incoming RTCP packet
> > as
> >
> > > the destination for both RTP and RTCP in the ret session (We do
> this
> 
> > > by putting 0's in the pubports messages). Note that this does not
> > work
> >
> > > through all NAT variants. The RAMS-R/PubPorts message is sent from
> > > c4 to P2. The burst is sent from P4 to c4', and certain NATs will
> > > not pass this traffic.
> > > Drawing 4 - Muxing - No explicite STUN request/bind. Send PubPorts
> > > from
> > > c4 to P4, initializing NAT bindings. Send RAMS-R, followed by the
> > > burst.
> > > This works through all NAT types. There is concern about the
> > > decoupling of the PubPorts from the RAMS-R, as dropped messages may
> > > cause problems.
> > >
> > > Hopefully this note clarifies the need to signal the ports.
> > >
> > > Inputs on ths problem are desired. We need to decide if the
> PubPorts
> 
> > > is the right way to go, and if the transaction is RAMS specific or
> > > is a generic RTP/RTCP message. Once we make that determination, we
> > > need to lay out the details of the message format.
> > >
> > > Based on the feedback - we will abandon the idea, keep it in the
> > > draft, or write a separate draft for it.
> > >
> > > Bill VerSteeg (with extensive input from Ali Begen and Dan Wing)
> > >
> > > -----Original Message-----
> > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf
> > > Of Zeev Vax
> > > Sent: Thursday, June 18, 2009 5:58 PM
> > > To: Ali C. Begen (abegen); Roni Even; Bill Ver Steeg (versteb);
> > > VANCAENEGEM Tom; avt at ietf.org
> > > Subject: Re: [AVT] comments on
> > > section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> > >
> > > If we assume all entities are one, why would you need to signal the
> > > retransmission port separately ?
> > >
> > > Zeev
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt