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

"Frederick, Ron" <ron.frederick@bluecoat.com> Fri, 05 December 2014 20:08 UTC

Return-Path: <ron.frederick@bluecoat.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4331A01EA for <avt@ietfa.amsl.com>; Fri, 5 Dec 2014 12:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFSyfU3AVuPT for <avt@ietfa.amsl.com>; Fri, 5 Dec 2014 12:08:49 -0800 (PST)
Received: from plsvl-mailgw-01.bluecoat.com (spf.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id C38FC1A014C for <avt@ietf.org>; Fri, 5 Dec 2014 12:08:49 -0800 (PST)
Received: from pwsvl-exchts-06.internal.cacheflow.com (esxdev03.bluecoat.com [10.2.2.166]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 19B9181A5FE; Fri, 5 Dec 2014 12:08:49 -0800 (PST)
Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-06.internal.cacheflow.com ([fe80::8554:761:8def:a2e1%12]) with mapi id 14.03.0123.003; Fri, 5 Dec 2014 12:08:48 -0800
From: "Frederick, Ron" <ron.frederick@bluecoat.com>
To: Stephen Casner <casner@acm.org>
Thread-Topic: [Technical Errata Reported] RFC3550 (4192)
Thread-Index: AQHQELrmxuAoKH/WfkOd7U9S8PK7hZyB8zUA
Date: Fri, 05 Dec 2014 20:08:48 +0000
Message-ID: <7E84273F-FC12-4FB6-976A-7AF724E3D718@bluecoat.com>
References: <20141204014737.6282D181CD3@rfc-editor.org> <alpine.OSX.2.19.9991.1412051000220.30685@auge.attlocal.net>
In-Reply-To: <alpine.OSX.2.19.9991.1412051000220.30685@auge.attlocal.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.2.106]
Content-Type: multipart/alternative; boundary="_000_7E84273FFC124FB6976A7AF724E3D718bluecoatcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/iq2pPGrMLblmJGyqemzjAsOtNAE
X-Mailman-Approved-At: Sat, 06 Dec 2014 12:49:55 -0800
Cc: "schulzrinne@cs.columbia.edu" <schulzrinne@cs.columbia.edu>, "avt@ietf.org" <avt@ietf.org>, "juliusfriedman@gmail.com" <juliusfriedman@gmail.com>, "van@packetdesign.com" <van@packetdesign.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Dec 2014 20:08:52 -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 <casner@acm.org<mailto:casner@acm.org>> 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:

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 <juliusfriedman@gmail.com>

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
--
Ron Frederick
ronf@bluecoat.com<mailto:ronf@bluecoat.com>