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

From: "Hedayat, Kaynam" <[email-masked]>
Date: Wed, 1 Feb 2006 02:25:17 -0500

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

---

From: Alan Clark <[email-masked]>
Date: Wed, 01 Feb 2006 10:59:50 -0500

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'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.

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.

Regards

Alan

---

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Feb 2006 18:21:31 +0000

On 1 Feb 2006, at 15:59, Alan Clark wrote:
> 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).
>
> 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.

Surely that is one of the reasons why the media might be encrypted?  
If a media stream is protected end to end, then it's not clear that  
hop by hop monitoring is desired.

> 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.
>
> 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 have serious concerns about this approach, since we are already  
seeing a slow creep in the amount regarded as "sufficient" as the  
various RTCP XR standards evolve. It's not clear that duplicating  
signalling information in-band with the media is a good architectural  
approach; indeed it seems to me to be a mistake.

Colin

---

From: Alan Clark <[email-masked]>
Date: Wed, 01 Feb 2006 17:01:30 -0500

Colin Perkins wrote:

>> 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  

Encryption is intended to protect the payload from potential 
eavesdropping - not to prevent the service from being manageable.  
Probes and analyzers are generally regarded as being benign - there is 
no point in having a secure service if it does not work!!

>> same sense, network managers need to be confident that they can  test 
>> and debug services that they deploy.
>>

I agree to some extent - the question is what is sufficient?  Having 
data on the codec type is extremely useful for example.  Also, if the IP 
stream is NAT'd then it can be difficult to correlate measurement data 
from within the network with some arbitrary IP address/port with IP 
endpoints.

Alan

---

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

On 1 Feb 2006, at 22:01, Alan Clark wrote:
>>> 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).
>>>
>>> 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.
>>
>> Surely that is one of the reasons why the media might be  
>> encrypted?  If a media stream is protected end to end, then it's  
>> not clear that  hop by hop monitoring is desired.
>
> Probes and analyzers are generally regarded as being benign - there  
> is no point in having a secure service if it does not work!!

Perhaps, but that makes a number of assumptions. I can certainly  
envisage cases where the person encrypting their communications does  
so to prevent management and monitoring tools from working. And, in  
general, I don't think you can always assume the user considers  
probes or analysis tools to be benign.

Colin

---

From: Alan Clark <[email-masked]>
Date: Sat, 04 Feb 2006 16:52:48 -0500

> probes or analysis tools to be benign.
As these payloads are entirely optional - if a person is concerned about 
security and not about management, they could simply not send the 
payload.  In my experience, which does include working with the kind of 
user that has to apply very high levels of security, they "do" want the 
service to be manageable however are not prepared to compromise security 
in order to facilitate this.  Having secure communications is only 
useful if it works - and if there are network problems then you 
typically need to use probes and analyzers to troubleshoot.  I think if 
you ask an enlightened user if security or management is more important 
they would answer "both".

I am of course also aware of some of the nuances of residential VoIP 
deployments in which IP stream analysis may be used to influence 
prioritization and encryption used to both hide the type of traffic and 
provide privacy - and work routinely with the various types of service 
provider involved.  Residential VoIP services are amongst the more 
problematic and hence these service providers are looking for enhancing 
rather than avoiding management capabilities.

My viewpoint is simply that we should ensure that we make real time 
communications systems manageable and that we should not make 
assumptions about the type of signaling protocol being used or the 
degree of access to the content of signaling messages.

If we take some simple practical scenarios. 

(i) An enterprise VoIP deployment is having problems, and a field 
service engineer from the IP phone vendor arrives on site to 
troubleshoot the problem.  The enterprise is using a different vendor's 
or potentially open source SIP Proxy/ Softswitch.  If the field service 
engineer attaches their analyzer next to one of the IP phones then they 
could obviously see both media and signaling. What if they need to 
attach the analyzer to some mid-network point to look at calls going to 
another location - the signaling will be routed directly from each IP 
phone to the SIP Proxy .. how does the analyzer retrieve the 
configuration data in real time in order to more fully understand what 
codec is used.  Would the enterprise be responsible for determining how 
the analyzer and SIP proxy interact?

(ii) Even simpler - SIP signaling is sent over secure transport to 
minimize the risk of fraudulent use of resources.  If probes and 
analyzers have to access signaling in order to perform in depth analysis 
of calls then they would all have to be a party to the key - which 
doesn't seem to secure.  Also, all the vendors of probes and analyzers 
have to implement all the different secure transport/ encryption 
algorithms that "may" be used in different sectors of the industry, in 
addition to the signaling protocols.

If the IP endpoint reports approximately 32 bytes of data once at the 
beginning of a three minute call then we are increasing bandwidth by 
maybe 0.005%, which doesn't seem to be particularly onerous.

Regards

Alan

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Feb 2006 09:23:06 +0000

Alan,

On 4 Feb 2006, at 21:52, Alan Clark wrote:
...
> degree of access to the content of signaling messages.

But that doesn't mean you can ignore the signalling. Like it or not,  
RTP requires an out of band signalling protocol to negotiate media  
streams, and an analyser will likely need access to that out of band  
information. Duplicating that information in-band is not an option.

> troubleshoot the problem.  The enterprise is using a different  
> vendor's or potentially open source SIP Proxy/ Softswitch.  If the  
> field service engineer attaches their analyzer next to one of the  
> IP phones then they could obviously see both media and signaling.  
> What if they need to attach the analyzer to some mid-network point  
> to look at calls going to another location - the signaling will be  
> routed directly from each IP phone to the SIP Proxy .. how does the  
> analyzer retrieve the configuration data in real time in order to  
> more fully understand what codec is used.  Would the enterprise be  
> responsible for determining how the analyzer and SIP proxy interact?

The analyser would need access to the signalling information,  
clearly. Does this need a standard interface? Yes, perhaps. But RTCP  
is not that interface: it is not designed for that role, and doesn't  
fit that role. Use a protocol that can reliably access the needed  
information, with appropriate security and auditing properties.

> analyzers have to access signaling in order to perform in depth  
> analysis of calls then they would all have to be a party to the key  
> - which doesn't seem to secure.  Also, all the vendors of probes  
> and analyzers have to implement all the different secure transport/  
> encryption algorithms that "may" be used in different sectors of  
> the industry, in addition to the signaling protocols.

Duplicating parts of the signalling in RTCP is also potentially  
insecure.

> If the IP endpoint reports approximately 32 bytes of data once at  
> the beginning of a three minute call then we are increasing  
> bandwidth by maybe 0.005%, which doesn't seem to be particularly  
> onerous.

It is not the bandwidth of these reports which concerns me, but  
rather than confusion of signalling and media. Put simply, I don't  
think that duplicating parts of the signalling within RTCP is  
appropriate. Yes - it appears to make the design of analysers easier,  
but it significantly warps the system architecture, and potentially  
causes numerous problems down the line.

Colin