[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: "Ali C. Begen (abegen)" <abegen at cisco.com>, Roni Even <Even.roni at huawei.com>, "Bill Ver Steeg (versteb)" <versteb at cisco.com>, VAN CAENEGEM Tom <Tom.Van_Caenegem at alcatel-lucent.be>, "avt at ietf.org" <avt at ietf.org>
Subject: Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
From: Zeev Vax <zeevvax at microsoft.com>
Date: Thu, 18 Jun 2009 21:58:09 +0000
Accept-language: en-US
Delivered-to: avt at core3.amsl.com
In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540995BF39 at xmb-sjc-215.amer.cisco.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> <025401c9effa$34040170$9c0c0450$%roni at huawei.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F15EC5C1E at tk5ex14mbxc105.redmond.corp.microsoft.com> <04CAD96D4C5A3D48B1919248A8FE0D540995BF39 at xmb-sjc-215.amer.cisco.com>
Thread-index: AcnuxB26XvRkvXRRTni4MNRgozvTWAAWU97gAAeQjdAAAolg4AAD9PPQAAKwHzAAAoEH4AAj0yqgABhckVAAAKI+MAAAgrDg
Thread-topic: [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

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
Sent: Thursday, June 18, 2009 2:46 PM
To: Zeev Vax; Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom; avt at ietf.org
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

Zeev,

I agree that mandating both is not a good idea. But, you should note that muxing does not solve our issues. So, mandating it will not be the cure for everything. See my email from Tuesday.

-acbegen

> -----Original Message-----
> From: Zeev Vax [mailto:zeevvax at microsoft.com]
> Sent: Thursday, June 18, 2009 2:27 PM
> To: Roni Even; Bill Ver Steeg (versteb); Ali C. Begen (abegen); 'VAN CAENEGEM Tom';
> avt at ietf.org
> Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
>
> Roni,
>
> As I said I support mandating the multiplexing, but not the multiple ports. If there are
> no other opinions, we can add that to draft.
>
> Zeev
>
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Thursday, June 18, 2009 2:50 AM
> To: Zeev Vax; 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom';
> avt at ietf.org
> Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
>
> 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:
- [AVT] Port mappings, NAT, and RAMS
  - From: Bill Ver Steeg (versteb)
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Ali C. Begen (abegen)

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
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Roni Even
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Zeev Vax
- Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
  - From: Ali C. Begen (abegen)

Prev by Date: Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Next by Date: Re: [AVT] comments on section10ofdraft-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