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

[Roni Even <Even.roni at huawei.com>]

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