Re: [AVTCORE] Header Compression and RFC5285bis

Stephen Casner <casner@acm.org> Wed, 11 May 2016 05:49 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 9D47F12D0E6 for <avt@ietfa.amsl.com>; Tue, 10 May 2016 22:49:22 -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 er9bAW4uZsi1 for <avt@ietfa.amsl.com>; Tue, 10 May 2016 22:49:20 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 719DD12B01A for <avt@ietf.org>; Tue, 10 May 2016 22:49:20 -0700 (PDT)
Received: from [10.99.0.14] (mail.brookshotel.ie [89.101.214.206]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u4B5n9h5007028 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 May 2016 22:49:12 -0700
Date: Wed, 11 May 2016 06:49:07 +0100 (BST)
From: Stephen Casner <casner@acm.org>
To: Roni Even <ron.even.tlv@gmail.com>
In-Reply-To: <071a01d1aa8e$9e4c1800$dae44800$@gmail.com>
Message-ID: <alpine.OSX.2.20.1605110646350.94339@auge.local>
References: <56FFE98E.2070406@ericsson.com> <071a01d1aa8e$9e4c1800$dae44800$@gmail.com>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-1210406478-1462945613=:94339"
X-Sonic-CAuth: UmFuZG9tSVYwa6F59aTMJIeV1cyyscwEpqeK8GkoOcCSyxbeF+VdTOl3OMD99bcyI6L81adBVK0cp5uOPTSOxhUpOfZJhQV0
X-Sonic-ID: C;Wuu1FDwX5hGhwreqjlfmnQ== M;nhQQFjwX5hGhwreqjlfmnQ==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/dkucy427tY073-1GP1N75YpsBPI>
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 05:49:22 -0000

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