RE: [Sipping] [PMOL] SIP End-to-End Performance Metrics

[Hadriel Kaplan <[e-mail]>]

Hey Daryl,
Comments:

Failed RRD - I'm a little confused by the wording of how we decide what constitutes a failed registration.  Clearly a 401/407 challenge round does not, but you state a second round would.  Why?  It's totally possible it's not a failure.
I'm also confused what the value/purpose of measuring this delay is.
The section says measuring failed RRD is useful for detecting problems with reaching the intended Registrar - that would be true if you counted transaction timeouts, not request/response delays for auth failures, no?

Failed SRD - need to specify a 401/407 is not a failed SRD (you say any 4xx).

Successful SDD - you say at the end "In these two examples, TB and TS are the same even if the UAC/UAS receives the indicated messages instead of sending them."  I'm pretty sure the delay in receiving a Bye and sending the 200 ok for that is not really useful. :)  Or at least a very different issue than that measured from sending a Bye and receiving a 200.

Failed SDD - what do we count the time of a Bye to a 4xx (but not 401/407) or 5xx as?  Since those are the failure conditions for the other cases, this seems a bit odd to no longer count it as one here.

Failed SDT - this seems to be at odds with the definition of successful SDT.  Successful SDT is stopped on sending the Bye, but this one is stopped on timing out that sent Bye. (in other words, every call will thus count as a successful SDT, and some will also count as a failed one)  Also, what good is this failed SDT info?  You already have Failed SDD.  It seems to me an SDT can only be of type "successful", and the timer should be stopped at send/receipt of Bye.

AHR - how does the UAC or UAS know this info?  I.e., how does the UAS know what max-forwards the UAC started with, and how does the UAC know what max-forwards the UAS received?

SER - need to specify that a 401/407 would also be subtracted in that denominator, or better yet the Invite would not be double-counted period.  Also, need to point out that "# of INVITE" is for new-sessions only (ie, ones without to-tags) - not re-Invites. (I know it's obvious, but ya never know)

-hadriel

> -----Original Message-----
> From: Daryl Malas [mailto:[e-mail]]
> Sent: Friday, December 14, 2007 5:42 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Sipping] [PMOL] SIP End-to-End Performance Metrics
>
> At the conference, I introduced the SIP End-to-End Performance Metrics
> draft (draft-malas-performance-metrics-08) to the PMOL working group.
> Although this draft is referenced in the PMOL WG charter, I wanted to
> ask everyone to review the draft and provide feedback of whether or not
> you feel the current version is ready for the WG to accept as a working
> group item.  A couple of questions came up, which I think should be
> answered regarding this consideration:
>
> Is the SIPPING WG content with the current set of metrics?
>
> Are there too many?
>
> Do these metrics capture the relevant concerns of performance regarding
> the SIP protocol?
>
> Are these metrics depicted accurately from a SIP protocol perspective?
>
> In addition to these questions, I have a couple of tasks from the PMOL
> group to include in the next revision.
>
> Here is a link to the draft:
> http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-08.txt
>
> Thanks...
>
> Daryl
>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP


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