Re: [MMUSIC] [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize

Julius Friedman <juliusfriedman@gmail.com> Sat, 10 January 2015 03:38 UTC

Return-Path: <juliusfriedman@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31261A7034; Fri, 9 Jan 2015 19:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 GcBoXUYNjsug; Fri, 9 Jan 2015 19:38:36 -0800 (PST)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587AA1A70FE; Fri, 9 Jan 2015 19:38:36 -0800 (PST)
Received: by mail-pd0-f172.google.com with SMTP id y13so20806959pdi.3; Fri, 09 Jan 2015 19:38:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9CkH4U1Pc2Nwro3YLKticxN09IF7x6FHbe57i/0GYhc=; b=EgDkX0pcceMttn4ObtnXL31ERFZK6D5RSFQH9ZpRKk5RWGVfG6PpgQyMq+wXfhUTjy kufJ5EB9zR88PbMQOLjL9qdMRnVzgqL5NKlLhU33D+MhYghmadZhVHwdT2vMQYNDv3E+ lL1aI0/W6wSEoR87eJnHwRdYM7nikls4NSNGH83dXdV5DhIrCVevZkuXPkGcqOGMHabG MPFjlo24+z9/WmVL7o+Neeax1+/2gTHDgklZ2tb/1fOFxCIksX0zczmMOi+YWwljkviQ g1XnVkGR9zV6VAlR06Qg9i4Mm5BrJMLmqmHx9/+heL9BjM9wg61f5veFaUD3nY1TI+03 7yMQ==
MIME-Version: 1.0
X-Received: by 10.68.236.67 with SMTP id us3mr27729223pbc.121.1420861115542; Fri, 09 Jan 2015 19:38:35 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Fri, 9 Jan 2015 19:38:35 -0800 (PST)
In-Reply-To: <87r3v38j3t.fsf@hobgoblin.ariadne.com>
References: <CACFvNHXwTm5k7Wiw65A=eSBEF9RqP4FJnNysziFik7vpnqrR4A@mail.gmail.com> <87r3v38j3t.fsf@hobgoblin.ariadne.com>
Date: Fri, 09 Jan 2015 22:38:35 -0500
Message-ID: <CACFvNHXyCbQgx3jtzShSQGT9H-TD_Wz7bEkyOB2zfQNjof1VZw@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Content-Type: multipart/alternative; boundary="047d7b2e11b1114d2e050c44021e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/NSH_Ybi8NRP0hFFpBM33dlkzVog>
Cc: mmusic@ietf.org, avt@ietf.org
Subject: Re: [MMUSIC] [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jan 2015 03:38:40 -0000

...

", it seems
to me that it counts only the bytes after the "RTP Fixed Header Fields"
and any RTP header extensions, and that number legitimately could be
small (depending on the media encoding in the RTP).
"

- There must be 12 octets which are the fixed header, this is where that
information comes from.

- If ROHC is used or some other encoding / compression which changes this
amount it is beyond the scope of RTP and that is why I say that the
underlying Transport should handle this.

We are not talking about other RFC's we are talking about the ones which
state the information (RFC2326 and it's biz draft), they introduce this
header and thus should concretely define it's functionality such that it
does not impose upon other requirements.

I am confused as how can you both say you don't understand and that there
is no error? It has now been explained further... Please re-consider, you
omitted to respond to other points within the same email chain which relate
to the problem so it imposes upon my response and would cause me to repeat
data here again which I was asked not to before.

If there is a better mechanism for communication of these issues please let
me know, I would be happy to prepare a summary and present it either as a
document or over a tele-conference to address this as well as any other
points which have yet to be addressed.

If there is no error then what is the process to include this useful
information in some way so that others may know as well?

I sincerely appreciate your time,
Julius



On Fri, Jan 9, 2015 at 9:28 PM, Dale R. Worley <worley@ariadne.com> wrote:

> Julius Friedman <juliusfriedman@gmail.com> writes:
> > 18.10 <
> http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.10>.
> > Blocksize
> >
> >    The Blocksize request-header field is sent from the client to the
> >    media server asking the server for a particular media packet size.
> >    This packet size does not include lower-layer headers such as IP,
> >    UDP, or RTP.  The server is free to use a blocksize which is lower
> >    than the one requested.  The server MAY truncate this packet size to
> >    the closest multiple of the minimum, media-specific block size, or
> >    override it with the media-specific size if necessary.  The block
> >    size MUST be a positive decimal number, measured in octets.  The
> >    server only returns an error (4xx) if the value is syntactically
> >    invalid.
> >
> > Both paragraphs go to specify that the number MUST be positive but
> > specify no LOWER bound.
> >
> > A Blocksize of 12 or less will cause data loss under UDP and cause
> > invalid framing under TCP.
>
> Could you explain this in more detail?  Since the "Blocksize" number
> "does not include lower-layer headers such as IP, UDP, or RTP", it seems
> to me that it counts only the bytes after the "RTP Fixed Header Fields"
> and any RTP header extensions, and that number legitimately could be
> small (depending on the media encoding in the RTP).
>
> > It should be noted that the Blocksize MUST be a positive decimal
> > number greater than or equal to that supported by the underlying
> > transport.
>
> In any case, *this* RFC does not *have* to state that, as that is a
> requirement imposed by other RFCs.
>
> > I would like to file this errata as soon as possible if everyone agrees;
> >
> > If it's not erratum can we please also address this misnomer I seem to
> have.
>
> As far as I can tell, it's not an erratum, because there is no "error"
> in the RFC.  What you're suggesting is that there is useful information
> that the RFC does not include, but that information is not an error in
> this RFC's text.
>
> Dale
>