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

From: Roni Even <[email-masked]>
Date: Sun, 01 Nov 2009 17:58:53 +0200

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.

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.

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

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

Regards

Roni Even

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 5 Nov 2009 10:19:43 +0100

Hi

Comments inline

Regards
/Ingemar

> ------------------------------
> 
> Message: 2
> Date: Wed, 4 Nov 2009 09:10:39 -0800
> From: "Ali C. Begen (abegen)" <[email-masked]>
> Subject: Re: [AVT] Comments on draft-johansson-avt-mcast-based-rams-01
> To: "Ingemar Johansson S" <[email-masked]>,
> 	<[email-masked]>, 	<[email-masked]>
> Message-ID:
> 	
> <[email-masked]>
> 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> > > End of avt Digest, Vol 67, Issue 1
> > > **********************************
> > >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 67, Issue 4
> **********************************
>