[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
Hi Colin,
Thanks for reading the draft. I am adding my comments below.
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Colin Perkins
> Sent: Sunday, June 21, 2009 4:54 AM
> To: Audio/Video Transport (AVT) WG
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
>
> On 16 Jun 2009, at 16:45, Internet-Drafts at ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Audio/Video Transport Working Group
> > of the IETF.
> >
> > Title : Unicast-Based Rapid Acquisition of Multicast RTP
> > Sessions
> > Author(s) : B. Steeg, et al.
> > Filename : draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
> > Pages : 41
> > Date : 2009-06-16
>
> I had some minor comments:
>
> Section 6: Do the RR and RS send the usual periodic RTCP reports on
> the retransmission session? I assume they do, but it'd be good to
> state that explicitly to avoid confusion.
Yes. We should add this.
> Section 7: Are the RAMS messages sent as part of compound RTCP
> packets, or is the non-compound extension assumed? I can see
> advantages to using compound packets, and it would be good if the
> draft explicitly stated that they were used, according to the usual
> rules.
We assumed compound packets so far. I believe we already have this in place. We will check again. But, do you think non-compound packets are useful for sending RAMS-R for example?
> Section 7: Have you considered using several feedback message type
> (FMT) values, one for each of the RAMS-R, RAMS-I, and RAMS-T messages,
> instead of a single value with subtypes? It's not clear that the extra
> level of indirection buys anything.
That was the initial plan and based on the feedback in the breakout session, we turned into this subtype format. For one thing, it saves FMT values. And expansion will be easier if new message formats need to be introduced in the future.
> Section 7.3: The Earliest Multicast Join Time and Burst Duration both
> specify times. The latter is specified in RTP clock units, the former
> says you need to decide between milliseconds and RTP clock units. It
> would make things easier for implementers if these were both the same.
There are still a few suggestions for this. ms vs RTP ticks is one issue, and delta time vs absolute time is another one. Currently, I am personally inclined to delta time signaled in RTP ticks since it can signal "join now" semantics. However, absolute time in RTP ticks would also be nice since it tells RR to join as soon as it sees a packet whose timestamp is equal to or higher than this value. Comments are welcome on this issue.
> Section 7.3: Is there any reason why a server would switch between
> supporting and not supporting updated requests within a single
> session? If not, then the S bit might be better signalled in the SDP,
> rather than in-band in each message.
That’s is a good suggestion. I don't think that is a dynamic feature and can be easily signaled in SDP.
> Section 7.3 and 7.4: It's not clear why extended RTP sequence numbers
> are used, since the top 16 bits are always zero.
This is an open issue. We are trying to figure out how to support extended seqnums. We may need an early sender report to figure this out. Suggestions?
> Section 7.3 "Note that if the RAMS requests has been accepted, RS MUST
> send this field as least once": Why is this a MUST? The RR must be
> able to work without this field, since the RAMS-I packet might be
> lost, so while I can see why this should be a SHOULD, I don't see the
> motivation for a MUST.
If RR is not told when to join SSM session, how is it supposed to know? You are right that RAMS-I may get lost, but in that case most likely the whole RAMS will fail. And at some point, RR will figure that out and join the SSM. However, if RAMS-I goes thru and the request was accepted, RR needs this info.
> Section 9: As I've mentioned off-line to the authors, I don't find
> this compelling.
I am hoping we will be able to find a good solution for this.
I will also let the co-authors comment on these comments.
Thanks again,
-acbegen
> Cheers,
> Colin
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt