Subject: Re: [AVT] Fwd: Retransmission and fast channel change with usage ofRTP/RTCP

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Mar 2008 16:48:34 +0000

Jose,

[catching up on old email]

On 21 Feb 2008, at 15:27, Jose Rey wrote:
> Hi Colin, hi all,
>
> regarding retransmission: DVB is currently developing a solution  
> for retransmission in VoD and live multicast IPTV services. The  
> unicast VoD scenario is rather simple. The multicast one isn't,  
> thus we would like to ask the community for feedback.
>
> The multicast solution is based on the draft specifying unicast  
> feedback for SSM. We intend to use up to two SSM sessions (one for  
> media, one optional for repair) plus one unicast repair session per  
> receiver. The Distribution Source of the media session would be the  
> network provider's head end. The Distribution Source of the repair  
> session is the "retransmission proxy", typically located very near  
> to the customer, usually at the (IP)-DSLAM. The repair session is  
> used to mitigate correlated packet losses, affecting one or several  
> hundreds of users. Finally, the Feedback Target is also co-located  
> with the retransmission proxy.
>
> In the typical scenario as above, the correlated losses happen  
> upstream of the retransmission proxy, e.g., due to L2 protection  
> switching. These losses are critical, as they can cause NACK  
> storms. In order to avoid these, an RTP client is placed halfway  
> down the of the media SSM tree, thus detecting and reporting packet  
> losses. "Halfway" means, in practice, at the retransmission proxy.  
> So, in the end, we have a retransmission proxy that detects and  
> reports upstream packet loss, hosts the feedback target, and serves  
> retransmissions (both unicast and multicast). Each being a  
> different logical entity with a different SSRC.

Seems like a reasonable approach.

> Now, since the RTP client at the retransmission proxy cannot send  
> its NACK in the media SSM group, it is proposed to send these in  
> the *repair* SSM through its Distribution Source, i.e. the  
> retransmission server, either as RFC-4585-NACKs or in summarized  
> RSI form. However, by doing this, we are mixing the SSRC spaces of  
> two different (but associated) sessions. Also the retransmission  
> client doesn't know what to do with this feedback as it would just  
> think the NACK is from another *repair* client.

You probably want to exchange RTCP information, so that all the  
devices see the full SSRC space, making this one RTP session.

> A proposed solution for indicating the repair client what to do  
> with this forwarded NACK would be to use an additional SDP  
> attribute listing the SSRC of the RTP client (we would indicate the  
> SSRCs of the retransmission proxy and feedback target as well). The  
> repair clients would then know, by looking at the SSRCs that it is  
> a forwarded NACK from the media SSM and that they must forward it  
> to the media client for NACK damping. The appropriate semantics  
> would probably have to be writen down in an I-D.

Explicit SDP signalling of the different roles, addresses, and SSRC  
values used would seem to be a good thing. It might also be possible  
to include role hints in-band in RTCP packets, although we'd need to  
think through the implications of that.

> Now, that's one scenario. Another one, though less common, is where  
> losses happen dowstream of the retransmission proxy, where it  
> cannot detect them. We are still thinking about a solution for that.

You mean correlated loss downstream of the retransmission proxy?

> We would welcome feedback on this proposal or similar work being  
> done elsewhere. If anyone has a better idea, we would of course  
> consider it.
>
> Thanks,
> José for Tom, Jeff and myself

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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Jose Rey" <[email-masked]>
Date: Tue, 25 Mar 2008 16:53:46 +0100

Colin,

thanks for your feedback. Inline...

[...]
> 
> > Now, since the RTP client at the retransmission proxy 
> cannot send its 
> > NACK in the media SSM group, it is proposed to send these in the 
> > *repair* SSM through its Distribution Source, i.e. the 
> retransmission 
> > server, either as RFC-4585-NACKs or in summarized RSI form. 
> However, 
> > by doing this, we are mixing the SSRC spaces of two different (but 
> > associated) sessions. Also the retransmission client 
> doesn't know what 
> > to do with this feedback as it would just think the NACK is from 
> > another *repair* client.
> 
> You probably want to exchange RTCP information, so that all 
> the devices see the full SSRC space, making this one RTP session.

We definitely want to avoid forwarding RTCP information from every single user either in either
'reflection' or 'summarized' mode into the repair session. That is, in part, the reasoning behind the out-of-band definition of who is who in the 'session', as below. It can be a lot of information, which is not really necessary for running IPTV. Is this exchange a prerequisite for forming a valid 'session'? I mean, RTCP receiver bandwidth and session group size can be communicated via SRB messages and RTCP for repair clients is probably going to be 'off', anyway.

> 
> > A proposed solution for indicating the repair client what 
> to do with 
> > this forwarded NACK would be to use an additional SDP attribute 
> > listing the SSRC of the RTP client (we would indicate the 
> SSRCs of the 
> > retransmission proxy and feedback target as well). The 
> repair clients 
> > would then know, by looking at the SSRCs that it is a 
> forwarded NACK 
> > from the media SSM and that they must forward it to the 
> media client 
> > for NACK damping. The appropriate semantics would probably 
> have to be 
> > writen down in an I-D.
> 
> Explicit SDP signalling of the different roles, addresses, 
> and SSRC values used would seem to be a good thing. It might 
> also be possible to include role hints in-band in RTCP 
> packets, although we'd need to think through the implications of that.

I think the first option is the preferred one. What would be the advantages of the second?

> > losses happen dowstream of the retransmission proxy, where 
> it cannot 
> > detect them. We are still thinking about a solution for that.
> 

Yes. For that, we are planning on distributing a polling mask, much like in PGM: a group of selected users has the 'privilege' to report in advance during a period when noone else is allowed to do it. The proxy then infers whether it is affecting a lot or just a few users (mcast or unicast retransmission).

Cheers,

José

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Colin Perkins <[email-masked]>
Date: Wed, 26 Mar 2008 23:02:03 +0000

Jose,

On 25 Mar 2008, at 15:53, Jose Rey wrote:
>>> RSI form. However, by doing this, we are mixing the SSRC spaces  
>>> of two different (but associated) sessions. Also the  
>>> retransmission client doesn't know what to do with this feedback  
>>> as it would just think the NACK is from another *repair* client.
>>
> We definitely want to avoid forwarding RTCP information from every  
> single user either in either 'reflection' or 'summarized' mode into  
> the repair session. That is, in part, the reasoning behind the out- 
> of-band definition of who is who in the 'session', as below. It can  
> be a lot of information, which is not really necessary for running  
> IPTV. Is this exchange a prerequisite for forming a valid  
> 'session'? I mean, RTCP receiver bandwidth and session group size  
> can be communicated via SRB messages and RTCP for repair clients is  
> probably going to be 'off', anyway.

They need to share an SSRC space for it to be a single RTP session.  
If you can do that via out-of-band signalling, fine. My gut feeling,  
though, is that it might make sense to specify that full RTCP is  
distributed to every device in the session, to allow for future  
extensibility (there's no point forwarding RTCP into the repair  
session, since that would just loop it back to the receivers that  
generated it, but I think it does make sense that the retransmission  
proxies see the full RTCP).

>>> A proposed solution for indicating the repair client what to do with
>>> listing the SSRC of the RTP client (we would indicate the SSRCs  
>>> of the
>>> retransmission proxy and feedback target as well). The repair  
>>> clients
>>> would then know, by looking at the SSRCs that it is a forwarded NACK
>>> from the media SSM and that they must forward it to the media client
>>> for NACK damping. The appropriate semantics would probably have  
>>> to be
>>> writen down in an I-D.
>>
>> Explicit SDP signalling of the different roles, addresses, and  
>> SSRC values used would seem to be a good thing. It might also be  
>> possible to include role hints in-band in RTCP packets, although  
>> we'd need to think through the implications of that.
>

I'm not sure, but there do seem to be a lot of proposals for using  
RTCP in middleboxes (both for these IPTV applications, and for  
monitoring parts of VoIP systems). I'm wondering if it would be  
useful to explicitly identify various devices as middleboxes within  
RTCP, rather than other participants having to infer that.

>>> Now, that's one scenario. Another one, though less common, is  
>>> where losses happen dowstream of the retransmission proxy, where  
>>> it cannot detect them. We are still thinking about a solution for  
>>> that.
>>
> Yes. For that, we are planning on distributing a polling mask, much  
> like in PGM: a group of selected users has the 'privilege' to  
> report in advance during a period when noone else is allowed to do  
> it. The proxy then infers whether it is affecting a lot or just a  
> few users (mcast or unicast retransmission).

Something like this? http://citeseer.ist.psu.edu/bolot94scalable.html  
That might be a useful thing to standardise as an AVPF extension.

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

---

From: <[email-masked]>
Date: Thu, 27 Mar 2008 23:39:37 +0200

Hi,

It's somehow funny for a co-author to send comments to the reflector.
However, as people interested in the draft know, we authors have deep
disagreement regarding this issue of decoding order recovery for session
multiplexing, and the issue has made the progress of this work very slow
for quite some time. I hope public discussions could be more helpful for
the group (i.e. AVT) to have a better common understanding of the issue.

Here are some comments to subsection 8.1.1 in draft-ietf-avt-rtp-svc-08,
titled "The Classical RTP Decoding Order Recovery Mode". Basically I
don't understand many details of the process described in the draft -
for those I could guess I have made some suggestions below on how to
improve the description. 

1. In the following copied text, NTP timestamps of NAL units or
operation point representations are mentioned. However, NAL units are
not directly assoicated with NTP timestamps, which are only directly
assoicated with RTCP SRs. The NTP timestamp for each NAL unit must be
defined.

"o NAL units with the same (RTP or NTP) timestamp are grouped in
decoding order to operation point representations in each RTP stream.

o Operation point representations with the same (NTP) timestamp  SHALL
be grouped to access units in order of the SVC RTP session dependency,
from lowest to highest."

2. Informative example, paragraph 1. The following sentence mentions
different session jitters. How are different session jitters seen from
the figure (and the description)?

"Figure 2. shows an example for buffering with different jitter between
sessions, i.e. at buffering startup not all packets of the same time
instance are available."

3. Informative example, paragraph 2. The first sentence says "The
process first proceeds to TS [8] and remove/ignore all preceding NAL
units in each of the buffers of RTP session A,B, and C." 
3.1. How does the process know that it proceeds to TS[8] and start
removing/ingoring stuff? Is it because that TS[8] is the first access
unit appearing in the buffer that has packets in all the sessions? If
yes, say so in the draft. 
3.2 This part of the process indicates that in the process additional
buffer is needed for each of the sessions to enable the finding of this
first access unit. 
3.3. In "and remove all preceding NAL units ...", "preceding" means in
what order (decoding order, presentation order or transmission order)? 
3.4. What are "the buffers"? Are they something that should be specified
by this document or they are implementation issues hence no need to be
specified? If implementation issue, what additional buffer sizes an
implmentation should typically prepare for this purpose?

4. Informative example, paragraph 2, sentence 2 (copied below). Wasn't
TS[1] removed accroding to the first sentence in this paragraph? If not,
which NAL units were actually removed by the first sentence in this
example?

"Then starting from session C, the first timestamp available in decoding
order (TS [1]) is selected and all operation point representations in
lower RTP sessions A and B are moved in order of the RTP session
dependency (in the example form session A -> B -> C) into the decoder."

5. Informative example, paragraph 2. Sentence 3 says "Then the next
timestamp in the highest RTP session C is selected and the process
described above is repeated."  The next timestamp in what order
(decoding order, presentation order or transmission order, or increasing
or decreasing of NTP timestamp order)?

6. Informative example, paragraph 2. Sentence 4 starts with "In case of
"real" packet loss at TS[4] and TS[2], ..." 
6.1. "packet loss" ->  "packet losses"?
6.2. Packet losses of which of the RTP sessions? Maybe it is easier to
list exactly which NAL units are lost.

7. I think the half-finished sentence "Decoding order and dependency of
NAL units per received RTP session with different jitter in sessions at
buffering startup time:" are there above Figure 2 should be removed or
better phrased. 

BR, YK

---

From: Colin Perkins <[email-masked]>
Date: Thu, 27 Mar 2008 21:54:00 +0000

On 27 Mar 2008, at 21:39, <[email-masked]> wrote:
...
> assoicated with RTCP SRs. The NTP timestamp for each NAL unit must be

The RTCP SR packets define the mapping between the two timelines,  
allowing you to directly derive the NTP timestamps from the RTP  
timestamps in each session. This is the standard RFC 3550 semantics:  
nothing specific to this format needs to be defined.

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

---

From: <[email-masked]>
Date: Fri, 28 Mar 2008 00:10:09 +0200

>The RTCP SR packets define the mapping between the two 
>timelines, allowing you to directly derive the NTP timestamps 
>from the RTP timestamps in each session. This is the standard 
>RFC 3550 semantics:  

By defining I meant adding something saying that the NTP timestamp is
derived for each packet (according to RFC 3550) and each NAL unit's NTP
timestamp is equal to the NTP timestamp of the packet the NAL unit is
carried in. This makes the description better, and I think it is aligned
with what you said above. 

BR, YK

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 28 Mar 2008 11:12:35 +0300

YK,
You are talking about a single stream and this is standard RFC 3550. If
you want it some place add it to RFC 3984 but I would say that no
payload mention it.
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-
> [email-masked]
> Sent: Friday, March 28, 2008 12:10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVT] Some comments to subsection 8.1.1
indraft-ietf-avt-rtp-
> svc-08

---

From: <[email-masked]>
Date: Fri, 28 Mar 2008 12:26:23 +0200

Roni,

But we are talking about session multiplexing, not about a single
stream. 

BR, YK 

>From: ext Even, Roni [mailto:[email-masked]] 
>Sent: Friday, March 28, 2008 10:13 AM
>To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
>Cc: [email-masked]
>Subject: RE: [AVT] Some comments to subsection 8.1.1 
>indraft-ietf-avt-rtp-svc-08
>
>YK,
>You are talking about a single stream and this is standard RFC 
>3550. If you want it some place add it to RFC 3984 but I would 
>say that no payload mention it.
>Roni
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 28 Mar 2008 10:38:46 +0000

Ye-Kui,

Synchronisation and timestamp mapping across sessions is a standard  
part of RTP. Again, no new mechanisms are needed.

Colin

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

---

From: <[email-masked]>
Date: Fri, 28 Mar 2008 16:32:23 +0200

Colin,

Thanks. And I agreed with you - I did not suggest the need of new
mechanisms below. What I suggested is just a small editorial
improvement. 

BR, YK 

>From: ext Colin Perkins [mailto:[email-masked]] 
>Sent: Friday, March 28, 2008 12:39 PM
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [email-masked]; [email-masked]
>Synchronisation and timestamp mapping across sessions is a 
>standard part of RTP. Again, no new mechanisms are needed.
>
>Colin
>
>
>
>>> You are talking about a single stream and this is standard 
>RFC 3550. 
>>> If you want it some place add it to RFC 3984 but I would 
>say that no 
>>> payload mention it.
>>> Roni
>>>

---

From: Randell Jesup <[email-masked]>
Date: Fri, 28 Mar 2008 11:16:18 -0400

>part of RTP. Again, no new mechanisms are needed.

It is standard, but its use in SVC is slightly unusual, since normally
there's an assumption in RFC 3550 that there can be timestamp drift between
two RTP streams, even if they come from the same source (and normally you
don't really know where they come from).  For example, with two audio
channels, both at 8000Hz sampling, both from the same endpoint, you'll get
RTCPs that lock both of their RTP timestamps to NTP - but the two streams
could drift relative to each other, because they might be sampled off
different clocks/crystals/devices.

In SVC, there's an additional constraint that all the related streams are
based off the same sampling timeline and clock, then converted to RTP
timestamps for each stream.  The timestamps (per RFC 3550) should have
random startpoints, but the RTCP packets will (once received!!) lock the
streams together, with no drift.

I would expect it makes sense to have about one sentence mentioning that
the base NAL sampling times used to generate the RTP timestamps all come
from the same source timeline, since that's not normally a constraint in
3550.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)