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

["VAN CAENEGEM Tom" <Tom.Van_Caenegem at alcatel-lucent.be>]

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


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