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

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

Zeev,
I assume you mean RTp/RTCP muxing. I am afraid it will not solve the problem
since the RAM-R is going to the FT while the RTP is coming from the burst
server using a different port. This will fail a symmetric NAT since the RTP
is not coming from the same IP/port to where the RAMS-R was sent
Roni

> -----Original Message-----
> From: Zeev Vax [mailto:zeevvax at microsoft.com]
> Sent: Friday, June 26, 2009 8:27 PM
> To: Roni Even; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg (versteb)'; 'Ali C.
> Begen (abegen)'; avt at ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> I'm really straggling with why do we need to include port signaling as
> part of this draft. The port can be signal dynamically or sent to
> client at start up, and we can point out the different options to do
> so. Saying that, going to great level of details on this looks to me
> outside the scope of this draft.
> The port muxing gives the means to connect this protocol to the
> retransmission one, and I think we should add that in order to clarify
> the usage of this protocol.
> 
> Zeev
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Friday, June 26, 2009 8:56 AM
> 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