Re: [AVTCORE] Errata 4192 RFC 3550

[Julius Friedman <[e-mail]>]

Thank you for your "suggestions" and your response.

It is not my intention to argue but if you would be so kind as to PLEASE
acknowledge this email or have another member acknowledge it I would be
very appreciative and I do believe that it would benefit the community as a
whole.

It is unfortunate you see things as such because clearly your calculation
is then magically determining your defined payload data rate using the time
including padding, csrc and extensions when this is in fact not your
intention.

Beliefs are not really relevant here, while I believe quite a few things
the science and the math speaks for itself. The loss of information and
apparent mis-calculation of data rate in all circumstances as well as
unnecessary subtraction which is revealing information which is not really
necessary to reveal at such a level is more then a belief it is a fact.

Since beliefs are being conveyed, I do believe since you or no one else
seems to be able to indicate what this "change" breaks, when I have easily
determined several things which can be better observed (while actually
allowing your "data rate" calculation with the extra information) then
something MUST occur, either change the name of the property to indicate
payload octets or accept my suggestion because it proposes no change that
would effect any calculations, only fix calculations existing even your own
by your own definition not mine.

The error is that "Jitter" and other times includes those values in the
calculated value anyway, e.g. the data  delay and other rates cannot be
determined without knowing the amount of bytes actually sent thus this
number is providing something which is not what is indicated and SHOULD be
changed either name wise to indicate your "logic" or my way to support the
name and use of it and correct existing implementations in use without
changing their code.

I do have proposals for RTP Version 3 as a special profile would not fix
this issue which needs to be addressed before we can move onto version 3
unless you would like to acknowledge that this standard has ambiguous
terminology and a new version is required. I actually have already tested a
version 3 prototype and would be happy to share implementation details but
I need to have my other erratta checked first so I can ensure this as well
as that is on the correct train of thought.

An extension would be outside the scope of this issue because the change
would need to occur at the client level, although it could be done it would
be more cumbersome and break the chain of responsibility of the RtpClient
which is already required to handle things like STUN, TCP ALF etc, although
I will say my version 3 prototype is version 2 compatible with (de)muxing
and extensions and requires a version 2 packet with an extension.

The version 3 updates really relate to a few other things which I will not
endeavor into a tangent about since they are not relevant to this
discussion.

I have a few other issues I would also like to address.

Padding, when it is used it is only used for encryption as packetization
and rtcp have their own mechanisms when required for such. When a block is
transformed for encryption if the padding used is removed there is no
change in the length of the payload and thus padding would not be set in
such an encryption mechanism.

E.g. a encryption which has extra data added which is removed totally
before decoding the packet.

Lastly when padding is used there is no way to determine if the packet has
been completely received if the encryption uses random data as padding and
the last byte becomes truncated, also when using 0 padded data it is
possible to incorrectly detect padding if using that method because 0 data
could occur in the payload.

Thus I suggest that the location of padding be changed to be directly after
the extension, this would constitute errata.

If such a change is made then I would be happy to change the implementation
as a ROUGH calculation would then be determinable given your variables
because the overhead would be able to be determined off the "top" of the
packet and reliably without errors of mis-calculating it's size.

Given these notions what is your response?

Should a vote be taken?

I do believe I am being flexible and I do believe I have highlighted enough
reasons to change the location of the padding and make my previous errata
accepted but either will suffice at this point.

Thank you as well as the members for your "time" and "effort" in this
matter.

Sincerely,
Julius Richard Friedman.


On Mon, Dec 8, 2014 at 5:36 PM, Stephen Casner <[e-mail]> wrote:

> On Fri, 5 Dec 2014, Julius Friedman wrote:
>
> > Hello All.
> >
> > There is definitely some confusion related to the errata I submitted for
> > RFC3550.
>
> I believe the confusion is within your interpretation of the standard,
> not in our interpretation of your proposed errata.  Perhaps you would
> like RTP to have some functions that are different than those that
> were specified, but those do not constitute errata.
>
> > The RFC clearly states:
> >
> > 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.
> >
> > Just because it CAN be used for an average does not mean it should.
>
> Let me clarify.  When we wrote that sentence, we were stating why this
> field was included.  It was included so that receivers would be able
> to know the sender's average payload data rate over various time
> intervals by taking the value of this field from two sender reports
> and dividing by the difference in time of the two sender reports.  The
> receiver might want to compare that result with the average of the
> data as received (perhaps with some losses).
>
> > Further it is the total number of octets in the payload besides the
> > header because the header is always 12 octets.
> >
> > Since csrc and extension octets are included then padding should be
> > also.
>
> The CSRC and extension octets part of the RTP header and the phrase
> "not including header" means that they would not be included in the
> sender's octet count.  What text in RFC 3550 led you to believe that
> the header is always just the first 12 octets and that therefore the
> CSRC and extension octets would be included in the sender's octet
> count?
>
> > Since rtcp also reflects the count with padding this is obviously
> > correct.
>
> I am not sure what you are referring to here.  In another email you
> said "Rtcp counters include this value anyway."  What RTCP counters
> include a count of padding bytes?  Perhaps you are referring to the
> fact that the legnth field in the RTCP header includes padding on the
> RTCP compound packet.  That is irrelevant to the question of whether
> the sender's octet count, which is a count of payload octets, should
> or should not include padding octets.
>
> > Any padding only packet would not change the counter for rtp and is
> > thus a security issue as well as a redundantly conveyed piece of
> > information because each packet contains the number of padding bytes
> > which can be accounted for in the implementation when required.
>
> I do not see a security issue.  Please explain how there would be an
> added security risk for an application that does send RTP data packets
> with padding compared to an application does does not send RTP data
> packets with padding, even if sometimes those applications send RTP
> data packets containing no payload data.
>
> The sender's octet count is an aggregate count of the payload octets
> over some number, often a large number, of RTP data packets.  If the
> receiver gets all of the data packets with no loss, then that same
> count could be calculated.  However, some packets may be lost.  RTP is
> designed to help implementations be tolerant of packet loss.
>
> > To account for padding when padding is not required and would be 0
> > is also contradictory.
>
> I don't understand this sentence.  The sender's octet count does not
> include padding octets, so for implementations that do not send
> padding the number of excluded padding octets is zero, but that does
> not form any contradiction.
>
> > Please read and re read the errata if required.
> >
> > Please advise.  ( intelligently )
>
> I suggest that careful reading and understanding of RFC 3550 is what
> is required here.
>
>                                                         -- Steve
>