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

Stephen Casner <casner@acm.org> Fri, 05 December 2014 18:40 UTC

Return-Path: <casner@acm.org>
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 14BDE1AD51C for <avt@ietfa.amsl.com>; Fri, 5 Dec 2014 10:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
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 CqDiNN-nOL5o for <avt@ietfa.amsl.com>; Fri, 5 Dec 2014 10:40:26 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11DB1AD516 for <avt@ietf.org>; Fri, 5 Dec 2014 10:40:26 -0800 (PST)
Received: from auge (75-25-120-141.lightspeed.snvaca.sbcglobal.net [75.25.120.141]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id sB5IduB6021270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Dec 2014 10:39:57 -0800
Date: Fri, 05 Dec 2014 10:39:56 -0800
From: Stephen Casner <casner@acm.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
In-Reply-To: <20141204014737.6282D181CD3@rfc-editor.org>
Message-ID: <alpine.OSX.2.19.9991.1412051000220.30685@auge.attlocal.net>
References: <20141204014737.6282D181CD3@rfc-editor.org>
User-Agent: Alpine 2.19.9991 (OSX 64 2014-05-31)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Sonic-CAuth: UmFuZG9tSVbuOqHsnSRiQ6RAO3ZIKcM6VrZ6naljhCyI4dqFb5fWQrNN/gMTVSLR5JRhMRNqwO/GWHIpdIOexujyjGgM+uqr
X-Sonic-ID: C;yDUMHK585BGLy1Zegs/dsg== M;6lk0HK585BGLy1Zegs/dsg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/NWugUWeUShvuSJ6-PyEOemzOemI
X-Mailman-Approved-At: Sat, 06 Dec 2014 12:49:55 -0800
Cc: schulzrinne@cs.columbia.edu, avt@ietf.org, juliusfriedman@gmail.com, van@packetdesign.com
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 18:40:28 -0000

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