Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

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

Hi Colin,

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

Sounds good to me.
 
> >> 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.

True but note that signaling a TS value and then asking RR to join right after he sees that TS value does not require clock sync. If there are no objections, we can go with the delta time.
 
> 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.

Agree.

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

What about the really high-bitrate streams where seqnum wrapping might be an issue during the course of unicast burst?

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

I see your point. SHOULD makes more sense.

Thanks,
-acbegen

 
> Cheers,
> --
> Colin Perkins
> http://csperkins.org/
> 
>