[AVTCORE] Fwd: Re: [Technical Errata Reported] RFC3550 (4192)

[Julius Friedman <[e-mail]>]

> Then the text definitely needs to change to indicate this is an average
and should not be used for verification.
>
> The property is senders octet count not average octet count and average
is not specifically stated when it should be which is still errata then....
>
> Let me ask this, what changes if the count includes the padding?
>
> Rtcp counters include this value anyway.
>
> Telling someone that no payload octets were sent when sending the padding
anyway is an apparent security risk.
>
> This is made possible by the counter not charging if only padding packets
are sent.
>
> This cannot be correct as is.
>
> Please advise.
>
> Also please ascertain the status of the rfc2435 and rfc 2326 errata i
submitted so I can communicate those changes if required.
> Please do the math before agreeing or disagreeing.
>
> You will clearly see something needs to change.
>
> If this is the case the  why would the extension octets be included in
the same counter?
>
> Your comments like Mr. Casner are not looking at the details.
>
> Please also note that this would be only for Srtp anyway as rtp doesn't
have padding.
>
> On Dec 5, 2014 3:08 PM, "Frederick, Ron" <[e-mail]>
wrote:
> >
> > I agree with Steve. This was intended to count average payload data
rate, and not total network data rate. While the padding (and other header
data excluded here) contributes to the total network data rate, it should
not contribute to the payload data rate.
> >
> > On Dec 5, 2014, at 10:39 AM, Stephen Casner <[e-mail]> wrote:
> >>
> >>
> >> I do not agree with the proposed change.  As stated in the referenced
> >> text, the sender's octet count was intended to be used to estimate the
> >> average payload data rate.  This is about the payload only, without
> >> any consideration of packetization.
> >>
> >>                                                        -- Steve
> >>
> >> On Wed, 3 Dec 2014, RFC Errata System wrote:
> >>
> >>> The following errata report has been submitted for RFC3550,
> >>> "RTP: A Transport Protocol for Real-Time Applications".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> http://www.rfc-editor.org/errata_search.php?rfc=3550&eid=4192
> >>>
> >>> --------------------------------------
> >>> Type: Technical
> >>> Reported by: Julius Friedman <[e-mail]>
> >>>
> >>> Section: 6.4.1
> >>>
> >>> Original Text
> >>> -------------
> >>> sender's octet count: 32 bits
> >>>      The total number of payload octets (i.e., not including header or
> >>>      padding) transmitted in RTP data packets by the sender since
> >>>      starting transmission up until the time this SR packet was
> >>>      generated.  The count SHOULD be reset if the sender changes its
> >>>      SSRC identifier.  This field can be used to estimate the average
> >>>      payload data rate.
> >>>
> >>> Corrected Text
> >>> --------------
> >>> sender's octet count: 32 bits
> >>>      The total number of payload octets
> >>>      transmitted in RTP data packets by the sender since
> >>>      starting transmission up until the time this SR packet was
> >>>      generated.  The count SHOULD be reset if the sender changes its
> >>>      SSRC identifier.  This field can be used to estimate the average
> >>>      payload data rate.
> >>>
> >>> Notes
> >>> -----
> >>> Where as payload octets is defined as the total number of data octets
contained in a Rtp Packet minus the 12 Header octets for Rtp Packets.
> >>>
> >>> Padding octets as well as octets which occur in the contributing
source list should also be included as they may differ on a per packet
basis and would make the total calculation invalid.
> >>>
> >>> During TCP communication any application layer header should NOT be
included in the total bytes count when including the header length.
> >>>
> >>> Any Rtcp packet counters should include the total length of the
packet (header, padding and any other data).
> >>>
> >>> Instructions:
> >>> -------------
> >>> This erratum is currently posted as "Reported". If necessary, please
> >>> use "Reply All" to discuss whether it should be verified or
> >>> rejected. When a decision is reached, the verifying party (IESG)
> >>> can log in to change the status and edit the report, if necessary.
> >>>
> >>> --------------------------------------
> >>> RFC3550 (draft-ietf-avt-rtp-new-12)
> >>> --------------------------------------
> >>> Title               : RTP: A Transport Protocol for Real-Time
Applications
> >>> Publication Date    : July 2003
> >>> Author(s)           : H. Schulzrinne, S. Casner, R. Frederick, V.
Jacobson
> >>> Category            : DRAFT STANDARD
> >>> Source              : Audio/Video Transport
> >>> Area                : Real-time Applications and Infrastructure
> >>> Stream              : IETF
> >>> Verifying Party     : IESG
> >
> > --
> > Ron Frederick
> > [e-mail]
> >
> >
> >