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

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Tom,

A few quick comments inline.

> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> 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: 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.

Yup. It can be removed.

 
> -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

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.


> 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.

> 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. 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

This is a very good point. If RS/FT address changes for each SSM session, then a new pubports is needed to bind the correct address/port on the NAT. And similar to RAMS-R, NACK would also require a pubports message whenever a binding is needed for regular retransmission. 

But, the main problem here is that we are separating the RAMS-R/NACK from the pubports message. Now, assume that we sent RAMS-R and pubports for session 1, and suppose pubports message made it but RAMS-R was lost. Then, we switched to session 2, sent a new RAMS-R and pubports. Then, we switched back to session 1, sending a new RAMS-R and pubports. Now, RS may get confused since it may not accurately match the outstanding RAMS-R and pubports messages. In the RAMS-R message, the parameters may have changed (such as burst bitrate). In the pubports, port mappings may have changed. As a result, RS may send the burst to the wrong port and/or the burst may be at a lower or higher bitrate than RR wants to have.

In other words, we are introducing new failure modes and this is a big concern for option 4, IMO.


> 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?

As long as the binding does not expire (meaning there is some transmission on that path), we should be fine. And I believe there are certain guidelines listed in the STUN spec.

-acbegen
 
> 
> 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