Subject: RE: [AVT] New draft-clark-avt-rtcpxr-video-00.txt

From: "Hedayat, Kaynam" <[email-masked]>
Date: Thu, 2 Feb 2006 22:08:18 -0500

-----------------------------------------------------------------------------------------------------------------------------------------------
Service Quality Matters. Test the performance and quality of your VoIP or IP video service at: 
http://www.TestYourVoIP.com
http://www.TestYourIPVideo.com-----Original Message-----
> From: Alan Clark [mailto:[email-masked]] 
> Sent: Wednesday, February 01, 2006 11:00 AM
> To: Hedayat, Kaynam
> Cc: IETF AVT working group
> Subject: Re: [AVT] New draft-clark-avt-rtcpxr-video-00.txt
> 
> Kaynam
> 
> Within the test and management equipment industry this is a 
> well established, long standing and probably perpetual 
> problem area.  The signaling may travel by a different path 
> to the media, may well be sent over an encrypted connection  
> and may be "owned" by a third party (in the case of voice or 
> video traffic being sent over interconnected networks).
> 
> It is not a question of "simplicity" but rather making sure 
> that emerging VoIP and Video services are actually capable of 
> being managed given the range of likely deployment scenarios. 
>  If probes and analyzers have to do extensive decoding of 
> RTP/ MPEG transport payloads - which may sometimes be 
> encrypted - in order to do any level of performance 
> monitoring and troubleshooting this would be extremely 
> expensive for service providers and enterprise network 
> managers and in some cases completely impractical.
I argue that this problem is already solved through out of band
correlation. I again argue that adding complexity and breaking the
architectural integrity of a protocol is not justified by simplicity of
implementations.
> 
> I'm sure that if your software engineers started writing code 
> that was completely impossible to either test or debug, then 
> you would not be too keen on using it, even if it appeared to 
> work.  In the same sense, network managers need to be 
> confident that they can test and debug services that they deploy.
Again, there are tools available today that allow the providers
troubleshoot and debug their networks through out of band correlation.
> 
> I would prefer to put "sufficient" information into the RTCP 
> XR Video payload to allow network test equipment to function 
> and consider the safe and sensible assumption is that 
> signaling information may not be available.
If signaling information is not available it is for a reason the most
common one hiding the signaling detail.
> 
> Regards
> 
> Alan
> 
> 
> Hedayat, Kaynam wrote:
> 
> >I agree with Colin on this point. Transfer of partial correlation 
> >information will introduce a need to include the full 
> details of SDP on 
> >the media path. The correct solution is offline correlation. 
> We should 
> >not introduce complexities endpoint implementations through 
> standards 
> >for the sake of simplicity in monitoring solutions.
> >
> >Regards,
> >Kaynam
> >
> >
> >
> >-------------------------------------------------------------
> ----------
> >-------------------------------------------------------------
> ----------
> >- Service Quality Matters. Test the performance and quality of your 
> >VoIP or IP video service at:
> >http://www.TestYourVoIP.com
> >http://www.TestYourIPVideo.com-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> >Colin Perkins
> >Sent: Thursday, January 19, 2006 7:27 PM
> >To: Alan Clark
> >Cc: IETF AVT working group
> >Subject: Re: [AVT] New draft-clark-avt-rtcpxr-video-00.txt
> >
> >Alan,
> >
> >On 19 Jan 2006, at 23:37, Alan Clark wrote:
> >  
> >
> >>I'll take a look at this - the intent with the "correlation 
> ID" was to
> >>    
> >>
> >
> >  
> >
> >>do what you suggest.  There is some duplicate information 
> in some of 
> >>the extended descriptions of payloads, which would also be 
> present in 
> >>SDP definitions within signaling protocols such as SIP, 
> however since 
> >>we can't rely on the signaling messages taking the same path as the 
> >>RTP stream,  mid-stream monitoring systems may not be able 
> to identify
> >>    
> >>
> >
> >  
> >
> >>the codec type (e.g. if a dynamic payload type is used).
> >>    
> >>
> >
> >Indeed, I expect that mid-stream monitoring won't be able to 
> determine 
> >the codec in an on-line basis. You'll need to correlate with the 
> >signalling later, if the signalling & media follow different 
> paths. At 
> >some point you'll always need to do that, unless you convey full 
> >details of the SDP and SIP (or whatever control protocol used) 
> >signalling in-band. And I hope no-one is proposing to convey 
> all those 
> >details in-band!
> >
> >Colin
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/avt
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/avt
> >
> >  
> >
> 
> 

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

---

From: Alan Clark <[email-masked]>
Date: Fri, 03 Feb 2006 07:09:22 -0500

Kaynam

With regard to your technical comments on the video draft - I'll take 
these into account in the next revision, hopefully out next week.

With regard to your comment below in which you say "this is solved by 
out of band correlation" I strongly disagree and think you are missing 
the point.  There are a wide range of types of network test equipment 
deployed in multiple locations, and many different network scenarios - I 
would only agree that "some types of test equipment" can use out of band 
correlation under "some network scenarios".  We would like to ensure 
that VoIP services are manageable and in my opinion it makes absolutely 
no sense to require access to signaling for all the reasons outlined in 
my earlier email.

Regards

Alan

---

From: David R Oran <[email-masked]>
Date: Fri, 3 Feb 2006 14:24:38 -0500

Coming in from left field....flame away.

1. I strongly agree with Kaynam and Colin that smashing all the  
stream descriptor information in band in RTP or RTCP is a very poor  
tradeoff and does do fairly strong damage to the overall RTP/RTCP/SIP/ 
RTSP/SDP protocol architecture as a whole.

2. I agree with Alan (but less strongly than in 1 above) that on-path  
snooping for quality measurement is useful and we should not make  
such instrumentation facilities jump through high barriers to get the  
correlation information they need in order to interpret and analyze  
the streams.

Finding a balance here is difficult, but here's a suggestion (deep  
breath).

How about we specify a new field in an SDES RTCP packet which  
contains a URI, which when dereferenced, yields an object of type  
application/sdp for the sdp that was used to construct the stream  
being snooped.

This could either be directly populated by an endpoint with the  
necessary uri scheme implemented, or indirectly populated by the  
endpoint using something like SIP session policy from something which  
can squirrel away the SDP.

The bandwidth needed would be small and stolen from the RTCP  
bandwidth. The use an of SDES-style object would avoid duplicating  
all the SDP data and semantics in a separate in-band mechanism. the  
information could be sent a low periodicity so a late-joining snooper  
would be able to find the correlation information while it's still  
relevant.

Running for the exits...

Dave.

On Feb 3, 2006, at 7:09 AM, Alan Clark wrote:

> Kaynam
>
> With regard to your technical comments on the video draft - I'll  
> take these into account in the next revision, hopefully out next week.
>
> With regard to your comment below in which you say "this is solved  
> by out of band correlation" I strongly disagree and think you are  
> missing the point.  There are a wide range of types of network test  
> equipment deployed in multiple locations, and many different  
> network scenarios - I would only agree that "some types of test  
> equipment" can use out of band correlation under "some network  
> scenarios".  We would like to ensure that VoIP services are  
> manageable and in my opinion it makes absolutely no sense to  
> require access to signaling for all the reasons outlined in my  
> earlier email.
>
> Regards
>
> Alan
>
>
>
>
> Hedayat, Kaynam wrote:
>
>>
>>> From: Alan Clark [mailto:[email-masked]] Sent:  
>>> Wednesday, February 01, 2006 11:00 AM
>>> To: Hedayat, Kaynam
>>> Within the test and management equipment industry this is a well  
>>> established, long standing and probably perpetual problem area.   
>>> The signaling may travel by a different path to the media, may  
>>> well be sent over an encrypted connection  and may be "owned" by  
>>> a third party (in the case of voice or video traffic being sent  
>>> over interconnected networks).
>>>
>>> It is not a question of "simplicity" but rather making sure that  
>>> emerging VoIP and Video services are actually capable of being  
>>> managed given the range of likely deployment scenarios. If probes  
>>> and analyzers have to do extensive decoding of RTP/ MPEG  
>>> transport payloads - which may sometimes be encrypted - in order  
>>> to do any level of performance monitoring and troubleshooting  
>>> this would be extremely expensive for service providers and  
>>> enterprise network managers and in some cases completely  
>>> impractical.
>>>
>>> that was completely impossible to either test or debug, then you  
>>> would not be too keen on using it, even if it appeared to work.   
>>> In the same sense, network managers need to be confident that  
>>> they can test and debug services that they deploy.
>>>
>>> I would prefer to put "sufficient" information into the RTCP XR  
>>> Video payload to allow network test equipment to function and  
>>> consider the safe and sensible assumption is that signaling  
>>> information may not be available.
>>>
>>>> I agree with Colin on this point. Transfer of partial  
>>>> correlation information will introduce a need to include the full
>>> details of SDP on
>>>> - Service Quality Matters. Test the performance and quality of  
>>>> your VoIP or IP video service at:
>>>>> we can't rely on the signaling messages taking the same path as  
>>>>> the RTP stream,  mid-stream monitoring systems may not be able
>>> to identify
>>>
>>>>>
>>>>>
>>>>
>>>>

---

From: Colin Perkins <[email-masked]>
Date: Sat, 4 Feb 2006 11:55:17 +0000

On 3 Feb 2006, at 19:24, David R Oran wrote:
> tradeoff and does do fairly strong damage to the overall RTP/RTCP/ 
> SIP/RTSP/SDP protocol architecture as a whole.
>
> 2. I agree with Alan (but less strongly than in 1 above) that on- 
> path snooping for quality measurement is useful and we should not  
> make such instrumentation facilities jump through high barriers to  
> get the correlation information they need in order to interpret and  
> analyze the streams.

Sure.

> application/sdp for the sdp that was used to construct the stream  

Remember that there may be sensitive data in the SDP (e.g. k= lines),  
so one might only want to reveal a limited subset of the information  
it contains.

> endpoint using something like SIP session policy from something  
> which can squirrel away the SDP.
>
> information could be sent a low periodicity so a late-joining  
> snooper would be able to find the correlation information while  
> it's still relevant.
>
> Running for the exits...

I'm not sure I'd necessarily include a URI referencing the SDP, but  
including a unique identifier that can be used to correlate a flow  
with the signalling makes sense to me.

Colin