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

From: "Xiaode Xu \(xdxu\)" <[email-masked]>
Date: Thu, 4 Jan 2007 12:30:29 -0800

Hi Colin,

We discussed the requirements before proposing the draft. In fact, a
carrier customer
has asked per-session inter-media nodes RTT from us. The SubRTCP is
mainly intended 
for providing such such RTTs efficiently. Conveying other metrics is
sort of bonus
Consideration from this transport mechanism. 

On the other hand, use of different RTCP message types to differentiate
RTCPs internal
to infrastructure nodes from the existing RTCP messages may favor the
implementation
of the functional addition and its future development.

The understanding of media delivery internal to infrastructure portion
is of great
interest to service operators. A separate mechanism and development is a
worth.

I will study 3550 further in particular section 7 and pick up the
points. 

I am on PTO now and will be back in office next Monday. I will try to
further 
justify the need of different RTCP message types for the need of the
separation
between internal and external.

Thanks for the comments,
Xiaode

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 6:43 AM
To: Xiaode Xu (xdxu)
Cc: AVT WG
Subject: Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt 

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: Colin Perkins <[email-masked]>
Date: Sat, 6 Jan 2007 10:23:18 +0000

Hi Xiaode,

On 4 Jan 2007, at 20:30, Xiaode Xu ((xdxu)) wrote:
> carrier customer has asked per-session inter-media nodes RTT from  
> us. The SubRTCP is mainly intended  for providing such such RTTs  
> efficiently. Conveying other metrics is sort of bonus Consideration  
> from this transport mechanism.

Being able to derive the RTT between nodes which are not senders  
sounds like a useful feature. Indeed, RTCP XR [RFC 3611] includes a  
mechanism to do this, and much more.

> RTCPs internal to infrastructure nodes from the existing RTCP  
> messages may favor the implementation of the functional addition  
> and its future development.
>
> is of great interest to service operators. A separate mechanism and  
> development is a worth.

I believe existing RTCP mechanisms, perhaps with the definition of  
some new report types, can solve this problem. Introducing a new  
"subRTCP" protocol seems to introduce complexity for no benefit.

> I will study 3550 further in particular section 7 and pick up the

You should also review RFC 3611, since the mechanisms defined there  
allow the calculation of internal RTTS, and the inference of more  
detailed performance metrics and network topology information.

Colin