Subject: [xrblock] comment on "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"

From: "Rachel Huang(yihong)" <[email-masked]>
Date: Wed, 12 Oct 2011 14:12:10 +0000

Hi,

I have reviewed the draft "draft-ietf-avt-rtcp-xr-burst-gap-discard-02".

I'm getting confused what this draft wanted to report?

Is it the proportion of packets discarded or the proportion of frames discarded? Cause in some texts it is the word "packets" while in other texts it is the word "frames".

   For example, in clause 1.1 , the first paragraph,
      "The new block type supports the reporting of the proportion of packets discarded by the receiver due to jitter. "

  And also the first paragraph describes:

      " This block is intended to be used in conjunction with [DISCARD] which provides the total packets discarded, and on which this block therefore depends."

 while in the fourth paragraph

    "The definitions of Burst, Gap, Loss and Discard are consistent with definitions in [RFC3611], with the clarification that Loss and Discard are defined in terms of frames. "

  The same confusion also exists in other part of the draft. There are still other issues I'd like to raise. But I think we should clarify this issue first.

Best regards!

Rachel

---

From: Alan Clark <[email-masked]>
Date: Wed, 12 Oct 2011 15:31:56 -0400

There is some confusion on what a ³frame² is for sample based codecs such as
G.711, so it may be best to make the context of what is lost or discarded to
be an RTP Packet (not an IP Packet).  Also - RTP packets have sequence
numbers and timestamps whereas codec generated frames within RTP packets may
or may not - so it would be technically possible for frames to be lost prior
to encapsulation in RTP however the system that is detecting loss and
discard may not know that.

Alan

On 10/12/11 10:12 AM, "Rachel Huang(yihong)" <[email-masked]>
wrote:

> Is it the proportion of packets discarded or the proportion of frames
> discarded? Cause in some texts it is the word "packets" while in other texts
> it is the word "frames".
> 
>       "The new block type supports the reporting of the proportion of packets
> discarded by the receiver due to jitter. "
> 
>       " This block is intended to be used in conjunction with [DISCARD] which
> provides the total packets discarded, and on which this block therefore
> depends."
> 
>    
> 
>     "The definitions of Burst, Gap, Loss and Discard are consistent with
> definitions in [RFC3611], with the clarification that Loss and Discard are
> defined in terms of frames. "
> 
>  
> 
>   The same confusion also exists in other part of the draft. There are still
> other issues I'd like to raise. But I think we should clarify this issue
> first.
> 
>  
> 
>  
> 
>  
> 
> Best regards!
> 
> Rachel
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: "Rachel Huang(yihong)" <[email-masked]>
Date: Thu, 13 Oct 2011 07:22:52 +0000

Thank you Alan, it does make sense.

________________________________
发件人: Alan Clark [[email-masked]]
发送时间: 2011年10月13日 3:31
到: Rachel Huang(yihong); [email-masked]
主题: Re: [xrblock] comment on "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"

There is some confusion on what a “frame” is for sample based codecs such as G.711, so it may be best to make the context of what is lost or discarded to be an RTP Packet (not an IP Packet).  Also - RTP packets have sequence numbers and timestamps whereas codec generated frames within RTP packets may or may not - so it would be technically possible for frames to be lost prior to encapsulation in RTP however the system that is detecting loss and discard may not know that.

Alan

On 10/12/11 10:12 AM, "Rachel Huang(yihong)" <[email-masked]<https://imailcn.huawei.com/owa/UrlBlockedError.aspx>> wrote:

Hi,

Best regards!

Rachel

________________________________
_______________________________________________
xrblock mailing list
[email-masked]<https://imailcn.huawei.com/owa/UrlBlockedError.aspx>
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Thu, 13 Oct 2011 16:13:51 +0800

Re: [xrblock] comment on "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"Agree, additional thought is
It looks to me this draft assume one RTP packet is corresponding to one frame, however in the case where video aplication are taken into account, one RTP packet may allow up to more one frame encapsualted in the packet or one frame needs to be splitted into more than one RTP packets. In that case, that will be problem when we calculate Packets Expected and the relationship between RTP packet and frame is not 1:1. Since according to the section 3.3 of this draft, Packets Expected is calcualted based on the sequence number of RTP packet.

Regards!
-Qin

  ----- Original Message ----- 
  From: Alan Clark 
  To: Rachel Huang(yihong) ; [email-masked] 
  Sent: Thursday, October 13, 2011 3:31 AM
  Subject: Re: [xrblock] comment on "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"

  There is some confusion on what a "frame" is for sample based codecs such as G.711, so it may be best to make the context of what is lost or discarded to be an RTP Packet (not an IP Packet).  Also - RTP packets have sequence numbers and timestamps whereas codec generated frames within RTP packets may or may not - so it would be technically possible for frames to be lost prior to encapsulation in RTP however the system that is detecting loss and discard may not know that.

  Alan

  On 10/12/11 10:12 AM, "Rachel Huang(yihong)" <[email-masked]> wrote:

    Hi,

     

    Best regards!

    Rachel

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

------------------------------------------------------------------------------

---

From: Alan Clark <[email-masked]>
Date: Thu, 13 Oct 2011 08:09:29 -0400

When video frames are transported over RTP - each video frame may be split
amongst multiple RTP packets.  In this case each RTP packet has a separate
sequence number although ³may² have the same timestamp.  So again (as you
suggest), the reporting of RTP packet stats seems clearer.

The intent with the new XR drafts was to make the metrics as broadly
applicable as possible - hence we should make them RTP packet oriented
wherever possible

Best Regards

Alan

On 10/13/11 4:13 AM, "Qin Wu" <[email-masked]> wrote:

> Agree, additional thought is
> It looks to me this draft assume one RTP packet is corresponding to one frame,
> however in the case where video aplication are taken into account, one RTP
> packet may allow up to more one frame encapsualted in the packet or one frame
> needs to be splitted into more than one RTP packets. In that case, that will
> be problem when we calculate Packets Expected and the relationship between RTP
> packet and frame is not 1:1. Since according to the section 3.3 of this draft,
> Packets Expected is calcualted based on the sequence number of RTP packet.
>  
> Regards!
> -Qin
>  
>>  
>> From:  Alan Clark <mailto:[email-masked]>
>>  
>> To: Rachel Huang(yihong) <mailto:[email-masked]>  ; [email-masked]
>>  
>> Subject: Re: [xrblock] comment on
>> "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"
>>  
>> 
>> 
>>> discarded? Cause in some texts it is  the word "packets" while in other
>>> texts it is the word  "frames".
>>> 
>>>       "The new block type  supports the reporting of the proportion of
>>> packets discarded by the  receiver due to jitter. "
>>> 
>>>       " This block is  intended to be used in conjunction with [DISCARD]
>>> which provides the total  packets discarded, and on which this block
>>> therefore  depends."
>>> 
>>>    
>>> 
>>>   The same confusion also exists in other  part of the draft. There are
>>> still other issues I'd like to raise. But I  think we should clarify this
>>> issue  first.
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Best  regards!
>>> 
>>> Rachel
>>> 
>>>  
>>>

---

From: Qin Wu <[email-masked]>
Date: Thu, 13 Oct 2011 20:17:17 +0800

Re: [xrblock] comment on "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"Yes, I agree with your opion and  support your proposal to make the draft being written as RTP packet oriented.

Regards!
-Qin
----- Original Message ----- 
  From: Alan Clark 
  To: Qin Wu ; Rachel Huang(yihong) ; [email-masked] 
  Sent: Thursday, October 13, 2011 8:09 PM
  Subject: Re: [xrblock] comment on "draft-ietf-avt-rtcp-xr-burst-gap-discard-02"

  When video frames are transported over RTP - each video frame may be split amongst multiple RTP packets.  In this case each RTP packet has a separate sequence number although "may" have the same timestamp.  So again (as you suggest), the reporting of RTP packet stats seems clearer.

  The intent with the new XR drafts was to make the metrics as broadly applicable as possible - hence we should make them RTP packet oriented wherever possible

  Best Regards

  Alan

     
    Regards!
    -Qin

      ----- Original Message ----- 

       

      Alan

        Hi,

         

        Best  regards!

        Rachel

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

--------------------------------------------------------------------------