Subject: [AVTCORE] comments on draft-ietf-avtcore-monarch-05

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 4 Nov 2011 15:30:21 -0700

I read the draft and have the following comments:

Section 2 and 3 contain some definitions. Should we add definitions
there for additional terms, including interval metric, cumulative
metric, and sampled metric. There has been some debate on the
definitions of these on xrblock alias, and it would be good to have a
consistent definition of these terms.

Section 3 reads, " The Metric Block exposes real time Application
Quality information". Section 2 defined transport level, application
level, and end system metrics. As such, the use of "application quality
information" seems too specific and limiting to me.

Section 5.2 read, There may be situation where more than one media
transport protocols are used by one application to interconnect to the
same session in the gateway.  For example, one RTCP XR Packet is sent to
the participating endpoints using non- RTP-based media transport (e.g.,
using SIP) in a VOIP session, one crucial factor lies in how to handle
their different identities that are corresponding to different media
transport."
Are we really expecting RTCP XR packets to be used outside of an RTP
session? Or are we trying to say there may be multiple RTP sessions for
a given VoIP session, and there is a need to be able to correlate the
RTCP XR packets from each of these RTP sessions with each other?

Nits:

Section 4:
- change " may have different monitoring requirements, design large
block ..." to " may have different monitoring requirements. Designing
large block ..."
- change " it is hardly to provide" to " it is hard to provide"
- change " block types For example" to " block types.  For example"
- change " consecutive metric interval" to " consecutive metric
intervals"

Thanks,
Charles

---

From: Qin Wu <[email-masked]>
Date: Mon, 07 Nov 2011 14:20:47 +0800

Hi, Charles:
Thank for your valuable comments, please see my reply below.

Regards!
-Qin
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 05, 2011 6:30 AM
Subject: [AVTCORE] comments on draft-ietf-avtcore-monarch-05

> consistent definition of these terms.

[Qin]: Fair, will add them into the update.

> information" seems too specific and limiting to me.

[Qin]: Correct, how about change as "QoS/QoE metric information".

> RTCP XR packets from each of these RTP sessions with each other?

[Qin]: Yes, this section focuses on describing correlation of RTP session with Non-RTP 
session for monitoring purpose. You may read RFC5104 for an example but not limited 
to this.

> - change " consecutive metric interval" to " consecutive metric

[Qin]: Fixed, thanks very much.

> 
> Thanks,
> Charles
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 7 Nov 2011 09:21:54 -0800

Hi Qin,

Please see inline.

> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Sunday, November 06, 2011 10:21 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
> 
> Hi, Charles:

Works for me.

> session for monitoring purpose. You may read RFC5104 for an example
but not limited

I was not able to find any description of correlating RTP and non RTP
sessions in RFC 5104.
RFC 5576 defines the "ssrc" SDP attribute, but even in that case, it
usage is defined for RTP-based media only. So am I still not sure of the
use case you have in mind here.

Thanks,
Charles

---

From: Qin Wu <[email-masked]>
Date: Tue, 08 Nov 2011 10:00:44 +0800

Hi, Charles:
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 08, 2011 1:21 AM
Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-monarch-05

Hi Qin,

Please see inline.

Works for me.

[Qin]: Sorry, I give you a wrong reference, it should be RFC6035.
In that case, we may need to consider how to deal different identities that corresponding to
both RTP session and SIP session. e.g., In SIP session, we may use global call identifier,
In RTP session, we may use SSRC, how to correlate with each other is the issue we may
need to look at. The solution is to use SDES item to associate SSRC of RTP stream with
global call identifier.

Thanks,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 8 Nov 2011 09:22:12 -0800

More inline.

> Sent: Monday, November 07, 2011 6:01 PM
> > > definitions of these on xrblock alias, and it would be good to
have
> a
> > > session? Or are we trying to say there may be multiple RTP
sessions
> for

I see. I now understand how to interpret the text within
draft-ietf-avtcore-monarch. I have some concerns regarding the mechanism
in RFC 6035, as the SIP Call-ID is a globally unique ID whereas the SSRC
is unique per RTP session only. That is more of an issue/limitation for
RFC 6035 than a concern with draft-ietf-avtcore-monarch, and
draft-ietf-avtcore-monarch addresses this by mentioning the combination
of CNAME and SSRC as a potential solution.

Cheers,
Charles

---

From: Qin Wu <[email-masked]>
Date: Wed, 09 Nov 2011 10:28:01 +0800

Yes, I agree.
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 09, 2011 1:22 AM
Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-monarch-05

More inline.

have
sessions

Cheers,
Charles