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

More inline.

> -----Original Message-----
> From: Qin Wu [mailto:bill.wu@huawei.com]
> Sent: Monday, November 07, 2011 6:01 PM
> To: Charles Eckel (eckelcu); avt@ietf.org
> Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
> 
> Hi, Charles:
> ----- Original Message -----
> From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
> To: "Qin Wu" <bill.wu@huawei.com>; <avt@ietf.org>
> Sent: Tuesday, November 08, 2011 1:21 AM
> Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
> 
> 
> Hi Qin,
> 
> Please see inline.
> 
> > -----Original Message-----
> > From: Qin Wu [mailto:bill.wu@huawei.com]
> > Sent: Sunday, November 06, 2011 10:21 PM
> > To: Charles Eckel (eckelcu); avt@ietf.org
> > Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
> >
> > Hi, Charles:
> > Thank for your valuable comments, please see my reply below.
> >
> > Regards!
> > -Qin
> > ----- Original Message -----
> > From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
> > To: <avt@ietf.org>
> > Sent: Saturday, November 05, 2011 6:30 AM
> > Subject: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
> >
> >
> > >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.
> >
> > [Qin]: Fair, will add them into the update.
> >
> > > 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.
> >
> > [Qin]: Correct, how about change as "QoS/QoE metric information".
> 
> Works for 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?
> >
> >
> > [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.
> 
> 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.
> 
> [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.

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

> Thanks,
> Charles
> 
> 
> > > 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"
> >
> > [Qin]: Fixed, thanks very much.
> >
> > >
> > > Thanks,
> > > Charles
> > >
> > >
> > >
> > > _______________________________________________
> > > Audio/Video Transport Core Maintenance
> > > avt@ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> > >