Re: [apps-discuss] Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10

Qin Wu <> Thu, 21 March 2013 11:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3D0A21F8F0C for <>; Thu, 21 Mar 2013 04:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 08hrUhwvgVYw for <>; Thu, 21 Mar 2013 04:50:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D45E21F8EE1 for <>; Thu, 21 Mar 2013 04:50:00 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id APP92980; Thu, 21 Mar 2013 11:49:58 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:49:57 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:49:56 +0000
Received: from w53375 ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 19:49:50 +0800
Message-ID: <>
From: Qin Wu <>
To: Eric Burger <>,,
References: <>
Date: Thu, 21 Mar 2013 19:49:49 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EED_01CE266D.3F5A8230"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: []
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Thu, 21 Mar 2013 10:20:16 -0700
Subject: Re: [apps-discuss] Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Mar 2013 11:50:03 -0000

Thank for your careful review.
Both Section 1.1 and Section 3.3 of this draft have already referred the readers to the relevant documents by
 pointing to disard draft. Burst gap discard and discard don't need to be coupled with RLE discard draft. 
So I think it will be more useful to have a separate roadmap document and go into details to discuss how to
 implement them in different use cases.

  ----- Original Message ----- 
  From: Eric Burger 
  To: ; 
  Sent: Monday, March 18, 2013 10:59 PM
  Subject: Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10

  In general, this document is ready to go. I have one editorial suggestion. In order to understand this document, I had to read draft-ietf-xrblock-rtcp-xr-discard-11 and draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 to figure out where this draft fits into the jitter reporting ecosystem. I get why these are all small, separate drafts. However, I could not easily find an overarching document tying things together. draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 does a decent job in the Introduction of describing the relationship between xr-burst-gap-discard and xr-discard. However, that is in the context of why we have a third draft on what on first read looks like the same metrics.

  The three drafts cover three facets of jitter metrics. What is missing is a roadmap for implementors that does two things. The first is it makes it clear where to go to do what. I can easily imagine an implementor wanting to do jitter measurements, finding just one of these drafts, and think they need to do a proprietary extension because the IETF 'forgot' to include something in the jitter reporting. Another issue is I found myself reading xr-discard and xr-burst-gap-discard in parallel. They made a whole lot more sense reading them that way than one at a time. Moreover, I found I had to read them in parallel to understand xr-burst-gap-discard. Therefore, it would be helpful to either have a separate roadmap document or a paragraph or two in each document referring the reader to the other documents. That way the reader knows they exist, knows there may be a better / more coverage for reporting than a single document implies, and they can find the other documents. I would offer this will improve the readability and ultimate interoperability of the resulting implementations.