[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

To: 'Zeev Vax' <zeevvax at microsoft.com>, "'Bill Ver Steeg (versteb)'" <versteb at cisco.com>, "'Ali C. Begen (abegen)'" <abegen at cisco.com>, 'VAN CAENEGEM Tom' <Tom.Van_Caenegem at alcatel-lucent.be>, avt at ietf.org
Subject: Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
From: Roni Even <Even.roni at huawei.com>
Date: Thu, 18 Jun 2009 12:50:08 +0300
Delivered-to: avt at core3.amsl.com
In-reply-to: <3B2FD2F513F8E1468C1A9FAE0C61BF2F1174CCA3 at tk5ex14mbxc105.redmond.corp.microsoft.com>
List-archive: <http://www.ietf.org/mail-archive/web/avt>
List-help: <mailto:avt-request@ietf.org?subject=help>
List-id: Audio/Video Transport Working Group <avt.ietf.org>
List-post: <mailto:avt@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
References: <mailman.10085.1245185397.4936.avt at ietf.org> <238382595265324EA50F6134BB42DCAF04046DCF at FRVELSMBS22.ad2.ad.alcatel.com> <015d01c9ef3e$13f25830$3bd70890$%roni at huawei.com> <238382595265324EA50F6134BB42DCAF040470B3 at FRVELSMBS22.ad2.ad.alcatel.com> <04CAD96D4C5A3D48B1919248A8FE0D54098D86E4 at xmb-sjc-215.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE910174E7C8 at xmb-rtp-21d.amer.cisco.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F1174CCA3 at tk5ex14mbxc105.redmond.corp.microsoft.com>
Thread-index: AcnuxB26XvRkvXRRTni4MNRgozvTWAAWU97gAAeQjdAAAolg4AAD9PPQAAKwHzAAAoEH4AAj0yqg

Zeev,
This is a question I had in the past. I think that it merits a separate
thread in order to get a consensus on the issue. Mandating RTP/RTCP
multiplexing for the unicast burst make it simpler and faster to start. 

Note the two ports may still be used for the retransmission case.

Roni



> -----Original Message-----
> From: Zeev Vax [mailto:zeevvax at microsoft.com]
> Sent: Wednesday, June 17, 2009 7:45 PM
> To: Bill Ver Steeg (versteb); Ali C. Begen (abegen); VAN CAENEGEM Tom;
> Roni Even; avt at ietf.org
> Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-
> acquisition-for-rtp-01
> 
> The text proposal looks fine to me.
> I don't think we should mandate support both, this would cause extra
> work in implementation of a solution, and I can't see any benefit.
> Giving that this is UDP traffic port muxing is a subset of separate
> ports, so we can mandate port muxing, and make optional the separate
> ports.
> 
> Zeev
> 
> 
> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> Sent: Wednesday, June 17, 2009 8:40 AM
> To: Ali C. Begen (abegen); VAN CAENEGEM Tom; Roni Even; avt at ietf.org;
> Zeev Vax
> Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-
> acquisition-for-rtp-01
> 
> Tom-
> 
> These words looks good to me as well, with the following clarification.
> 
> We do need to consider how we handle RTP/RTCP port muxing throughout
> the
> document, and make the wording consistent wherever we reference the
> ports in use. I am in favor of allowing (but not mandating) the RR to
> signal RTP/RTCP port muxing. This would require the RS to support both
> methods. This is just my opinion, and we need to come to consensus on
> this matter.
> 
> 
> Bill VerSteeg
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Wednesday, June 17, 2009 10:15 AM
> To: VAN CAENEGEM Tom; Roni Even; avt at ietf.org
> Subject: Re: [AVT] comments on
> section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> The proposed text looks good to me. We should probably put the burst
> and
> retransmission sources in the same block in Figure 2 as well.
> 
> -acbegen
> 
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> > VAN CAENEGEM Tom
> > Sent: Wednesday, June 17, 2009 5:23 AM
> > To: Roni Even; avt at ietf.org
> > Subject: Re: [AVT] comments on section
> > 10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> >
> >
> >  Hi Roni,
> >
> > Perhaps the start of section 6.2 can be rewritten as follows:
> >
> >
> > <START>
> >
> > 6.2.  Message Flows
> >
> >    Figure 2 shows the main entities involved in rapid acquisition:
> >
> >    o  Multicast Source
> >
> >    o  Feedback Target (FT)
> >
> >    o  Burst/ Retransmission Source
> >
> >    o  RTP Receiver (RR)
> >
> > (fig 2)
> >
> >
> > The feedback target (FT) is the entity as defined in [rtcpssm draft],
> > to which the RR sends its RTCP FB messages, indicating packet loss in
> > the ssm primary stream by means of a NACK or indicating the RR's
> > desire to have rapid acquisition of the ssm primary stream (by means
> > of an RTCP FB message as defined in this document). While the
> > burst/retransmission source is responsible for responding on these
> > messages and, in the case of rapid acquisition, further RTCP
> > interaction with the RR during this acquisition process, it is
> assumed
> 
> > in the remainder of the document that these two logical entities (FT
> > and burst/retransmission source) are combined in a single physical
> > entity and share state. In the remainder of the text, the term
> > retransmission server is used whenever appropriate, to refer to the
> > combined functionality of the FT and retransmission/burst source.
> > However, it must be noted that only the FT is involved in the primary
> > ssm RTP session, whereas the burst/retransmission source transmits
> > unicast RTP burst and RTP retransmissions packets (both formatted  as
> > RTP retransmission packets
> > [RFC4585]) in a single separate unicast RTP retransmission session to
> > each RR.
> >
> > Note also that the same method (with the identical message flows)
> > would also apply in a scenario where rapid acquisition is performed
> by
> 
> > a feedback target co-located with the media source.
> >
> > (...)
> >
> > <END>
> >
> > Tom: As we mandate the retransmission source and burst source to be
> in
> 
> > the same session, I think it is no longer required to split-up among
> > these two logical entities. I invite other people, including the
> > co-authors to comment on this new text proposal.
> >
> > With respect to your comments on the RTP/RTCP port muxing support
> > indication by the RR inside the RAMS-R message. That would be needed,
> > but is not sufficient as, if only declarative SDP is used, and we
> want
> 
> > to have the possibility that the RTP/RTCP packets in the
> > retransmission session can be received by the RR on the same port the
> > RR issues the RTCP RAMS-R, we need also a way by which the RR can
> > signal this too. We provided a possible solution in the draft, but I
> > understood that you think such a solution should be proposed in a
> separate draft proposal?
> > But I guess that would also apply then to the signaling of support
> for
> 
> > RTP/RTCP port muxing by the RR?
> >
> > Tom
> >
> > -----Original Message-----
> > From: Roni Even [mailto:Even.roni at huawei.com]
> > Sent: woensdag 17 juni 2009 13:24
> > To: VAN CAENEGEM Tom; avt at ietf.org
> > Subject: RE: [AVT] comments on section 10
> > ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> >
> > Tom,
> > I understand the RAMS-R and RAMS-T, the text is not clear enough in
> > section
> > 6.2
> >
> > It still leaves open the issue of the addresses for the RR in the
> case
> 
> > of declarative SDP when there is no answer SDP from the RR.
> >
> > About RTP/RTCP multiplexing, the declarative SDP can show that the RS
> > supports it and I still think that some information about the
> > addressing (like support for RTP/RTCP mux) should be supplied in the
> > RAMS-R for the declarative case.
> >
> > Roni
> >
> > > -----Original Message-----
> > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf
> > > Of VAN CAENEGEM Tom
> > > Sent: Wednesday, June 17, 2009 11:17 AM
> > > To: avt at ietf.org
> > > Subject: Re: [AVT] comments on section 10 of draft-ietf-avt-rapid-
> > > acquisition-for-rtp-01
> > >
> > > Hi Roni,
> > >
> > > I think your understanding was indeed different from the general
> > >assumptions in this draft. Previously we agreed to only consider the
> > >case where there is only one physical entity involved (called the
> > >Retransmission Server in the draft), which allows us to NOT consider
> > >and  discuss cases where for instance the feedback target (which is
> > >defined  in the rtcpssm draft/RFC) is not in the same box as the
> > >retransmission  source or burst source, the entities sourcing
> > >retransmision/burst  packets. In that case we then would also need
> to
> 
> > >describe how these  separate entities communicate.
> > > The fact that these different entities are now in the same box does
> > >not  necessarily mean that all interactions and data exchange with
> > >the RRs  is  part of the same RTP session, which is in this case the
> > >SSM RTP  session.
> > > As Ali explained, the NACK and RAMS-R RTCP FB messages are directed
> > >to
> >
> > >the FB target, where we do not  defer from the rtcpssm draft. The
> RTP
> 
> > >retransmission/burst packets that are sent as a response to the NACK
> > >and  the RAMS-R can be either session multiplexed with respect to
> the
> 
> > >original SSM RTP session or SSRC muxed (same session), following RFC
> > >4588.
> > >As the retransmission packets in this case are addressing the RR  in
> > >unicast, we obviously have a dedicated RTP session for the
> > >retransmission/burst packets. We had some internal discussion on
> > >whether  considering the use case of having a separate session
> > >between RS and RR  for RTP retransmission packets triggered by an
> > >RTCP FB NACK and a  separate session for RTP burst packets triggered
> > >by an RTCP RAMS-R made  sense, but we ended up agreeing that
> allowing
> 
> > >a single session was the  easiest way out, without imposing serious
> > >limitations to the general  architecture.
> > >
> > > This means that the ports used by the (single) RTP
> > > retransmission/burst session are in principle decoupled from the
> > > primary SSM session. Hence if an RR wants to receive the
> > > burst/retransmission packets and associated RTCP messages on the
> > > same port the RR sent out the RTCP RAMS-R/ NACK FB messages, this
> > > should either be signaled by the RR, OR such port usage scheme is
> > > considered the "default" case -which also means the RR supports
> > > RTP/RTCP port muxing for the retransmission/burst session-, and
> then
> 
> > > the RR needs to
> >
> > > signal the ports for receiving the RTP and RTCP packets in the
> > > retransmission session when it requires dedicated ports.
> > >
> > > The RAMS-I (RS-> RR) and RAMS-T (RR-> RS) messages are only
> relevant
> 
> > > to a specific RR requesting the RTP burst stream and the RS, and
> > > carry
> >
> > > information/signaling related to the retransmission/burst session
> > > and have nothing to do with the SSM session. Hence the FB target as
> > > logical entity is not involved here.
> > >
> > > I hope this clarifies rather than it contributes to your confusion.
> > > But we may need to rephrase the part you quoted, as your
> > > interpretation was different from its intended meaning. We also
> > > tried to be more explicit in which session which RAMS or other RTCP
> (e.g.
> > > Bye) messages needed to be exchanged compared to a previous version
> > > of
> >
> > > the draft, but we are open of course to any other suggestions from
> > > your side if this is not clear enough in your opinion.
> > >
> > > Tom
> > >
> > >
> > >
> > >
> > >
> > >
> > > " A Retransmission Source may equally act as a Burst Source.  The
> > >    Retransmission Source may also incorporate the Feedback Target
> > >    ([I-D.ietf-avt-rtcpssm] permits the feedback target to be a
> > >    retransmission server, since it is a logical function to which
> RRs
> > >    send their unicast feedback), and we will use the term
> > > Retransmission
> > >    Server (RS) in the remainder of the document to refer to a
> single
> > >    physical entity comprising these three entities that share
> state.
> > >    Note that the same method (with the identical message flows)
> would
> > >    also apply in a scenario where rapid acquisition is performed by
> a
> > >    feedback target co-located with the media source."
> > >
> > > I assumed that we are only dealing with the case that the RS is a
> > > single entity and not three different entities with different
> > > addresses
> > >
> > > I also thought that this was agreed in previous discussions
> > >
> > > If my understanding is not correct I will review the draft since
> the
> 
> > > current text is not explicit enough to specify which part is doing
> > > each message. I saw that RAMS-R is going to feedback target but
> > > RAMS-T
> >
> > > is going to RS which is not specifying a specific address according
> > > to
> >
> > > you.
> > >
> > > Roni
> > >
> > > -----Original Message-----
> > > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > > Sent: Tuesday, June 16, 2009 10:00 PM
> > > To: Roni Even; avt at ietf.org
> > > Subject: RE: [AVT] comments on section 10
> > > ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> > >
> > > Remember that the RAMS-R (RR->RS) message is NOT on the
> > > retransmission
> > > (unicast) session, it's on the primary session since it is sent to
> > > the
> >
> > > feedback target of the primary SSM session. Thus, the source port
> RR
> 
> > > uses to send RAMS-R "cannot" be assumed to be the destination port
> > > it wishes to receive the unicast burst on.
> > >
> > > If you agree with this statement, it is clear why we need port
> > > signaling.
> > > Muxing will not help much here. It will just reduce the number of
> > > signaled ports from 2 to 1.
> > >
> > > -acbegen
> > >
> > >
> > > > -----Original Message-----
> > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf
> 
> > > > Of Roni
> > > Even
> > > > Sent: Tuesday, June 16, 2009 10:08 AM
> > > > To: avt at ietf.org
> > > > Subject: [AVT] comments on section 10
> > > ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> > > >
> > > > Hi,
> > > >
> > > > I looked at section 10 and have some comments
> > > >
> > > >
> > > >
> > > > 1.       If RTP/RTCP multiplexing is used, there is no need for
> any
> > > specific operation
> > > > from the RR side. The RR sends the RAMS-R message to the RS from
> > > > the
> >
> > > > port
> > > it wants to
> > > > receive the RAMS-I and RTP payload. The RS just sends the
> > > > information to
> > > the port from
> > > > which it received the RAMS-R and not to the one in the SDP
> > > >
> > > > 2.       In the case where there is no RTP/RTCP multiplexing, the
> > > RAMS-R
> > > RTCP message will
> > > > go to the RS and the RAMS-I will go to the port on the RR from
> > > > where
> >
> > > > the
> > > RAMS-R was
> > > > received. For the RTP, the RR does not know if it has a NAT on
> the
> > > way
> > >
> > > > to
> > > the RS and
> > > > should try to get a routable address (using STUN for example) and
> > > providing the port to
> > > > the RS ( we still need to agree on how to do it)
> > > >
> > > > 3.       If the above two points are correct than the RR receive
> > port
> > > in
> > > the SDP is not
> > > > really useful
> > > >
> > > >
> > > >
> > > > Roni Even
> > >
> > >
> > > _______________________________________________
> > > 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
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt

Follow-Ups:
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Zeev Vax

References:
- Re: [AVT] comments on section 10 of draft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: VAN CAENEGEM Tom
- Re: [AVT] comments on section 10 of draft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Roni Even
- Re: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: VAN CAENEGEM Tom
- Re: [AVT] comments on section 10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Ali C. Begen (abegen)
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Bill Ver Steeg (versteb)
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Zeev Vax

Prev by Date: Re: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Next by Date: Re: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Previous by thread: Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Next by thread: Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Index(es):
- Date
- Thread