Subject: [xrblock] WGLC for aft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 11 Jul 2012 16:55:57 +0200

This message initiates a Working Group Last Call for the Internet-Draft
' RTCP XR Report Block for Burst/Gap Loss metric Reporting '. Please
read and send your comments, questions and concerns to the WG mail list
before 7/25 COB. 

If you read the document and you believe it's just fine and ready for
submission to the IESG please send a message stating this. 

The document is available at
http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt.

Thanks and Regards,

Dan

---

From: Hendrik Scholz <[email-masked]>
Date: Mon, 16 Jul 2012 14:43:21 +0200

Hi,

line 238:
This definition is based on the assumption that the observer
is co-located with the RTP receiver and thus a packet loss/delay
cannot happen after observation. For RTCP this would be true
I suppose unless somebody comes up with the idea of generating
RTCP reports on B2BUAs.
In case of a 'mid point' monitoring approach the loss/discard numbers 
may be wrong as a packet may have been lost/delayed on the remaining
path.
Should we add a statement to indicate that this is end-to-end (I am
aware of companies who want to segment the RTP path and generate hop by
hop RTCP)?

line 137:
There is a superfluous space after '[MONARCH]'

I have no further comments.

Regards,
  Hendrik

-- 
Hendrik Scholz <[email-masked]>

---

From: Alan Clark <[email-masked]>
Date: Mon, 16 Jul 2012 08:53:45 -0400

Hi Hendrik

It is quite likely that RTCP XR reports could be generated by something that
is not the literal endpoint, for example a B2BUA, transcoding gateway or
trunking gateway. From this perspective, there would often be issues that
affect media quality after the measurement point.

The draft should make it clear that the reported metrics apply to the
termination point of the RTP stream, whether that is the eventual endpoint
or not. This would be consistent with RFC3550.

Regards

Alan

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Jul 2012 11:54:46 +0800

----- Original Message ----- 
From: "Hendrik Scholz" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 16, 2012 8:43 PM
Subject: Re: [xrblock] WGLC foraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

> may be wrong as a packet may have been lost/delayed on the remaining

[Qin]: You are right.
Just to clarify this metric is 'transport -related terminal metric', that is to say
this metric will be only measured at the terminal or any endpoints that consume or 
terminate the media stream.

> aware of companies who want to segment the RTP path and generate hop by

[Qin]: Okay, I propose the following change to the 1st paragraph in the section 3.
OLD TEXT:
"
   Metrics in this block report on Burst/Gap Loss in the stream arriving
   at the RTP system.

"
NEW TEXT:
"
   Metrics in this block report on Burst/Gap Loss in the stream arriving
   at the terminal or RTP system that terminates the stream.
"

> There is a superfluous space after '[MONARCH]'

[Qin]: Good catch and will fix this.

> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Jul 2012 11:55:45 +0800

Exactly.

Regards!
-Qin

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 23 Jul 2012 09:33:25 +0000

Hi,

I have read this document and believe it's in good shape. I have 3 minor comments:

1.  Section 3.2, the definition of " Loss and Discard Combination flag ": in some sentences, the key words "should" and "should not" are supposed to be capitalized.

2. Section 3.2, block length: 16 bits, "For the Delay block, the block length is equal to 5." should be corrected to "For the Burst/Gap Loss block, the block length is equal to 5."

3. Some editorial errors, for example, in the fourth paragraph of section 1.1, the space before the dot should be deleted.

Best regards,
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, July 11, 2012 10:56 PM
To: xrblock
Subject: [xrblock] WGLC for aft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

Thanks and Regards,

Dan

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Jul 2012 11:30:21 +0100

Dan,

> http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt.

No objections, but as with burst-gap-discard, I think it'd be useful to clarify how the sampled metric is calculated.

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Tue, 24 Jul 2012 10:19:10 +0800

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Monday, July 23, 2012 6:30 PM
Subject: Re: [xrblock] WGLC foraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

> No objections, but as with burst-gap-discard, I think it'd be useful to clarify how the sampled metric is calculated.

[Qin]: Same as I clarified for burst gap discard draft, burst gap loss metric is not measured at a time instance. I can add one statement as follows:
"
      In this
      document, Burst/Gap Loss Metric is not measured at a particular
      time instant but over one or several reporting intervals.
      Therefore Burst/Gap Loss Metric MUST not be chosen as Sampled
      Metric.
"