Subject: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06

From: Alan Clark <[email-masked]>
Date: Tue, 16 Jul 2013 11:58:03 -0400

Alan Clark¹s Comments on Discard RLE block draft

The draft is entitled Run Length Encoding of Discarded Packets however
includes a block that is not a run length encoded and which does not contain
a count of discarded packets.
 
Section 3
 
This draft has a strong dependency on the definitions of RFC3611 Section 4.1
and has a weak reference to a discard definition.
draft-ietf-xrblock-xr-discard draft has a definition of Discard and I
recommend that we refer to this.
 
³The XR Discard RLE report block uses exactly the same format, parameter and
chunk definitions as the Loss RLE Report Block defined in RFC3611 Section
4.1 with the sole change that Chunks represent counts of discarded packets
rather than lost packets. A definition of a discarded packet is given in
draft-ietf-xrblock-xr-discard.²
 
Figure 1 should be titled ³XR Discard RLE Report Block²
 
Last but one paragraph states that Discard RLE report blocks should not
contain conflicting indications of packets being early and late - however
does not state what a receiver should do if it receives conflicting blocks.
State whether the blocks should be ignored or only the conflicting packets
ignored.

Other than a normative reference to ³discard² the definition of this block
does not require an RFC6390 metric template as it refers to a sufficiently
detailed definition in RFC3611.
  
Section 4
 
The XR Bytes Discarded report block is much closer in intent and form to the
Discard Count block contained in  draft-ietf-xrblock-xr-discard, and is not
run length encoded or a count of packets which places it in conflict with
the ³Run Length Encoding of Discarded Packets² draft¹s title.

In order to comply with RFC6390 this block definition should follow the
metric template and describe:
 
(i) How to determine if a packet or a byte is discarded. Presumably this
would be that the packet was received but was too early or late to be
useful.  What if a duplicate packet was received - would the discard of a
duplicate packet be regarded as a ³discard²?
 
(ii) How to count how many bytes are discarded - is this RTP payload bytes,
UDP/TCP payload bytes or IP packet bytes?  Presumably the intent is RTP
payload bytes however this should be explicitly stated and reference made to
the treatment of RTP header extensions and padding.
 
(iii) What edge cases may exist and how to handle these.  For example if a
late packet is received at the start of an interval then the resulting
discarded packet and bytes would technically apply to the previous interval.
>From a practical perspective it may be simpler just to say that if a packet
is discarded during an interval then it is counted as a discard for that
interval, however this should be explicitly stated.

In summary - I would recommend the following:
 
Either
 
(a) Rename the draft to ensure that the title represents both blocks (as it
currently only describes one block) AND include a metrics definition
according to the template given in RFC6390 for both blocks.
 
Or - Preferred but with one complication
 
(b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard
draft. The RLE Discard block draft can rely on the description in RFC3611,
which does not follow the template but is fairly detailed and can be
slightly augmented to refer to the definition of ³discard² in
draft-ietf-xrblock-xr-discard. The main problem with this is that the
draft-ietf-xrblock-xr-discard draft is in the RFC Editor¹s Edit queue - I¹m
not sure whether this would be too much of an Edit?

Regards

Alan Clark

---

From: Alan Clark <[email-masked]>
Date: Wed, 17 Jul 2013 07:26:53 -0400

Hi Varun

On 7/17/13 5:44 AM, "Varun Singh" <[email-masked]> wrote:

> Okay
> How about adding the following line at the appropriate place:
> "If packets appear in both report blocks, the conflicting packets are
> ignored."
> 
>> [Alan] That would be ok
>> 
> I'll move the reference of ietf-xrblock-rtcp-xr-discard from Informative to
> Normative.
> Should that suffice?
> 
>     [Alan] Change from Informative to Normative and also make the text clearly
> refer to the definition of ³discard² in the ietf-xrblock-rtcp-xr-discard draft
> 
>> Section 4
>>  
>> run length encoded or a count of packets which places it in conflict with the
>> ³Run Length Encoding of Discarded Packets² draft¹s title.
>> 
> 
> Proposal for new title:
>  RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding
> (RLE) of Discarded Packets and Bytes Discarded.
> 
> [Alan] This does not work as it reads as if the Bytes Discarded are also RLE.
> You would have to change to something like ³RTP Control Protocol (RTCP)
> Extended Reports (XR) for Bytes Discarded and Run Length Encoding (RLE) of
> Sequences of Discarded Packets² to make it clear that the byte discard counts
> are not run length encoded.  I suggest that you discuss this with Dan and
> Shida.
> 
>> would be that the packet was received but was too early or late to be useful.
>> What if a duplicate packet was received - would the discard of a duplicate
>> packet be regarded as a ³discard²?
>>  
> 
> Duplicate packets are ignored, I can make that explicit.
> 
> [Alan] Ok.
> 
> I don't have a strong opinion here, but my proposal would be to report the
> size of the whole RTP packet,
> including RTP header and payload. However, just reporting the sum of the RTP
> payloads is also fine.
> 
> Any comments
> 
> [Alan] My suggestion would be to report the number of payload bytes discarded.
> 
> I will clarify it should be counted in the interval that it was discarded in.
> 
> [Alan] Ok
> 
> See above for title proposal.
> 
> 
>> which does not follow the template but is fairly detailed and can be slightly
>> augmented to refer to the definition of ³discard² in
> I would not want to hold up the drafts longer or reset the process.
> But I am open to whatever is the best course of action.
> 
> [Alan] It is a conundrum - the bytes discarded block would be a much better
> fit in draft-ietf-xrblock-xr-discard
> 
>> 
> 
>

---

From: Varun Singh <[email-masked]>
Date: Wed, 17 Jul 2013 12:44:19 +0300

Hi Alan,

On Jul 16, 2013, at 6:58 PM, Alan Clark wrote:

> Alan Clark’s Comments on Discard RLE block draft
> 
> The draft is entitled Run Length Encoding of Discarded Packets however includes a block that is not a run length encoded and which does not contain a count of discarded packets. 
>  
> Section 3
>  
> This draft has a strong dependency on the definitions of RFC3611 Section 4.1 and has a weak reference to a discard definition.  draft-ietf-xrblock-xr-discard draft has a definition of Discard and I recommend that we refer to this.
>  
> “The XR Discard RLE report block uses exactly the same format, parameter and chunk definitions as the Loss RLE Report Block defined in RFC3611 Section 4.1 with the sole change that Chunks represent counts of discarded packets rather than lost packets. A definition of a discarded packet is given in draft-ietf-xrblock-xr-discard.”
>  

I will make an explicit reference to Discards. 

> Figure 1 should be titled “XR Discard RLE Report Block”
>  

Okay

> Last but one paragraph states that Discard RLE report blocks should not contain conflicting indications of packets being early and late - however does not state what a receiver should do if it receives conflicting blocks. State whether the blocks should be ignored or only the conflicting packets ignored.

How about adding the following line at the appropriate place:
"If packets appear in both report blocks, the conflicting packets are ignored."

> 
> Other than a normative reference to “discard” the definition of this block does not require an RFC6390 metric template as it refers to a sufficiently detailed definition in RFC3611.
>   

I'll move the reference of ietf-xrblock-rtcp-xr-discard from Informative to Normative.
Should that suffice?

> Section 4
>  
> The XR Bytes Discarded report block is much closer in intent and form to the Discard Count block contained in  draft-ietf-xrblock-xr-discard, and is not run length encoded or a count of packets which places it in conflict with the “Run Length Encoding of Discarded Packets” draft’s title. 
> 

Proposal for new title:
 RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) of Discarded Packets and Bytes Discarded.

> In order to comply with RFC6390 this block definition should follow the metric template and describe:
>  
> (i) How to determine if a packet or a byte is discarded. Presumably this would be that the packet was received but was too early or late to be useful.  What if a duplicate packet was received - would the discard of a duplicate packet be regarded as a “discard”?
>  

> (ii) How to count how many bytes are discarded - is this RTP payload bytes, UDP/TCP payload bytes or IP packet bytes?  Presumably the intent is RTP payload bytes however this should be explicitly stated and reference made to the treatment of RTP header extensions and padding.
>  

I don't have a strong opinion here, but my proposal would be to report the size of the whole RTP packet, 
including RTP header and payload. However, just reporting the sum of the RTP payloads is also fine.

Any comments

> (iii) What edge cases may exist and how to handle these.  For example if a late packet is received at the start of an interval then the resulting discarded packet and bytes would technically apply to the previous interval.  From a practical perspective it may be simpler just to say that if a packet is discarded during an interval then it is counted as a discard for that interval, however this should be explicitly stated.
> 

> (a) Rename the draft to ensure that the title represents both blocks (as it currently only describes one block) AND include a metrics definition according to the template given in RFC6390 for both blocks. 
>  

> (b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can rely on the description in RFC3611, which does not follow the template but is fairly detailed and can be slightly augmented to refer to the definition of “discard” in draft-ietf-xrblock-xr-discard. The main problem with this is that the draft-ietf-xrblock-xr-discard draft is in the RFC Editor’s Edit queue - I’m not sure whether this would be too much of an Edit?
> 

Cheers,
Varun

---

From: Varun Singh <[email-masked]>
Date: Wed, 17 Jul 2013 14:44:30 +0300

Hi Alan,

Thanks for the input. Comments inline and snipping away text that we agree with. 

Regards,
Varun

----
http://www.netlab.tkk.fi/~varun

> On 17.7.2013, at 14.26, Alan Clark <[email-masked]> wrote:
> 
> Hi Varun
> 
> 
> [Alan] This does not work as it reads as if the Bytes Discarded are also RLE.  You would have to change to something like “RTP Control Protocol (RTCP) Extended Reports (XR) for Bytes Discarded and Run Length Encoding (RLE) of Sequences of Discarded Packets” to make it clear that the byte discard counts are not run length encoded.  I suggest that you discuss this with Dan and Shida.
> 

Agree with reordering the title, if it is the way forward. 

> [Alan] My suggestion would be to report the number of payload bytes discarded.

I am fine with that too and will add text to explicitly state it. 

> [Alan] It is a conundrum - the bytes discarded block would be a much better fit in draft-ietf-xrblock-xr-discard
> 
> 

I agree it is a better fit, I'll wait for Shida and/or Dan's input before proceeding.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jul 2013 17:40:05 +0200

Dear all,

Thanks Alan for your feedback.
Forwarding to 
[email-masked], as 
mentioned at 
http://www.ietf.org/iesg/directorate/performance-metrics.html, so that 
everybody is in the loop.

Regards, Benoit
> RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 
> Alan Clark's Comments on Discard RLE block draft
>
> includes a block that is not a run length encoded and which does not 
> contain a count of discarded packets.
>
> Section 3
>
> This draft has a strong dependency on the definitions of RFC3611 
> Section 4.1 and has a weak reference to a discard definition. 
> "The XR Discard RLE report block uses exactly the same format, 
> parameter and chunk definitions as the Loss RLE Report Block defined 
> in RFC3611 Section 4.1 with the sole change that Chunks represent 
> counts of discarded packets rather than lost packets. A definition of 
> a discarded packet is given in draft-ietf-xrblock-xr-discard."
>
> Figure 1 should be titled "XR Discard RLE Report Block"
>
> Last but one paragraph states that Discard RLE report blocks should 
> not contain conflicting indications of packets being early and late - 
> however does not state what a receiver should do if it receives 
> conflicting blocks. State whether the blocks should be ignored or only 
> the conflicting packets ignored.
>
> Other than a normative reference to "discard" the definition of this 
> block does not require an RFC6390 metric template as it refers to a 
> sufficiently detailed definition in RFC3611.
>
> Section 4
>
> The XR Bytes Discarded report block is much closer in intent and form 
> to the Discard Count block contained in 
>  draft-ietf-xrblock-xr-discard, and is not run length encoded or a 
> count of packets which places it in conflict with the "Run Length 
> Encoding of Discarded Packets" draft's title.
>
> (i) How to determine if a packet or a byte is discarded. Presumably 
> this would be that the packet was received but was too early or late 
> to be useful.  What if a duplicate packet was received - would the 
> discard of a duplicate packet be regarded as a "discard"?
>
> (ii) How to count how many bytes are discarded - is this RTP payload 
> bytes, UDP/TCP payload bytes or IP packet bytes?  Presumably the 
> intent is RTP payload bytes however this should be explicitly stated 
> and reference made to the treatment of RTP header extensions and padding.
>
> (iii) What edge cases may exist and how to handle these.  For example 
> if a late packet is received at the start of an interval then the 
> resulting discarded packet and bytes would technically apply to the 
> previous interval.  From a practical perspective it may be simpler 
> just to say that if a packet is discarded during an interval then it 
> is counted as a discard for that interval, however this should be 
> explicitly stated.
>
> (a) Rename the draft to ensure that the title represents both blocks 
> (as it currently only describes one block) AND include a metrics 
> definition according to the template given in RFC6390 for both blocks.
>
> (b) Move the Bytes Discarded block to the 
> draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can 
> rely on the description in RFC3611, which does not follow the template 
> but is fairly detailed and can be slightly augmented to refer to the 
> definition of "discard" in draft-ietf-xrblock-xr-discard. The main 
> problem with this is that the draft-ietf-xrblock-xr-discard draft is 
> in the RFC Editor's Edit queue - I'm not sure whether this would be 
> too much of an Edit?
>
> Regards
>
> Alan Clark
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jul 2013 17:44:06 +0200

including 
[email-masked] for 
the latest email in the email thread.

Regards, Benoit
> http://www.netlab.tkk.fi/~varun <http://www.netlab.tkk.fi/%7Evarun>
>
> On 17.7.2013, at 14.26, Alan Clark <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Re: RFC6390 review of 
>> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 Hi Varun
>>
>>
>>         The XR Bytes Discarded report block is much closer in intent
>>         and form to the Discard Count block contained in
>>          draft-ietf-xrblock-xr-discard, and is not run length encoded
>>         or a count of packets which places it in conflict with the
>>         “Run Length Encoding of Discarded Packets” draft’s title.
>>
>>
>>     Proposal for new title:
>>      RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length
>>     Encoding (RLE) of Discarded Packets and Bytes Discarded.
>>
>>     [Alan] This does not work as it reads as if the Bytes Discarded
>>     are also RLE.  You would have to change to something like “RTP
>>     Control Protocol (RTCP) Extended Reports (XR) for Bytes Discarded
>>     and Run Length Encoding (RLE) of Sequences of Discarded Packets”
>>     to make it clear that the byte discard counts are not run length
>>     encoded.  I suggest that you discuss this with Dan and Shida.
>>
>
>>         (ii) How to count how many bytes are discarded - is this RTP
>>         payload bytes, UDP/TCP payload bytes or IP packet bytes?
>>          Presumably the intent is RTP payload bytes however this
>>         should be explicitly stated and reference made to the
>>         treatment of RTP header extensions and padding.
>>
>>
>>         (a) Rename the draft to ensure that the title represents both
>>         blocks (as it currently only describes one block) AND include
>>         a metrics definition according to the template given in
>>         RFC6390 for both blocks.
>>
>>
>>         draft-ietf-xrblock-xr-discard draft. The RLE Discard block
>>         draft can rely on the description in RFC3611, which does not
>>         follow the template but is fairly detailed and can be
>>         slightly augmented to refer to the definition of “discard” in
>>         draft-ietf-xrblock-xr-discard. The main problem with this is
>>         that the draft-ietf-xrblock-xr-discard draft is in the RFC
>>         Editor’s Edit queue - I’m not sure whether this would be too
>>         much of an Edit?
>>
>>     [Alan] It is a conundrum - the bytes discarded block would be a
>>     much better fit in draft-ietf-xrblock-xr-discard
>>
>>
>