Re: [AVTCORE] Header Compression and RFC5285bis

Stephen Casner <casner@acm.org> Wed, 11 May 2016 19:22 UTC

Return-Path: <casner@acm.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779B912D7A5 for <avt@ietfa.amsl.com>; Wed, 11 May 2016 12:22:31 -0700 (PDT)
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 autolearn_force=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 eiIoYA3L4foc for <avt@ietfa.amsl.com>; Wed, 11 May 2016 12:22:30 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14B012D76F for <avt@ietf.org>; Wed, 11 May 2016 12:22:24 -0700 (PDT)
Received: from [10.134.156.193] ([5.149.174.126]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u4BJMHh3005760 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 May 2016 12:22:18 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Stephen Casner <casner@acm.org>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <082301d1aba6$bc375a00$34a60e00$@gmail.com>
Date: Wed, 11 May 2016 20:22:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1E96DD1-E810-413B-B4F3-D6B0AA8F52CF@acm.org>
References: <56FFE98E.2070406@ericsson.com> <071a01d1aa8e$9e4c1800$dae44800$@gmail.com> <alpine.OSX.2.20.1605110646350.94339@auge.local> <082301d1aba6$bc375a00$34a60e00$@gmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
X-Sonic-CAuth: UmFuZG9tSVY7LRQlWmpcrafc+X+jhFz4p0oLPujOZJWrmRJ+GC/vnofuIe2H1CJ/CccF+KlgY/VraPOW5TC7ln/egGRTeLhb
X-Sonic-ID: C;uCtjrK0X5hG6bLEI9Bb3tg== M;SJZOra0X5hG6bLEI9Bb3tg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/oljRx1bf8Axza797FZMhiN1my_w>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] Header Compression and RFC5285bis
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 11 May 2016 19:22:31 -0000

Yes, that's fine. Thanks.

-- Steve

> On May 11, 2016, at 6:01 PM, Roni Even <ron.even.tlv@gmail.com> wrote:
> 
> Steve,
> This is the full paragraph in the current version.
> It looks OK to me
> 
> "Use of RTP header extensions will reduce the efficiency of RTP header
>   compression, since the header extension will be sent uncompressed
>   unless the RTP header compression module is updated to recognize the
>   extension header.  If header extensions are present in some packets,
>   but not in others, this can also reduce compression efficiency by
>   requiring an update to the fixed header to be conveyed when header
>   extensions start or stop being sent.  The interactions of the RTP
>   header extension and header compression is explored further in
>   [RFC2508] and [RFC3095]."
> 
> Roni
> 
>> -----Original Message-----
>> From: Stephen Casner [mailto:casner@acm.org]
>> Sent: Wednesday, May 11, 2016 8:49 AM
>> To: Roni Even
>> Cc: 'Magnus Westerlund'; 'IETF AVTCore WG'
>> Subject: RE: [AVTCORE] Header Compression and RFC5285bis
>> 
>> Roni,
>> 
>> I think it would be appropriate to include another sentence before the one
>> you propose:  "The use of RTP header extensions may reduce the
>> effectiveness of header compression."
>> 
>>                                                        -- Steve
>> 
>>> On Tue, 10 May 2016, Roni Even wrote:
>>> 
>>> Hi Magnus,
>>> I am updating the document based on other comments from Colin.
>>> The current text says "The interactions of the RTP   header extension
> and
>>> header compression is explored further in   [RFC2508] and [RFC3095]."
>>> Do you think we need more text here? Any suggestions Roni
>>> 
>>>> -----Original Message-----
>>>> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Magnus
>>>> Westerlund
>>>> Sent: Saturday, April 02, 2016 6:47 PM
>>>> To: IETF AVTCore WG; Stephen Casner
>>>> Subject: [AVTCORE] Header Compression and RFC5285bis
>>>> 
>>>> Hi,
>>>> 
>>>> Stephen Casner raised a private comment on the
>>>> draft-ietf-avtext-sdes-hdr-ext-05 when he did the IANA expert review.
>>>> This was that both
>>>> draft-ietf-avtext-sdes-hdr-ext-05 and RFC5285bis doesn't discuss
>>>> impact of header compression due to the presence of RTP header
>> extensions.
>>>> 
>>>> I have to agree that this is something that at least RFC5285bis
>>>> should
>>> have a
>>>> discussion on. There are some impact.
>>>> 
>>>> In the case of Robust Header Compression (ROHC) (RFC 5795 and RFC
>>>> 5225) the impact to my understanding is the following. RFC5225 and
>>>> the RTP profile don't compress the actual header extension at all.
>>>> The X bit in
>>> the
>>>> header is compressed and it is classified in Section A.5 as Rarely
>>> changing.
>>>> The assumption here is that what value is set on a previous packet
>>>> will be maintained on the next.
>>>> 
>>>> Looking at the emerging usages that is mostly right, but there will
>>>> be
>>> periods
>>>> where the x bit may be flipping its value. The usage I am
>>>> considering is
>>> these
>>>> initial inclusion of the MID, CNAME etc. However for example a video
>>>> stream, it is sufficient to include the header extension in a single
>>> packet out
>>>> potentially many for an particular video image/frame. Thus one might
>>>> have
>>> a
>>>> on, off, next TS, on, then off on subsequent packets.
>>>> 
>>>> The impact of the classification as Rarely changing is that when a
>>>> change
>>> is
>>>> needed a larger header than otherwise needed will be sent.
>>>> Thus the impact will be that each on and off behaviour will result
>>>> in one
>>> and
>>>> maybe two larger ROHC headers to get the change across compared to
>>>> if no RTP header extensions would have been present.
>>>> 
>>>> I haven't looked at CRTP, but I would guess similar impact.
>>>> 
>>>> Cheers
>>>> 
>>>> Magnus Westerlund
>>>> 
>>>> --------------------------------------------------------------------
>>>> -- Services, Media and Network features, Ericsson Research EAB/TXM
>>>> ----------------------------------------------------------------------
>>>> Ericsson AB                 | Phone  +46 10 7148287
>>>> Färögatan 6                 | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden | mailto:
>> magnus.westerlund@ericsson.com
>>>> --------------------------------------------------------------------
>>>> --
>>>> 
>>>> _______________________________________________
>>>> Audio/Video Transport Core Maintenance avt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/avt
> 
>