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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jan 2015 13:22:54 +0100

Hi Julius

On 2014-12-17 16:36, Julius Friedman wrote:
> 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?

I don't quite understand you here. But, I guess that you are complaining
about that the measured entity is not the most relevant.

However, this is not at all reason enough to make a change to the RTCP
report block specification in RFC 3550. As noted before, using Errata is
not the appropriate method for technical change. Errata is used to flag
significant issues, or clarify text that might be misinterpret to avoid
incompatibility issue.

> 
> What about the security concerns related to congruence?

If I understand the security concern correctly. This is that in case one
uses padded payloads in the protection operation, this report leaks the
summary over the amount of new payload bytes received between each
report, potentially for a single packet. Thus providing an information
leak that might provide some insight into the protected data. For
example the audio frame lengths from a variable rate codec.

In would agree that this would be worth taking note of as a security
issue. Potentially change the design to avoid it. However, I would first
of all note that this RTCP definition has been in place since 1996. It
is very widely deployed and any change to it would result in
incompatibilities.

Further it is clearly possible to protected against. Simply encrypt the
RTCP also. Which would be my recommendation anyway if one encrypts the
RTP packets.

> 
> 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?

First of all it is a technical change that is non-backwards compatible.
It does not represent clarifying the WG consensus on how it should be done.

> 
> 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)?

Any implementation that tracks these values would flag an inconsistency
and possible cease transmission. Because your receiver will claim to
have received more bytes than the sending party has sent according to
its calculation of this value.

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

Please understand a few things. There are process that exist. There are
purposes and rules for what is allowed to be done with difference
processed and mechanisms. In addition there are considerations of the
impact of any changes to existing specifications. Which in its turn
leads back to the process question.

Roni, in his role a WG co-chair has the responsibility for driving these
processes. One of these is to determine the WG's recommendation to the
AD for how an errata is to be handled.

> 
> 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.

Sorry, I don't understand how you get faster synchronization. This
should have no effect on the RTCP packet transmission rules and their
execution.

> 
> 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?
> 

RFC 2326 is an MMUSIC item. Please, keep the topics separated and with
clear subject lines. Please avoid cross posting between the WG mailing
lists.

Can you please refrain from creating more erratas until you have
achieved some WG consensus that any issue is requiring an errata and
what the new text should actually be.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Jan 2015 16:43:26 +0100

WG,

There has been quite some discussion. There appear to be substantial
support for putting this Errata into the "Rejected" state.

Any additional feedback, please provided it by the 12th of February.

Cheers

Magnus

On 2014-12-04 02:47, 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 <[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
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund