Subject: [Sipping] Sip Performance Metrics: Average Hops per INVITE (AHI) and Average Hops per Session (AHS)

From: Daryl Malas <[email-masked]>
Date: Fri, 16 Jun 2006 10:36:45 -0600

I have had a request to add a metric, which could help avoid routing
loops in an operators network.  I have come up with two metrics, and I
wanted to get feedback from the mailing list before I update the draft.
Here is what I'm thinking:

> Average Hops per INVITE (AHI)
> 
>  
> 
> AHI is calculated as an average and is defined as the number of hops
> per INVITE request.  This metric is used to indicate potential
> inefficient routing and/or help an operator detect and/or prevent
> routing loops.
> 
>  
> 
> Variables =
> 
>             a = # of INVITE requests
> 
>             b = SUM of a “Max Forwards” value
> 
>  
> 
>                       (a * 70) – (b)
> 
>             AHI = ----------------------
> 
>                              a
> 
>  
> 
> The value of 70 is used based on the recommended origination value for
> each request as described in section 8.1.1.6 of [2]. Any consistent
> value used by an operator or provider may be used in place of the
> recommended value.
> 
>  
> 
> Average Hops per Session (AHS)
> 
>  
> 
> AHS is calculated in a similar manner to AHI; however, the “Max
> Forwards” value is taken from each request associated with the entire
> session as described in the following section 2.5.  This metric is
> also used in a similar manner as AHI.
> 
>  
> 
> Variables =
> 
>             a = # of SIP requests
> 
>             b = # of completed sessions
> 
>             c = SUM of a “Max Forwards” value
> 
>  
> 
>                     (a * 70) – (c)
> 
>             AHS =---------------------
> 
>                           b
> 
>  
> 
> The value of 70 is used based on the recommended origination value for
> each request as described in section 8.1.1.6 of [2].  Any consistent
> value used by an operator or provider may be used in place of the
> recommended value.
> 
Your feedback and thoughts are appreciated.

Thanks...

--Daryl

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 19 Jun 2006 11:11:55 -0400

> > value used by an operator or provider may be used in place of the

In practice, 70 is usually clipped by proxies to something smaller.

I'm not sure that an average is very useful - if most messages have a
small number of hops it will mask even horrible inefficiencies in a
minority.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 20 Jun 2006 22:03:40 -0400

Daryl,

This email has been in my queue for numerous days.  Sorry for the delay.
I think that establishing SIP performance metrics is a very valuable
exercise, and I appreciate the effort. Now as for the topic at hand, and
specifically the "Hops per x"....Outside of the AHI Tuna reference that
splashed into my head ;) here are some thoughts.  

Your looking into quantifying hop detection is congruent with recent
focus on draft-ietf-sip-hop-limit-diagnostics-03. Detecting the
existence of a loop is basically knowing a 483 has been returned. Right?
Why not just determine the frequency of 483 Too Many Hops messages?
draft-ietf-sip-hop-limit-diagnostics would help in determining the
culprit.

With that said, the metrics you put forth blow might be valuable in
determining propensity to the equivalent of post dial delay.  Just a
thought.

Adam

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Friday, June 16, 2006 12:37 PM
To: [email-masked]
Subject: [Sipping] Sip Performance Metrics: Average Hops per INVITE
(AHI)and Average Hops per Session (AHS)

I have had a request to add a metric, which could help avoid routing
loops in an operators network.  I have come up with two metrics, and I
wanted to get feedback from the mailing list before I update the draft.
Here is what I'm thinking:

>             b = SUM of a "Max Forwards" value
> 
>  
> 
>                       (a * 70) - (b)
> 

> AHS is calculated in a similar manner to AHI; however, the "Max 
> Forwards" value is taken from each request associated with the entire 
>             c = SUM of a "Max Forwards" value
> 
>  
> 
>                     (a * 70) - (c)
> 

Thanks...

--Daryl

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: Daryl Malas <[email-masked]>
Date: Thu, 22 Jun 2006 11:08:27 -0600

Adam,

I know there have been various items within the working group to detect
route loops, such as the draft you described below.  I think of the
number of 483's as a fault, based on a predefined threshold.  IRT, ISO
FCAPS, the difference lies in a Fault condition versus a Performance
metric.  My draft is attempting to define Performance metrics, instead
of detecting faults...that being said, you could predict or detect a
potential fault based on evaluating the output from a performance
metric. ;-)

Thanks...--Daryl

---

From: Daryl Malas <[email-masked]>
Date: Thu, 22 Jun 2006 11:13:39 -0600

Scott,

My assumption is a provider, enterprise, or carrier will specify a
consistent value within their network.  If a call traverses to another
entity whether a peer, IXC, or similar; it is a pretty safe assumption
the value may change.  I believe this metric is valuable in identifying
inefficiencies within "your" respective network for optimizing routing,
and avoiding route loops, to whatever the termination point is.  Once
the message leaves "your" network, then the number of hops is up to the
downstream provider's responsibility.  Most of those hops may be
completely invisible to the originating user or provider due to topology
hiding.

My thoughts...--Daryl