Subject: [pm-dir] Operations Directorate Review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Fri, 15 Mar 2013 11:30:12 -0400

OPS-Dir, authors, ADs,

This is a somewhat brief and combined OPS-DIR and PM-DIR
review of the subject draft.

Al

-=-=-=-=-=-=-=-

As this draft specifies addition metrics for use in monitoring
performance, the operator has the choice to deploy this or not,
and the applicability of the metrics is clearly stated (so
there should be few misunderstandings of the results). As a result,
I don't foresee an operations issue here.

-=-=-=-=-=-=-=-

In Section 3.2:
   Reserved (resv): 5 bits

      These bits are reserved.  They MUST be set to zero by senders and
      ignored by receivers (See RFC6709 section 4.2).  The block MUST be
      discarded if the block length is set to a different value.

   block length: 16 bits

      The length of this report block in 32-bit words, minus one.  For
      the Burst/Gap Loss block, the block length is equal to 5.  The
      block MUST be discarded if the block length is set to a different
      value.

The last sentence of the Reserved field is not correct, as it refers
to block length.  What must the receiver do if the resv bits are non-zero?
This has next-gen/future implications, of course.

-=-=-=-=-=-

Threshold: 8 bits

      The Threshold is equivalent to Gmin in [RFC3611], i.e. the number
      of successive packets that must be received prior to and following
      a lost packet in order for this lost packet to be regarded as part
      of a gap.

Why is this field re-named? Consistency with 3611 implies using the term Gmin.

The VAD silence Gmin calculation consideration raised in section 4
should be noted here in the definition.

(and, the term used in section 4 is Gmin, not Threshold)

-=-=-=-=-=-

From: Tina TSOU [mailto:[email-masked]]
Sent: Tuesday, March 05, 2013 6:21 PM
To: MORTON JR., ALFRED (AL)
Cc: [email-masked]
Subject: Request for Operations Directorate Review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08 by 2013-03-15

Hello,

As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact.

IETF Last Call:

The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-loss/

IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-loss/ballot/

Please provide comments and review to the Ops-dir mailing list ([email-masked]<mailto:[email-masked]>) by 2013-03-15, and include the authors of the draft as well.

A Check-list of possible questions/topics to address in an OPS-DIR review may be found in Appendix A of RFC 5706.

Only include the questions that apply to your review.

Would you add the review requests and update the status by yourself at our wiki page?

http://trac.tools.ietf.org/area/ops/trac/wiki/Reviews

Thank you,

Tina

---

From: Qin Wu <[email-masked]>
Date: Thu, 21 Mar 2013 19:09:33 +0800

Hi,Al:
Thank for your valuable comments, see reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: MORTON JR., ALFRED C (AL) 
  To: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Friday, March 15, 2013 11:30 PM
  Subject: Operations Directorate Review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08

  OPS-Dir, authors, ADs,

  Al

  -=-=-=-=-=-=-=-

  -=-=-=-=-=-=-=-

  In Section 3.2:

     Reserved (resv): 5 bits

   

     block length: 16 bits

        value.

[Qin]:The last sentence of the reserved field is typo and should be deleted, thank

for catching this.

  -=-=-=-=-=-

  Threshold: 8 bits

        of a gap.

[Qin]:My clarification is in Section 4.7.6, Gmin definition, Gmin is also explained as "Gap threshold".

So using threshold is still consistent with RFC3611. On the other hand, Gmin doesn't distinguish

whether the packet near the start or end of an RTP session that is within a gap or a burst is

a lost packet or a discarded packet. Threshold does.

[Qin]: Good point, I propose to add the following text to say:

"

Note that the threshold is calculated in accordance with Gmin Calculation defined in section 4.7.2 of RFC3611.

"

  -=-=-=-=-=-

   

  Hello,

  IETF Last Call:

  Please provide comments and review to the Ops-dir mailing list ([email-masked]) by 2013-03-15, and include the authors of the draft as well.

   

  Thank you,

  Tina