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

[Zeev Vax <zeevvax at microsoft.com>]

my understanding is that port muxing can solve both problems, if we assume retransmission server and burst server are running on one physical server. For RTP RTCP muxing, the most logical is to use the RTCP port to send the RTP traffic, any other way looks to me like unnecessary overhead.

AT this point given the amount of emails we exchange on the subject, I suggest we set a conf call to discuss the issue.

Zeev

-----Original Message-----
From: Roni Even [mailto:Even.roni at huawei.com]
Sent: Friday, June 26, 2009 10:59 AM
To: Zeev Vax; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'; avt at ietf.org
Subject: RE: [AVT] Port mappings, NAT, and RAMS

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