Subject: [Sipping] Comments on draft-malas-performance-metrics-05.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Oct 2006 09:59:49 +0200

Hi,

a few comments on draft-malas-performance-metrics-05.txt.

The Section "Conventions used in this document", which currently appears
between the Abstract and the TOC, is usually part of the Terminology
Section instead.

Expand acronyms (e.g., UAC, UAS) on their first use.

Section 3.1.2: RRD is defined as:

"the interval is defined from the initial REGISTER request and the final
response indicating a failure received from the destination registrar or
interim proxies."

However, in the example, the UAC receives an error response, it sends a
new REGISTER, and then gives up. RRD is calculated until the UAC gives
up. Therefore, the description needs to clarify which final responses
are taking into account to calculate RRD (i.e., when the UAC gives up)
and which ones are not (e.g., authentication challenges).

Section 3.2 talks about the Session Request Delay (SSD and says that is
telephony applications of SIP is known as Post Dial Delay.

The ITU defines the post-selection delay as:

"Post-selection delay (en bloc sending) is defined as the time interval
from the instant the first bit of the initial SETUP message containing
all the selection digits is passed by the calling terminal to the access
signalling system until the last bit of the first message indicating
call disposition is received by the calling terminal (ALERTING message
in case of successful call)."

However, the draft defines Time Begin as:

   "TB occurs when the designated request has been processed by the
    application and last bit of the request packet has been sent from the
    proxy or UA (and is externally observable at some physical
    interface)."

Therefore, while for the ITU, TB relates to the first bit of the
message, for the draft TB relates to the last bit of the message. We
should either use the first bit of the message as well of clarify that
the Post Dial Delay is not the same thing as SRD.

Section 3.4 defines the Session Duration Time as an interval starting
with a 200 OK response. However, session establishments involving an
answer in the ACK cannot be considered to be established until the ACK
arrives to the UAS. These sessions can be considered to be "accepted",
though. Section 3.4 should clarify this point.

The example in Section 4 does not seem to relate to any of the ways to
provide finer granularity, which are described right before the example.

Cheers,

Gonzalo

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Oct 2006 10:07:06 +0200

Hi,

an extra comment. The document should talk about Both Way Media, not 
about Both Way *RTP* Media. There is nothing in the document that limits 
it to RTP-based media.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Oct 2006 19:04:39 +0200

Hi,

> Are you suggesting I use "start time" language as specified in ITU-T 
> E.721, to define TB within this document?  I don't have any problem
> with that.  I will update the draft accordingly.

unless we have a reason to do otherwise, I would stick to the ITU
definition.

>> 
>> Section 3.4 defines the Session Duration Time as an interval
>> starting with a 200 OK response. However, session establishments
>> involving an answer in the ACK cannot be considered to be
>> established until the ACK arrives to the UAS. These sessions can be
>> considered to be "accepted", though. Section 3.4 should clarify
>> this point.
> 
> IMO, this comes down to the point of measurement.  I believe it is 
> easier to capture the inputs to the metrics at the UAC, than it is to
>  capture inputs from both the UAC and UAS.  This may be my own
> perception though.  If you think it is less accurate, then I could
> change the TS to begin when the ACK is sent by the UAC.  In this
> case, the UAC has assumed the session has begun.  Also, this is where
> the inputs to the metrics are taking place.  Perhaps, I should create
> all of the same metrics from the perspective of the UAS.  I could
> specify for the UAS a similar set of inputs (or outputs if you will)
> for the metrics.  Or, I create more "accurate" metrics by taking into
> consideration both the UAC and UAS for all applicable metrics.  This
> would require the capture of data from both as well.  Is there
> interest in measuring performance from the UAS perspective?

Using the 200 OK is fine as long as the draft explains that, at that
point, the session is accepted, but its media streams may have not been
established yet. As long as the draft is clear on what we are doing, I
am OK with it.

Regarding performance measurements from the UAS perspective, I believe
they are as interesting as the ones from the UAC. We should define them.

Cheers,

Gonzalo

---

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 31 Oct 2006 09:44:36 -0700

Comments inline...

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 1:00 AM
> To: sipping
> Cc: Malas, Daryl
> Subject: Comments on draft-malas-performance-metrics-05.txt
> 
> Hi,
> 

I will update this, thanks.
> Expand acronyms (e.g., UAC, UAS) on their first use.

I will go through the document and correct any of these, thanks.
> and which ones are not (e.g., authentication challenges).

I will add some clarity to this in the next version, thanks.

Are you suggesting I use "start time" language as specified in ITU-T
E.721, to define TB within this document?  I don't have any problem with
that.  I will update the draft accordingly.

IMO, this comes down to the point of measurement.  I believe it is
easier to capture the inputs to the metrics at the UAC, than it is to
capture inputs from both the UAC and UAS.  This may be my own perception
though.  If you think it is less accurate, then I could change the TS to
begin when the ACK is sent by the UAC.  In this case, the UAC has
assumed the session has begun.  Also, this is where the inputs to the
metrics are taking place.  Perhaps, I should create all of the same
metrics from the perspective of the UAS.  I could specify for the UAS a
similar set of inputs (or outputs if you will) for the metrics.  Or, I
create more "accurate" metrics by taking into consideration both the UAC
and UAS for all applicable metrics.  This would require the capture of
data from both as well.  Is there interest in measuring performance from
the UAS perspective? 
> provide finer granularity, which are described right before the
example.

I will try to provide a better example in this section, thanks.

---

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 31 Oct 2006 10:35:08 -0700

I will clarify why the 200 OK is chosen as the TB point by the UAC.  I
think this will become clearer by defining the TB and TS for the UAS, as
well.  I will update the TB to be similar to E.721's definition.

Thanks...--Daryl

> Sent: Tuesday, October 31, 2006 10:05 AM
> To: Malas, Daryl
> Cc: sipping
> Subject: Re: Comments on draft-malas-performance-metrics-05.txt
> 
> Hi,
>