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 > >
- [AVTCORE] Header Compression and RFC5285bis Magnus Westerlund
- Re: [AVTCORE] Header Compression and RFC5285bis Roni Even
- Re: [AVTCORE] Header Compression and RFC5285bis Stephen Casner
- Re: [AVTCORE] Header Compression and RFC5285bis Roni Even
- Re: [AVTCORE] Header Compression and RFC5285bis Roni Even
- Re: [AVTCORE] Header Compression and RFC5285bis Stephen Casner