From tellviveks@gmail.com Fri Apr 1 22:57:03 2011 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669333A6A43 for ; Fri, 1 Apr 2011 22:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SiT9ZaC1Ntc for ; Fri, 1 Apr 2011 22:57:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 571A03A6A3B for ; Fri, 1 Apr 2011 22:57:01 -0700 (PDT) Received: by iwn39 with SMTP id 39so4742846iwn.31 for ; Fri, 01 Apr 2011 22:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LYP8SRMcpich7cKtmxHeTzsBgLyG+8FkrT4G1yd20MA=; b=EmTe9yAUEeYWHlXemTXpeBE9HrK+Sdd35BrESXmZViAPWHbl1y8uVcLz5DyA4A3yi9 Jlt0pxxTVjxMmrtq8cHafmskytZFAvpeIWM1TNgUw9wnPF6PBAMImVhpMYoDG6rQxlby U7YugAZsjGivVv0Wk+gu4nEUa6G8gEDsZjHiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hSDVjg0/otmQTvBIICx3e0b/ilKHmiGVQ+K/6AUnu2tnzL8vUEFum7jlXOZueSB7dO YXBkNAy1Kd5SoOFGqNB8KDv1JD4lDeEX6zPx9xPtdy/SMm+mJ3DoB8bz4CcApkzyGb6d C2Fds77PnjnD1TmCxmxxUfu5WmuSRQ42BaPow= MIME-Version: 1.0 Received: by 10.231.91.148 with SMTP id n20mr4714419ibm.112.1301723920985; Fri, 01 Apr 2011 22:58:40 -0700 (PDT) Received: by 10.231.79.9 with HTTP; Fri, 1 Apr 2011 22:58:40 -0700 (PDT) In-Reply-To: <4D90907A.4000405@effnet.com> References: <4D90907A.4000405@effnet.com> Date: Sat, 2 Apr 2011 14:58:40 +0900 Message-ID: From: Vivek Soni To: Carl Knutsson , rohc@ietf.org Content-Type: multipart/alternative; boundary=bcaec543192ce7ede2049fe937e7 X-Mailman-Approved-At: Sun, 03 Apr 2011 23:41:55 -0700 Subject: Re: [rohc] RoHC Profile 4 Static chain termination X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 05:57:03 -0000 --bcaec543192ce7ede2049fe937e7 Content-Type: text/plain; charset=ISO-8859-1 Hello Carl, Thanks for the clarification. As I understand from your reply, 1. If the static chain is implicitly terminated by the next header field, the compressor MAY or MAY NOT mark the MSB. In case the compressor does marks the MSB, it just becomes redundant and is not a problem. 2. In case the compressor tries to compress only few IP headers, it explicitly marks the MSB to indicate the end of static chain. I felt the text of RFC 3843 section 3.1 is not very clear about this. Hence the confusion. Regards, Vivek On Mon, Mar 28, 2011 at 10:43 PM, Carl Knutsson wrote: > Hi Vivek, > > I guess you are referring to profile 0x0004 in RFC 3843 section 3.1. > > I don't think I understand exactly what you are trying to change or > clarify with your suggestion. > > The version field MSB is used to terminate the static chain when it > isn't implicitly given by the next header/protocol field. For example if > you want to compress only the IPv4 header for an IPv4/IPv6 packet. Or do > you want to disqualify the use of the version field static chain > termination in those cases were the end is implicitly given by the > protocol field? In that case the MSB in the IP version field may be > redundant but the compression will function correctly. > In any case I can't really see that this requires a correction or > clarification to the RFC. > > Note that this RFC that was published some years ago, so we are not > likely to change it for smaller editorial fixes. We could file an > errata, but at this point I can't see anything in the static chain > termination section that needs a clarification or correction. > > cheers, > > /Calle > > > On 03/28/2011 04:24 AM, Vivek Soni wrote: > > Hello, > > > > I understand that the compressor can terminate the static chain at any > > header by explicity setting the MSB of version field. But I am not clear > > when exactly should compressor do this. > > > > My understanding is that it is applicable only when there are multiple > > IP headers and compressor decides to compress only few of them. > > > > Whereas in other cases for example > > 1. The packet has only one IP header ("Protocol"/"next header" field is > > other than IPinIP or IPv6) > > 2. The packet has multiple IP headers and the compressor compresses all > > of them. > > > > In both these cases, the static chain termination is implicit. Therefore > > the compressor need not (SHOULD NOT) > > indicate the end of static chain explicitly by setting MSB of version > field. > > > > Is this understanding of mine correct. In that case, would be it be > > better if RFC is more clear about it by using > > stronger text like "SHOULD NOT" instead of "Alternatively". > > > > Regards, > > Vivek > > > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www.ietf.org/mailman/listinfo/rohc > > --bcaec543192ce7ede2049fe937e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Carl,

Thanks for the clarification.=A0As I underst= and from your reply,

1. If the static chain is imp= licitly terminated by the next header field, the compressor MAY or MAY NOT= =A0mark the MSB.=A0
In case the compressor does marks the MSB, it just becomes redundant a= nd is not a problem.

2. In case the compressor tri= es to compress only few IP headers, it explicitly marks the MSB to indicate= the end of=A0static chain.

I felt the text of=A0=A0RFC 3843 section 3.1 is not ver= y clear about this. Hence the confusion.

Regards,<= /div>
Vivek


On Mon, Mar 28= , 2011 at 10:43 PM, Carl Knutsson <carl.knutsson@effnet.com> wrote:
Hi Vivek,

I guess you are referring to profile 0x0004 in RFC 3843 section 3.1.

I don't think I understand exactly what you are trying to change or
clarify with your suggestion.

The version field MSB is used to terminate the static chain when it
isn't implicitly given by the next header/protocol field. For example i= f
you want to compress only the IPv4 header for an IPv4/IPv6 packet. Or do you want to disqualify the use of the version field static chain
termination in those cases were the end is implicitly given by the
protocol field? In that case the MSB in the IP version field may be
redundant but the compression will function correctly.
In any case I can't really see that this requires a correction or
clarification to the RFC.

Note that this RFC that was published some years ago, so we are not
likely to change it for smaller editorial fixes. We could file an
errata, but at this point I can't see anything in the static chain
termination section that needs a clarification or correction.

cheers,

/Calle


On 03/28/2011 04:24 AM, Vivek Soni wrote:
> Hello,
>
> I understand that the compressor can terminate the static chain at any=
> header by explicity setting the MSB of version field. But I am not cle= ar
> when exactly should compressor do this.
>
> My understanding is that it is applicable only when there are multiple=
> IP headers and compressor decides to compress only few of them.
>
> Whereas in other cases for example
> 1. The packet has only one IP header ("Protocol"/"next = header" field is
> other than IPinIP or IPv6)
> 2. The packet has multiple IP headers and the compressor compresses al= l
> of them.
>
> In both these cases, the static chain termination is implicit. Therefo= re
> the compressor need not (SHOULD NOT)
> indicate the end of static chain explicitly by setting MSB of version = field.
>
> Is this understanding of mine correct. In that case, would be it be > better if RFC is more clear about it by using
> stronger text like "SHOULD NOT" instead of "Alternative= ly".
>
> Regards,
> Vivek
>
>
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www.ietf.org/mailman/listinfo/rohc


--bcaec543192ce7ede2049fe937e7-- From tellviveks@gmail.com Mon Apr 25 03:11:42 2011 Return-Path: X-Original-To: rohc@ietfc.amsl.com Delivered-To: rohc@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 27C1DE0725 for ; Mon, 25 Apr 2011 03:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMg7b0JnpdMl for ; Mon, 25 Apr 2011 03:11:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 4C97CE0726 for ; Mon, 25 Apr 2011 03:11:41 -0700 (PDT) Received: by iyn15 with SMTP id 15so1500141iyn.31 for ; Mon, 25 Apr 2011 03:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Gc94P5fY5OGXyiXnLYlzAGgP8kGgnCIPLlPL02idSZw=; b=PJLhqDLMP+fiSrfy/ZdlnudVD0IefFlmV1MLA0ijGY29DXHs63ENPGvcz5NSxhzF8a 5dxS5y5GSxLMO78V1UafvuN9MU0D2bFj2cleiEp87ywvE4TbDkKlrTKdUEPHSkUEak5x y3yOUbZ783dFbDTXG3TUCnSC0t73YP8JTNM78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Racq57YMVKWzUaajrkxMdk7KylU0hvJWohNW9HjySnEhy99ajKXuuHb0zV7UafStv3 eGXh0qzzD/G6HxWFiD0sqlz8STfMrXGWpjWitE9iOgpOUWhELmtj0XvqWfQ3V3CnsIV7 IhvfXRgIm/a0R2RyYatMGJI2SKT43CGTI8lsA= MIME-Version: 1.0 Received: by 10.231.206.14 with SMTP id fs14mr2726170ibb.104.1303726300889; Mon, 25 Apr 2011 03:11:40 -0700 (PDT) Received: by 10.231.79.14 with HTTP; Mon, 25 Apr 2011 03:11:40 -0700 (PDT) Date: Mon, 25 Apr 2011 19:11:40 +0900 Message-ID: From: Vivek Soni To: rohc@ietf.org Content-Type: multipart/alternative; boundary=90e6ba4fc31c0c83a704a1bb6fa8 X-Mailman-Approved-At: Wed, 27 Apr 2011 00:14:16 -0700 Subject: [rohc] Clarification sought for RTP CSRC list compression [RohC v1] X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 10:11:42 -0000 --90e6ba4fc31c0c83a704a1bb6fa8 Content-Type: text/plain; charset=ISO-8859-1 Dear all, Would appreciate if someone can clarify the following doubt. Consider an RTP flow with all packets having one CSRC element. Case 1: The compressor creates a gen_id for the list and starts enocoding these packets in ET=0 packet types along with gen_id. At some of point of time it decides to use this gen_id as ref_id and encodes the packet without the CSRC info(say U0 packet) and expects the decompressor to use the ref_id to recreate the CSRC element. Case 2. The compressor creates a gen_id for the list and starts enocoding these packets in ET=0 packet types along with gen_id. At some of time before it receives a packet without any CSRC element and thus enocodes it using a packet type without CSRC info (say U0). How does the decompressor differentiate between the two cases. For case 1, the decompressor should refer to its ref_id and create CSRC element whereas for case 2 it should not.How can the decompressor decide if the compressed packet it received is encoded using a reference list or not. Additionally, how does the compressor informs the decompressor not to use the ref_id any more. Regards, Vivek --90e6ba4fc31c0c83a704a1bb6fa8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

Would appreciate if someone can cla= rify the following doubt.

Consider an RTP flow wit= h all packets having one CSRC element.

Case 1:
The compressor creates a gen_id for the list and starts enocoding thes= e packets in ET=3D0 packet types along with gen_id.
At some of po= int of time it decides to use this gen_id as ref_id and encodes the packet = without the CSRC info(say U0 packet)=A0
and expects the decompressor to use the ref_id to recreate the CSRC el= ement.

Case 2.=A0
The compressor creates= a gen_id for the list and starts enocoding these packets in ET=3D0 packet = types along with gen_id.
At some of time before it receives a packet without any CSRC element a= nd thus enocodes it using a packet type without CSRC info (say U0).

How does the decompressor differentiate between the two c= ases. For case 1, the decompressor should refer to its ref_id and create CS= RC element
whereas for case 2 it should not.How can the decompressor decide if th= e compressed packet it received is encoded using a reference list or not.

Additionally, how does the compressor informs the d= ecompressor not to use the ref_id any more.

Regards,
Vivek=A0

--90e6ba4fc31c0c83a704a1bb6fa8--