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

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

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