[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 Ali,
On 21 Jun 2009, at 20:39, Ali C. Begen (abegen) wrote:
Thanks for reading the draft. I am adding my comments below.
...
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?
Depending on what you're doing, I can see use cases for both compound
and non-compound packets. I'd suggest following the usual rules:
mandate compound, unless support for non-compound is signalled.
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.
I'm not sure saving FMT values is an issue, but okay.
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.
Delta time is easier, since you have to worry less about clock sync.
I tend to prefer RTP ticks rather than milliseconds, since the
receiver is guaranteed to have a clock running in RTP ticks, but the
main issue is consistency.
...
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?
Why do you need extended sequence numbers? It's not really a well-
defined concept across receivers in RTP.
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.
Sure, if it's missing, the RR will have to guess when to join the SSM
session. That's undesirable, but the RR will need that functionality
anyway. You gain nothing by making this a MUST, other than confusing
naive implementers into thinking they can assume this will always be
received.
Cheers,
--
Colin Perkins
http://csperkins.org/