Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 24 Apr 2009 12:36:26 +0200

Hi,

I have two questions/comments mostly regarding the RTCP-SSM draft
(http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background
of my questions is the use case of "broadcast channels" in an IPTV
context, where the channels are distributed over IP multicast (SSM). In
this context, the concept of feedback target(s) is obviously very
useful, and actually necessary given today's restrictions with multicast
in upstream in the "WAN". 

For the IPTV use case, it also makes sense to have multiple feedback
targets, each responsible for a subset of RTP receivers, because of the
large number of RTP receivers involved (100.000s is possible). The way
to signal this by means of SDP is that each local subset of RTP
receivers sees a different IP address in the "a=rtcp: "portnumber" IN
IP4 "IP address"  line.  So, multiple "localised" FT  is covered by the
draft IMO.

However, in that case, the maximum bandwidth that can be used for RTCP
reporting by RTP receivers only needs to be determined by the size of
the local group of RTP receivers (sending RTCP to the same localised
Feedback Target), especially in the summary FB model. But in my
interpretation of the architecture, the actual RTCP bandwith limit
information can only be retrieved by the RTP receivers from the
information sent by the distribution source in the ssm session. Either
by refected RTCP reports from RTP receivers (not a feasible solution for
the given use case) or from a RSI message -in the summary FB model-
indicating the session size or explicitly the RTCP reporting bandwidth
limit. The fact is that this information is sent to ALL RTP receivers,
which may be reporting to different Feedback targets where each Feedback
target is collecting RTCP messages from a different number of RTP
receivers, and hence may have different "requirements" for total RTCP
reporting bandwidth limit.  My question is whether local Feedback
targets have been considered with respect to this issue?

My second question again has to do with multiple feedback targets for
the same use case. 

In the IPTV use case for rtcpssm, Feedback Targets can also be used as
retransmission sources (RFC 4588) and in
http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-
rtp-03, the feedback target architecture is used to allow fast
acquisition of SSM RTP sessions. The draft proposes that  a "burst
source" is co-located with the FT which transmits unicast data (starting
with a random access point of the video channel) from a cache that holds
the most recent data distributed over the RTP SSM. It does transmit the
RTP packets at an accelerated speed, allowing the RTP receiver to join
the SSM after some time.

The idea I would like to bring forward is to allow separate Feedback
Targets  for the same RTP receiver (population): one Feedback target
acts as RTP retransmission server (see
http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-
rtp-03) and collects RTCP FB messages, while the other Feedback Target
is solely "responsible" for the non RTCP-FB messages, such as RTCP XR
messages. I realise this idea is not necessarily linked with  the
rtcp-ssm draft, but IMO only for a massive scale application that makes
use of RTP and leverages rtcp ssm such a separation is justified. The
possibility for separation of the monitoring service -associated with a
server function basically responsible for collecting RTCP receiver
reports for the purpose of monitoring- and the retransmission service
requiring a server function that is responsible for processing and
responding to RTCP FB messages, is driven from the point of view of
server function optimisation (different requirements on the server
platform). 

In terms of signaling two Feedback Targets, we could make use of the
following lines:

a=rtcp:40001 IN IP4 192.0.2.1 (This is for retransmission)
a=rtcp-fb:96 nack
a=rtcp:40001 IN IP4 192.0.2.2 (This is for XR collection)

However, that is probably quite ambiguous..?
Furthermore I also realise such a solution introduces other questions
than just signaling syntax including the fact that we may need guiding
rules on how RTCP reports are issued by the RTP receiver with two RTCP
targets in place, as in the example above. The new RFC 5506 is certainly
helpful here, but this is probably not sufficient. 
Comments appreciated on this idea.

Kind regards,
Tom Van Caenegem

---

From: "Roni Even" <[email-masked]>
Date: Tue, 28 Apr 2009 00:01:48 +0300

Tom,

I think this question should go to mmusic. What you are trying to do here is
to define semantics for the content of a RTCP flow pointing to different
devices. The m-line or the RTCP line in SDP does not address what is the
content of the stream that will go in the RTP session.  RFC 4796 addresses
the media content issue but you are looking for something similar to the
RTCP attribute. This may require a new parameter to the rtcp attribute. 

You will also need to look at backward interoperability where the receiver
will not understand this semantics and may change the RTCP message to the
wrong address. 

The example for the content attribute was to specify to video m-lines one
with screen capture as a video stream and the other from a camera. SDP does
not define the behavior of the receiver if it receives two m-lines of the
same media type and can only support one. It is not clear which one he will
chose (first or second). The work on capability negotiation tries to address
this issue.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN
CAENEGEM Tom
Sent: Friday, April 24, 2009 1:36 PM
To: [email-masked]
Subject: [AVT] Multiple Feedback Targets in "
http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

Hi, 

I have two questions/comments mostly regarding the RTCP-SSM draft (
<http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18>
http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background of my
questions is the use case of "broadcast channels" in an IPTV context, where
the channels are distributed over IP multicast (SSM). In this context, the
concept of feedback target(s) is obviously very useful, and actually
necessary given today's restrictions with multicast in upstream in the
"WAN". 

For the IPTV use case, it also makes sense to have multiple feedback
targets, each responsible for a subset of RTP receivers, because of the
large number of RTP receivers involved (100.000s is possible). The way to
signal this by means of SDP is that each local subset of RTP receivers sees
a different IP address in the "a=rtcp: "portnumber" IN IP4 "IP address"
line.  So, multiple "localised" FT  is covered by the draft IMO.

However, in that case, the maximum bandwidth that can be used for RTCP
reporting by RTP receivers only needs to be determined by the size of the
local group of RTP receivers (sending RTCP to the same localised Feedback
Target), especially in the summary FB model. But in my interpretation of the
architecture, the actual RTCP bandwith limit information can only be
retrieved by the RTP receivers from the information sent by the distribution
source in the ssm session. Either by refected RTCP reports from RTP
receivers (not a feasible solution for the given use case) or from a RSI
message -in the summary FB model- indicating the session size or explicitly
the RTCP reporting bandwidth limit. The fact is that this information is
sent to ALL RTP receivers, which may be reporting to different Feedback
targets where each Feedback target is collecting RTCP messages from a
different number of RTP receivers, and hence may have different
"requirements" for total RTCP reporting bandwidth limit.  My question is
whether local Feedback targets have been considered with respect to this
issue?

My second question again has to do with multiple feedback targets for the
same use case. 

In the IPTV use case for rtcpssm, Feedback Targets can also be used as
retransmission sources (RFC 4588) and in
<http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp
-03>
http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-
03, the feedback target architecture is used to allow fast acquisition of
SSM RTP sessions. The draft proposes that  a "burst source" is co-located
with the FT which transmits unicast data (starting with a random access
point of the video channel) from a cache that holds the most recent data
distributed over the RTP SSM. It does transmit the RTP packets at an
accelerated speed, allowing the RTP receiver to join the SSM after some
time.

The idea I would like to bring forward is to allow separate Feedback Targets
for the same RTP receiver (population): one Feedback target acts as RTP
retransmission server (see
<http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp
-03>
http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-
03) and collects RTCP FB messages, while the other Feedback Target is solely
"responsible" for the non RTCP-FB messages, such as RTCP XR messages. I
realise this idea is not necessarily linked with  the rtcp-ssm draft, but
IMO only for a massive scale application that makes use of RTP and leverages
rtcp ssm such a separation is justified. The possibility for separation of
the monitoring service -associated with a server function basically
responsible for collecting RTCP receiver reports for the purpose of
monitoring- and the retransmission service requiring a server function that
is responsible for processing and responding to RTCP FB messages, is driven
from the point of view of server function optimisation (different
requirements on the server platform). 

However, that is probably quite ambiguous..? 
Furthermore I also realise such a solution introduces other questions than
just signaling syntax including the fact that we may need guiding rules on
how RTCP reports are issued by the RTP receiver with two RTCP targets in
place, as in the example above. The new RFC 5506 is certainly helpful here,
but this is probably not sufficient. 

Kind regards, 
Tom Van Caenegem

---

From: Colin Perkins <[email-masked]>
Date: Wed, 29 Apr 2009 18:45:35 +0100

Roni,

The signalling aspects could certainly go to MMUSIC, and are probably  
not too difficult to address. The proposal also involves some  
potentially significant changes to the RTCP architecture, which should  
be considered in AVT (although hopefully as additional documents  
rather than being folded into the - already long overdue - rtcpssm  
draft).

Cheers,
Colin

On 27 Apr 2009, at 22:01, Roni Even wrote:
> Tom,
> I think this question should go to mmusic. What you are trying to do  
> here is to define semantics for the content of a RTCP flow pointing  
> to different devices. The m-line or the RTCP line in SDP does not  
> address what is the content of the stream that will go in the RTP  
> session.  RFC 4796 addresses the media content issue but you are  
> looking for something similar to the RTCP attribute. This may  
> require a new parameter to the rtcp attribute.
> You will also need to look at backward interoperability where the  
> receiver will not understand this semantics and may change the RTCP  
> message to the wrong address.
>
> The example for the content attribute was to specify to video m- 
> lines one with screen capture as a video stream and the other from a  
> camera. SDP does not define the behavior of the receiver if it  
> receives two m-lines of the same media type and can only support  
> one. It is not clear which one he will chose (first or second). The  
> work on capability negotiation tries to address this issue.
>
> Roni Even
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of VAN CAENEGEM Tom
> Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18 
> "
>
>
> Hi,
>
> I have two questions/comments mostly regarding the RTCP-SSM draft (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18 
> ). The background of my questions is the use case of "broadcast  
> channels" in an IPTV context, where the channels are distributed  
> over IP multicast (SSM). In this context, the concept of feedback  
> target(s) is obviously very useful, and actually necessary given  
> today's restrictions with multicast in upstream in the "WAN".
>
> targets, each responsible for a subset of RTP receivers, because of  
> the large number of RTP receivers involved (100.000s is possible).  
> The way to signal this by means of SDP is that each local subset of  
> RTP receivers sees a different IP address in the "a=rtcp:  
> "portnumber" IN IP4 "IP address"  line.  So, multiple "localised"  
> FT  is covered by the draft IMO.
>
> However, in that case, the maximum bandwidth that can be used for  
> RTCP reporting by RTP receivers only needs to be determined by the  
> size of the local group of RTP receivers (sending RTCP to the same  
> localised Feedback Target), especially in the summary FB model. But  
> in my interpretation of the architecture, the actual RTCP bandwith  
> limit information can only be retrieved by the RTP receivers from  
> the information sent by the distribution source in the ssm session.  
> Either by refected RTCP reports from RTP receivers (not a feasible  
> solution for the given use case) or from a RSI message -in the  
> summary FB model- indicating the session size or explicitly the RTCP  
> reporting bandwidth limit. The fact is that this information is sent  
> to ALL RTP receivers, which may be reporting to different Feedback  
> targets where each Feedback target is collecting RTCP messages from  
> a different number of RTP receivers, and hence may have different  
> "requirements" for total RTCP reporting bandwidth limit.  My  
> question is whether local Feedback targets have been considered with  
> respect to this issue?
>
> My second question again has to do with multiple feedback targets  
> for the same use case.
>
> In the IPTV use case for rtcpssm, Feedback Targets can also be used  
> as retransmission sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 
> , the feedback target architecture is used to allow fast acquisition  
> of SSM RTP sessions. The draft proposes that  a "burst source" is co- 
> located with the FT which transmits unicast data (starting with a  
> random access point of the video channel) from a cache that holds  
> the most recent data distributed over the RTP SSM. It does transmit  
> the RTP packets at an accelerated speed, allowing the RTP receiver  
> to join the SSM after some time.
>
> acts as RTP retransmission server (seehttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03) 
>  and collects RTCP FB messages, while the other Feedback Target is  
> solely "responsible" for the non RTCP-FB messages, such as RTCP XR  
> rtcp-ssm draft, but IMO only for a massive scale application that  
> makes use of RTP and leverages rtcp ssm such a separation is  
> justified. The possibility for separation of the monitoring service – 
> associated with a server function basically responsible for  
> collecting RTCP receiver reports for the purpose of monitoring- and  
> the retransmission service requiring a server function that is  
> responsible for processing and responding to RTCP FB messages, is  
> driven from the point of view of server function optimisation  
> (different requirements on the server platform).
>
> Furthermore I also realise such a solution introduces other  
> questions than just signaling syntax including the fact that we may  
> need guiding rules on how RTCP reports are issued by the RTP  
> receiver with two RTCP targets in place, as in the example above.  
> The new RFC 5506 is certainly helpful here, but this is probably not  
> sufficient.
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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