Re: [rohc] Comments on RFC 4997

Klaus Warnke <klaus.warnke@acticom.de> Fri, 19 June 2009 09:20 UTC

Return-Path: <klaus.warnke@acticom.de>
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 171193A69E1 for <rohc@core3.amsl.com>; Fri, 19 Jun 2009 02:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 WJ-MX+tkSgXS for <rohc@core3.amsl.com>; Fri, 19 Jun 2009 02:20:25 -0700 (PDT)
Received: from mail.acticom-networks.com (mail.acticom-networks.com [87.106.254.214]) by core3.amsl.com (Postfix) with ESMTP id 9FE973A6A10 for <rohc@ietf.org>; Fri, 19 Jun 2009 02:20:25 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.acticom-networks.com (Postfix) with ESMTP id 158F51C00435; Fri, 19 Jun 2009 11:20:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at acticom-networks.com
Received: from mail.acticom-networks.com ([127.0.0.1]) by localhost (mail.acticom-networks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osw9RMbunx3Q; Fri, 19 Jun 2009 11:20:30 +0200 (CEST)
Received: from godfather.bln.acticom.de (mail.oosoft.net [212.99.204.33]) by mail.acticom-networks.com (Postfix) with ESMTP id 3A6011C0042E; Fri, 19 Jun 2009 11:20:30 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by godfather.bln.acticom.de (Postfix) with ESMTP id AC574F3ADA; Fri, 19 Jun 2009 11:20:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at bln.acticom.de
Received: from godfather.bln.acticom.de ([127.0.0.1]) by localhost (godfather.bln.acticom.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn6IWtQ4awDL; Fri, 19 Jun 2009 11:20:27 +0200 (CEST)
Received: from [192.168.33.27] (tornado.bln.acticom.de [192.168.33.27]) by godfather.bln.acticom.de (Postfix) with ESMTP id 26610F3AD5; Fri, 19 Jun 2009 11:20:27 +0200 (CEST)
Message-ID: <4A3B585B.5000409@acticom.de>
Date: Fri, 19 Jun 2009 11:20:27 +0200
From: Klaus Warnke <klaus.warnke@acticom.de>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Lee, Jiwoong" <jiwoongl@qualcomm.com>
References: <29F0770B56D6A94794A647432F9A9EF0685CDB33D5@NALASEXMB14.na.qualcomm.com>
In-Reply-To: <29F0770B56D6A94794A647432F9A9EF0685CDB33D5@NALASEXMB14.na.qualcomm.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "rohc@ietf.org" <rohc@ietf.org>
Subject: Re: [rohc] Comments on RFC 4997
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 09:20:27 -0000

Hi Lee,

from my point of view the definitions are correct.

A compressed value is a value that exist in a compressed format only.

The discriminator is used to distinguish the packets to choose
the correct format for decompression. Therefore this field does
not appear in a uncompressed format.

 > field_4 =:= '1010'; // set ULENGTH to zero

If a compressed packet start with '1010' the COMPRESSED format3
could be used. But the field_4 does not appear in a UNCOMPRESSED
format, so the ULENGTH is zero.

 > abc_flag_bits =:= uncompressed_value(3, 7) [0];

eg_header
{
UNCOMPRESSED {
abc_flag_bits [ 3 ];
}

COMPRESSED flags_set {
abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
}
}

To compress a eg_header into the flags_set format, the
abs_flag_bits field in the uncompressed eg_header with the length
3 must have the value 7. If not, the flags_set format can not be
used, an other format must (irregular, for example). But the
value 7 itself does not appear in the flags_set format itself,
therefore the CLENTH is zero. It is compressed away.

The '[3]' in the UNCOMPRESSED format says, that this field is in
this format three bits in length. You can see this also in every
COMPRESSED format definiton:

abc_flag_bits =:= irregular(3) [ 3 ];
abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
abc_flag_bits =:= static [ 0 ];

In irregular the field is send as it is with 3bits. For
uncompressed_value see above. In static, the value in the
eg_header must be the same as saved in the context. To
decompressed such format, a value in the context must exist.

The fn defines a two way mapping between uncompressed and
compressed format. You can use the eg_header UNCOMPRESSED ->
COMPRESSED flags_set mapping, if all definitions could be
fulfilled. Maybe more than one works for compression.
And vice versa.

This is how I understand the fn.

br
Klaus Warnke

Lee, Jiwoong wrote:
>
> Dear ROHC WG,
>
> I hope this comment was not discussed before. At least my quick search 
> did not find the related thread.
>
> These are some questions and comments about RFC 4997.
>
> 1. Definition of Single quotes
>
> According to pp 26 of the same document, a discriminator is defined
> discriminator =:= '01101';
> as equivalent to
> discriminator =:= compressed_value(5, 13);
>
> In pp 36 the last paragraph, COMPRESSED format3 was defined with
> field_4 =:= '1010'; // set ULENGTH to zero
>
> Here unless one do not impose different interpretation of the single
> quotes for the /field/ and the /discriminator/, wouldn’t it be better
> to change this into the following?
> field_4 =:= '1010'; // set ULENGTH to 4
>
> 2. Possible error in the Worked Example
>
> I suspected in Appendix B.7 pp. 56 “COMPRESSED flags_set” format,
>
> abc_flag_bits =:= uncompressed_value(3, 7) [0];
>
> shoud be corrected to
>
> abc_flag_bits =:= irregular(3) [3];
>
> Accordingly, subsequent examples till Appendix B.8 should be corrected.
>
> 3. Encoding function naming issue.
>
> To my impression, the ROHC documents are using the notion and the term 
> “compression” to mean both of compression and encoding, as if they are 
> the same. I believe it is not.
>
> To single out a case, the same document is defining encoding functions
>
> “uncompressed_value( ., . )” and “compressed_value( ., .)”
>
> These functions are indeed for inference functions. That is, it says 
> “the field value can be computed by using other explicit field 
> values”. Above naming does not carry this descriptive understanding at 
> all. I understand the author’s original idea of that naming – which is 
> possibly derived from the fact that the associated field is/is not 
> defined in UNCOMPRESSED/COMPRESSED format, or so, which is less 
> crucial in catching the notion of “inference” encoding.
>
> I will appreciate your inputs.
>
> Many thanks,
>
> Jwoong
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www.ietf.org/mailman/listinfo/rohc
>   


-- 
Klaus Warnke                klaus.warnke@acticom.de
http://www.acticom.de
Tel +49-30-4303.2510        Fax +49-30-4303.2519
* --------------------------------------------------------- *
acticom GmbH
Am Borsigturm 42, 13507 Berlin, Germany
Managing Directors:  Olaf Kehrer, Gerrit Schulte
Commercial Register: Berlin-Charlottenburg HRB 73245
VAT-ID DE205131766
* --------------------------------------------------------- *
This email and the information it contains may be
privileged and/or confidential. It is for the intended
addressee(s) only. The unauthorised use, disclosure or
copying of this email, or any information contained,
is prohibited. If you are not an intended recipient,
please notify the sender immediately and delete this email.