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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------