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

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

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