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

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 3 Nov 2009 09:37:20 +0100

Hi

And thanks for the comments, answers inline below.
Regards
Ingemar

> 
> Hi Ingemar,
> 
> I read the draft, I am not sure how simple this option is but 
> first I have some general comments
> 
>  
> 
> 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.
Retransmission of missing packets is also an option if the glitch is
small.

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

> 
>  
> 
> 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
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 67, Issue 1
> **********************************
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 4 Nov 2009 09:10:39 -0800

A few comments inline.

> 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

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

> > declarative SDP from the RS

Minor point: RS does not necessarily generate the SDPs for RRs.

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

> 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