[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Comments on draft-johansson-avt-mcast-based-rams-01
Hi
Comments inline
Regards
/Ingemar
> ------------------------------
>
> Message: 2
> Date: Wed, 4 Nov 2009 09:10:39 -0800
> From: "Ali C. Begen (abegen)" <abegen at cisco.com>
> Subject: Re: [AVT] Comments on draft-johansson-avt-mcast-based-rams-01
> To: "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>,
> <avt at ietf.org>, <Even.roni at huawei.com>
> Message-ID:
>
> <04CAD96D4C5A3D48B1919248A8FE0D540A901F05 at xmb-sjc-215.amer.cisco.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> A few comments inline.
>
> > > In the last paragraph of section 2.1 you discuss timing
> > > between the main multicast session and the rapid stream. I am
> > > not sure how good it will work since the join request is not
> > > precise in term of timing.
> > Do you mean that the time between the leave and the join
> request is not
> > to be regarded as precise?. I can agree with this, however
> I don't know
> > if this is a big issue as one can always let the multicast
> based RAMS
> > stream run a little bit ahead to cope for the possible glitch.
>
> The only constraint here is the burst (unicast or multicast)
> cannot get ahead of the primary multicast stream.
OK, I believe one option that is discussed is to delay the primary mcast
stream slightly
>
> > Retransmission of missing packets is also an option if the glitch is
> > small.
>
> Indeed.
>
> > >
> > > The same goes for the suggestion to delay the multicast
> > > stream, I assume that this is an RS application decision but
> > > I think that there should be a warning that if the delay is
> > > too big it may cause the RR to send a retransmission request
> > > since it will think it lost a packet.
> > Do you mean a retransmitted RAMS-R ?, if this is the case
> then I beliee
> > the RS can simply ignore it.
>
> I suspect an RR implementing multicast-based RAMS should know
> that its request can be delayed more than the unicast RAMS
> case due to aggregation. So, it should wait more before
> re-sending its request.
Sounds reasonable
>
> Note that in neither approach, if RR has not received
> anything yet from RS, it cannot ask for a regular
> retransmission since it has no idea of what to request. It
> can either re-send its RAMS-R or simply give up and join the
> primary session.
>
> Requesting retransmission for the missing burst packets
> becomes an option only after RR received a burst packet.
OK
>
> > If it is retransmission requests for missing packets then I
> am not sure
> > why this would happen.
> >
> > >
> > >
> > >
> > > In 2.2.1 you have an Ed note about using SDP but RAMS-R is
> > > from the RR which does not send an SDP. The RAMS work using
> > > declarative SDP from the RS
>
> Minor point: RS does not necessarily generate the SDPs for RRs.
OK, but in some sense whatever entity creates the SDP must know about
the capabilities of the RS
>
> > Understood. The point I was trying to make is that it may
> be sufficient
> > that the RR sticks to what is specified in the declarative
> SDP from the
> > RS. Still I see the possibility that the RR may implement
> e.g dual IP
> > stacks and can then indicate support for IPv6 even though
> the SDP only
> > indicates support for IPv4, this may be far-fetched though..
>
> The simplest solution here is to assign the mcast
> addresses/ports for the multicast-RAMS sessions in the SDP.
> So, RRs implementing multicast-RAMS would already know the
> address/port information.
OK, this is inline with the labeling approach proposed by Roni or ?
could be an option
>
> >
> > >
> > >
> > >
> > > In 2.2.2 the RS sends the multicast address in the RTCP
> > > message. I think we discussed this in port mapping and there
> > > was some consensus that RTCP should not be used to convey
> > > addresses. Maybe the RS can allocate the addresses in the SDP
> > > and in the RTCP just provide a label to the group
> > If I recall this correctly (sorry, have not been able to follow this
> > dicussion in detail) this is related to NAT traversal issues. The
>
> Nat traversal is part of the discussion. The more general
> problem is how we can allow RRs to choose their own ports in
> the retransmission/RAMS sessions.
OK, I have some extra homework to catch up here.
>
> -acbegen
>
> > multicast based RAMS differs in the aspect that the RR
> actively joins
> > the said address. On the other hand the SDP alternative you describe
> > above may also be an option esp. as I believe that this
> schema is most
> > attractive for the most popular channels.
> > >
> > >
> > >
> > > Regards
> > >
> > > Roni Even
> > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:
> > > <http://www.ietf.org/mail-archive/web/avt/attachments/20091101
> > /e1c983b5/attachment.htm>
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt at ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> > > End of avt Digest, Vol 67, Issue 1
> > > **********************************
> > >
> > _______________________________________________
> > 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
>
>
> End of avt Digest, Vol 67, Issue 4
> **********************************
>