Re: [AVTCORE] Errata 4192 RFC 3550

[Julius Friedman <[e-mail]>]

Dear Mr. Taylor, AVT.

Thus it was my reasons for explicitly opening this discussion.

Possibly the errata name and notes and focus could be shifted but as is the
case with many things in science, not to diverge but the points are simple:

The instructions given for calculating transit time, jitter inter arrival
and all other "times" in the "real time" protocol take account data
transferred on the medium of transfer, this time calculation MUST include
the time taken to receive CSRC, Extensions and Padding. Thus the Senders
Octet Count not including these values goes against these calculations to
form a value which is both detrimental to the given standard algormithmic
calculations for those values as well as  security in cases where
encryption is used.

This does not take into account "middle boxes" which are one of Mr.
Casner's areas of other modifications to internet drafts, in most of his
modifications the middle boxes are allowed to remove extensions which when
occurs causes information to be hidden under the current verbiage for no
reason when allowing for it's detection is both beneficial and accurate
given the description and taking into account its relationship to the data
rate.

In short if my total octet count is X I can manually determine what my
packet overhead is (csrc, extension or padding) and if i have the total
numbers (X) I can also remove time for the padding and csrc and extension
because I will have the total rate given by the time at which the packet
was received.

Simply if I determine X is 100 I can determine X is made from csrc total Y,
extension total Z and then X - (Y + Z) would come out to exactly what the
existing senders octet count is given the standard today and create a valid
calculation of "jitter" and the other calculated values which would then
finally no longer be saturated by the presence of extra data (regardless if
the middle box removes it which causes additional delay which is just seen
as jitter in the network anway)

This should be easy to achieve consensus on since the change basically says
instead of performing subtraction for data not part of the "data" of the
payload just increment for the "payload" section (which may include csrc,
and extension and padding).

This removes a calculation which is also mostly 0 all of the time when none
of the values are used and only causes issues when there are mediums in
between anyway such as mixers, hence it is VERY VERY important to use the
values such as jitter in the way they were designed and as indicated in the
standard and to acknowledge that your already taking those values into
account (even if you don't know it because they were removed by a middle
box).

It is also very very easy to detect that the sender is keeping count a
different way than you are and thus would indicate a middle box or older
version of the standard being implemented which would also subsequently be
able to be detected and accounted for giving the change.

That is what I would like to address however, the problem is that this does
not even take into account that padding at the end of the packet can be
truncated and is another issue itself.

Hence the location of padding ALSO needs to really be changed to make
reception more reliable, that will probably harder to specify in errata and
thus will require a protocol change but obviously consensus needs to be
attained.

I would love to focus on the new draft but I think that we need to fix some
things in the existing version with errata first because it will both
justify the nature of new version and explain the nuisances with the
previous version which can then be adjusted for if required.

I also notice that RFC3551 specified that DVI be dropped but it specified
NO other default VIDEO transfer mechanism.

Since PCM is sometimes required and thus it was named for audio I do
believe that uncompressed / raw should also be specified as a minimum
mandatory requirement for implementations.

This would enable audio and video transfer in a uncompressed manner which
is standardly defined in https://tools.ietf.org/html/rfc4175.

How the consensus could be taken to remove a required video format but not
specify a standard replace would also be errata in my opinion but
apparently it's not...

There are probably other issues and I would be glad to help address them
but I need to determine what needs to be addressed and where and ensure
that consensus is achieved to write a draft.

I have found my errata for RFC2435 @
http://www.rfc-editor.org/errata_search.php?rfc=2435

I will re-submit my errata for RFC2326 today or tomorrow.

Hopefully we can all take some time to focus on the content here and decide
the path to take but I hope we can at least agree that its very clear to me
something needs to be done.

Thank you again for your time!



On Wed, Dec 10, 2014 at 2:26 PM, Tom Taylor <[e-mail]>
wrote:

> We are saying that regardless of considerations of implementation, the
> IETF requires that changes of this sort be achieved using certain
> procedures. The current wording of RFC 3550 was achieved through Working
> Group consensus, and that is what would be required for further changes.
> The way to achieve that is through the writing of an Internet Draft and
> list discussion. So far there has been no indication of Working Group
> interest in your interpretation, but who knows?
>
> I have not seen your errata for the other two documents, presumably
> because they went to a different E-mail list, but the same procedural
> considerations apply.
>
> Tom Taylor
>
>
> On 10/12/2014 2:00 PM, Julius Friedman wrote:
>
>> Thank you Mr. Taylor.
>>
>> The bottom line is that even given the verbiage existing that it is simply
>> invalid to calculate the rate of just the payload using the time including
>> other data.
>>
>> That itself is errata.
>>
>> If the change is made as I suggested then existing hardware (even if it
>> not
>> updated with the new logic) will be able to be at least detected using my
>> change.
>>
>> Some implementations already use this information in the count anyway and
>> would thus be valid instead of invalid (with no change).
>>
>> There are bigger fish to fry such as the location and content of the
>> padding, of which the location is the most important for detection of
>> completion of the packet.
>>
>> We need to address one or the other and then it can validate your
>> equations
>> existing (but would still require a change to the location of the offset
>> of
>> the padding) or as I suggested for this errata to change the wording or
>> the
>> name.
>>
>> Both are really in order it's just a matter of how its done and not
>> hastily
>> but after consideration I would suggest that if "compatibility" with
>> existing hardware is most important then to update just the name and
>> indicate my errata as a name change only and why so that it can be
>> adjusted
>> for as best as possible where required; then to file more errata to change
>> the location of the padding or just start work on a new version of the rtp
>> standard with ambiguous definitions removed.
>>
>> Thank you for your time and effort and I look forward to your dialog in
>> this matter!
>>
>> Can you also please check my RFC2435 Errata and RFC2326 Errata so I can
>> discuss those as well?
>>
>> Sincerely,
>> Julius Richard Friedman
>>
>> On Wed, Dec 10, 2014 at 1:50 PM, Tom Taylor <[e-mail]>
>> wrote:
>>
>>  Stephen's point is that you are proposing a protocol change. That cannot
>>> be done by way of an erratum. If you want to write an Internet Draft with
>>> your proposals, they can be debated. I wonder if you could use the XR
>>> capability to get the information you want?
>>>
>>> Tom Taylor
>>>
>>>  ...
>