Re: [AVT] Comments on draft-johansson-avt-mcast-based-rams-01

["Ali C. Begen (abegen)" <abegen at cisco.com>]

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.

> 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.
 
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.

> 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.

> 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.

> 
> >
> >
> >
> > 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.

-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