[AVT] Port mappings, NAT, and RAMS

["Bill Ver Steeg (versteb)" <versteb at cisco.com>]

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