IETF Logo Mail Archive

Re: [AVTCORE] Header Compression and RFC5285bis

"Roni Even" <ron.even.tlv@gmail.com> Tue, 10 May 2016 07:36 UTC

Return-Path: <ron.even.tlv@gmail.com>
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 BB0DC12D1CA for <avt@ietfa.amsl.com>; Tue, 10 May 2016 00:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 h2ZoHqVXPUQ9 for <avt@ietfa.amsl.com>; Tue, 10 May 2016 00:36:27 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 8BE7412D580 for <avt@ietf.org>; Tue, 10 May 2016 00:36:24 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id n129so165975905wmn.1 for <avt@ietf.org>; Tue, 10 May 2016 00:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=rn6jtKBbumxqp0FJKJ3aPrS7mr9QBOcVu6hpnte1M78=; b=HGkPnSKnVJxVChjQQzdQzOeQtRH0nvNt7cDcrLOr0nmrR6rchJFv/z/ZSNHf3hj9u0 IBNVCfGsl0yCDDPbjTkxPBlg/fM4NOrWDTRdaOi8oMHCNSwvozYU7UtdWi1Br9OGqIZR TFjrFyHu9G6QT3sgk6PdnDkUXF6Y/DzDnma38ynp/diGwWzAfzOXQT9huGv6D7InvAQA Pi4Co68kjvs2tdQn5fTIuinGuigNF3pNyXAOAS6yI2xm/kARHKNck33Rek6Xe0/VP+5C ApwKJzTXAa4z0AsFhEos8c1k5EnpnoYL8TZDtWSMyvNsnCvn7duzp2UjrbxaD0dsW1N1 wE+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=rn6jtKBbumxqp0FJKJ3aPrS7mr9QBOcVu6hpnte1M78=; b=iWxINf+rD5VCArQwlRN2Srb6FkXI7yVn5kl3uhBrHX1GyJZmeWdm5C2+PcaIVjfSRa 8OSah8if+ZUteei8ZZ1aPchCoRQLJUuT20nFPiNLE0DdTKGbQhnR3205jbYmWvu7G7pg D7BBv0+7O74ip3po4IwmZr/3MtFZtIoCz4F40I8pYzONc6lvHbmwAkq60tvDXPbiqyHV C3UI2cDVBFbciwSdIpVIpl4eZgO5/933uTfnhmQNZj8YjydA5kL/dkaUKkebvn9KEoVq gvaEhxOto/bqH2WxiZEFMuzELmWFHlIYTYkxX/HNJcY55HbdtPBVNSTXbJdAXvI7RAWj upTg==
X-Gm-Message-State: AOPr4FWhJQZRg6NXoUk0Tj5wF/frVW0O7ApTCfpERB+kVSmAkdoRF2TheVowH0AOQdlPpA==
X-Received: by 10.194.236.3 with SMTP id uq3mr26749619wjc.44.1462865781686; Tue, 10 May 2016 00:36:21 -0700 (PDT)
Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id jr8sm956238wjb.15.2016.05.10.00.36.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 00:36:20 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'IETF AVTCore WG' <avt@ietf.org>, 'Stephen Casner' <casner@acm.org>
References: <56FFE98E.2070406@ericsson.com>
In-Reply-To: <56FFE98E.2070406@ericsson.com>
Date: Tue, 10 May 2016 10:36:07 +0300
Message-ID: <071a01d1aa8e$9e4c1800$dae44800$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKz49dNSeiH6WyIxJ1uGuCsbsh9+J3tVRoA
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/X3p9pRpdAUlxV_fcld2PrvzJcNI>
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: Tue, 10 May 2016 07:36:30 -0000

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

v2.23.0 | Report a Bug | By Email