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

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of VAN CAENEGEM Tom
> Sent: Thursday, June 25, 2009 3:35 AM
> To: Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen 
> (abegen); Roni Even; avt at ietf.org
> Subject: Re: [AVT] Port mappings, NAT, and RAMS
> 
> Bill,
> 
> Thanks for presenting so clearly the different options. A few opinions
> here:
> 
> -For option 3 and 4, a STUN server is not involved, so perhaps the
> associated slides should not mention a STUN server there.
> 
> -For option 3, the pub-port message is in fact not needed, 
> not from the
> NAPT point of view, and not from the RS point of view if we consider a
> clause saying that the RR only needs to send a pub-port message to the
> RS (Feedback Target) when it does NOT want to receive the RTP/RTCP
> burst/retransmission packets on the same port as the source port on
> which the RR sent out the RAMS-R or NACK RTCP message (hence 
> no need to
> define "zero" port values). Of course the RR can only do so, if it
> 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
> case, the NAPT will always work and there is (again) no need for a
> pub-port message. The RTP receiver of course needs to know whether the
> RS supports this port/multiplexing scheme and this could be solved  by
> means of defining a new atribute in SDP, that is then included in the
> declarative SDP. 
> 
> With this, I am not saying that I do not want to define the pub-port
> message because RTP receivers that want to choose themselves 
> which ports
> are used for the acceleration session should rely on the pub-port
> message to signal this to the RS (option 1 and 2) and to 
> circumvent the
> NAPT when using option 4.
> 
> For option 4, the pub-port message is used to make the NAPT 
> binding. And
> each time a RR asks for a retransmission , the RR may have to send a
> pubreport message, because the NAPT bindings have a limited 
> lifetime.

The RR can keep the NAT's binding alive by sending periodic STUN
indications (as described for RTP flows in Section 4.4 of 
draft-ietf-avt-app-rtp-keepalive), or maybe we could define a bogus
RTCP message if a STUN indication to keep the binding alive is
offensive.  draft-ietf-avt-app-rtp-keepalive mentions that RTCP
usually doesn't need keepalive traffic to keep a NAT binding alive
because RTCP is sent periodically.  In the situation with RAMS
RTCP messages, the RTCP requesting re-transmission is not sent 
periodicially.  

> It
> is not clear to me whether for all options you considered, the
> pub-report message is always sent whenever a  NACK is sent?  Or would
> you recommend saying that it must be sent when a RAMS-R is sent
> (obviously), and then during the acceleration/retransmission 
> session it
> is never sent anymore for option 1 and 2 (as the RS keeps state), and
> for option 4 in your slides it is up to the RR to decide when to
> transmit the pub-port, based on its knowledge of NAT binding lifetime?

It is difficult-to-impossible to determine the lifetime of a NAT's 
binding with much confidence.

-d

> In summary, my opinions are the following:
> 
> -the pub-port message is only used by the RR to signal a dedicated set
> of ports to the RS on which it wants to receive the RTP/RTCP burst and
> retransmission packets. This is option 1 and 2. For an acceleration
> (+retransmission) session, the pub-port is sent once in a compound
> together with RAMS-R, and for a retransmission-only session (no
> RAMS/acceleration involved), it is sent in a compound 
> together with the
> 1st issued NACK. For subsequent NACKs, there is no need to send the
> pub-report along.
>  
> -when the declarative SDP indicates that the RS supports RTP/RTCP
> muxing, and the RR does not use the pub-port message, the RR 
> expects the
> retransmission/burts packets on the same port on which it sent out the
> RAMS-R or the NACK RTCP message.
> 
> -when additionally the declarative SDP indicates with a new attribute
> that the RS is prepared to use as source port for the
> burst/retransmission packets the ports used by the RR for the
> burst/retransmission request, the RR expects the RS to use the same
> ports (source and destination) for the retransmission/burts packets as
> used by the receiver in the RAMS-R or the NACK RTCP message (but
> reversed of course). The new SDP attribute could include a range of
> ports out which the RTP receiver needs to select a value that it will
> use as destination port for the RAMS-R or NACK.  
> 
> I would also be in favour that we mandate an RS to support RTP/RTCP
> muxing, such that an RTP receiver can always make a choice 
> which scheme
> to follow.
> 
> I think it would make more sense to describe this whole solution with
> the pub-port message definition and new SDP attribute as well as the
> STUN message exchange in a separate draft as it is also applicable to
> solutions making use of RTCP FB messages for retransmission only (RTCP
> NACK), but with no need for rapid acquisition. 
> 
> Regards,
> Tom 
> 
> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com] 
> Sent: woensdag 24 juni 2009 14:37
> To: Zeev Vax; Ali C. Begen (abegen); Roni Even; VAN CAENEGEM 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