Subject: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)

From: RFC Errata System <[email-masked]>
Date: Wed, 3 Dec 2014 17:47:37 -0800 (PST)

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 <[email-masked]>

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

---

From: Julius Friedman <[email-masked]>
Date: Fri, 5 Dec 2014 14:01:44 -0500

Thanks for your response.

I do believe your incorect and plese keep in mind that it is also a
security issues to indicate what part of the payload changes due to
encryption.

The indication does not change only satisfied the required information
without bias for padding.

The data is more accurate as I indicated changed because the parties will
be able to track padding if required in their own counters and if they dont
they will never calculate more or less bytes then actually sent which is
possible with the current text if the payload required padding.

Please also keep in mind that if I didn't set padding because it wasn't
required then no change is required also if I forgot to set padding and
thus proves itself the change is warranted.

Individuals who choose to follow this old way of thinking invite themselves
to security issues and overhead of calculating redundantly included
information as the length of a rtcp packet already included padding for
that reason.

Think carefully about the above scenarios and also that the end rate you
specify would actually be more accurate.

I have also submitted erratta for rfc2435 and rfc2326 have they been
addressed?

Sincerely,
Julius Friedman
On Dec 5, 2014 1:40 PM, "Stephen Casner" <[email-masked]> 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:
>
> > 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.
> >

---

From: Julius Friedman <[email-masked]>
Date: Fri, 5 Dec 2014 15:59:09 -0500

> 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" <[email-masked]>
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 <[email-masked]> wrote:
> >>
> >>
> >>>
> >>> 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.
> >>>
> >>> Any Rtcp packet counters should include the total length of the
packet (header, padding and any other data).
> > --
> > Ron Frederick
> > [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Fri, 5 Dec 2014 10:39:56 -0800 (PST)

-- Steve

---

From: "Frederick, Ron" <[email-masked]>
Date: Fri, 5 Dec 2014 20:08:48 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Steve

Section: 6.4.1

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

[email-masked]<mailto:[email-masked]>

---

From: Julius Friedman <[email-masked]>
Date: Wed, 17 Dec 2014 10:36:55 -0500

So quite simply how can jitter and transit use the absolute time from
packet to packet but yet the calculation of payload data rate is using the
same?

Wouldn't time spent on non data items be used then?

What about the security concerns related to congruence?

How is that not errata unless these invalid calculations and security
issues were intentionally mandated and why now would I knowing these things
continue to do things as usual?

Furthermore can you simply tell me what breaks if I use the octets
indicated as I indicated (by only not accounting for the 12 octet header)?

WITH ALL DUE RESPECT That should be the determining factor not your
opinions about intentions.

My tests reveal faster synchronization with rtcp with legacy clients as
well as a correct rate and data rate when then is calculated by removing
the csrc extension and padding.

How about some calculations and tests are also performed to validate this
as most default profiles don't use any of the items in question anyway.

Additionally why has nothing been said about rfc2326 and errata 4199?

Thanks!
 On Dec 17, 2014 10:17 AM, "Roni Even" <[email-masked]> wrote:

> Hi,
> This is not an errata and if there is a requirement for a different metrics
> it can be specified as a new metrics (maybe using XR reports) and not by
> changing existing metrics.
>
> Thanks
> Roni Even
> AVTCore co-chair
>
> > -----Original Message-----
> > From: avt [mailto:[email-masked]] On Behalf Of RFC Errata System
> > Sent: 04 December, 2014 3:48 AM
> > To: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> keith.drage@alcatel-
> > lucent.com; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)
> >
> list
> > should also be included as they may differ on a per packet basis and
> would
> > 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.
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Dec 2014 17:17:26 +0200

Hi,

Thanks
Roni Even
AVTCore co-chair

> [email-masked]; [email-masked]; [email-masked]; keith.drage@alcatel-
list
> should also be included as they may differ on a per packet basis and would
> make the total calculation invalid.
> 
(header,
"Reply
> All" to discuss whether it should be verified or rejected. When a decision
is
edit the