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

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

Roni,

I am puzzled again. Are you suggesting that we use the RAMS-R message
also as a means to signal to the retransmission server that the RTP
receiver will only send NACKs? I do not get that way of thinking.
What the RAMS draft is about is defining the RAMS messages for rapid MC
acquisition. The architecture as such is not a new item. You can combine
rtcp-ssm and RFC 4585, RFC 4588, and there it is, the architecture.. In
the RAMS draft we only have imposed some constraints saying for instance
that the FT must be the same as the retransmission server (similar as in
DVB by the way). The additional port signaling we need that we are
discussing about now could be done by SDP negotiation or by means of
RTSP. But because of time constraints this is not a good solution,
regardless whether this is retransmission only, or retransmission and
rapid acquisition combined. 

I can only repeat myself: IF we define a port signaling means it must be
applicable both to retransmission-only (no RAMS messages are involved,
only NACKs) and to rapid acquisition (what the RAMS draft is about).
Hence, the RAMS-R message must be decoupled from the port signaling, and
even stronger:  the solution should be defined in a separate draft.

Tom 
 

-----Original Message-----
From: Roni Even [mailto:Even.roni at huawei.com] 
Sent: vrijdag 26 juni 2009 17:56
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,
So maybe, since it is the same architecture,  it is a good time to allow
RAMS-R to only signal retransmission.  

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 6:41 PM
> 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,
> 
> My perspective here is the one from real operator networks where 
> operators are providing IPTV services making use of RTP, including 
> multicast services. IPTV operators need to address packet loss, and 
> one way to address this is by making use of RTP retransmissions. I 
> lead the standardisation effort in DVB in 2007-2008, where we defined 
> the RTP retransmission solution referring to rtcp-ssm draft, RFC 4585 
> (defining AVT-FB profile and RTCP FB message such as NACK) and RFC 
> 4588 (Retransmission), and also the RTP mux draft. Hence this 
> architecture/solution is based on ssm, and the RTP receiver needs to 
> send all its RTCP messges , including the RTCP NACK FB, to the 
> feedback target. The feedback target is also here the same entity as 
> the retransmission server. DVB has its own way of signaling 
> parameters, but also here we were facing the fact that parameters are 
> signaled to the receivers. The receivers do not/cannot signal towards 
> the FT/RET server which ports they want. So we took a shortcut by 
> allowing that the destination port of the RTP packet could be defined 
> by the system (so quite exotic) OR when this port was not signaled, 
> the RTP receiver knew that the RTP retransmission packet port matches 
> the source port it used in the NACK messages. There have been some 
> email exchanges from DVB with AVT when this work was conducted, but 
> there was not that much interaction.
> 
> RAMS is a solution that addresses a different topic, that is: how to 
> shorten zapping response times. From a service need point of view, 
> packet loss repair and minimising zapping times are quite separate
> topics: some operators may only be interested in achieving high image 
> quality (relying on retransmissions), others may (also) want to offer 
> smallest zapping response times without impact on quality (relying on 
> RAMS messaging). Note also that a "retransmission service" and  -what 
> is called in DVB-  "fast channel change service" impose quite 
> different loads onto the networks, especially when these servers are 
> localised deep in the network. So that may for instance be a reason 
> why some IPTV service providers do not want "fast channel change" 
> service, but do need retransmission service.  So, imposing to use 
> "RAMS" for an IPTV service that provides retransmission(-only) support

> -to allow a standards way by which the receiver itself can select its 
> ports- is quite absurd, and will not work.
> 
> In short: the architecture for retransmissions-only and for "fast 
> channel change" service are exactly the same, but RAMS as such has 
> nothing to do with retransmission service, still faces the same 
> problem of port signaling.
> 
> Tom
> 
> 
> 
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: vrijdag 26 juni 2009 16:53
> 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,
> I do not agree that we need a solution for SSM + retransmission not in

> the architecture of RAMS. Can you show me such a use and why not use 
> RAMS.
> The assumption is that the first request for retransmission is going 
> to the FT. If the request goes to the retransmission server, you can 
> use RTP/RTCP multiplexing.
> Roni
> 
> > -----Original Message-----
> > From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> > Sent: Friday, June 26, 2009 1:10 PM
> > 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
> >
> > 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
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt