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

From: [email-masked]
Date: Tue, 16 Jun 2009 08:45:01 -0700 (PDT)

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

When an RTP receiver joins a primary multicast session, it may need
to acquire and parse certain Reference Information before it can
process any data sent in the multicast session.  Depending on the
join time, length of the Reference Information repetition interval,
size of the Reference Information as well as the application and
transport properties, the time lag before an RTP receiver can
usefully consume the multicast data, which we refer to as the
Acquisition Delay, varies and may be large.  This is an undesirable
phenomenon for receivers that frequently switch among different
multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay.  In this
method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the primary
multicast stream.  This unicast RTP flow may be transmitted at a
faster than natural rate to further accelerate the acquisition.  The
motivating use case for this capability is multicast applications
that carry real-time compressed audio and video.  However, the
proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a
problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 21 Jun 2009 12:54:03 +0100

>   Filename  : draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

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.

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.

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.

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.

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.

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.

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.

Section 9: As I've mentioned off-line to the authors, I don't find  
this compelling.

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 21 Jun 2009 12:39:42 -0700

Hi Colin,

Thanks for reading the draft. I am adding my comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 

Yes. We should add this.
 
> draft explicitly stated that they were used, according to the usual

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?

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

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

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

> 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?
 
> lost, so while I can see why this should be a SHOULD, I don't see the

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Mon, 22 Jun 2009 13:23:10 +0100

Hi Ali,

> Thanks for reading the draft. I am adding my comments below.
...
> 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.

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

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

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Jun 2009 08:52:11 -0700

Hi Colin,

> mandate compound, unless support for non-compound is signalled.

Sounds good to me.
 
> 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.
 
> main issue is consistency.

Agree.

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

> naive implementers into thinking they can assume this will always be

I see your point. SHOULD makes more sense.

Thanks,
-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Wed, 24 Jun 2009 09:53:33 +0100

Hi Ali,

On 22 Jun 2009, at 16:52, Ali C. Begen (abegen) wrote:
...
>>>> 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.
>>>
> What about the really high-bitrate streams where seqnum wrapping  
> might be an issue during the course of unicast burst?

Can't you use modulo arithmetic as usual? I don't see any issues,  
unless the RAMS-T is sent more than a full sequence number cycle ahead  
of time.

Cheers,
Colin

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 24 Jun 2009 10:57:31 -0400

Colin -

Thanks for the detailed feedback. I agree with Ali's responses. 

Regarding your last item - I agree that NAT presents some challenges in
this environment. We have recently sent an analysis of the NAT issues
described in sections 9 an 10 to the AVT list. We have tried to
summarize the 4 alternative NAT solutions that have been suggested,
showing the up-side and down-side of each. I would love to see a more
elegant solution to this dificult problem, and look forward to feedback
from the list.

Bill VerSteeg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Colin Perkins
Sent: Sunday, June 21, 2009 7:54 AM
To: Audio/Video Transport (AVT) WG
Subject: Re: [AVT] I-D
Action:draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

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.

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.

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.

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.

Section 9: As I've mentioned off-line to the authors, I don't find this
compelling.

Cheers,
Colin

--
Colin Perkins
http://csperkins.org/