Subject: [AVT] Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Jan 2007 14:42:58 +0000

On 29 Dec 2006, at 20:50, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: SubRTCP:RTCP Extension for Internal Monitoring of RTP  
> Sessions.
> 	Author(s)	: X. Xu, et al.
> 	Filename	: draft-xu-avt-subrtcp-00.txt
> 	Pages		: 13
> 	Date		: 2006-12-29
> 	
>    This document describes SubRTCP, an extension to RTCP.  SubRTCP
>    operates on the same underlying transport establishement as for  
> RTCP
>    but functions independently of the latter.  SubRTCP extends RTCP to
>    the middle nodes of an RTP session to allow monitoring of its data
>    delivery also at and between these middle nodes.  Such an internal
>    visibility provided by SubRTCP at the middle nodes complements the
>    delivery monitoring by RTCP at the endpoints particularly in  
> service
>    providers' interest.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-xu-avt-subrtcp-00.txt

I'm a little confused by this draft. It seems to be based on a  
misunderstanding that RTCP only operates between end systems, and  
cannot be sent by middleboxes. That is incorrect: RFC 3550 explicitly  
allows middleboxes to send RTCP reports, which can be used to monitor  
the quality of the session as seen within the network (see section 7  
of RFC 3550). As such, the S-RR packet type is redundant, since  
middleboxes can send regular RR packets containing the same information.

Something like the S-TS packet may be required if there is a need to  
determine the round-trip time between middleboxes that aren't sending  
their own RTP data packets (and so won't send RTCP SR packets). That  
can be a regular RTCP packet type, rather than part of a "subRTCP"  
protocol, however.

Some requirements discussion is probably needed, before trying to  
architect a solution like this.

Colin

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

---

From: "Hideaki YAMADA" <[email-masked]>
Date: Fri, 12 Jan 2007 01:31:41 +0900

Hi Xiaode,

Most multimedia sessions over IP-based networks use RTP. 
Furthermore, the RTCP-XR and the RTCP-HR provide useful monitoring 
and diagnosis of VoIP performance between the endpoints. 

The behavior of IP packet transmissions over mobile networks 
differs from that of fixed networks.
Your proposed scheme could support a procedure for reporting the 
quality condition of a portion of end-to-end IP networks, such as 
the Fixed and Mobile Convergence (FMC) networks. 
We are studying a similar scheme called Multi-RTCP scheme.

Do you have any specifications to start the trigger of the subRTCP
at the middle nodes which you defined?

Thanks,
Yama

Hideaki YAMADA
**********************************
KDDI Corporation, R&D Labs., Japan

On 29 Dec 2006, at 20:50, [email-masked] wrote:
>    service providers' interest.

---

From: "Xiaode Xu \(xdxu\)" <[email-masked]>
Date: Fri, 12 Jan 2007 11:39:28 -0800

Hi Yama, 

Thanks for sharing the info. I think the end-to-end monitoring with
treating the transport as black box
can be done by the RTCP today. For example, in GPRS case, IP is running
on top of the GSM platform (
SNDCP/SM/LLC/etc.), an endpoint should still be doing RTCP/RTP on the IP
regardless of its foundation.
For UMA/FMC, I suppose the existing RTCP should be capable. 

SubRTCP separates the internal part (sub-network) from endpoints that
service providers can take the
advantage of the monitoring function provided by SubRTCP.

The SubRTCP draft intentionally leaves the trigger out. It can be
triggered by user running a config
at a middlebox via CLI or SNMP. Or it can be asborbed into media
description function e.g. SDP. But
this part may be addressed in an informational doc later.

Thanks,
Xiaode

-----Original Message-----
From: Hideaki YAMADA [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 8:32 AM
To: Xiaode Xu (xdxu)
Cc: 'AVT WG'
Subject: [AVT] Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt 

Hi Xiaode,

Most multimedia sessions over IP-based networks use RTP. 
Furthermore, the RTCP-XR and the RTCP-HR provide useful monitoring and
diagnosis of VoIP performance between the endpoints. 

The behavior of IP packet transmissions over mobile networks differs
from that of fixed networks.
Your proposed scheme could support a procedure for reporting the quality
condition of a portion of end-to-end IP networks, such as the Fixed and
Mobile Convergence (FMC) networks. 
We are studying a similar scheme called Multi-RTCP scheme.

Do you have any specifications to start the trigger of the subRTCP at
the middle nodes which you defined?

Thanks,
Yama

Hideaki YAMADA

On 29 Dec 2006, at 20:50, [email-masked] wrote:
> 	Title		: SubRTCP:RTCP Extension for Internal Monitoring
of
RTP

---

From: "Xiaode Xu \(xdxu\)" <[email-masked]>
Date: Fri, 12 Jan 2007 11:39:28 -0800

Hi Yama, 

Thanks,
Xiaode

-----Original Message-----
From: Hideaki YAMADA [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 8:32 AM
To: Xiaode Xu (xdxu)
Cc: 'AVT WG'
Subject: [AVT] Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt 

Hi Xiaode,

Thanks,
Yama

Hideaki YAMADA

of
RTP

---

From: Colin Perkins <[email-masked]>
Date: Tue, 16 Jan 2007 16:48:37 +0000

On 12 Jan 2007, at 19:39, Xiaode Xu ((xdxu)) wrote:
> treating the transport as black box can be done by the RTCP today.  
> For example, in GPRS case, IP is running on top of the GSM platform  
> (SNDCP/SM/LLC/etc.), an endpoint should still be doing RTCP/RTP on  
> the IP regardless of its foundation. For UMA/FMC, I suppose the  
> existing RTCP should be capable.
>
> SubRTCP separates the internal part (sub-network) from endpoints  
> that service providers can take the advantage of the monitoring  
> function provided by SubRTCP.

Standard RTCP can also be generated by RTP middleboxes, and is more  
developed than subRTCP. If the subRTCP proposal is to progress, the  
groups needs to understand why this separation is important, and why  
standard RTCP cannot be used.

Colin