From rohc-bounces@ietf.org Fri Apr 1 02:38:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22395 for ; Fri, 1 Apr 2005 02:38:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGqq-00065o-R8 for rohc-web-archive@ietf.org; Fri, 01 Apr 2005 02:45:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGjE-0005GN-Mf; Fri, 01 Apr 2005 02:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGjB-0005Fh-KL for rohc@megatron.ietf.org; Fri, 01 Apr 2005 02:38:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22331 for ; Fri, 1 Apr 2005 02:38:00 -0500 (EST) Received: from smtp2.wanadoo.fr ([193.252.22.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGqS-00064m-Ou for rohc@ietf.org; Fri, 01 Apr 2005 02:45:33 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0202.wanadoo.fr (SMTP Server) with ESMTP id DBBF51C001CA for ; Fri, 1 Apr 2005 09:37:50 +0200 (CEST) Received: from wanadoo.fr (AMontpellier-152-1-16-52.w81-251.abo.wanadoo.fr [81.251.166.52]) by mwinf0202.wanadoo.fr (SMTP Server) with ESMTP id EFCA81C001AA; Fri, 1 Apr 2005 09:37:49 +0200 (CEST) X-ME-UUID: 20050401073749982.EFCA81C001AA@mwinf0202.wanadoo.fr Message-ID: <424CFA44.2030304@wanadoo.fr> Date: Fri, 01 Apr 2005 09:37:40 +0200 From: Herve Siegrist User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: "Lepine, Jean-Pierre" Subject: Re: [rohc] SigComp User Guide, deflate bytecode References: <1CCF22B8BDBD254DA84EC0B05D3DAEEC029CAD29@mtlexch01.mtl.cmac.com> In-Reply-To: <1CCF22B8BDBD254DA84EC0B05D3DAEEC029CAD29@mtlexch01.mtl.cmac.com> X-Spam-Score: 1.6 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: abigail.surtees@roke.co.uk, rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878577395==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --===============0878577395== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Well, actually, I would think that these extra bytes are actually record marking bytes, but not SigComp record marking: they are the bytes generated by the ZLIB library when you use it for partial compression, i.e.: call its deflate method with the flush argument set to Z_SYNC_FLUSH to compress a partial block.

This lets your compressor compress successive messages while keeping the compression history of the previous messages, hence making the compression of further messages more efficient. This mode of operation is needed to implement dynamic compression as per RFC 3321 when using ZLIB to compress the data.

>From the SigComp standpoint, these ZLIB record marking bytes can then safely be suppressed from the compressed data as the decompression bytecode does not need them...

Herve.
Hi,
 
I hope I'm not too late but I just saw a posting dated from 14 Mar 2005 (see below). After reading the User Guide, I thought the extra "ff ff" may have been placed there for the sake of record marking in a stream-based application. Does this make sense ?
 
Jean-Pierre
 
 
 
Hi Herve,

>
> While I'm at it, just one more little question on that topic:
> what are the extra "0000 00ff ff00" bytes added at the end of
> the sample message provided in the draft? They do not seem to
> relate to actual compressed data, and the sample message
> decompresses just as well without them...

You're right, it does. 
They don't break anything by being there because although the sentinel of 7
bits of zero is not necessary (as the draft says) it just happens that in
this message the total number_of_bits_needed mod 8 = 1 so we do have the 7
bit sentinel to make the message byte aligned.  Any bytes beyond it are
ignored.

I'm not sure why the bytes are there and they're not needed, so I'll remove
them. 

Thanks for pointing it out.

Best regards,

Abbie
>
> Herve Siegrist.
>
>
> _______________________________________________
> Rohc mailing list
> Rohc at ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
--===============0878577395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0878577395==-- From rohc-bounces@ietf.org Fri Apr 1 02:52:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23379 for ; Fri, 1 Apr 2005 02:52:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHH4J-0006W2-JK for rohc-web-archive@ietf.org; Fri, 01 Apr 2005 02:59:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGuP-0007ZO-Ji; Fri, 01 Apr 2005 02:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGuN-0007ZE-Ad for rohc@megatron.ietf.org; Fri, 01 Apr 2005 02:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23120 for ; Fri, 1 Apr 2005 02:49:34 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHH1d-0006Q6-Jf for rohc@ietf.org; Fri, 01 Apr 2005 02:57:07 -0500 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j317n6P2024819 for ; Fri, 1 Apr 2005 09:49:32 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 09:49:27 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 09:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2005 09:49:26 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2782@esealmw109.eemea.ericsson.se> Thread-Topic: Lessons learned from 5 years of 3095 experience Thread-Index: AcU2j1Prk9HYBxB2Rfikz0LR8TlFmA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 01 Apr 2005 07:49:27.0206 (UTC) FILETIME=[54468C60:01C5368F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Subject: [rohc] Lessons learned from 5 years of 3095 experience X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable ROHCers, In the ROHC implementer's guide, we have collected clarifications to ambiguities, inconsistencies, and other specification flaws of RFC 3095. The purpose of this has been to guide implementer's towards interoperability and functional operation, but not to introduce=20 changes to any well specified mechanisms, even if we have seen potential for improvements. The implementer's guide therefore got an appendix B where additional ideas for improvements, based on experience, could be collected. However, there is currently not much in this appendix. Now with 5 years of RFC 3095 experience, I think it would be a proper time to start collecting additional experience-based ideas also for appendix B. We should do this while we have implementer's actively involved in the working group, and before we all start forgetting what we have disliked in 3095. When doing ROHC TCP, we have already taken our 3095 experiences into account, so we can probably identify the most important ideas by looking into what we have done different with ROHC TCP. However, there are probably additional RTP-specific=20 issues that are also worth paying attention to and document. So, please contribute with your reflections and ideas! BR /L-E -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 8 404 29 61 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 4 16:08:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25592 for ; Mon, 4 Apr 2005 16:08:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXzr-0003jw-9Y for rohc-web-archive@ietf.org; Mon, 04 Apr 2005 16:16:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXcD-0000lc-Ae; Mon, 04 Apr 2005 15:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXcA-0000k2-2w; Mon, 04 Apr 2005 15:52:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19745; Mon, 4 Apr 2005 15:52:00 -0400 (EDT) Message-Id: <200504041952.PAA19745@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Apr 2005 15:51:59 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-11.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : ROHC Implementer's Guide Author(s) : L. Jonsson, P. Kremer Filename : draft-ietf-rohc-rtp-impl-guide-11.txt Pages : 23 Date : 2005-4-4 This document describes common misinterpretations and some ambiguous points of RFC 3095, which defines the framework and four profiles of a robust and efficient header compression scheme. The members of the ROHC working group have identified these issues during implementation and at the various interoperability test events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rtp-impl-guide-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-4161614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-4161614.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Tue Apr 5 03:50:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19288 for ; Tue, 5 Apr 2005 03:50:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIixJ-0005Ok-O4 for rohc-web-archive@ietf.org; Tue, 05 Apr 2005 03:58:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIijJ-0005ip-Ay; Tue, 05 Apr 2005 03:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIijF-0005ib-Qq for rohc@megatron.ietf.org; Tue, 05 Apr 2005 03:44:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19015 for ; Tue, 5 Apr 2005 03:44:03 -0400 (EDT) Message-Id: <200504050744.DAA19015@ietf.org> Received: from smtp.163.com ([202.108.44.204] helo=163.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIirK-0005EL-3c for rohc@ietf.org; Tue, 05 Apr 2005 03:52:28 -0400 Received: from bupt (unknown [59.64.153.209]) by smtp1 (Coremail) with SMTP id HUBf2r1BUkIhTNYA.1 for ; Tue, 05 Apr 2005 15:43:57 +0800 (CST) X-Originating-IP: [59.64.153.209] Date: Tue, 5 Apr 2005 15:44:09 +0800 From: "liuyang" To: "rohc" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Subject: [rohc] questions about UDVM implementation, X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1039384464==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad This is a multi-part message in MIME format. --===============1039384464== Content-Type: multipart/alternative; boundary="=====003_Dragon366175421010_=====" This is a multi-part message in MIME format. --=====003_Dragon366175421010_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbDsNCiAgDQogIEkgYW0gd29ya2luZyBvbiBteSBzaWdjb21wIGxheWVyIGZvciBh IHNpcCBwaG9uZS5mb3IgdGhlIHJlYXNvbiBvZiBzaW1wbGljaXR5LA0KbXkgc2lnY29tcCBsYXll ciB3aWxsIG9ubHkgc3VwcG9ydCB0aGUgbWVzc2FnZXMgY29tcHJlc3NlZCBieSBMWlNTIGluIHRo ZSBiZWdpbmluZyxzbyB0aGVyZSBhcmUgb25seSANCjEyIFVEVk0gaW5zdHJ1Y3Rpb25zIHRoYXQg aSBtdXN0IHRvIGltcGxlbWVudC4NCiAgQnV0IGhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zIGkgbWV0 Og0KICAgIDEuaW4gdGhlIDxkcmFmdC1wcmljZS1yb2hjLXNpZ2NvbXAtdXNlci1ndWlkZS0wMi50 eHQ+LCBhbiBleGFtcGxlIG1lc3NhZ2UgY29tcHJlc3NlZCB1c2luZyB0aGUgTFpTUyBhbGdvcml0 aG0gaXMgZ2l2ZW4gDQogICAgICAgIGFzOiAweDI3OWEgMDQwNiBlMzc4IGIyMDAgNjA3NCAxMDE4 IDRjZTYgMTM0OSBiODQyICxidXQgaSBjYW4ndCBkZWNvbXByZXNlIHRoaXMgbWVzc2FnZSBjb3Jy ZWN0bHksaSBkb24ndCBrbm93IHdoeS4NCiAgICAyLnRoZSBpbnN0cnVjdGlvbiAgSU5QVVQtSFVG Rk1BTiAoaW5kZXgsIGVuZF9vZl9tZXNzYWdlLCAyLCA5LCAwLCAyNTUsIDE2Mzg0LCA0LCA0MDk2 LCA4MTkxLCAxKSANCiAgICAgICAgICAgICBpIGRvbid0IGtub3cgd2h5IHRha2luZyBvdXQgOSBi aXRzIGZyb20gdGhlIGNvbXByZXNzZWQgbWVzc2FnZSBhbmQgd2hhdCBleGFjdGx5IHRoZSBmdW5j dGlvbiBvZiB0aGlzICAgICAgICAgICAgICAgICBpbnN0cnVjdGlvbiB3aWxsIGRvLg0KICAgICAg ICAgIFRoYW5rIHlvdSBpbiBhZHZhbmNlLGhhdmUgYSBuaWNlIGRheSENCg0KICAgICAgICANCi8q KioqKioqKioqKioqKioqKioqKioqKioqKioqKnF1b3RvZWQqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqLw0KNC4yLiAgTFpTUyANCiAgICANCiAgIFRoaXMgc2VjdGlvbiBw cm92aWRlcyBVRFZNIGJ5dGVjb2RlIGZvciB0aGUgc2ltcGxlIGJ1dCBlZmZlY3RpdmUgTFpTUyAN CiAgIGNvbXByZXNzaW9uIGFsZ29yaXRobSBbTFpTU10uIA0KICAgIA0KICAgVGhlIHByaW5jaXBh bCBpbXByb3ZlbWVudCBvZmZlcmVkIGJ5IExaU1Mgb3ZlciBMWjc3IGlzIHRoYXQgZWFjaCANCiAg IGNvbXByZXNzZWQgY2hhcmFjdGVyIGJlZ2lucyB3aXRoIGEgMS1iaXQgaW5kaWNhdG9yIGZsYWcg dG8gc3BlY2lmeSANCiAgIHdoZXRoZXIgdGhlIGNoYXJhY3RlciBpcyBhIGxpdGVyYWwgb3IgYW4g b2Zmc2V0L2xlbmd0aCBwYWlyLiBBIA0KICAgbGl0ZXJhbCB2YWx1ZSBpcyBzaW1wbHkgYSBzaW5n bGUgdW5jb21wcmVzc2VkIGJ5dGUgdGhhdCBpcyBhcHBlbmRlZCANCiAgIGRpcmVjdGx5IHRvIHRo ZSBkZWNvbXByZXNzZWQgbWVzc2FnZS4gDQogICAgDQogICBBbiBvZmZzZXQvbGVuZ3RoIHBhaXIg Y29udGFpbnMgYSAxMi1iaXQgb2Zmc2V0IHZhbHVlIGZyb20gMSB0byA0MDk2IA0KICAgaW5jbHVz aXZlLCBmb2xsb3dlZCBieSBhIDQtYml0IGxlbmd0aCB2YWx1ZSBmcm9tIDMgdG8gMTggaW5jbHVz aXZlLiANCiAgIFRha2VuIHRvZ2V0aGVyIHRoZXNlIHZhbHVlcyBzcGVjaWZ5IG9uZSBvZiB0aGUg cHJldmlvdXNseSByZWNlaXZlZCANCg0KDQogDQogDQpQcmljZSBldCBhbC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxNF0gDQoNCklOVEVS TkVULURSQUZUICAgICAgICAgICAgIFNpZ0NvbXAgVXNlciBHdWlkZSAgICAgICAgICAgICAgIE1h eSAxNSwgMjAwMyANCiANCiANCiAgIHRleHQgc3RyaW5ncyBpbiB0aGUgY2lyY3VsYXIgYnVmZmVy LCB3aGljaCBpcyB0aGVuIGFwcGVuZGVkIHRvIHRoZSANCiAgIGVuZCBvZiB0aGUgZGVjb21wcmVz c2VkIG1lc3NhZ2UuIA0KICAgIA0KICAgQXNzZW1ibHkgZm9yIGFuIExaU1MgZGVjb21wcmVzc29y IGlzIGdpdmVuIGJlbG93OiANCiAgICANCiAgIGF0ICgzMikgDQogICAgDQogICA6aW5kZXggICAg ICAgICAgICAgICAgICAgICAgICAgIHBhZCAoMikgDQogICA6bGVuZ3RoX3ZhbHVlICAgICAgICAg ICAgICAgICAgIHBhZCAoMikgDQogICA6b2xkX3BvaW50ZXIgICAgICAgICAgICAgICAgICAgIHBh ZCAoMikgDQogICAgDQogICBhdCAoNDIpIA0KICAgIA0KICAgc2V0IChyZXF1ZXN0ZWRfZmVlZGJh Y2tfbG9jYXRpb24sIDApIA0KICAgIA0KICAgYXQgKDY0KSANCiAgICANCiAgIDpieXRlX2NvcHlf bGVmdCAgICAgICAgICAgICAgICAgcGFkICgyKSANCiAgIDpieXRlX2NvcHlfcmlnaHQgICAgICAg ICAgICAgICAgcGFkICgyKSANCiAgIDppbnB1dF9iaXRfb3JkZXIgICAgICAgICAgICAgICAgcGFk ICgyKSANCiAgIDpkZWNvbXByZXNzZWRfcG9pbnRlciAgICAgICAgICAgcGFkICgyKSANCiAgICAN CiAgIHNldCAocmV0dXJuZWRfcGFyYW1ldGVyc19sb2NhdGlvbiwgMCkgDQogICAgDQogICBhbGln biAoNjQpIA0KICAgIA0KICAgOmluaXRpYWxpemVfbWVtb3J5IA0KICAgIA0KICAgc2V0ICh1ZHZt X21lbW9yeV9zaXplLCA4MTkyKSANCiAgIHNldCAoc3RhdGVfbGVuZ3RoLCAodWR2bV9tZW1vcnlf c2l6ZSAtIDY0KSkgDQogICAgDQogICBNVUxUSUxPQUQgKDY0LCA0LCBjaXJjdWxhcl9idWZmZXIs IHVkdm1fbWVtb3J5X3NpemUsIDAsIA0KICAgY2lyY3VsYXJfYnVmZmVyKSANCiAgICANCiAgIDpk ZWNvbXByZXNzX3NpZ2NvbXBfbWVzc2FnZSANCiAgICANCiAgIDpuZXh0X2NoYXJhY3RlciANCiAg ICANCiAgIElOUFVULUhVRkZNQU4gKGluZGV4LCBlbmRfb2ZfbWVzc2FnZSwgMiwgOSwgMCwgMjU1 LCAxNjM4NCwgNCwgNDA5NiwgDQogICA4MTkxLCAxKSANCiAgIENPTVBBUkUgKCRpbmRleCwgODE5 MiwgbGVuZ3RoLCBlbmRfb2ZfbWVzc2FnZSwgbGl0ZXJhbCkgDQogICAgDQogICAgOmxpdGVyYWwg DQogICAgDQogICBzZXQgKGluZGV4X2xzYiwgKGluZGV4ICsgMSkpIA0KICAgIA0KICAgT1VUUFVU IChpbmRleF9sc2IsIDEpIA0KICAgQ09QWS1MSVRFUkFMIChpbmRleF9sc2IsIDEsICRkZWNvbXBy ZXNzZWRfcG9pbnRlcikgDQogICBKVU1QIChuZXh0X2NoYXJhY3RlcikgDQogICAgDQogICA6bGVu Z3RoIA0KDQoNCiANCiANClByaWNlIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XSANCg0KSU5URVJORVQtRFJBRlQgICAgICAg ICAgICAgU2lnQ29tcCBVc2VyIEd1aWRlICAgICAgICAgICAgICAgTWF5IDE1LCAyMDAzIA0KIA0K IA0KICAgIA0KICAgSU5QVVQtQklUUyAoNCwgbGVuZ3RoX3ZhbHVlLCAhKSANCiAgIEFERCAoJGxl bmd0aF92YWx1ZSwgMykgDQogICBMT0FEIChvbGRfcG9pbnRlciwgJGRlY29tcHJlc3NlZF9wb2lu dGVyKSANCiAgIENPUFktT0ZGU0VUICgkaW5kZXgsICRsZW5ndGhfdmFsdWUsICRkZWNvbXByZXNz ZWRfcG9pbnRlcikgDQogICBPVVRQVVQgKCRvbGRfcG9pbnRlciwgJGxlbmd0aF92YWx1ZSkgDQog ICBKVU1QIChuZXh0X2NoYXJhY3RlcikgDQogICAgDQogICA6ZW5kX29mX21lc3NhZ2UgDQogICAg DQogICBFTkQtTUVTU0FHRSAocmVxdWVzdGVkX2ZlZWRiYWNrX2xvY2F0aW9uLCANCiAgIHJldHVy bmVkX3BhcmFtZXRlcnNfbG9jYXRpb24sIHN0YXRlX2xlbmd0aCwgNjQsIA0KICAgZGVjb21wcmVz c19zaWdjb21wX21lc3NhZ2UsIDYsIDApIA0KICAgIA0KICAgOmNpcmN1bGFyX2J1ZmZlciANCiAg ICANCiAgIEFuIGV4YW1wbGUgbWVzc2FnZSBjb21wcmVzc2VkIHVzaW5nIHRoZSBMWlNTIGFsZ29y aXRobSBpcyBnaXZlbiANCiAgIGJlbG93OiANCiAgICANCiAgIDB4Mjc5YSAwNDA2IGUzNzggYjIw MCA2MDc0IDEwMTggNGNlNiAxMzQ5IGI4NDIgDQovKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKipxdW90b2VkKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovDQqh oaGhDQo= --=====003_Dragon366175421010_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4zNzkwLjAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2VhZWFlYT4N CjxESVY+DQo8RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgY29sb3I9IzY2NjY2Nj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjxGT05UIGNvbG9yPSM2NjY2NjY+PEEgDQpocmVmPSJtYWlsdG86Ij48 L0E+PC9GT05UPjwvRk9OVD48L0RJVj48QlI+DQo8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICA8VEJP RFk+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9IjEwMCUiPg0KICAgICAgPEJMT0NLUVVPVEUgDQog ICAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lO LUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+DQogICAgICAgIDxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9y87M5T5EZWFyIGFs bDs8L0ZPTlQ+PC9GT05UPjwvRElWPg0KICAgICAgICA8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBm YWNlPcvOzOU+Jm5ic3A7Jm5ic3A7PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48 Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNwOyZuYnNwO0kgYW0gd29ya2luZyBvbiBteSBzaWdj b21wIGxheWVyIA0KICAgICAgICBmb3IgYSBzaXAgcGhvbmUuZm9yIHRoZSByZWFzb24gb2Ygc2lt cGxpY2l0eSw8L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9 Mj5teSBzaWdjb21wIGxheWVyIHdpbGwgb25seSBzdXBwb3J0IHRoZSANCiAgICAgICAgbWVzc2Fn ZXMgY29tcHJlc3NlZCBieSBMWlNTIGluIHRoZSBiZWdpbmluZyxzbyB0aGVyZSBhcmUgb25seSAN CiAgICAgICAgPC9GT05UPjwvRElWPg0KICAgICAgICA8RElWPjxGT05UIGZhY2U9y87M5SBzaXpl PTI+MTIgVURWTSBpbnN0cnVjdGlvbnMgdGhhdCBpIG11c3QgdG8gDQogICAgICAgIGltcGxlbWVu dC48L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj4mbmJz cDsmbmJzcDtCPC9GT05UPjxGT05UIGZhY2U9y87M5SBzaXplPTI+dXQgDQogICAgICAgIGhlcmUg YXJlIHNvbWUgcXVlc3Rpb25zIGkgbWV0OjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9O VCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAxLmluIHRoZSANCiAgICAgICAg Jmx0O2RyYWZ0LXByaWNlLXJvaGMtc2lnY29tcC11c2VyLWd1aWRlLTAyLnR4dCZndDssJm5ic3A7 YW4gZXhhbXBsZSANCiAgICAgICAgbWVzc2FnZSBjb21wcmVzc2VkIHVzaW5nIHRoZSBMWlNTIGFs Z29yaXRobSBpcyANCiAgICAgICAgZ2l2ZW4mbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgICBhczombmJzcDsweDI3OWEgMDQwNiBlMzc4 IGIyMDAgNjA3NCAxMDE4IDRjZTYgMTM0OSBiODQyICxidXQgaSBjYW4ndCANCiAgICAgICAgZGVj b21wcmVzZSB0aGlzIG1lc3NhZ2UgY29ycmVjdGx5LGkgZG9uJ3Qga25vdyB3aHkuPC9GT05UPjwv RElWPg0KICAgICAgICA8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Mi50aGUgDQogICAgICAgIGluc3RydWN0aW9uJm5ic3A7IElOUFVULUhVRkZNQU4g KGluZGV4LCBlbmRfb2ZfbWVzc2FnZSwgMiwgOSwgMCwgMjU1LCANCiAgICAgICAgMTYzODQsIDQs IDQwOTYsIDgxOTEsIA0KICAgICAgICAxKSZuYnNwOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtp IA0KICAgICAgICBkb24ndCBrbm93IHdoeSB0YWtpbmcgb3V0IDkgYml0cyBmcm9tIHRoZSBjb21w cmVzc2VkIG1lc3NhZ2UgYW5kIHdoYXQgDQogICAgICAgIGV4YWN0bHkgdGhlIGZ1bmN0aW9uIG9m IA0KICAgICAgICB0aGlzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICAgICAgICBpbnN0cnVjdGlvbiZuYnNwO3dpbGwgZG8uPC9GT05UPjwvRElWPg0KICAgICAgICA8 RElWPjxGT05UIGZhY2U9y87M5SANCiAgICAgICAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFuayB5b3UgDQogICAgICAgIGlu IGFkdmFuY2UsaGF2ZSBhIG5pY2UgZGF5ITwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9O VCBmYWNlPcvOzOUgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj48Rk9O VCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg DQogICAgICAgIDwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBmYWNlPcvOzOUgDQog ICAgICAgIHNpemU9Mj4vKioqKioqKioqKioqKioqKioqKioqKioqKioqKipxdW90b2VkKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi88L0ZPTlQ+PC9ESVY+DQogICAgICAg IDxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj40LjIuJm5ic3A7IExaU1MgPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyANCiAgICAgICAgPEJSPiZuYnNwOyZuYnNwOyBUaGlzIHNlY3Rpb24gcHJvdmlk ZXMgVURWTSBieXRlY29kZSBmb3IgdGhlIHNpbXBsZSBidXQgDQogICAgICAgIGVmZmVjdGl2ZSBM WlNTIDxCUj4mbmJzcDsmbmJzcDsgY29tcHJlc3Npb24gYWxnb3JpdGhtIFtMWlNTXS4gDQogICAg ICAgIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyBUaGUgcHJpbmNpcGFs IGltcHJvdmVtZW50IA0KICAgICAgICBvZmZlcmVkIGJ5IExaU1Mgb3ZlciBMWjc3IGlzIHRoYXQg ZWFjaCA8QlI+Jm5ic3A7Jm5ic3A7IGNvbXByZXNzZWQgDQogICAgICAgIGNoYXJhY3RlciBiZWdp bnMgd2l0aCBhIDEtYml0IGluZGljYXRvciBmbGFnIHRvIHNwZWNpZnkgPEJSPiZuYnNwOyZuYnNw OyANCiAgICAgICAgd2hldGhlciB0aGUgY2hhcmFjdGVyIGlzIGEgbGl0ZXJhbCBvciBhbiBvZmZz ZXQvbGVuZ3RoIHBhaXIuIEEgDQogICAgICAgIDxCUj4mbmJzcDsmbmJzcDsgbGl0ZXJhbCB2YWx1 ZSBpcyBzaW1wbHkgYSBzaW5nbGUgdW5jb21wcmVzc2VkIGJ5dGUgdGhhdCANCiAgICAgICAgaXMg YXBwZW5kZWQgPEJSPiZuYnNwOyZuYnNwOyBkaXJlY3RseSB0byB0aGUgZGVjb21wcmVzc2VkIG1l c3NhZ2UuIA0KICAgICAgICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsg QW4gb2Zmc2V0L2xlbmd0aCBwYWlyIGNvbnRhaW5zIGEgDQogICAgICAgIDEyLWJpdCBvZmZzZXQg dmFsdWUgZnJvbSAxIHRvIDQwOTYgPEJSPiZuYnNwOyZuYnNwOyBpbmNsdXNpdmUsIGZvbGxvd2Vk IA0KICAgICAgICBieSBhIDQtYml0IGxlbmd0aCB2YWx1ZSBmcm9tIDMgdG8gMTggaW5jbHVzaXZl LiA8QlI+Jm5ic3A7Jm5ic3A7IFRha2VuIA0KICAgICAgICB0b2dldGhlciB0aGVzZSB2YWx1ZXMg c3BlY2lmeSBvbmUgb2YgdGhlIHByZXZpb3VzbHkgcmVjZWl2ZWQgDQogICAgICAgIDwvRk9OVD48 L0RJVj4NCiAgICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBmYWNl PcvOzOUgc2l6ZT0yPjxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPlByaWNlIGV0IA0KICAgICAgICBh bC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAgIFtQYWdlIDE0XSANCiAgICAgICAgPEJSPjxCUj5J TlRFUk5FVC1EUkFGVCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgU2lnQ29tcCBVc2VyIA0KICAg ICAgICBHdWlkZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgTWF5IDE1LCAy MDAzIDxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPiZuYnNwOyZuYnNwOyB0ZXh0IHN0cmluZ3MgaW4g dGhlIA0KICAgICAgICBjaXJjdWxhciBidWZmZXIsIHdoaWNoIGlzIHRoZW4gYXBwZW5kZWQgdG8g dGhlIDxCUj4mbmJzcDsmbmJzcDsgZW5kIG9mIA0KICAgICAgICB0aGUgZGVjb21wcmVzc2VkIG1l c3NhZ2UuIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyANCiAgICAgICAg QXNzZW1ibHkgZm9yIGFuIExaU1MgZGVjb21wcmVzc29yIGlzIGdpdmVuIGJlbG93OiA8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgICA8QlI+Jm5ic3A7Jm5ic3A7IGF0ICgzMikgPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KICAgICAgICA6aW5kZXgmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAgIHBhZCAoMikgPEJSPiZuYnNw OyZuYnNwOyANCiAgICAgICAgOmxlbmd0aF92YWx1ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgcGFkICgyKSA8QlI+Jm5ic3A7Jm5i c3A7IA0KICAgICAgICA6b2xkX3BvaW50ZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAgIHBhZCAoMikgPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IGF0ICg0MikgDQogICAgICAgIDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyBzZXQgDQogICAgICAgIChyZXF1ZXN0ZWRfZmVl ZGJhY2tfbG9jYXRpb24sIDApIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNwOyZuYnNw OyANCiAgICAgICAgYXQgKDY0KSA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4mbmJzcDsmbmJz cDsgDQogICAgICAgIDpieXRlX2NvcHlfbGVmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgICAgICAgcGFkICgyKSA8QlI+Jm5ic3A7Jm5ic3A7IA0KICAgICAgICA6 Ynl0ZV9jb3B5X3JpZ2h0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAg ICBwYWQgKDIpIDxCUj4mbmJzcDsmbmJzcDsgDQogICAgICAgIDppbnB1dF9iaXRfb3JkZXImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAgIHBhZCAoMikgPEJSPiZuYnNw OyZuYnNwOyANCiAgICAgICAgOmRlY29tcHJlc3NlZF9wb2ludGVyJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgICBwYWQg KDIpIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyBzZXQgDQogICAgICAg IChyZXR1cm5lZF9wYXJhbWV0ZXJzX2xvY2F0aW9uLCAwKSA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICAgICAgICA8QlI+Jm5ic3A7Jm5ic3A7IGFsaWduICg2NCkgPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KICAgICAgICA6aW5pdGlhbGl6ZV9tZW1vcnkgPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IHNldCANCiAgICAgICAgKHVkdm1fbWVt b3J5X3NpemUsIDgxOTIpIDxCUj4mbmJzcDsmbmJzcDsgc2V0IChzdGF0ZV9sZW5ndGgsIA0KICAg ICAgICAodWR2bV9tZW1vcnlfc2l6ZSAtIDY0KSkgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+ Jm5ic3A7Jm5ic3A7IA0KICAgICAgICBNVUxUSUxPQUQgKDY0LCA0LCBjaXJjdWxhcl9idWZmZXIs IHVkdm1fbWVtb3J5X3NpemUsIDAsIDxCUj4mbmJzcDsmbmJzcDsgDQogICAgICAgIGNpcmN1bGFy X2J1ZmZlcikgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KICAgICAg ICA6ZGVjb21wcmVzc19zaWdjb21wX21lc3NhZ2UgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+ Jm5ic3A7Jm5ic3A7IA0KICAgICAgICA6bmV4dF9jaGFyYWN0ZXIgPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IElOUFVULUhVRkZNQU4gDQogICAgICAgIChpbmRleCwgZW5k X29mX21lc3NhZ2UsIDIsIDksIDAsIDI1NSwgMTYzODQsIDQsIDQwOTYsIDxCUj4mbmJzcDsmbmJz cDsgDQogICAgICAgIDgxOTEsIDEpIDxCUj4mbmJzcDsmbmJzcDsgQ09NUEFSRSAoJGluZGV4LCA4 MTkyLCBsZW5ndGgsIGVuZF9vZl9tZXNzYWdlLCANCiAgICAgICAgbGl0ZXJhbCkgPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDpsaXRlcmFsIA0KICAgICAgICA8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4mbmJzcDsmbmJzcDsgc2V0IChpbmRleF9sc2IsIChp bmRleCArIDEpKSANCiAgICAgICAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5i c3A7IE9VVFBVVCAoaW5kZXhfbHNiLCAxKSANCiAgICAgICAgPEJSPiZuYnNwOyZuYnNwOyBDT1BZ LUxJVEVSQUwgKGluZGV4X2xzYiwgMSwgJGRlY29tcHJlc3NlZF9wb2ludGVyKSANCiAgICAgICAg PEJSPiZuYnNwOyZuYnNwOyBKVU1QIChuZXh0X2NoYXJhY3RlcikgPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyANCiAgICAgICAgPEJSPiZuYnNwOyZuYnNwOyA6bGVuZ3RoIDwvRk9OVD48L0RJVj4NCiAg ICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6 ZT0yPjxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPlByaWNlIGV0IA0KICAgICAgICBhbC4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogICAgICAgIFtQYWdlIDE1XSANCiAgICAgICAgPEJSPjxCUj5JTlRFUk5FVC1E UkFGVCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgU2lnQ29tcCBVc2VyIA0KICAgICAgICBHdWlk ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgTWF5IDE1LCAyMDAzIDxCUj4m bmJzcDs8QlI+Jm5ic3A7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0K ICAgICAgICBJTlBVVC1CSVRTICg0LCBsZW5ndGhfdmFsdWUsICEpIDxCUj4mbmJzcDsmbmJzcDsg QUREICgkbGVuZ3RoX3ZhbHVlLCAzKSANCiAgICAgICAgPEJSPiZuYnNwOyZuYnNwOyBMT0FEIChv bGRfcG9pbnRlciwgJGRlY29tcHJlc3NlZF9wb2ludGVyKSANCiAgICAgICAgPEJSPiZuYnNwOyZu YnNwOyBDT1BZLU9GRlNFVCAoJGluZGV4LCAkbGVuZ3RoX3ZhbHVlLCANCiAgICAgICAgJGRlY29t cHJlc3NlZF9wb2ludGVyKSA8QlI+Jm5ic3A7Jm5ic3A7IE9VVFBVVCAoJG9sZF9wb2ludGVyLCAN CiAgICAgICAgJGxlbmd0aF92YWx1ZSkgPEJSPiZuYnNwOyZuYnNwOyBKVU1QIChuZXh0X2NoYXJh Y3RlcikgDQogICAgICAgIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNwOyZuYnNwOyA6 ZW5kX29mX21lc3NhZ2UgDQogICAgICAgIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNw OyZuYnNwOyBFTkQtTUVTU0FHRSANCiAgICAgICAgKHJlcXVlc3RlZF9mZWVkYmFja19sb2NhdGlv biwgPEJSPiZuYnNwOyZuYnNwOyANCiAgICAgICAgcmV0dXJuZWRfcGFyYW1ldGVyc19sb2NhdGlv biwgc3RhdGVfbGVuZ3RoLCA2NCwgPEJSPiZuYnNwOyZuYnNwOyANCiAgICAgICAgZGVjb21wcmVz c19zaWdjb21wX21lc3NhZ2UsIDYsIDApIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAg IDxCUj4mbmJzcDsmbmJzcDsgOmNpcmN1bGFyX2J1ZmZlciA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICAgICAgICA8QlI+Jm5ic3A7Jm5ic3A7IEFuIGV4YW1wbGUgbWVzc2FnZSBjb21wcmVzc2Vk IHVzaW5nIHRoZSBMWlNTIGFsZ29yaXRobSANCiAgICAgICAgaXMgZ2l2ZW4gPEJSPiZuYnNwOyZu YnNwOyBiZWxvdzogPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7Jm5ic3A7IA0KICAg ICAgICAweDI3OWEgMDQwNiBlMzc4IGIyMDAgNjA3NCAxMDE4IDRjZTYgMTM0OSBiODQyIDwvRk9O VD48L0RJVj4NCiAgICAgICAgPERJVj4vKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKipxdW90b2VkKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovPC9ESVY+DQog ICAgICAgIDxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj6hoaGhPC9GT05UPjwvRElWPg0KICAg ICAgICA8RElWPjxGT05UIGZhY2U9y87M5SANCnNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9C TE9DS1FVT1RFPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjwvRk9OVD48L0ZPTlQ+PC9E SVY+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon366175421010_=====-- --===============1039384464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1039384464==-- From rohc-bounces@ietf.org Wed Apr 6 07:39:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00172 for ; Wed, 6 Apr 2005 07:39:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ914-0003Oh-TY for rohc-web-archive@ietf.org; Wed, 06 Apr 2005 07:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8lo-0004BW-GH; Wed, 06 Apr 2005 07:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8ln-0004BC-6r for rohc@megatron.ietf.org; Wed, 06 Apr 2005 07:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29178 for ; Wed, 6 Apr 2005 07:32:25 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ8lY-0002RQ-Kn for rohc@ietf.org; Wed, 06 Apr 2005 07:32:13 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <22RDRK4G>; Wed, 6 Apr 2005 12:23:27 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A2@rsys004a> From: "Finking, Robert" To: rohc@ietf.org Date: Wed, 6 Apr 2005 12:23:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [rohc] TCP profile FN, ip_id_behavior_enc X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi All, The current tcp-pf.txt contains the following: ip_id_behavior_enc === { uc_format = ip_id_behavior; %[ 2 ] default_methods = { ip_id_behavior ::= irregular(2); }; co_format_sequential = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == 0b00); }; co_format_sequential_swapped = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == 0b01); }; co_format_random = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == 0b10); }; co_format_zero = ip_id_behavior, %[ 2 ] { let (ip_id_behavior:uncomp_value == 0b11); }; }; Can somebody explain to me what this is supposed to do - because I don't think it does what it's supposed to (though I think the fix is quite easy). As an aside, it is odd seeing the behaviour flags written in binary here when they are in decimal in the preceding format (ip_id_enc_irreg). I think it would be clearer if we stuck to using a single number base for a particular attribute like this - or is there some significance of the actual bits here that we don't need to see elsewhere (in which case a comment might be useful)? Minor point, but I thought I'd mention it since I noticed it. Cheers Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 6 09:33:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10960 for ; Wed, 6 Apr 2005 09:33:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAnQ-0007d1-3v for rohc-web-archive@ietf.org; Wed, 06 Apr 2005 09:42:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAdD-0003rw-HE; Wed, 06 Apr 2005 09:31:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAdB-0003rk-Me for rohc@megatron.ietf.org; Wed, 06 Apr 2005 09:31:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10782 for ; Wed, 6 Apr 2005 09:31:39 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAlX-0007aC-S1 for rohc@ietf.org; Wed, 06 Apr 2005 09:40:20 -0400 Received: by wproxy.gmail.com with SMTP id 71so373553wra for ; Wed, 06 Apr 2005 06:31:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=Tudibu7bYQ/Q4qh2sz5RGACcnDhpctyjklsz/Ue1h0b82hYVARnZL5Mc8ztO5xxWraP9cg3TxnDeeOuoPnhJnsL1Ykkb852D9bjBT9EFBL+Z4SYGGejeAsGYEuVLb/zbqh48R5A1Og6t+fBzaHM01jIliZKdzzYZGrw51NEQMV4= Received: by 10.54.32.28 with SMTP id f28mr561372wrf; Wed, 06 Apr 2005 06:31:30 -0700 (PDT) Received: by 10.54.26.9 with HTTP; Wed, 6 Apr 2005 06:31:30 -0700 (PDT) Message-ID: <29ed16a4050406063152628e54@mail.gmail.com> Date: Wed, 6 Apr 2005 15:31:30 +0200 From: Ana Minaburo To: nemo@ietf.org, rohc@ietf.org In-Reply-To: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3248_24001933.1112794290551" References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [rohc] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anacarolina.minaburo@enst-bretagne.fr List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 ------=_Part_3248_24001933.1112794290551 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit ---------- Forwarded message ---------- From: Eun Kyoung PAIK Date: Apr 3, 2005 3:44 PM Subject: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, March 16, 2005 12:09 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-minaburo-rohc-nemo-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ROHC (Robust Header Compression) in NEMO network Author(s) : A. Minaburo, et al. Filename : draft-minaburo-rohc-nemo-00.txt Pages : 0 Date : 2005-3-9 This document defines the use of ROHC header compression mechanisms for the NEMO Basic Support protocol [9]. The idea is to use both NEMO and ROHC as they have been defined without any change. The tunneling in the NEMO Basic Support protocol will be done over different supports (Wireless LAN, 3G or PPP) links, where ROHC compression can work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-minaburo-rohc-nemo-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ENCODING mime FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt ------=_Part_3248_24001933.1112794290551 Content-Type: text/plain; name=ATT00500.txt; charset=us-ascii Content-Disposition: attachment; filename="ATT00500.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_Part_3248_24001933.1112794290551 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=_Part_3248_24001933.1112794290551-- From rohc-bounces@ietf.org Wed Apr 6 09:50:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12445 for ; Wed, 6 Apr 2005 09:50:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJB3P-00081n-C9 for rohc-web-archive@ietf.org; Wed, 06 Apr 2005 09:58:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJArZ-0000gf-TU; Wed, 06 Apr 2005 09:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJArX-0000gU-VO for rohc@megatron.ietf.org; Wed, 06 Apr 2005 09:46:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12099 for ; Wed, 6 Apr 2005 09:46:29 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAzt-0007wt-ON for rohc@ietf.org; Wed, 06 Apr 2005 09:55:10 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j36DkLcn024860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2005 15:46:23 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.13.1/8.12.8/Submit) id j36DkGSg011123; Wed, 6 Apr 2005 15:46:16 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: "Finking, Robert" Subject: Re: [rohc] TCP profile FN, ip_id_behavior_enc References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A2@rsys004a> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Wed, 06 Apr 2005 15:46:16 +0200 In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A2@rsys004a> (Robert Finking's message of "Wed, 6 Apr 2005 12:23:19 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 "Finking, Robert" wrote: > The current tcp-pf.txt contains the following: > > ip_id_behavior_enc === > { > uc_format = ip_id_behavior; %[ 2 ] > > default_methods = > { > ip_id_behavior ::= irregular(2); > }; > > co_format_sequential = ip_id_behavior, %[ 2 ] > { > let (ip_id_behavior:uncomp_value == 0b00); > }; > > co_format_sequential_swapped = ip_id_behavior, %[ 2 ] > { > let (ip_id_behavior:uncomp_value == 0b01); > }; > > co_format_random = ip_id_behavior, %[ 2 ] > { > let (ip_id_behavior:uncomp_value == 0b10); > }; > > co_format_zero = ip_id_behavior, %[ 2 ] > { > let (ip_id_behavior:uncomp_value == 0b11); > }; > }; > > Can somebody explain to me what this is supposed to do This structure is supposed to encode the value of the ip_id_behavior field where it is present in compressed packets. In fact, all four compressed formats of this structure encode the value in the same way (with irregular), although a specific compressed format is selected based on the uncomp_value (which is identical to comp_value) attribute. In one of our off-list discussions I proposed to define this structure with only one compressed format which is independent of the value. There was an objection saying that the mapping between values and meanings (expressed by format names) would be lost that way. However, I still think the "right" solution to associate values with meanings is the use of constant definitions rather than different format names. A new proposal: The above structure could be replaced by the following definitions: IP_ID_BEHAVIOR_SEQUENTIAL = 0; IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; IP_ID_BEHAVIOR_RANDOM = 2; IP_ID_BEHAVIOR_RANDOM_SWAPPED = 3; ip_id_behavior_enc === { uc_format = ip_id_behavior; %[ 2 ] co_format = { ip_id_behavior ::= irregular(2); }; }; Then all occurances of ip_id_behavior values in the spec could be changed to use the defined constants. > - because I don't > think it does what it's supposed to (though I think the fix is quite easy). What do you think it does? > As an aside, it is odd seeing the behaviour flags written in binary here > when they are in decimal in the preceding format (ip_id_enc_irreg). I think > it would be clearer if we stuck to using a single number base for a > particular attribute like this - or is there some significance of the actual > bits here that we don't need to see elsewhere (in which case a comment might > be useful)? Minor point, but I thought I'd mention it since I noticed it. You are right. In an earlier version this structure had encodings such as "ip_id_behavior ::= '00';" (i.e., the compressed_value encoding method) and so on its compressed formats rather than using irregular. This was wrong as the structure has to bind both the compressed and the uncompressed side to the same value. When changing the structure, I used binary numbers so that the bits remained visible as in the previous version, but there is no real reason to keep it that way. (With the use of constants this issue would disappear anyway.) Regards Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 6 10:28:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16906 for ; Wed, 6 Apr 2005 10:28:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBUd-0000RW-Vn for rohc-web-archive@ietf.org; Wed, 06 Apr 2005 10:26:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBGf-0002f5-7I; Wed, 06 Apr 2005 10:12:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBGc-0002dK-Ny for rohc@megatron.ietf.org; Wed, 06 Apr 2005 10:12:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15616 for ; Wed, 6 Apr 2005 10:12:24 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBOz-0000IM-64 for rohc@ietf.org; Wed, 06 Apr 2005 10:21:05 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <22RDRMT6>; Wed, 6 Apr 2005 15:12:24 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A8@rsys004a> From: "Finking, Robert" To: "'Eilert Brinkmann'" Subject: RE: [rohc] TCP profile FN, ip_id_behavior_enc Date: Wed, 6 Apr 2005 15:12:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Hi Eilert, Thanks for the reply. I agree with you about the alternative encoding that uses a single format, but also remember the off list discussion now you mention it! The reason I think there is a bug here is that the default encoding will never be used. The default methods are only referred to for fields which do not have any bindings specified by a packet format. All the packet formats specify a binding for the ip_id_behavior field (albeit just for one of its attributes), therefore the default encoding methods will not be consulted for that field. If instead the irregular encoding was added to the uc_format encodings list, it would always apply: ip_id_behavior_enc === { uc_format = ip_id_behavior %[ 2 ] { ip_id_behavior ::= irregular(2); }; : : There are quite a few formats like this, where there is something in the default encodings which should always apply, and should really be moved to the uc_format field encodings list. Does this make sense or have I missed something? I am right behind you with using constants and getting rid of the other formats though! If needs be we could just put a comment in to explain what the format is doing (though without enumerating all the constants inside the comment). Cheers Raffles > From: Eilert Brinkmann [mailto:eilert@tzi.org] > Sent: Wednesday, April 06, 2005 2:46 PM > > "Finking, Robert" wrote: > > The current tcp-pf.txt contains the following: > > > > ip_id_behavior_enc === > > { > > uc_format = ip_id_behavior; %[ 2 ] > > > > default_methods = > > { > > ip_id_behavior ::= irregular(2); > > }; > > > > co_format_sequential = ip_id_behavior, %[ 2 ] > > { > > let (ip_id_behavior:uncomp_value == 0b00); > > }; > > > > co_format_sequential_swapped = ip_id_behavior, %[ 2 ] > > { > > let (ip_id_behavior:uncomp_value == 0b01); > > }; > > > > co_format_random = ip_id_behavior, %[ 2 ] > > { > > let (ip_id_behavior:uncomp_value == 0b10); > > }; > > > > co_format_zero = ip_id_behavior, %[ 2 ] > > { > > let (ip_id_behavior:uncomp_value == 0b11); > > }; > > }; > > > > Can somebody explain to me what this is supposed to do > > This structure is supposed to encode the value of the ip_id_behavior > field where it is present in compressed packets. In fact, all four > compressed formats of this structure encode the value in the same way > (with irregular), although a specific compressed format is selected > based on the uncomp_value (which is identical to comp_value) > attribute. > > In one of our off-list discussions I proposed to define this structure > with only one compressed format which is independent of the > value. There was an objection saying that the mapping between values > and meanings (expressed by format names) would be lost that > way. However, I still think the "right" solution to associate values > with meanings is the use of constant definitions rather than different > format names. A new proposal: The above structure could be replaced by > the following definitions: > > IP_ID_BEHAVIOR_SEQUENTIAL = 0; > IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; > IP_ID_BEHAVIOR_RANDOM = 2; > IP_ID_BEHAVIOR_RANDOM_SWAPPED = 3; > > ip_id_behavior_enc === > { > uc_format = ip_id_behavior; %[ 2 ] > > co_format = > { > ip_id_behavior ::= irregular(2); > }; > }; > > Then all occurances of ip_id_behavior values in the spec could be > changed to use the defined constants. > > > - because I don't > > think it does what it's supposed to (though I think the fix > is quite easy). > > What do you think it does? > > > As an aside, it is odd seeing the behaviour flags written > in binary here > > when they are in decimal in the preceding format > (ip_id_enc_irreg). I think > > it would be clearer if we stuck to using a single number base for a > > particular attribute like this - or is there some > significance of the actual > > bits here that we don't need to see elsewhere (in which > case a comment might > > be useful)? Minor point, but I thought I'd mention it since > I noticed it. > > You are right. In an earlier version this structure had encodings such > as "ip_id_behavior ::= '00';" (i.e., the compressed_value encoding > method) and so on its compressed formats rather than using > irregular. This was wrong as the structure has to bind both the > compressed and the uncompressed side to the same value. When changing > the structure, I used binary numbers so that the bits remained visible > as in the previous version, but there is no real reason to keep it > that way. (With the use of constants this issue would > disappear anyway.) > > Regards > > Eilert > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 6 11:20:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24478 for ; Wed, 6 Apr 2005 11:20:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCT1-0003I9-P3 for rohc-web-archive@ietf.org; Wed, 06 Apr 2005 11:29:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJCK9-0001aw-Fj; Wed, 06 Apr 2005 11:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJCK5-0001aU-Cx for rohc@megatron.ietf.org; Wed, 06 Apr 2005 11:20:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24319 for ; Wed, 6 Apr 2005 11:20:02 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCSR-0003ED-E5 for rohc@ietf.org; Wed, 06 Apr 2005 11:28:44 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <22RDRNSA>; Wed, 6 Apr 2005 16:19:57 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A9@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , Carsten Bormann , Kristofer Sandlund Subject: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Wed, 6 Apr 2005 16:19:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cadb9ba0ba1c1ba4f99ac017158fabc3 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ea58f9afed4c81098229b1759fb296b > You say that sometimes you do not know whether it will be only an > "if", but I have not seen an example of when this is really needed. > I'm still waiting for a realistic example of when one would have > to have that. Just because the current definition of let allows that > does not mean it is really needed. OK, so let's go for proof by contradiction. I'll go through the current tcp-profile and replace each occurrence of "let" with either an assignment, or an if statement. Then if the meaning is changed from that in the current profile, somebody needs to shout up and say why it's wrong. Otherwise I agree with you that "if" and assignment are clearer: whilst it goes against the grain for me personally, is probably the better solution. To be as clear as possible, I've used "when" for the non-binding conditional case, and ordinary assignment syntax (i.e. single equals sign) for assignment. Here goes: static_or_irreg32(flag) === { uc_format = field; %[ 32 ] co_format_irreg_enc = field, %[ 32 ] { when (flag == 1); field ::= irregular(32); }; co_format_static_enc = field, %[ 0 ] { when (flag == 0); field ::= static; }; }; Similarly for static_or_irreg16(flag), static_or_irreg8(flag). variable_length_32_enc(flag) === { uc_format = field; %[ 32 ] co_format_not_present = field, %[ 0 ] { when(flag == 0); field ::= static; }; co_format_8_bit = field, %[ 8 ] { when(flag == 1); field ::= lsb(8, 63); }; co_format_16_bit = field, %[ 16 ] { when(flag == 2); field ::= lsb(16, 16383); }; co_format_32_bit = field, %[ 32 ] { when(flag == 3); field ::= irregular(32); }; }; Similarly for variable_length_16_enc(flag). optional32(flag) === { uc_format = item; % 0 or 32 bits co_format_present = item, %[ 32 ] { when(flag == 1); item ::= irregular (32); }; co_format_not_present = item, %[ 0 ] { when(flag == 0); item ::= compressed_value (0, 0); }; }; opt_lsb_7_or_31 (flag) === { uc_format = item; % 32 bits co_format_present = item, % 8 or 32 bits { when (flag == 1); item ::= lsb_7_or_31; }; co_format_not_present = item, %[ 0 ] { when (flag == 0); item ::= compressed_value (0, 0); }; }; optional_checksum (flag_value) === { uc_format = value, % 0 or 16 bits reserved1; % 0 or 16 bits co_format_cs_present = value, %[ 16 ] reserved1, %[ 0 ] { when(flag_value == 1); value ::= irregular (16); reserved1 ::= uncompressed_value (16, 0); }; co_format_not_present = value, %[ 0 ] reserved1, %[ 0 ] { when(flag_value == 0); value ::= compressed_value (0, 0); reserved1 ::= compressed_value (0, 0); }; }; irreg_tos_tc === { uc_format = tos_tc; %[ 6 ] co_format_tos_tc_present = tos_tc, %[ 6 ] { when(ecn_used:uncomp_value == 1); tos_tc ::= irregular (6); }; co_format_tos_tc_not_present = tos_tc, %[ 0 ] { when(ecn_used:uncomp_value == 0); tos_tc ::= static; }; }; Similarly for ip_irreg_ecn. co_format_ipv6_outer_irregular_without_ttl = tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits { % for 'outer' headers only, irregular chain is required tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; when(ttl_irregular_chain_flag == 0); }; co_format_ipv6_outer_irregular_with_ttl = tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits ttl_hopl, %[ 8 ] { % for 'outer' headers only, irregular chain is required tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; when(ttl_irregular_chain_flag == 1); ttl_hopl ::= irregular(8); }; % Note that the ECN bits are stored in the global control field % so that they can be output in TCP irregular chain. co_format_ipv6_innermost_irregular = { ip_inner_ecn:uncomp_value = ip_ecn_flags:uncomp_value; }; ip_id_enc_dyn (behavior) === { uc_format = ip_id; %[ 16 ] co_format_ip_id_seq = ip_id, %[ 16 ] { when((behavior == 0) || (behavior == 1) || (behavior == 2)); % In dynamic chain, but random, seq, and seq-swapped are 16 bits ip_id ::= irregular(16); }; co_format_ip_id_zero = ip_id, %[ 0 ] { when(behavior == 3); % Zero IPID ip_id ::= uncompressed_value (16, 0); }; }; ip_id_enc_irreg (behavior) === { uc_format = ip_id; %[ 16 ] co_format_ip_id_seq = ip_id, %[ 0 ] { when(behavior == 0); % sequential ip_id ::= static; % Nothing to send in irregular chain }; co_format_ip_id_seq_swapped = ip_id, %[ 0 ] { when(behavior == 1); % sequential-swapped ip_id ::= static; % Nothing to send in irregular chain }; co_format_ip_id_rand = ip_id, %[ 16 ] { when(behavior == 2); % random ip_id ::= irregular (16); }; co_format_ip_id_zero = ip_id, %[ 0 ] { when(behavior == 3); % zero ip_id ::= uncompressed_value (16, 0); }; }; ip_id_behavior_enc === { uc_format = ip_id_behavior; %[ 2 ] default_methods = { ip_id_behavior ::= irregular(2); }; co_format_sequential = ip_id_behavior, %[ 2 ] { ip_id_behavior:uncomp_value = 0b00; }; co_format_sequential_swapped = ip_id_behavior, %[ 2 ] { ip_id_behavior:uncomp_value = 0b01; }; co_format_random = ip_id_behavior, %[ 2 ] { ip_id_behavior:uncomp_value = 0b10; }; co_format_zero = ip_id_behavior, %[ 2 ] { ip_id_behavior:uncomp_value = 0b11; }; }; As an aside, I think this format has a bug in it (see separate post). co_format_ipv4_outer_irregular_without_ttl = ip_id, % 0 or 16 bits tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg(ip_id_behavior:uncomp_value); tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; when(ttl_irregular_chain_flag == 0); }; co_format_ipv4_outer_irregular_with_ttl = ip_id, % 0 or 16 bits tos_tc, % 0 or 6 bits ip_ecn_flags, % 0 or 2 bits ttl_hopl, %[ 8 ] { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg(ip_id_behavior:uncomp_value); tos_tc ::= irreg_tos_tc; ip_ecn_flags ::= ip_irreg_ecn; when(ttl_irregular_chain_flag == 1); ttl_hopl ::= irregular(8); }; % Note that the ECN bits are stored in the global control field % so that they can be output in TCP irregular chain. co_format_ipv4_innermost_irregular = ip_id, % 0 or 16 bits { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg (ip_id_behavior:uncomp_value); ip_inner_ecn:uncomp_value = ip_ecn_flags:uncomp_value; }; tcp_opt_eol(nbits) === { uc_format = type, %[ 8 ] padding; % (nbits - 8) bits default_methods = { type ::= uncompressed_value(8, 0); pad_len ::= static; padding ::= uncompressed_value (nbits - 8, 0); }; co_format_eol_list_item = pad_len, % 8 bits padding, %[ 0 ] { pad_len ::= compressed_value(8, nbits - 8); }; co_format_eol_irregular = { pad_len:uncomp_value = nbits - 8; }; }; Again I think this has a bug in it in that the default static encoding will never be used. sack_var_length_enc (base) === { uc_format = sack_field; %[ 32 ] default_methods = { sack_offset:uncomp_value = sack_field:uncomp_value - base; sack_offset:uncomp_length = 32; sack_field:uncomp_length = 32; }; co_format_lsb_15 = discriminator, %[ 1 ] sack_offset, %[ 15 ] { discriminator ::= '0'; sack_offset ::= lsb (15, -1); }; co_format_lsb_22 = discriminator, %[ 2 ] sack_offset, %[ 22 ] { discriminator ::= '10'; sack_offset ::= lsb (22, -1); }; co_format_lsb_30 = discriminator, %[ 2 ] sack_offset, %[ 30 ] { discriminator ::= '11'; sack_offset ::= lsb (30, -1); }; }; co_format_sack1_list_item = discriminator, block_1, { when(length:uncomp_value == 10); discriminator ::= '00000001'; block_1 ::= tcp_opt_sack_block (ack_value); }; Similarly for other sack list items tcp_opt_generic === { uc_format = type, %[ 8 ] length_msb, %[ 1 ] length_lsb, %[ 7 ] contents; % n bits control_fields = option_static; %[ 1 ] default_methods = { type ::= static; % % lengths are always < 128 % (i.e. the msb is always 0) % length_msb ::= uncompressed_value (1, 0); length_lsb ::= static; contents ::= static; option_static:uncomp_length = 1; }; co_format_generic_list_item = type, %[ 8 ] option_static, %[ 1 ] length_lsb, %[ 7 ] contents, % n bits { type ::= irregular (8); option_static ::= irregular (1); length_lsb ::= irregular (7); contents ::= irregular (length_len:uncomp_value * 8 - 16); }; % Used when context of option has option_static set to one co_format_generic_irregular_static = { option_static:uncomp_value = 1; }; % An item that can change, but currently is unchanged co_format_generic_irregular_stable = discriminator, %[ 8 ] { option_static:uncomp_value = 0; discriminator ::= '11111111'; }; % An item that can change, and has changed compared to context. % Length is not allowed to change here, since a length change is % most likely to cause new NOPs or an EOL length change. co_format_generic_irregular_full = discriminator, %[ 8 ] contents, % n bits { option_static:uncomp_value = 0; discriminator ::= '00000000'; contents ::= irregular (length_lsb:uncomp_value * 8 - 16); }; }; list_tcp_options(nbits, ack_value) === { uc_format = item, tail; default_methods = { when(nbits >= item:uncomp_length); tail ::= list_tcp_options(nbits - item:uncomp_length, ack_value); }; co_format_list_end = { when(nbits == 0); item ::= irregular(0); tail ::= irregular(0); }; co_format_eol = item, tail { when(nbits == item:uncomp_length); % redundant item ::= tcp_opt_eol(nbits); tail ::= irregular(0); }; : : Again, I think the "when" in default_methods here should be moved to the uc_format encodings list. tcp_list_presence_enc(list_length, presence, ack_value) === { uc_format = tcp_options; co_format_list_not_present = tcp_options, %[ 0 ] { when(presence == 0); tcp_options ::= static; }; co_format_list_present = tcp_options, % 8 + n*8 bits { when(presence == 1); tcp_options ::= list_tcp_options(list_length, ack_value); }; }; port_replicate(flags) === { uc_format = port; %[ 16 ] co_format_port_static_enc = port, %[ 0 ] { when(flags == 0b00); port ::= static; }; co_format_port_lsb8 = port, %[ 8 ] { when(flags == 0b01); port ::= lsb (8, 64); }; co_format_port_irr_enc = port, %[ 16 ] { when(flags == 0b10); port ::= irregular (16); }; }; zero_or_irr16_enc(flag) === { uc_format = field; %[ 16 ] co_format_non_zero = field, %[ 16 ] { when(flag == 0); field ::= irregular (16); }; co_format_zero = field, %[ 0 ] { when(flag == 1); field ::= uncompressed_value (16, 0); }; }; ack_enc_dyn(flag) === { uc_format = ack_number; %[ 32 ] co_format_ack_non_zero = ack_number, %[ 32 ] { when(flag == 0); ack_number ::= irregular (32); }; co_format_ack_zero = ack_number, %[ 0 ] { when(flag == 1); ack_number ::= uncompressed_value (32, 0); }; }; tcp_ecn_flags_enc === { uc_format = tcp_ecn_flags; %[ 2 ] co_format_irreg = tcp_ecn_flags, %[ 2 ] { when(ecn_used:uncomp_value == 1); tcp_ecn_flags ::= irregular(2); }; co_format_unused = { when(ecn_used:uncomp_value == 0); tcp_ecn_flags ::= static; }; }; tcp_res_flags_enc === { uc_format = tcp_res_flags; %[ 4 ] co_format_irreg = tcp_res_flags, %[ 4 ] { when(ecn_used:uncomp_value == 1); tcp_res_flags ::= irregular(4); }; co_format_unused = { when(ecn_used:uncomp_value == 0); tcp_res_flags ::= uncompressed_value(4, 0); }; }; tcp_irreg_ip_ecn === { uc_format = ip_ecn_flags; %[ 2 ] co_format_tc_present = ip_ecn_flags, %[ 2 ] { when(ecn_used:uncomp_value == 1); ip_ecn_flags ::= compressed_value(2, ip_inner_ecn:uncomp_value); }; co_format_tc_not_present = ip_ecn_flags, %[ 0 ] { when(ecn_used:uncomp_value == 0); ip_inner_ecn ::= static; % Global control field ip_ecn_flags ::= compressed_value(0,0); % Nothing transmit }; }; optional_2bit_padding(used_flag) === { uc_format = ; co_format_used = padding, %[ 2 ] { when(used_flag == 1); padding ::= compressed_value (2, 0x0); }; co_format_unused = padding, { when(used_flag == 0); padding ::= compressed_value (0, 0x0); }; }; tos_tc_enc(flag) === { uc_format = tos_tc; %[ 6 ] co_format_static = tos_tc, %[ 0 ] { when(flag == 0); tos_tc ::= static; }; co_format_irreg = tos_tc, %[ 6 ] padding, %[ 2 ] { when(flag == 1); tos_tc ::= irregular(6); padding ::= compressed_value (2, 0); }; }; ip_id_lsb (behavior, k, p) === { uc_format = ip_id; %[ 16 ] default_methods = { ip_id:uncomp_length == 16; }; co_format_nbo = ip_id_offset, % k bits { when(behavior == 0); ip_id_offset:uncomp_value = ip_id:uncomp_value - msn:uncomp_value; ip_id_offset:uncomp_length = 16; ip_id_offset ::= lsb (k, p); }; co_format_non_nbo = ip_id_offset, % k bits { when(behavior == 1); ip_id_nbo:uncomp_value = (ip_id:uncomp_value / 256) + (ip_id:uncomp_value & 255) * 256; ip_id_nbo:uncomp_length = 16; ip_id_offset:uncomp_value = ip_id_nbo:uncomp_value - msn:uncomp_value; ip_id_offset:uncomp_length = 16; ip_id_offset ::= lsb (k, p); }; }; Note there is an error here - the ip_id_offset is not specified as a control field and yet it has an uncompressed side, which needs declaring. The above example however is a great illustration of the benefit of L-E's idea - it makes the profile considerably easier to read (IMHO). dont_fragment(version) === { uc_format = df; %[ 1 ] co_format_v4 = df, %[ 1 ] { when(version == 4); df ::= irregular(1); }; co_format_v6 = df, { when(version == 6); df ::= compressed_value(1,0); }; }; co_baseheader(payload_size, ttl_irregular_chain_flag) === { uc_format_v4 = version, %[ 4 ] header_length, %[ 4 ] : options_list, % n bits { when(version:uncomp_value == 4); }; uc_format_v6 = version, %[ 4 ] tos_tc, %[ 6 ] : options_list, % n bits { when(version:uncomp_value == 6); }; control_fields = ip_id_behavior; % 2 bits default_methods = { version ::= static; tos_tc ::= static; : : version:uncomp_length = 4; seq_number_scaled:uncomp_value = seq_number:uncomp_value / payload_size; seq_number_residue:uncomp_value = mod(seq_number:uncomp_value, payload_size); ack_number:uncomp_value = (ack_stride:uncomp_value * ack_number_scaled:uncomp_value) + ack_number_residue:uncomp_value; ack_number_residue:uncomp_value = mod(ack_number:uncomp_value, ack_stride:uncomp_value); }; co_format_co_common = discriminator, %[ 7 ] ttl_hopl_outer_flag, %[ 1 ] : : { discriminator ::= '1111101'; ttl_hopl_outer_flag::= irregular(1); % Need to bind argument so that user can pass it on to the % structure for IPv4/IPv6 irregular chain. ttl_irregular_chain_flag = ttl_hopl_outer_flag:uncomp_value; : : }; % Send LSBs of sequence number co_format_rnd_1 = discriminator, %[ 8 ] seq_number, %[ 16 ] msn, %[ 4 ] psh_flag, %[ 1 ] header_crc, %[ 3 ] { when((ip_id_behavior:uncomp_value == 2) || (ip_id_behavior:uncomp_value == 3)); discriminator ::= '10111110'; msn ::= lsb(4, 4); header_crc ::= crc3 (this:uncomp_value, this:uncomp_length); psh_flag ::= irregular (1); seq_number ::= lsb(16, 32767); }; similarly for all other co_formats _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 6 17:53:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08517 for ; Wed, 6 Apr 2005 17:53:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIbJ-0008Ex-Qa for rohc-web-archive@ietf.org; Wed, 06 Apr 2005 18:02:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJISo-00058I-LA; Wed, 06 Apr 2005 17:53:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJISm-000571-QQ for rohc@megatron.ietf.org; Wed, 06 Apr 2005 17:53:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08514 for ; Wed, 6 Apr 2005 17:53:25 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIbC-0008Eg-DA for rohc@ietf.org; Wed, 06 Apr 2005 18:02:11 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j36LrFFK021081; Wed, 6 Apr 2005 23:53:16 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A9@rsys004a> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27A9@rsys004a> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2930a75d320539e103774421b5da799f@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Wed, 6 Apr 2005 20:03:12 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.7 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, Kristofer Sandlund , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit On Apr 06 2005, at 17:19 Uhr, Finking, Robert wrote: > ip_inner_ecn:uncomp_value = ip_ecn_flags:uncomp_value; Why not ip_ecn_flags:uncomp_value = ip_inner_ecn:uncomp_value; > pad_len:uncomp_value = nbits - 8; Why not nbits = pad_len:uncomp_value + 8; I still don't understand what we are trying to achieve here. I have no problem leaving out the "when" (the parentheses did help syntax analysis; I don't think really bad things happen if you leave them out). If people think it includes readability, we could allow "=" as a synonym of "==" (although then I'd like to change the separator we use between format names and field lists). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 7 08:22:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15619 for ; Thu, 7 Apr 2005 08:22:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJW9r-00088b-GL for rohc-web-archive@ietf.org; Thu, 07 Apr 2005 08:30:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVxT-0005tX-5q; Thu, 07 Apr 2005 08:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVxR-0005tS-FH for rohc@megatron.ietf.org; Thu, 07 Apr 2005 08:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15288 for ; Thu, 7 Apr 2005 08:17:59 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJW5y-0007yF-AN for rohc@ietf.org; Thu, 07 Apr 2005 08:26:52 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j37CH6Qc006752; Thu, 7 Apr 2005 13:17:06 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <23Y4WRF5>; Thu, 7 Apr 2005 13:17:16 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27B6@rsys004a> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Thu, 7 Apr 2005 13:16:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rohc@ietf.org, Kristofer Sandlund , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Carsten, All, > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, April 06, 2005 7:03 PM > > On Apr 06 2005, at 17:19 Uhr, Finking, Robert wrote: > > > ip_inner_ecn:uncomp_value = ip_ecn_flags:uncomp_value; > > Why not > > ip_ecn_flags:uncomp_value = ip_inner_ecn:uncomp_value; > > > pad_len:uncomp_value = nbits - 8; > > Why not > nbits = pad_len:uncomp_value + 8; > Because we're trying to make it into an assignment statement with LHS and RHS, NOT an equivalence relation. > I still don't understand what we are trying to achieve here. We're trying to either make it easier for non mathematicians to understand or else to prove that doing so breaks the packet formats. > > I have no problem leaving out the "when" (the parentheses did help > syntax analysis; I don't think really bad things happen if you leave > them out). I think we want to see an explicitly "if" or "when" or something to make the non-binding conditionals obvious. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 7 08:24:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15836 for ; Thu, 7 Apr 2005 08:24:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJWBq-0008BY-NO for rohc-web-archive@ietf.org; Thu, 07 Apr 2005 08:32:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJW25-0006kW-AS; Thu, 07 Apr 2005 08:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJW24-0006kN-28 for rohc@megatron.ietf.org; Thu, 07 Apr 2005 08:22:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15708 for ; Thu, 7 Apr 2005 08:22:46 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJWAa-00089j-Ta for rohc@ietf.org; Thu, 07 Apr 2005 08:31:38 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j37CMWht007644; Thu, 7 Apr 2005 14:22:34 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27B6@rsys004a> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27B6@rsys004a> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1aefeb64220601d056968125ef8bbd8b@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Thu, 7 Apr 2005 14:22:31 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, Kristofer Sandlund , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Apr 07 2005, at 14:16 Uhr, Finking, Robert wrote: > Because we're trying to make it into an assignment statement with LHS > and RHS I understand that. I just don't know what qualifies something to be an LHS. (It seems to me that if there is nothing that qualifies as an LHS, the "when" notation is being used.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 7 09:57:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24564 for ; Thu, 7 Apr 2005 09:57:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXdx-0003Sx-5N for rohc-web-archive@ietf.org; Thu, 07 Apr 2005 10:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXT9-00085t-Iw; Thu, 07 Apr 2005 09:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXT8-00085j-7O for rohc@megatron.ietf.org; Thu, 07 Apr 2005 09:54:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24208 for ; Thu, 7 Apr 2005 09:54:47 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXbf-0003OZ-Ie for rohc@ietf.org; Thu, 07 Apr 2005 10:03:41 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j37DsTQc030122; Thu, 7 Apr 2005 14:54:29 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <23Y4WRN0>; Thu, 7 Apr 2005 14:54:39 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27BE@rsys004a> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Thu, 7 Apr 2005 14:54:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: rohc@ietf.org, Kristofer Sandlund , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, April 07, 2005 1:23 PM > > I just don't know what qualifies > something to be an > LHS. If it is not defined elsewhere. On the other hand, all components of an RHS must be defined (at least if I've understood L-E correctly). _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 7 16:25:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04760 for ; Thu, 7 Apr 2005 16:25:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdi6-0001L4-DI for rohc-web-archive@ietf.org; Thu, 07 Apr 2005 16:34:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdWy-0004LA-5s; Thu, 07 Apr 2005 16:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdWw-0004JQ-IE for rohc@megatron.ietf.org; Thu, 07 Apr 2005 16:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04573 for ; Thu, 7 Apr 2005 16:23:07 -0400 (EDT) From: pelle@cdt.luth.se Received: from lisa.sm.luth.se ([130.240.3.1] helo=sm.luth.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdfV-0001FH-BP for rohc@ietf.org; Thu, 07 Apr 2005 16:32:04 -0400 Received: from localhost (localhost [127.0.0.1]) by sm.luth.se (8.12.9/8.13.0) with ESMTP id j37KN1pY014810; Thu, 7 Apr 2005 22:23:01 +0200 (MEST) Received: from cacher3.ericsson.net (cacher3.ericsson.net [194.237.142.21]) by www.sm.luth.se (IMP) with HTTP for ; Thu, 7 Apr 2005 22:23:01 +0200 Message-ID: <1112905381.425596a58488d@www.sm.luth.se> Date: Thu, 7 Apr 2005 22:23:01 +0200 To: "Finking, Robert" Subject: RE: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27B6@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27B6@rsys004a> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 194.237.142.21 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 8bit Cc: "'Carsten Bormann'" , rohc@ietf.org, Kristofer Sandlund , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 8bit > > I still don't understand what we are trying to achieve here. > > We're trying to either make it easier for non mathematicians to understand or > else to prove that doing so breaks the packet formats. I don't understand either what we're trying to solve... I think that the let statement works well as it is, and if there is a risk that "non-mathematicians" won't understand it then it's simply to make sure that's it's properly defined in FN. This is becoming to close to become a matter of personal taste I feel. > > > > I have no problem leaving out the "when" (the parentheses did help > > syntax analysis; I don't think really bad things happen if you leave > > them out). > > I think we want to see an explicitly "if" or "when" or something to make the > non-binding conditionals obvious. Now, this is where I might be shooting myself in the foot (laf laf) - I thought that these conditionals where binding, if not simply because they need to be reversible for the statement to be both valid for compression and decompression? It seems to me that there would be something missing if using a "if" the "intuitive" way - we'd have to redefine it to become equivalent to today's "let". What's the point? Please, let's have the "let" rest in peace (or fix its definition so that anyone can understand it) and let us focus on reviewing the packet formats and actual compression... /Ghyslain > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 02:53:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10881 for ; Fri, 8 Apr 2005 02:53:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnVG-00048S-87 for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 03:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnLp-00023o-EV; Fri, 08 Apr 2005 02:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnLm-00023V-M0 for rohc@megatron.ietf.org; Fri, 08 Apr 2005 02:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10832 for ; Fri, 8 Apr 2005 02:52:17 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnUT-00047w-NJ for rohc@ietf.org; Fri, 08 Apr 2005 03:01:19 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j386p7Tc028147; Fri, 8 Apr 2005 08:52:15 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 08:51:58 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 08:52:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] TCP profile FN, ip_id_behavior_enc Date: Fri, 8 Apr 2005 08:51:57 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2793@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] TCP profile FN, ip_id_behavior_enc Thread-Index: AcU6ryhi83bisELPQBWa8fA7LcD0LQBWA/3A From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Eilert Brinkmann" , "Finking, Robert" X-OriginalArrivalTime: 08 Apr 2005 06:52:06.0420 (UTC) FILETIME=[7A4C8540:01C53C07] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable >=20 > IP_ID_BEHAVIOR_SEQUENTIAL =3D 0; > IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED =3D 1; > IP_ID_BEHAVIOR_RANDOM =3D 2; > IP_ID_BEHAVIOR_RANDOM_SWAPPED =3D 3; And what would "RANDOM_SWAPPED" mean?=20 Do we cover IP_ID_ZERO? Then no field at all is sent, but anyway... /L-E=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 03:09:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12117 for ; Fri, 8 Apr 2005 03:09:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnlD-0004bD-MG for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 03:18:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnb9-0004xY-Jv; Fri, 08 Apr 2005 03:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnb5-0004wX-FK for rohc@megatron.ietf.org; Fri, 08 Apr 2005 03:08:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12006 for ; Fri, 8 Apr 2005 03:08:06 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnjn-0004Zu-IU for rohc@ietf.org; Fri, 08 Apr 2005 03:17:08 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3877piB008044; Fri, 8 Apr 2005 09:07:58 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:07:59 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:07:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Fri, 8 Apr 2005 09:07:52 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2794@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Thread-Index: AcU7r59b+1BzIhE8SKy2LpFnQ4/dZAAWM3Mw From: "Lars-Erik Jonsson \(LU/EAB\)" To: , "Finking, Robert" X-OriginalArrivalTime: 08 Apr 2005 07:07:58.0193 (UTC) FILETIME=[B1998E10:01C53C09] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , rohc@ietf.org, Kristofer Sandlund X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Folks, Personally, I liked the new proposal from Robert, that made much more sense to me than the let. Further, I do not understand the concern Ghyslain expressed about the new proposal, i.e. I do not see what would be wrong with it. Anyway, it seems like I am the only one disagreeing with the let statement, and I will not continue to argue if there is consensus among the others that I am just a disturber in this matter (as seems to be Ghyslain's opinion). I now leave it up to you to decide whether to address my concern or not, in any case I will at least be happy with 95% of the FN. /L-E > -----Original Message----- > From: pelle@cdt.luth.se [mailto:pelle@cdt.luth.se] > Sent: den 7 april 2005 22:23 > To: Finking, Robert > Cc: 'Carsten Bormann'; rohc@ietf.org; Kristofer Sandlund; Lars-Erik > Jonsson (LU/EAB) > Subject: RE: [rohc] FN let statements and TCP packet formats (was: > Updated FN Draft - Appendix A) >=20 >=20 > > > I still don't understand what we are trying to achieve here. > >=20 > > We're trying to either make it easier for non=20 > mathematicians to understand or > > else to prove that doing so breaks the packet formats. >=20 > I don't understand either what we're trying to solve... I=20 > think that the let=20 > statement works well as it is, and if there is a risk that=20 > "non-mathematicians"=20 > won't understand it then it's simply to make sure that's it's=20 > properly defined=20 > in FN. This is becoming to close to become a matter of=20 > personal taste I feel. =20 > =20 > > >=20 > > > I have no problem leaving out the "when" (the parentheses=20 > did help=20 > > > syntax analysis; I don't think really bad things happen=20 > if you leave=20 > > > them out). > >=20 > > I think we want to see an explicitly "if" or "when" or=20 > something to make the > > non-binding conditionals obvious. >=20 > Now, this is where I might be shooting myself in the foot=20 > (laf laf) - I thought=20 > that these conditionals where binding, if not simply because=20 > they need to be=20 > reversible for the statement to be both valid for compression and=20 > decompression? It seems to me that there would be something=20 > missing if using=20 > a "if" the "intuitive" way - we'd have to redefine it to=20 > become equivalent to=20 > today's "let". What's the point? >=20 > Please, let's have the "let" rest in peace (or fix its=20 > definition so that=20 > anyone can understand it) and let us focus on reviewing the=20 > packet formats and=20 > actual compression... >=20 > /Ghyslain >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 03:25:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13361 for ; Fri, 8 Apr 2005 03:25:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJo0k-0005Ap-Cw for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 03:34:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnrq-0006di-6C; Fri, 08 Apr 2005 03:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnrk-0006Xd-9v for rohc@megatron.ietf.org; Fri, 08 Apr 2005 03:25:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13274 for ; Fri, 8 Apr 2005 03:25:19 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJo0R-00058q-JR for rohc@ietf.org; Fri, 08 Apr 2005 03:34:21 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j387PAQO017394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 09:25:11 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.13.1/8.12.8/Submit) id j387P4GL008768; Fri, 8 Apr 2005 09:25:04 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: "Lars-Erik Jonsson \(LU/EAB\)" Subject: Re: [rohc] TCP profile FN, ip_id_behavior_enc References: <026F8EEDAD2C4342A993203088C1FC051C2793@esealmw109.eemea.ericsson.se> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Fri, 08 Apr 2005 09:25:04 +0200 In-Reply-To: <026F8EEDAD2C4342A993203088C1FC051C2793@esealmw109.eemea.ericsson.se> (Lars-Erik Jonsson's message of "Fri, 8 Apr 2005 08:51:57 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 "Lars-Erik Jonsson \(LU/EAB\)" wrote: >> IP_ID_BEHAVIOR_SEQUENTIAL = 0; >> IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; >> IP_ID_BEHAVIOR_RANDOM = 2; >> IP_ID_BEHAVIOR_RANDOM_SWAPPED = 3; > > And what would "RANDOM_SWAPPED" mean? Argh, just an ugly mistake. Obviously, I mixed something up when composing the constant names. > Do we cover IP_ID_ZERO? Then no field at all is sent, but anyway... Yes. Of course, the fourth definition should be: IP_ID_BEHAVIOR_ZERO = 3; Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 04:44:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18820 for ; Fri, 8 Apr 2005 04:44:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpFQ-0007hs-Km for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 04:53:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJp5K-0002ks-1h; Fri, 08 Apr 2005 04:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJp56-0002gY-FN for rohc@megatron.ietf.org; Fri, 08 Apr 2005 04:43:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18666 for ; Fri, 8 Apr 2005 04:43:10 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpDo-0007gU-CB for rohc@ietf.org; Fri, 08 Apr 2005 04:52:14 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j388gfQc024607; Fri, 8 Apr 2005 09:42:41 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <23Y4WS4S>; Fri, 8 Apr 2005 09:42:52 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27C2@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , pelle@cdt.luth.se Subject: RE: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Fri, 8 Apr 2005 09:42:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Carsten Bormann , rohc@ietf.org, Kristofer Sandlund X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 OK, great. Thanks L-E. In that case the only issue is the lack of clarity in the description. I'll update the draft to try and clarify the let statement section as requested previously. Regards Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Friday, April 08, 2005 8:08 AM > To: pelle@cdt.luth.se; Finking, Robert > Cc: Carsten Bormann; rohc@ietf.org; Kristofer Sandlund > Subject: RE: [rohc] FN let statements and TCP packet formats > (was: Updated FN Draft - Appendix A) > > > Folks, > > Personally, I liked the new proposal from Robert, that made > much more sense to me than the let. Further, I do not understand > the concern Ghyslain expressed about the new proposal, i.e. I > do not see what would be wrong with it. > > Anyway, it seems like I am the only one disagreeing with the > let statement, and I will not continue to argue if there is > consensus among the others that I am just a disturber in this > matter (as seems to be Ghyslain's opinion). I now leave it up > to you to decide whether to address my concern or not, in any > case I will at least be happy with 95% of the FN. > > /L-E > > > > -----Original Message----- > > From: pelle@cdt.luth.se [mailto:pelle@cdt.luth.se] > > Sent: den 7 April 2005 22:23 > > To: Finking, Robert > > Cc: 'Carsten Bormann'; rohc@ietf.org; Kristofer Sandlund; Lars-Erik > > Jonsson (LU/EAB) > > Subject: RE: [rohc] FN let statements and TCP packet formats (was: > > Updated FN Draft - Appendix A) > > > > > > > > I still don't understand what we are trying to achieve here. > > > > > > We're trying to either make it easier for non > > mathematicians to understand or > > > else to prove that doing so breaks the packet formats. > > > > I don't understand either what we're trying to solve... I > > think that the let > > statement works well as it is, and if there is a risk that > > "non-mathematicians" > > won't understand it then it's simply to make sure that's it's > > properly defined > > in FN. This is becoming to close to become a matter of > > personal taste I feel. > > > > > > > > > > I have no problem leaving out the "when" (the parentheses > > did help > > > > syntax analysis; I don't think really bad things happen > > if you leave > > > > them out). > > > > > > I think we want to see an explicitly "if" or "when" or > > something to make the > > > non-binding conditionals obvious. > > > > Now, this is where I might be shooting myself in the foot > > (laf laf) - I thought > > that these conditionals where binding, if not simply because > > they need to be > > reversible for the statement to be both valid for compression and > > decompression? It seems to me that there would be something > > missing if using > > a "if" the "intuitive" way - we'd have to redefine it to > > become equivalent to > > today's "let". What's the point? > > > > Please, let's have the "let" rest in peace (or fix its > > definition so that > > anyone can understand it) and let us focus on reviewing the > > packet formats and > > actual compression... > > > > /Ghyslain > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 07:32:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05882 for ; Fri, 8 Apr 2005 07:32:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrsA-0007b8-Qz for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 07:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrhb-0003rT-EX; Fri, 08 Apr 2005 07:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrhZ-0003rL-AE for rohc@megatron.ietf.org; Fri, 08 Apr 2005 07:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05723 for ; Fri, 8 Apr 2005 07:31:04 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrqI-0007XV-9O for rohc@ietf.org; Fri, 08 Apr 2005 07:40:07 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j38AUEmg032436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Apr 2005 12:30:14 +0200 Message-ID: <42566B6D.7040500@effnet.com> Date: Fri, 08 Apr 2005 13:30:53 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eilert Brinkmann Subject: Re: [rohc] TCP profile FN, ip_id_behavior_enc References: <026F8EEDAD2C4342A993203088C1FC051C2793@esealmw109.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: "Finking, Robert" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi! I think we have one more problem regarding the IPID. Currently, I don't think the descriptions actually capture what comrpessed packet format set IPv6 uses, since it does not have this control field (ip_id_behavior). So, I think we need to place a let-statement in the ipv6 default_methods to say that the behavior is IP_ID_BEHAVIOR_RANDOM, so that the _rnd packet format set is always used. This would also mean that the behavior control field would have to be defined for IPv6 as well. Or do we add some 'let' to the compressed packet formats to indicate that "if behavior is undefined" instead? Btw, I'm fine with changing the behavior numbers to symbolic constants, that seems like a good idea. /Kristofer Sandlund, Effnet AB Eilert Brinkmann wrote: > "Lars-Erik Jonsson \(LU/EAB\)" wrote: > >>>IP_ID_BEHAVIOR_SEQUENTIAL = 0; >>>IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; >>>IP_ID_BEHAVIOR_RANDOM = 2; >>>IP_ID_BEHAVIOR_RANDOM_SWAPPED = 3; >> >>And what would "RANDOM_SWAPPED" mean? > > > Argh, just an ugly mistake. Obviously, I mixed something up when > composing the constant names. > > >>Do we cover IP_ID_ZERO? Then no field at all is sent, but anyway... > > > Yes. Of course, the fourth definition should be: > > IP_ID_BEHAVIOR_ZERO = 3; > > Eilert > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 07:41:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06763 for ; Fri, 8 Apr 2005 07:41:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJs0f-00085c-Di for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 07:50:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrn1-0004e5-5C; Fri, 08 Apr 2005 07:36:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrmz-0004e0-Iw for rohc@megatron.ietf.org; Fri, 08 Apr 2005 07:36:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06158 for ; Fri, 8 Apr 2005 07:36:40 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrvj-0007hS-21 for rohc@ietf.org; Fri, 08 Apr 2005 07:45:44 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j38Ba8ij020370; Fri, 8 Apr 2005 13:36:38 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 13:35:22 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 13:35:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] TCP profile FN, ip_id_behavior_enc Date: Fri, 8 Apr 2005 13:35:21 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27A1@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] TCP profile FN, ip_id_behavior_enc Thread-Index: AcU8DCM365/jtJMKSr2QXoB7FUkEWQAIsySA From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Eilert Brinkmann" X-OriginalArrivalTime: 08 Apr 2005 11:35:22.0283 (UTC) FILETIME=[0C9F67B0:01C53C2F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Actually, the way we cover the zero case is by the more generic = definition CONSTANT, right? /L-E > -----Original Message----- > From: Eilert Brinkmann [mailto:eilert@tzi.org] > Sent: den 8 april 2005 09:25 > To: Lars-Erik Jonsson (LU/EAB) > Cc: Finking, Robert; rohc@ietf.org > Subject: Re: [rohc] TCP profile FN, ip_id_behavior_enc >=20 >=20 > "Lars-Erik Jonsson \(LU/EAB\)" wrote: > >> IP_ID_BEHAVIOR_SEQUENTIAL =3D 0; > >> IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED =3D 1; > >> IP_ID_BEHAVIOR_RANDOM =3D 2; > >> IP_ID_BEHAVIOR_RANDOM_SWAPPED =3D 3; > > > > And what would "RANDOM_SWAPPED" mean?=20 >=20 > Argh, just an ugly mistake. Obviously, I mixed something up when > composing the constant names. >=20 > > Do we cover IP_ID_ZERO? Then no field at all is sent, but anyway... >=20 > Yes. Of course, the fourth definition should be: >=20 > IP_ID_BEHAVIOR_ZERO =3D 3; >=20 > Eilert >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 08:04:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09191 for ; Fri, 8 Apr 2005 08:04:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsMM-0000ym-7u for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 08:13:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsBF-0002gL-SA; Fri, 08 Apr 2005 08:01:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsBE-0002gG-J8 for rohc@megatron.ietf.org; Fri, 08 Apr 2005 08:01:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08837 for ; Fri, 8 Apr 2005 08:01:43 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsJz-0000uE-BV for rohc@ietf.org; Fri, 08 Apr 2005 08:10:47 -0400 Received: from [192.168.101.53] (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j38B11mg032599 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 8 Apr 2005 13:01:02 +0200 Message-ID: <42567250.9060409@effnet.com> Date: Fri, 08 Apr 2005 14:00:16 +0200 From: Carl Knutsson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Subject: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: carl.knutsson@effnet.com List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Hi all, I think the draft is in good shape. I have some comments and suggestions concerning the handling of decompression failures and local repairs caused by late packets. From 5.2.3 Detected Decompression failures: "Fortunately, as the outcome of the decompression of updating packets can be verified, the decompressor can reliably detect decompression failures caused by reordering and discard the packet." When reading this sentence, you get the impression that the decompressor can detect if the decompression failure is caused by reordering. That is not the case, decompressor failures are detected, but whether it is caused is packet loss bit errors or reordering is unknown. The sentence is correct, but when I read it the first time, I got the impression that the cause of the decompression failure could be identified. I believe the reference to in section 5.3.2.3 in rfc3095, in the last sentence of this section, should be changed to section 5.3.2.2.3. Section 5.3.2.3 is "Feedback in Unidirectional mode" and section 5.3.2.2.3 is "Actions upon CRC failures". 6.1.2.3. Considerations for Local Repair Mechanisms I have some comments on the local repair for late updating packets. The decompressor should not always try local repair for late packets. Late packets, decompressed by moving backwards into the interpretation interval, could cause the decompressor to revert to an old context. If the local repair for the late packet is successful, the next in-order packet could potentially be outside the interpretation interval. This will decrease the robustness against packet loss. The algorithm suggested in rfc3095 section 5.3.2.2.5 would discard at least two packets, if not more, when repairing the context. Instead, if the decompressor is confident that the packet is late, it may be allowed to pass the packet on to upper layers or discard the packet without updating the context. The compressor can be confident that a packet is late by going backwards in the interpretation interval and try to decompress the the packet, using the CRC to validate the attempt (as suggested in this section). In rfc 3095 section 5.3.2.2.3, a decompression failure caused by a late packet outside the interpretation interval, will add to the k out of n check. Several late packets could cause decompressor, with a correct context, to discard all packets until the context state is refreshed. Allowing the decompressor to ignore context updates from suspected late packet could decrease it vulnerability against late packets. I suggest that we change the this section to something like this: "When decompression fails, and if reordering is believed to be cause of this failure, subsequent decompressions may be attempted for sequentially late packets by going backwards in the interpretation interval (as opposed to moving forward for local repair). If one of the decompression attempt is successful, the late packet may be passed on to upper layers with or without updating the decompressor context. If the subsequent decompression attempt fails, the packet should be handled according to [3] section 5.3.2.2.3." [3] is rfc3095 and section 5.3.2.2.3 is "Action upon CRC failure". We leave it up to the implementor determine if it is a late packet and if the decompressor context should be updated or not. A late packet could include a new update vital to the decompressor context, but it could also include an old update that will destroy the context. The implementor have the choice to ignore any special treatment for late packet and handle it according to section 5.3.2.2.3 of rfc3095. To hint, without getting to much into detail, that it is not always for the best to immediately update the context for a late packet, even if it is decompressed successfully and validated by the CRC. Brgds, /Carl Knutsson, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 08:35:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12450 for ; Fri, 8 Apr 2005 08:35:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsqk-0002hh-JK for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 08:44:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsfQ-0007dc-2j; Fri, 08 Apr 2005 08:32:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsfO-0007dL-Oe for rohc@megatron.ietf.org; Fri, 08 Apr 2005 08:32:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11994 for ; Fri, 8 Apr 2005 08:32:53 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJso9-0002Vt-Jk for rohc@ietf.org; Fri, 08 Apr 2005 08:41:58 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j38CWZQc012746; Fri, 8 Apr 2005 13:32:36 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <23Y4WTFC>; Fri, 8 Apr 2005 13:32:47 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A27CE@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , rohc@ietf.org Subject: RE: [rohc] FN let statements and TCP packet formats (was: Updated FN Draft - Appendix A) Date: Fri, 8 Apr 2005 13:32:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi L-E, All, OK - expect an update next week some time =) Thanks for getting involved everybody - useful discussion. Regards Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Friday, April 08, 2005 12:32 PM > To: Finking, Robert > Subject: RE: [rohc] FN let statements and TCP packet formats > (was: Updated FN Draft - Appendix A) > > > OK, as a guidelines for rewriting the let description, I hope > you will use the ideas you've developed during our > discussions, i.e. to explain conceptually the relation > between binding, assignment, assertion, and how let covers > all these aspects. I also expect additional examples for > appendix B that shows when/how let is needed, with different > purposes. Assignment is already there, an example of the > assertion usage (like for IP-ID, with parameter?) should be > added, and probably also an example when you have both types > of usages. > > /L-E > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 8 09:38:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19349 for ; Fri, 8 Apr 2005 09:38:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtpn-0006Kz-Us for rohc-web-archive@ietf.org; Fri, 08 Apr 2005 09:47:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtdw-0004L5-3W; Fri, 08 Apr 2005 09:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtdu-0004KH-0v for rohc@megatron.ietf.org; Fri, 08 Apr 2005 09:35:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18961 for ; Fri, 8 Apr 2005 09:35:24 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtmf-00067x-ES for rohc@ietf.org; Fri, 08 Apr 2005 09:44:30 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j38DXfkQ018860; Fri, 8 Apr 2005 15:35:17 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 15:34:11 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 15:34:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt Date: Fri, 8 Apr 2005 15:34:11 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27A5@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcU8Mx5KiV0UU3CmRLeNjQYLD+MGygACPCfw From: "Lars-Erik Jonsson \(LU/EAB\)" To: , X-OriginalArrivalTime: 08 Apr 2005 13:34:11.0454 (UTC) FILETIME=[A5F091E0:01C53C3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Carl, Thanks for the review, proposed actions to your comments can be found = inline. /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Carl Knutsson > Sent: den 8 april 2005 14:00 > To: rohc@ietf.org > Subject: [rohc] WG review: draft-ietf-rohc-over-reordering-02.txt >=20 >=20 > Hi all, >=20 > I think the draft is in good shape. I have some comments and=20 > suggestions=20 > concerning the handling of decompression failures and local repairs=20 > caused by late packets. >=20 > From 5.2.3 Detected Decompression failures: >=20 > "Fortunately, as the outcome of the decompression of updating packets=20 > can be verified, the decompressor can reliably detect decompression=20 > failures caused by reordering and discard the packet." >=20 > When reading this sentence, you get the impression that the=20 > decompressor can detect if the decompression failure is caused by=20 > reordering. That is not the case, decompressor failures are > detected, but whether it is caused is packet loss bit errors or > reordering is unknown. The sentence is correct, but when I read it > the first time, I got the impression that the cause of the > decompression failure could be identified. OK, true, so what about: "Fortunately, as the outcome of the decompression of updating packets = can be verified, the decompressor can reliably detect decompression = failures, including those caused by reordering, and discard the packet. = Note that local repairs, subject to the limitations stated in [2] = section 5.3.2.2.3, can still be performed." > I believe the reference to in section 5.3.2.3 in rfc3095, in the last=20 > sentence of this section, should be changed to section 5.3.2.2.3.=20 > Section 5.3.2.3 is "Feedback in Unidirectional mode" and section=20 > 5.3.2.2.3 is "Actions upon CRC failures". Thanks, corrected! =20 > 6.1.2.3. Considerations for Local Repair Mechanisms >=20 > I have some comments on the local repair for late updating=20 > packets. The decompressor should not always try local repair > for late packets. Late packets, decompressed by moving > backwards into the interpretation interval, could cause the > decompressor to revert to an old context. If the local > repair for the late packet is successful, the next in-order=20 > packet could potentially be outside the interpretation > interval. This will decrease the robustness against packet > loss. The algorithm suggested in rfc3095 section 5.3.2.2.5 > would discard at least two packets, if not more, when > repairing the context. >=20 > Instead, if the decompressor is confident that the packet > is late, it may be allowed to pass the packet on to upper > layers or discard the packet without updating the context. > The compressor can be confident that a packet is late by > going backwards in the interpretation interval and try to > decompress the packet, using the CRC to validate the=20 > attempt (as suggested in this section). >=20 > In rfc 3095 section 5.3.2.2.3, a decompression failure > caused by a late packet outside the interpretation interval, > will add to the k out of n check. Several late packets could > cause decompressor, with a correct context, to discard all > packets until the context state is refreshed.=20 > Allowing the decompressor to ignore context updates from=20 > suspected late packet could decrease it vulnerability against > late packets. >=20 > I suggest that we change the this section to something like this: >=20 > "When decompression fails, and if reordering is believed to=20 > be cause of this failure, subsequent decompressions may be > attempted for sequentially late packets by going backwards in > the interpretation interval (as opposed to moving forward for > local repair). If one of the decompression attempt is successful, > the late packet may be passed on to upper layers with or without > updating the decompressor context. If the subsequent > decompression attempt fails, the packet should be handled=20 > according to [3] section 5.3.2.2.3." I'm happy with this text as suggested! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 11 10:00:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15024 for ; Mon, 11 Apr 2005 10:00:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzce-0000Sb-8b for rohc-web-archive@ietf.org; Mon, 11 Apr 2005 10:10:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzRS-000059-QR; Mon, 11 Apr 2005 09:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzRP-0008Vq-Rn for rohc@megatron.ietf.org; Mon, 11 Apr 2005 09:59:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14855 for ; Mon, 11 Apr 2005 09:58:53 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzae-0000Of-4f for rohc@ietf.org; Mon, 11 Apr 2005 10:08:37 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3BDwfhv025950; Mon, 11 Apr 2005 15:58:46 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:58:32 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:58:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2005 15:58:31 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27B4@esealmw109.eemea.ericsson.se> Thread-Topic: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt Thread-Index: AcU1vSAyjMg9U1pxQSyIjuHmXyM1SAIzU3qg From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ertekin Emre" X-OriginalArrivalTime: 11 Apr 2005 13:58:31.0993 (UTC) FILETIME=[8BBA6290:01C53E9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org Subject: [rohc] RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Emre and others, I agree with Kristofers comments, and he is completely correct when he says I am not that fond of the use of 2119 keywords in requirements documents, and the reason is very well exemplified by the point being raised in this case. The 2119 keywords are defined to indicate to an implementer what functionality to implement, but it is not at all clear how to interpret such words in the context of a requirements document. Some more comments from me: * HC for SA transport mode Re-using existing HC schemes sound like a good idea, but there is no existing scheme that only compress transport layer headers. Further, one could argue that the transport header overhead is too small to justify compression of that alone. In any case, I believe compression for the transport-SA case is not as easy to justify as for tunnel mode, and would require much more work. * 5. Goals and requirements This is an essential part of the document, but I would prefer to have a slightly different approach for it. The most important thing here, in my mind, is to make clear what work is needed to have a complete solution, considering what we already have. Some of these would, in my mind, be work assumptions, while the rest of them are "work items", as we are already into solution space, considering the initial assumptions. We do not need strong words, we must understand what work is needed. - a. is actually an assumption that the HCoIPsec work is to be based in existing HC protocols, with modifications/extensions. - b. is stating the goal of the whole work, to develop a HC solution for IPsec SA's. Also an initial assumption, or goal. - c. talks about the HC protocol improvements needed to cope with increased delays, loss, and reordering between compressor and=20 decompressor. This is specific work that must be done. - d. is nothing new. As Kristofer noted, one can never guarantee this without an infinite checksum, but existing HC schemes already have this as a goal, ROHC has specifically addressed thus. I see no reason to repeat that here. - e. is obvious to me, although it is unclear exactly what one mean with HC signalling. I do not think this is needed here, but if it is kept, it must be explained what signalling this is about, more specifically. Might be a requirement on the solution, but it would be more useful with a discussion of the content of it. - f. translates into two work items, which I would call defining: 1) Negotiation for HC scheme usage/support and HC scheme parameters 2) Encapsulation and identification - g. means to me that a SA would constitute the HC point2point link, i.e. the channel over which a corresponding compressor/decompressor pair is operating, and the CID space would then obviously be local to each SA. This is more of a work assumption than a requirement, I think.=20 - h. is fine as a on the complete solution requirement! >From this, I see 3 different work items: # The improvements of existing HC schemes so that they can work over this channel scenario, i.e. address c) # Define negotiation mechanisms for HC over SA's # Define encapsulation/identification of header compressed data over SA's, i.e. within ESP or AH. * Identification and encapsulation Identification can be done either by negotiation (always on/always = off) and make use of e.g. ROHC "uncompressed", or by having new = prot/nextHdr identifier(s). Encapsulation would require type identifiers for all schemes but ROHC (this should be made clear at various places in the document), which is why more than one protocol number (otherwise one useless octet will be added in the ROHC case, as ROHC handles its own packet type identification). Apart from this, I think the draft looks good! Rgds, /L-E > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 31 mars 2005 08:45 > Subject: Re: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt >=20 >=20 > Hi Emre, >=20 > Some comments from a quick read-through of the draft. >=20 > Section 5: > d. HCoIPsec MUST NOT allow incorrectly decompressed packets to be > forwarded from the decompressor (i.e., decryptor) > This actually implies that the HC scheme must have an=20 > inifintely long checksum, and it is not possible to actually > fulfill this requirement. One alternative is to weaken the > text to say "should try to avoid....", but maybe that's too > weak. Instead, I would try to put this in comparison with > "the same tunnel without HC" and say that it "..should not > deliver a larger amount of incorrect headers than the same > tunnel without HC" (using "must" instead of "should" would > mean that there also has be a way to quantify this, and I > don't think you want to go down that road). >=20 > e. HCoIPsec MUST minimize the amount of header=20 > compression signaling between compressor and decompressor > Do you mean feedback/header requests here or do you mean that=20 > one should not=20 > introduce any further signaling here? Clarify please. Also=20 > "MUST minimize", what=20 > does that mean? It does not really say how much signaling is=20 > reasonable. Again,=20 > weaken the text and say something like "...should attempt to=20 > minimize...". Point=20 > c) of the same section also has a similar wording that the=20 > same comment applies to. >=20 > Editorial details: > A minor thing that I'm sure that L-E will point out later is=20 > that some people (myself included) are not too fond of the > use of "MUST", "MAY" etc in requirements drafts (I'd prefer > just using "must" etc). But since a lot of people use the > RFC2119 keywords in req-drafts, it is not an error, so you > can keep it that way if you want to. And now I noticed that > if you use them, you need to have a reference to 2119 :)=20 > Also, isn't it mandatory these days to split the references=20 > into normative and informative references? >=20 >=20 > Other than those comments, the draft seems well-written and=20 > probably sufficient for its purpose. >=20 > BR, > Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 12 08:33:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24995 for ; Tue, 12 Apr 2005 08:33:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLKjW-0007bZ-Tz for rohc-web-archive@ietf.org; Tue, 12 Apr 2005 08:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLKYJ-00006X-Vm; Tue, 12 Apr 2005 08:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLKYJ-0008VF-CK for rohc@megatron.ietf.org; Tue, 12 Apr 2005 08:31:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24848 for ; Tue, 12 Apr 2005 08:30:53 -0400 (EDT) Received: from [207.236.152.71] (helo=mtlexch02.mtl.slr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLKhD-0007XB-Vq for rohc@ietf.org; Tue, 12 Apr 2005 08:40:49 -0400 Received: by MTLEXCH02 with Internet Mail Service (5.5.2657.72) id <2VFTCJ0M>; Tue, 12 Apr 2005 08:35:08 -0400 Message-ID: <1CCF22B8BDBD254DA84EC0B05D3DAEEC02A81A12@mtlexch01.mtl.cmac.com> From: "Lepine, Jean-Pierre" To: rohc@ietf.org Date: Tue, 12 Apr 2005 08:30:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.9 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Subject: [rohc] SigComp state creation and the state retention priority X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0523104748==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0523104748== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53F5B.6E49EEC0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C53F5B.6E49EEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, =20 I sent the following email almost 2 weeks ago but I didn't get any = feedback on it. I would really appreciate a follow-up on this. Thanks. =20 -----Message d'origine----- De : Lepine, Jean-Pierre=20 Envoy=E9 : 31 mars, 2005 08:58 =C0 : rohc@ietf.org Objet : SigComp state creation and the state retention priority Hi all, =20 I would just like to confirm something regarding SigComp state creation = and the state retention priority. =20 Initially, I thought that trying to create a state item in a = compartment could NEVER push state items with a higher priority out of the = compartment. In particular, suppose a compartment uses its full amount of SMS with = state items of priority 1, I thought that trying to create a state item with priority 0 would fail without any effect on the compartment's content. =20 However, after reviewing RFC 3320, I now understand that for the above example, one or more state items of priority 1 MUST be pushed out of = the compartment (freed) until enough memory is available to create the = state item of priority 0. More generally, a state item with a given priority, = even the highest, CAN be pushed out of a compartment by the creation of = state items with lower priorities. In other words, a newer state item is considered more important than an older state item, even if the older = one has a higher priority. =20 Am I right ? =20 If so, I guess there are some key motivations behind this design choice = but I don't really see them. I find this to be not very practical as a compressor must be careful not only with the chosen state priorities, = but also with the order of state creation requests.=20 =20 ------_=_NextPart_001_01C53F5B.6E49EEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 everybody,
 
I sent=20 the following email almost 2 weeks ago but I didn't get any feedback on = it.
I=20 would really appreciate a follow-up on this.
Thanks.
 
-----Message d'origine-----
De : Lepine, = Jean-Pierre=20
Envoy=E9 : 31 mars, 2005 08:58
=C0 :=20 rohc@ietf.org
Objet : SigComp state creation and the = state=20 retention priority

Hi=20 all,
 
I = would just like to=20 confirm something regarding SigComp state creation and the state = retention=20 priority.
 
Initially, I thought=20 that trying to create a state item in a compartment could NEVER push = state items=20 with a higher priority out of the compartment. In particular, suppose a = compartment uses its full amount of SMS with state items of priority 1, = I=20 thought that trying to create a state item with priority 0 would fail = without=20 any effect on the compartment's content.
 
However, after=20 reviewing RFC 3320, I now understand that for the above example, one or = more=20 state items of priority 1 MUST be pushed out of the compartment (freed) = until=20 enough memory is available to create the state item of priority 0.=20 More=20 generally, a state item with a given priority, even the highest, CAN be = pushed=20 out of a compartment by the creation of state items with lower = priorities.=20 In other words, a newer state item is considered more important than an = older=20 state item, even if the older one has a higher = priority.
 
Am I = right=20 ?
 
If = so, I guess there=20 are some key motivations behind this design choice but I don't really = see them.=20 I find this to be not very practical as a compressor must be careful = not only=20 with the chosen state priorities, but also with the order of state = creation=20 requests.
 
------_=_NextPart_001_01C53F5B.6E49EEC0-- --===============0523104748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0523104748==-- From rohc-bounces@ietf.org Wed Apr 13 06:48:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13967 for ; Wed, 13 Apr 2005 06:48:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLfaC-0002ug-9S for rohc-web-archive@ietf.org; Wed, 13 Apr 2005 06:58:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfPp-0006n8-PT; Wed, 13 Apr 2005 06:48:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfPo-0006mB-BR for rohc@megatron.ietf.org; Wed, 13 Apr 2005 06:48:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13912 for ; Wed, 13 Apr 2005 06:48:09 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLfZZ-0002u3-1o for rohc@ietf.org; Wed, 13 Apr 2005 06:58:18 -0400 Received: from tipau (tipau [193.175.133.74]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j3DAm8415504 for ; Wed, 13 Apr 2005 12:48:08 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau (8.12.7/8.8.8) with ESMTP id j3DAm7bb027501 for ; Wed, 13 Apr 2005 12:48:07 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j3DAm76u027500 for rohc@ietf.org; Wed, 13 Apr 2005 12:48:07 +0200 From: Cristian CONSTANTIN Date: Wed, 13 Apr 2005 12:48:07 +0200 To: rohc@ietf.org Message-ID: <20050413104807.GN16335@terix.fokus.gmd.de> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [rohc] sigcomp - meaning of the F bit in the input_bit_order register X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0617476188==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --===============0617476188== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aSnC4ZPPfhCvD8sN" Content-Disposition: inline --aSnC4ZPPfhCvD8sN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi! please help me to grasp the meaning of the F/H bits :-)=20 in the SigComp rfc, at 8.2. Requesting Additional Compressed Data there is this statement: "When an INPUT instruction requests n bits of compressed data, it interprets the received bits as an integer between 0 and 2^n - 1. The F-bit and the H-bit specify whether the bits in these integers are considered to arrive in MSB to LSB order (bit set to 0) or in LSB to MSB order (bit set to 1)." how should this be interpreted? 1. same as for the P bit; that is the bytes themselves are always in=20 network byte order but the bits in the bytes are in LSB to MSB order when F=3D1 and the other way around for F=3D0. 2. the bits in the _(short) integer_ are: =20 a. LSB to MSB for F=3D1. that would mean that the component bytes are also swapped which would more or less contradict another statement in 8.2: "Note that the input_bit_order register cannot change the order in which the bytes themselves are passed to the INPUT instructions (bytes are always passed in the same order as they occur in the SigComp message)." =20 b. MSB to LSB for F=3D0.=20 now, if 1 is the right interpretation, then wouldn't P=3D1 && F=3D1 cancel= =20 each other's effect? thank you for your attention. bye now! cristian --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --aSnC4ZPPfhCvD8sN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCXPjnypNgyZIZ1MERAlNGAJ9FfMMGVV4n4ZkuOoHt0r/osY9eIwCgnM5x /4NUwW4fdz35hH38smAXOAo= =xhu+ -----END PGP SIGNATURE----- --aSnC4ZPPfhCvD8sN-- --===============0617476188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0617476188==-- From rohc-bounces@ietf.org Wed Apr 13 07:18:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15586 for ; Wed, 13 Apr 2005 07:18:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLg33-0003bT-PL for rohc-web-archive@ietf.org; Wed, 13 Apr 2005 07:28:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfrR-0002Gx-0A; Wed, 13 Apr 2005 07:16:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfrP-0002G6-9Q for rohc@megatron.ietf.org; Wed, 13 Apr 2005 07:16:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15434 for ; Wed, 13 Apr 2005 07:16:31 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLg11-0003Xi-OI for rohc@ietf.org; Wed, 13 Apr 2005 07:26:41 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3DBGNAu025528; Wed, 13 Apr 2005 13:16:24 +0200 (MEST) In-Reply-To: <20050413104807.GN16335@terix.fokus.gmd.de> References: <20050413104807.GN16335@terix.fokus.gmd.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8768e91af5ebac81317adc7548ff0829@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] sigcomp - meaning of the F bit in the input_bit_order register Date: Wed, 13 Apr 2005 13:16:21 +0200 To: Cristian CONSTANTIN X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Apr 13 2005, at 12:48 Uhr, Cristian CONSTANTIN wrote: > now, if 1 is the right interpretation, then wouldn't P=1 && F=1 cancel > each other's effect? No, because P is about the way the bits are taken out of the input bytes and F/H are about the way they are assembled to binary numbers. If you are only ever assembling 8-bit numbers, they do cancel out. For 16-bit numbers, as you notice, the combination of P and F/H gives you a way to do the two different byte orders (which does NOT contradict the fact that bytes keep their order when being parsed into bits). For fractional-byte numbers (which tend to straddle input byte boundaries), it's best to draw a picture :-) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 13 14:57:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22828 for ; Wed, 13 Apr 2005 14:57:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLnDb-0007zn-R6 for rohc-web-archive@ietf.org; Wed, 13 Apr 2005 15:08:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLn2G-0006sF-Bd; Wed, 13 Apr 2005 14:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLn2F-0006sA-5t for rohc@megatron.ietf.org; Wed, 13 Apr 2005 14:56:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22653 for ; Wed, 13 Apr 2005 14:56:13 -0400 (EDT) Received: from mclean-vscan5.bah.com ([156.80.3.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLnBx-0007wD-2m for rohc@ietf.org; Wed, 13 Apr 2005 15:06:25 -0400 Received: from mclean-vscan5.bah.com (mclean-vscan5.bah.com [156.80.3.66]) by mclean-vscan5.bah.com (8.11.0/8.11.0) with SMTP id j3DIu2w18713; Wed, 13 Apr 2005 14:56:02 -0400 (EDT) Received: from mclnexbh02.resource.ds.bah.com ([156.80.7.152]) by mclean-vscan5.bah.com (SAVSMTP 3.1.6.45) with SMTP id M2005041314560219466 ; Wed, 13 Apr 2005 14:56:02 -0400 Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.122]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 14:56:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2005 14:56:01 -0400 Message-ID: <37BDD2FAF2AEAE459C6C70FDC2892E4E3D8DBA@MCLNEXVS05.resource.ds.bah.com> Thread-Topic: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt Thread-Index: AcU1vSAyjMg9U1pxQSyIjuHmXyM1SAIzU3qgAHPTS6A= From: "Ertekin Emre" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 13 Apr 2005 18:56:03.0135 (UTC) FILETIME=[70A9FCF0:01C5405A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org Subject: [rohc] RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Content-Transfer-Encoding: quoted-printable Lars-Erik, Kristofer, and others: Thank you for your comments on the I-D. Please find response to your comments below: ------=20 (1) On use of the RFC 2119 keywords in the I-D: I used the RFC 2119 keywords in the document, as I thought that key-words defined in 2119 are to be used to indicate requirement levels. However, I do understand Lars-Erik's point, regarding how the keywords are intended to provide implementers guidance in terms of what functionality to implement. This is not really the case in the HCoIPsec requirements I-D. Therefore, I will remove all dependencies to RFC 2119 key-words in the I-D.=20 (2) I will split the references into Normative and Informative.=20 (3) I intended the HC over transport mode SAs specification to be optional, and I still would like to keep the draft agnostic to tunnel or transport mode IPsec SAs. I agree that the idea of just compressing the transport layer protocol header significantly reduces the gains of HC algorithms, and that current HC algorithms do not have the capability to just compress the transport-layer header. However, I do not think that there is any reason to preclude this option. This approach may provide more flexibility in the future, in case there is a scenario where compression of only the transport layer header becomes more beneficial. Conceivably, the specifications in response to this I-D could be entitled "ROHC over Tunnel Mode IPsec SAs", and "ECRTP over Tunnel Mode IPsec SAs". In the future, if header compression over transport mode SAs was proposed, the document(s) would be entitled " over Transport Mode IPsec SAs". Perhaps in future revisions of this I-D, we will clearly indicate that transport mode header compression is optional. In addition, we will add text which provides justification as to why this functionality is included in the draft. Does this sound good? (4a) Based on Lars-Erik's/Kristofer's comments for the I-D "requirements", we are proposing to revamp section 5 of the draft. The new outline is as follows: 5.1. Work Goals 5.2. Work Assumptions 5.3. Work Items 5.3.1. HC-Scheme Specific (HC-Scheme Extensions) 5.3.2. Initialization and Negotiation of HC Session 5.3.3. Encapsulation and Identification of Header-Compressed Packets (4b) We intend on folding the ideas presented by the current requirements I-D into the new sections: I: Split requirement (a) into two: i. HCoIPsec must reduce the overhead transmitted between two IPsec devices - this will be binned into section 5.1=20 ii. An HCoIPsec solution should use existing HC schemes - this will be binned into section 5.2 II: Requirement (b) will be binned into section 5.1 (5.2?) III: Requirement (c) will be binned into section 5.3.1. The wording will be relaxed based on Kristofer's comments (i.e., "should minimize"...) [Please see point (5) below] IV. Requirement (d) will be binned into section 5.2. the wording will be relaxed based on Kristofer's comments (i.e., "should minimize"...) [Please see point (5) below] V. Requirement (e) will be deleted. [Please see point (6) below.]=20 VI. Requirement (f) will be binned into sections 5.3.2 and 5.3.3=20 VII. Requirement (g) will be binned into section 5.2; we will clarify this work assumption with some explanatory text VIII. Requirement (h) will be deleted, as whether or not the solution will increase the number of SAs depends on the oIPsec solution proposed. (5) There were questions previously on the wording of the requirements, indicating that they were worded too strongly. These comments were particularly applicable to requirement (c), and requirement (d). I agree with both comments - as we write the draft based on the new outline, I will make sure that the wording is relaxed. (e.g., requirement (c), HCoIPsec should minimize the HC algorithm performance degradation due to increased delays, packet loss, jitter, and reordering events between the compressor and decompressor) (e.g. requirement (d), wording changed: "An SA with header compression enabled should not deliver a larger amount of incorrect packets than the same SA with header compression disabled") (6) On comments regarding requirement (e): The intension of this requirement was to indicate that if a feedback channel from the decompressor to the compressor is not used sparingly, then the overall gains presented by the HCoIPsec session may take a significant hit (even more so than hop-by-hop HC). For example, take the case where ROHC is instantiated over an IPsec tunnel mode SA; any feedback sent from the decompressor to the compressor require tunneling. This additional overhead can reduce the overall benefits of HC. However, after further thought about the requirement, maybe the requirement should be deleted. Whether this requirement is beneficial or not is dependent on where HCoIPsec is used. (e.g., for a scenario where bandwidth is asymmetrical, where the compressor-->decompressor channel is a small pipe, and the decompressor-->compressor channel is a large pipe, this requirement would not necessarily be critical.) =20 ------- Thanks again for your comments. Once we finish incorporating them, should we post the revised draft to the mailer? Best Regards, Emre=20 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com]=20 > Sent: Monday, April 11, 2005 9:59 AM > To: Ertekin Emre > Cc: rohc@ietf.org > Subject: RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt >=20 > Emre and others, >=20 > I agree with Kristofers comments, and he is completely=20 > correct when he says I am not that fond of the use of 2119=20 > keywords in requirements documents, and the reason is very=20 > well exemplified by the point being raised in this case. The=20 > 2119 keywords are defined to indicate to an implementer what=20 > functionality to implement, but it is not at all clear how to=20 > interpret such words in the context of a requirements document. >=20 > Some more comments from me: >=20 > * HC for SA transport mode >=20 > Re-using existing HC schemes sound like a good idea, but there is no > existing scheme that only compress transport layer headers. Further, > one could argue that the transport header overhead is too small to > justify compression of that alone. In any case, I believe=20 > compression > for the transport-SA case is not as easy to justify as for tunnel > mode, and would require much more work. >=20 >=20 > * 5. Goals and requirements >=20 > This is an essential part of the document, but I would prefer to > have a slightly different approach for it. The most important thing > here, in my mind, is to make clear what work is needed to have a > complete solution, considering what we already have. Some of these > would, in my mind, be work assumptions, while the rest of them are > "work items", as we are already into solution space, considering the > initial assumptions. We do not need strong words, we must understand > what work is needed. >=20 > - a. is actually an assumption that the HCoIPsec work is to be based > in existing HC protocols, with modifications/extensions. > - b. is stating the goal of the whole work, to develop a HC solution > for IPsec SA's. Also an initial assumption, or goal. > - c. talks about the HC protocol improvements needed to cope with > increased delays, loss, and reordering between compressor and=20 > decompressor. This is specific work that must be done. > - d. is nothing new. As Kristofer noted, one can never guarantee > this without an infinite checksum, but existing HC schemes already > have this as a goal, ROHC has specifically addressed thus. I see > no reason to repeat that here. > - e. is obvious to me, although it is unclear exactly what one mean > with HC signalling. I do not think this is needed here, but if it > is kept, it must be explained what signalling this is about, more > specifically. Might be a requirement on the solution, but it would > be more useful with a discussion of the content of it. > - f. translates into two work items, which I would call defining: > 1) Negotiation for HC scheme usage/support and HC scheme=20 > parameters > 2) Encapsulation and identification > - g. means to me that a SA would constitute the HC point2point link, > i.e. the channel over which a corresponding=20 > compressor/decompressor > pair is operating, and the CID space would then obviously be local > to each SA. This is more of a work assumption than a requirement, > I think.=20 > - h. is fine as a on the complete solution requirement! >=20 > From this, I see 3 different work items: > # The improvements of existing HC schemes so that they can work over > this channel scenario, i.e. address c) # Define negotiation=20 > mechanisms for HC over SA's # Define=20 > encapsulation/identification of header compressed data over > SA's, i.e. within ESP or AH. >=20 >=20 > * Identification and encapsulation >=20 > Identification can be done either by negotiation (always=20 > on/always off) > and make use of e.g. ROHC "uncompressed", or by having new=20 > prot/nextHdr > identifier(s). Encapsulation would require type identifiers for all > schemes but ROHC (this should be made clear at various=20 > places in the > document), which is why more than one protocol number (otherwise one > useless octet will be added in the ROHC case, as ROHC=20 > handles its own > packet type identification). >=20 >=20 > Apart from this, I think the draft looks good! >=20 >=20 > Rgds, > /L-E >=20 >=20 > > -----Original Message----- > > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > > Sent: den 31 mars 2005 08:45 > > Subject: Re: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt > >=20 > >=20 > > Hi Emre, > >=20 > > Some comments from a quick read-through of the draft. > >=20 > > Section 5: > > d. HCoIPsec MUST NOT allow incorrectly decompressed=20 > packets to be > > forwarded from the decompressor (i.e., decryptor) This=20 > > actually implies that the HC scheme must have an inifintely long=20 > > checksum, and it is not possible to actually fulfill this=20 > requirement.=20 > > One alternative is to weaken the text to say "should try to=20 > > avoid....", but maybe that's too weak. Instead, I would try to put=20 > > this in comparison with "the same tunnel without HC" and=20 > say that it=20 > > "..should not deliver a larger amount of incorrect headers than the=20 > > same tunnel without HC" (using "must" instead of "should"=20 > would mean=20 > > that there also has be a way to quantify this, and I don't=20 > think you=20 > > want to go down that road). > >=20 > > e. HCoIPsec MUST minimize the amount of header=20 > > compression signaling between compressor and=20 > decompressor Do=20 > > you mean feedback/header requests here or do you mean that=20 > one should=20 > > not introduce any further signaling here? Clarify please.=20 > Also "MUST=20 > > minimize", what does that mean? It does not really say how much=20 > > signaling is reasonable. Again, weaken the text and say=20 > something like=20 > > "...should attempt to minimize...". Point > > c) of the same section also has a similar wording that the same=20 > > comment applies to. > >=20 > > Editorial details: > > A minor thing that I'm sure that L-E will point out later=20 > is that some=20 > > people (myself included) are not too fond of the use of=20 > "MUST", "MAY"=20 > > etc in requirements drafts (I'd prefer just using "must" etc). But=20 > > since a lot of people use the > > RFC2119 keywords in req-drafts, it is not an error, so you=20 > can keep it=20 > > that way if you want to. And now I noticed that if you use=20 > them, you=20 > > need to have a reference to 2119 :) Also, isn't it mandatory these=20 > > days to split the references into normative and informative=20 > > references? > >=20 > >=20 > > Other than those comments, the draft seems well-written and=20 > probably=20 > > sufficient for its purpose. > >=20 > > BR, > > Kristofer Sandlund, Effnet AB >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 14 04:04:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13059 for ; Thu, 14 Apr 2005 04:04:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLzUb-0004Ni-HL for rohc-web-archive@ietf.org; Thu, 14 Apr 2005 04:14:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLzF5-0007DA-4V; Thu, 14 Apr 2005 03:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLzEz-0007C0-8M for rohc@megatron.ietf.org; Thu, 14 Apr 2005 03:58:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12594 for ; Thu, 14 Apr 2005 03:58:11 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLzOn-0004Cj-KD for rohc@ietf.org; Thu, 14 Apr 2005 04:08:30 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3E7vtQc020367; Thu, 14 Apr 2005 08:57:55 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <26RQ8JZ8>; Thu, 14 Apr 2005 08:58:14 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5ECD@rsys004a> From: "Surtees, Abigail" To: "'Lajos Zaccomer (IJ/ETH)'" Subject: RE: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. Date: Thu, 14 Apr 2005 08:58:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C540C7.698F2CAC" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C540C7.698F2CAC Content-Type: text/plain Hi Zacco, Once again, apologies for the delay in responding to this. I am somewhat confused by some of the statements in the discussion below and the level of indentation isn't helping. Consequently, I'm going to state my understanding and you can tell me where you disagree or I am wrong. I hope that's ok. I've used text here and put some ASCII diagrams in the attached file (they get messed up if they're in the body of the email). Let's start with basic SigComp operation (to ensure we're all clear on the terminology and interpretation of pictures - using a 2 byte partial hash to identify state): Scenario 1: Endpoint A sends a message to endpoint B requesting two pieces of state to be created and feedback to be returned: Bytecode with hash bcbc Buffer state with hash bff1 The state handler at B has no idea what the pieces of state are - they are just chunks of bytes. Endpoint B includes the feedback in its return message, thus endpoint A can refer to both pieces of state in its next message. Scenario 2: Endpoint A knows about a dictionary (with hash d1c7). It sends a message to endpoint B requesting state creation and feedback as in scenario 1, but also advertising d1c7. If endpoint B doesn't know anything about d1c7, then the advertisement will be ignored and the return message will not refer to it. If endpoint B does know about d1c7 and has the capacity to use it, then the return message will refer to it. Scenario 3: Endpoint A knows about dictionary (with hash d1c7) and wants to be able to use it for compression itself, so it uploads it to endpoint B as another piece of state. Scenario 4: Endpoint A knows about dictionary (with hash d1c7) and wants to be able to refer to it at endpoint B AND it thinks B may be a sophisticated implementation. Therefore endpoint A not only uploads the dictionary (as in scenario 3) but also advertises its presence at endpoint A, allowing B to refer to it. N.B. By advertising it, endpoint A is saying that the dictionary will be available for the duration of the compartment (this may be in memory external to the compressor SMS, or it may be created within the compartment e.g. at sufficiently high priority in the compressor A SMS that it will not be pushed out by other state - compressor A has full control of both alternatives). The simplest implementation of B on receipt of the advert for d1c7 would decide it knows nothing about d1c7 as is the case with any other state advert about which it knows nothing. A more sophisticated implementation may notice that the state being advertised has also been created in the decompressor SMS. Therefore, because it has the bytes of the state, the compressor at B *could* make use of the state. However, the compressor at endpoint B does not know what sort of state it is - it's just a bunch of bytes. Some heuristic (e.g. comparison with the next message to be compressed) could be used to decide whether or not the piece of state is useful as a reference to improve the compression ratio of the next message. Endpoint B can refer to d1c7 as long as it knows what it is (i.e. it might get pushed out of the decompressor SMS at B, at which point, B no longer has it). As mentioned above, once the state has been advertised by endpoint A, endpoint A must keep it for the duration of the compartment. So far, all of the above is standard rfc 3320 behaviour. When compressor A advertises the dictionary, where it stores the bytes of dictionary (inside or outside SMS) is implementation specific, though in scenarios 3 and 4 it must be accounted for in the SMS monitoring because it is mirroring the SMS at endpoint B. At endpoint B there is no requirement to do anything other than store state according to rfc 3320. I think that placing 'usd1' as the first 4 bytes of a dictionary is then a simple heuristic optimisation. If endpoint A puts 'usd1' at the beginning of the state then endpoint B has a simple way of recognising that the state will be useful as a reference. If, however, A doesn't do that, then B (if it wants to) can use some other heuristic, as it would without the optimisation. Equally, if endpoint A does put 'usd1' in the state and endpoint B doesn't look for it, both endpoints continue as if it were not there. The key point is that, whatever happens, the actual state creation and handling at both endpoints is the same, regardless of whether or not the state contains the bytes 'usd1'. Is my interpretation correct? If not, please explain my misunderstanding. Whether or not my understanding is correct, the text describing this mechanism needs clarification in the PoC specification. (I realise this is not the place for that discussion - I'm just trying to make sure I understand correctly). Best regards, Abbie > > > > Sorry for the delay. I've got some questions about the PoC > > related use of > > usds. > > > > > > > > > 3. USD. I fully understand the usage of a USD. However, I do > > > > not understand > > > > if a USD-state should be treated any differenty then any > > > > other state created > > > > at the remote end. Is a USD per definition a shared state? > > > > > > No, it isn't. RFC 3321 says it's a regular state. POC USD is > > > something different. I would say it's a regular and a shared > > > state at the same time. > > > > What does that actually mean? As you say 3321 says it's a > > regular state, so > > in SigComp terms how can it be a shared state as well? > > [zacco] In PoC, the terminal uploads the USD after saving it > in the state memory. The special advertisement lets the > server know it received a USD that it also saves in the state > memory (or outside the state memory, which must be signalled > backwards). Thus, both endpoints will have the USD and can > use it for compression. That is why I say PoC USD is a > dynamic (or regular) and shared state at the same time. > > > > > > > > > > I'm guessing that > > > > it must be if the sending compressor is to have any > > > advantage of the > > > > USD-state at the remote end. Then, again, should the > > > > USD-state (local state) > > > > at A be considered to occupy State-memory? Should it be > > > > considered any > > > > differently then any other shared state? > > > > > > It depends on which USD you are talking about. A regular > > > state is not saved in a state memory at the compressor side, > > > so if you go for the RFC 3321 USD, it decreases the available > > > memory at B in the state memory of compresssor at A. In case > > > POC USD is used, it must be saved as a local state, otherwise > > > the compressor at B would not be able to access it. > > > > However, we believe that the POC definition of using USD as > > shared state is > > not well defined and can lead to loss of synchronisation > > between the two > > endpoints. > > > > When you say it must be saved as 'local state', do you mean > > in the state > > memory of the compressor at B or not in a compartment at all? > > Not in a compartment at all (in A). However, in B it is up to > the endpoint if it saves in the state memory or not in the > compartment. > > > > > > > > 5. (Little bit off-topic, PoC specific question): In the PoC > > > > NEMS Signalling > > > > Spec. "Signalling flows (UNI) v2.06", a procedure for > > > > establishing a USD is > > > > described. Among others it states that the four first > > bytes of the > > > > state-value should be "usd1". Can any helpful individual > > > > explain to me what > > > > the purpose might be? Should either local or remote > > > endpoint take any > > > > specific action here? > > > > The spec says: > > > > "For USD identification it is important that the identifier > > > > string is placed > > > > in the beginning of the state_value of the USD, therefore > > > > special attention > > > > must be paid in the case of large USD as the UDVM has a > > > > circular buffer." > > > > I do not understand the purpose here.. > > > > > > Suppose Endpoint 2 supports USD (without the optional > > > requirement of moving it to the local state location) and the > > > explicit acknowledgement specified in RFC 3321, too. If > > > Endpoint 2 explicitlly acks the uploaded USD state ID, > > > Endpoint 1 will think USD is moved to the local states > > > location (indication is the same as if it was an explicit > > > ack) and will not update (decrease) its remote available SMS. > > > Later on it may result in decompression failure if a state is > > > saved deleting another one in use, due to the remote > > > available SMS out of synchron. > > > > > > > I'm a bit confused here: > > > > By 'moving it to the local state location' I take it that you > > mean that the > > state created at Endpoint 2's decompressor would be moved to > > Endpoint 2's > > compressor. Is this correct? Would it be duplicated (i.e. > > still exist in > > the decompressor) or actually moved (and therefore the > > compressor at A has > > no control over or knowledge of when it is deleted)? > > > It is not duplicated. I meant it was moved to the > "non-compartment" state memory. It must be remembered somehow > (implementation stuff) that the state actually belongs to a > specific compartment, so when the compartment is deleted, the > USD must also be deleted. > > > Are you saying that the presence of the string "usd1" is an > > indicator to > > endpoint 2 that it should move/copy the state into the compressor > > compartment? > > Besides the state is saved and advertised at the same time. > The reason why the usd tag was added is that this situation > might easily happen with a well-known bytecode. > > > > > If so, this seems to be at odds with the SigComp conceptual > > model of state > > that it is just 'some bytes'. > > > > Why do you say that? 'usd1' is not something that appears at > the beginning of a state, especially in a first message, and > especially not in a bytecode. > > > If my understanding above is correct, then the piece of state > > presumably has > > minimum retention priority? Care must once again be taken > due to the > > possibility that the creation of multiple pieces of minimum > retention > > priority state can lead to loss of synchronisation between > endpoints. > > > > USD is just one state, which is absolutely in line with the > "one shared state at a time" concept. > > > How does this mechanism interact with the use of shared mode > > as defined in > > 3321? > > > > Nothing special, as the shared state is not saved as a state > in B, only in A. > > > I also think there are some implications for > interoperability between > > endpoints that do this and endpoints that don't. As you > > showed in your > > example above, if there is disagreement between endpoints > > about whether or > > not state is moved to 'local state location' (whatever that > > is) it can lead > > to loss of synchronisation between endpoints. > > > > Is this concept mandatory in PoC? If not, or if a non PoC > > endpoint receives > > a state create request and an explicit advertisement, it will > > not know that > > it should check the first 4 bytes for "usd1" and move the state so > > synchronisation will be lost as you explained. > > As far as I know it is mandatory, but this I should check. > > > > > Best regards, > > > > Abbie > > > > -- > > > > Visit our website at www.roke.co.uk > > > > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. > > > > The information contained in this e-mail and any attachments > > is proprietary to > > Roke Manor Research Ltd and must not be passed to any third > > party without > > permission. This communication is for information only and > > shall not create or > > change any contractual relationship. > > > > > ------_=_NextPart_000_01C540C7.698F2CAC Content-Type: text/plain; name="sigcomp_pictures.txt" Content-Disposition: attachment; filename="sigcomp_pictures.txt" Scenario 1: Compressor A: compress message create bytecode and buffer state state handler contains: [bcbc, bff1, 800 bytes free] ----------Msg 1, inc bytecode, request: create bcbc, create bff1, feedback----------> Decompressor B: decompress message create 2 pieces of state state handler contains: [bcbc, bff1, 800 bytes free] <---------------Msg 2, inc bytecode of B and returned feedback----------------------- Compressor A can now refer to either or both of bcbc and bff1. -----------------------Msg 3, ref bcbc, bff1 ---------------------------------------> Scenario 2: Compressor A: compress message create bytecode and buffer state state handler contains: [bcbc, bff1, 800 bytes free] --Msg 1, inc bytecode, advertise d1c7, request: create bcbc, create bff1, feedback--> If endpoint B doesn't know anything about d1c7, then the advertisement will be ignored giving: <---------------Msg 2, inc bytecode of B and returned feedback----------------------- If endpoint B does know about d1c7 and has the capacity to use it, then the return message can refer to it giving: <---------------Msg 2, inc bytecode of B, ref d1c7 and returned feedback------------- Scenario 3: Compressor A: compress message create bytecode, dictionary and buffer state state handler contains: [bcbc, bff1, d1c7, 300 bytes free] N.B. if the dictionary is not specific to the compartment, the actual bytes of the dictionary may or may not be stored outside of the compressor sms according to the implementation. ---Msg 1, inc bytecode, dictionary, request: create bcbc, create bff1, create d1c7, feedback-------------------------------------------------------> Decompressor B: decompress message create 3 pieces of state state handler contains: [bcbc, bff1, d1c7, 300 bytes free] <-----------------Msg 2, inc bytecode and returned feedback-------------------------- Scenario 4: Compressor A: compress message create bytecode, dictionary and buffer state state handler contains: [bcbc, bff1, d1c7, 300 bytes free] N.B. if the dictionary is not specific to the compartment, the actual bytes of the dictionary may or may not be stored outside of the compressor sms according to the implementation. ---Msg 1, inc bytecode, dictionary, advertise d1c7, request: create bcbc, create bff1, create d1c7, feedback------------------------------------------> Decompressor B: decompress message create 3 pieces of state state handler contains: [bcbc, bff1, d1c7, 300 bytes free] If endpoint B is not particularly sophisticated, it will ignore the advert for d1c7 because it knows nothing about that piece of state giving: <-----------------Msg 2, inc bytecode and returned feedback-------------------------- If endpoint B is more sophisticated, it may notice d1c7 has just been created and use heuristics to work out that it is worth referencing to improve the return compression ratio giving: <---------------Msg 2, inc bytecode of B, ref d1c7 and returned feedback------------- In all cases this is standard 3320 state handling. ------_=_NextPart_000_01C540C7.698F2CAC Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------_=_NextPart_000_01C540C7.698F2CAC-- From rohc-bounces@ietf.org Thu Apr 14 06:05:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20696 for ; Thu, 14 Apr 2005 06:05:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM1Nz-0007Kg-JW for rohc-web-archive@ietf.org; Thu, 14 Apr 2005 06:15:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM19a-0005EK-Ld; Thu, 14 Apr 2005 06:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM19T-0005Ci-7u for rohc@megatron.ietf.org; Thu, 14 Apr 2005 06:00:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20432 for ; Thu, 14 Apr 2005 06:00:36 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM1JG-0007CS-Qu for rohc@ietf.org; Thu, 14 Apr 2005 06:10:57 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3E9xuOW026342; Thu, 14 Apr 2005 11:59:59 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 11:59:54 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 11:59:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 11:59:54 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27D4@esealmw109.eemea.ericsson.se> Thread-Topic: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt Thread-Index: AcU1vSAyjMg9U1pxQSyIjuHmXyM1SAIzU3qgAHPTS6AAGmSIAA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ertekin Emre" , "Kristofer Sandlund" X-OriginalArrivalTime: 14 Apr 2005 09:59:54.0524 (UTC) FILETIME=[B5173DC0:01C540D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org Subject: [rohc] RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable > (1) On use of the RFC 2119 keywords in the I-D: >=20 > Therefore, I will remove all dependencies to RFC 2119 key-words > in the I-D.=20 EXCELLENT! > (2) I will split the references into Normative and Informative.=20 GOOD! > (3) I intended the HC over transport mode SAs specification to > be optional, and I still would like to keep the draft agnostic > to tunnel or transport mode IPsec SAs. I agree that the idea > of just compressing the transport layer protocol header > significantly reduces the gains of HC algorithms, and that > current HC algorithms do not have the capability to just > compress the transport-layer header. However, I do not think > that there is any reason to preclude this option.=20 What I believe is important to do in this document is to explain the fundamental differences between the two, and be clear that transport mode compression would require new HC algorithms. Also, as you say, be very specific about tunnel mode being the primary target. > Perhaps in future revisions of this I-D, we will clearly > indicate that transport mode header compression is optional. > In addition, we will add text which provides justification as > to why this functionality is included in the draft. Does this > sound good? Yes, make clear it is not the primary target, explain where it could potentially be useful (and what gain could be expected), but also why it is not on top of the priority list. > (4a) Based on Lars-Erik's/Kristofer's comments for the I-D > "requirements", we are proposing to revamp section 5 of the=20 > draft. The new outline is as follows: >=20 > 5.1. Work Goals > 5.2. Work Assumptions > 5.3. Work Items > 5.3.1. HC-Scheme Specific (HC-Scheme Extensions) > 5.3.2. Initialization and Negotiation of HC Session > 5.3.3. Encapsulation and Identification of=20 > Header-Compressed Packets >=20 > (4b) We intend on folding the ideas presented by the current > requirements I-D into the new sections: > I: Split requirement (a) into two: > i. HCoIPsec must reduce the overhead transmitted between two > IPsec devices - this will be binned into section 5.1 I would say that the goal is to "make HC applicable to IPsec SAs", we know that compression is used to reduce overhead. To me it is pointless to formulate it with a must wording. > ii. An HCoIPsec solution should use existing HC schemes - > this will be binned into section 5.2 OK! > II: Requirement (b) will be binned into section 5.1 (5.2?) I would say this is 5.2, as nothing else can be done in an encrypted tunnel. The point is not to compress the outer header, although that can also be done on a per-hop basis, but to compress the inner ones, and that obviously means we are compressing end-2-end over the tunnel. > III: Requirement (c) will be binned into section 5.3.1. The > wording will be relaxed based on Kristofer's comments (i.e., "should > minimize"...) [Please see point (5) below] FINE! > IV. Requirement (d) will be binned into section 5.2. the > wording will be relaxed based on Kristofer's comments (i.e., "should > minimize"...) [Please see point (5) below] I do not think this is actually needed, but could of course be listed in 5.2, as an assumption based on common HC practice. > V. Requirement (e) will be deleted. [Please see point (6) > below.]=20 GOOD! > VI. Requirement (f) will be binned into sections 5.3.2 and > 5.3.3=20 EXCELLENT! > VII. Requirement (g) will be binned into section 5.2; we will > clarify this work assumption with some explanatory text EXCELLENT! > VIII. Requirement (h) will be deleted, as whether or not the > solution will increase the number of SAs depends on the ROHC>oIPsec solution proposed. Actually I think it should be kept, just elaborate a little bit and refer to existing HC schemes. > (6) On comments regarding requirement (e): >=20 > The intension of this requirement was to indicate that if a feedback > channel from the decompressor to the compressor is not used sparingly, > then the overall gains presented by the HCoIPsec session may take a > significant hit (even more so than hop-by-hop HC). For example, take > the case where ROHC is instantiated over an IPsec tunnel mode SA; any > feedback sent from the decompressor to the compressor require=20 > tunneling. > This additional overhead can reduce the overall benefits of HC. Oh, then you could write that more specifically, I did not understand what you meant with "signaling". Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 14 21:01:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17411 for ; Thu, 14 Apr 2005 21:01:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMFNJ-0004N7-Ac for rohc-web-archive@ietf.org; Thu, 14 Apr 2005 21:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFBH-0004Av-75; Thu, 14 Apr 2005 20:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFBD-00047R-5C; Thu, 14 Apr 2005 20:59:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17235; Thu, 14 Apr 2005 20:59:29 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMFLI-0004KW-9C; Thu, 14 Apr 2005 21:09:57 -0400 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LN4CNC0C5U93FRVG@vaxc.its.monash.edu.au>; Fri, 15 Apr 2005 10:59:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7CC0480002; Fri, 15 Apr 2005 10:59:15 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 544D13C008; Fri, 15 Apr 2005 10:59:15 +1000 (EST) Date: Fri, 15 Apr 2005 10:59:09 +1000 From: Greg Daley In-reply-to: <425EBC50.2070005@iprg.nokia.com> To: Vijay Devarapalli Message-id: <425F11DD.6090901@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> <425EBC50.2070005@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7BIT Cc: nemo@ietf.org, rohc@ietf.org, anacarolina.minaburo@enst-bretagne.fr Subject: [rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7BIT Hi Vijay, I think there may be some value in this, if more than just the next IPv6 header can be compressed. If it doesn't mitigate the NEMO MTU issue, people may not care for it. Regarding the draft itself: Section 2 has all of the details about ROHC compression. For the 7 paragraphs after paragraph 2, there is not a single explicit reference to the ROHC documents for NEMO people to investigate. This section, while brimming with details, seems to leave me feeling I don't have enough ROHC context myself. It would be good to have diagrams illustrating which headers will be subject to compression, and some considerations about the NEMOs themselves (apart from the 10 lines in the first, second and last paragraph of the section). After all, it is called: "The use of ROHC in NEMO" Apart from that, it seems like a good idea in general, not just for NEMO. It seems like a MIPv6 HA/MAP/FMIPv6AR issue too, although the addresses in the upper layer tunnel have more constrained destinations in the non-router case. I didn't see any text about packet reordering in the document. I'd guess that the Internet is about the most likely point-to-point medium to re-order packets. Vijay Devarapalli wrote: > In general, I like the the idea of using ROHC in the tunnel between > the mobile router and the home agent, to reduce the tunnel overhead. > I would like to see this draft standardized. > > one quick comment. > >> As the addresses are classified as static, each time the MR changes >> its attachment point the ROHC context will be initialized. > > > wonder why? the MR could just send a binding update to the HA from > the new CoA. binding updates are sent reliably. when the HA processes > the binding update, its updates the ROHC context with the new CoA. > once the MR receives a binding acknowledgement which shows success > status, it also updates the local ROHC context with the new CoA. Actually, I'm not sure that the draft text itself was accurate. If addresses INSIDE the tunnel changed, then there would have to be changes to the binding or to the context. Why would there need to be changes to the context if the transporting tunnel endpoint addresses - the outer addresses (which aren't subject to compression) change? The data transferred on the tunnel doesn't change because of the CoA change. I'd like to see this document develop maybe as informational if no NEMO-specific protocol issues arise. Greg _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 01:59:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05468 for ; Fri, 15 Apr 2005 01:59:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMK25-0006IH-9i for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 02:10:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMJhy-0002n7-8p; Fri, 15 Apr 2005 01:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMJht-0002mk-5r for rohc@megatron.ietf.org; Fri, 15 Apr 2005 01:49:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04923 for ; Fri, 15 Apr 2005 01:49:24 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMJrt-0005uD-25 for rohc@ietf.org; Fri, 15 Apr 2005 01:59:53 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3F5nHfm023528; Fri, 15 Apr 2005 07:49:20 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 07:49:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. Date: Fri, 15 Apr 2005 07:49:09 +0200 Message-ID: Thread-Topic: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. Thread-Index: AcVAx60CEoLn6Fv0SxKIj11j6sEmuwAsZ5Jg From: "Lajos Zaccomer \(IJ/ETH\)" To: "Surtees, Abigail" X-OriginalArrivalTime: 15 Apr 2005 05:49:06.0425 (UTC) FILETIME=[D6234E90:01C5417E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Content-Transfer-Encoding: quoted-printable HI Abbie, No problem. See my comments inline ... Best regards, Zacco > -----Original Message----- > From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] > Sent: Thursday, April 14, 2005 9:58 AM > To: Lajos Zaccomer (IJ/ETH) > Cc: rohc@ietf.org > Subject: RE: [rohc] [SigComp]Shared mode and some other=20 > SigComp-state rela ted stuff. >=20 >=20 > Hi Zacco, >=20 > Once again, apologies for the delay in responding to this. >=20 > I am somewhat confused by some of the statements in the=20 > discussion below and the level of indentation isn't helping. =20 > Consequently, I'm going to state my understanding and you can=20 > tell me where you disagree or I am wrong. I hope that's ok. =20 > I've used text here and put some ASCII diagrams in the=20 > attached file (they get messed up if they're in the body of=20 > the email). >=20 > Let's start with basic SigComp operation (to ensure we're all=20 > clear on the terminology and interpretation of pictures -=20 > using a 2 byte partial hash to identify state): >=20 > Scenario 1: > Endpoint A sends a message to endpoint B requesting two=20 > pieces of state to be created and feedback to be returned: >=20 > Bytecode with hash bcbc > Buffer state with hash bff1 >=20 > The state handler at B has no idea what the pieces of state=20 > are - they are just chunks of bytes. Endpoint B includes the=20 > feedback in its return message, thus endpoint A can refer to=20 > both pieces of state in its next message. >=20 > Scenario 2: >=20 > Endpoint A knows about a dictionary (with hash d1c7). It=20 > sends a message to endpoint B requesting state creation and=20 > feedback as in scenario 1, but also advertising d1c7. >=20 > If endpoint B doesn't know anything about d1c7, then the=20 > advertisement will be ignored and the return message will not=20 > refer to it. >=20 > If endpoint B does know about d1c7 and has the capacity to=20 > use it, then the return message will refer to it. >=20 > Scenario 3: > Endpoint A knows about dictionary (with hash d1c7) and wants=20 > to be able to use it for compression itself, so it uploads it=20 > to endpoint B as another piece of state. >=20 > Scenario 4: > Endpoint A knows about dictionary (with hash d1c7) and wants=20 > to be able to refer to it at endpoint B AND it thinks B may=20 > be a sophisticated implementation. Therefore endpoint A not=20 > only uploads the dictionary (as in scenario 3) but also=20 > advertises its presence at endpoint A, allowing B to refer to=20 > it. N.B. By advertising it, endpoint A is saying that the=20 > dictionary will be available for the duration of the=20 > compartment (this may be in memory external to the compressor=20 > SMS, or it may be created within the compartment e.g. at=20 > sufficiently high priority in the compressor A SMS that it=20 > will not be pushed out by other state - compressor A has full=20 > control of both alternatives). [zacco] In PoC, state d1c7 is called a USD and is stored in memory = external to the compressor. OMA-POC-2004-0655-CP-SigComp 5.X.1.2 says: "The USD is a locally available state, [RFC3320], at the PoC Client and = to improve the compression efficiency in the uplink the PoC Client MAY = upload the USD to its SIP/IP Core compartment. To increase the = compression efficiency in the downlink, the PoC client MAY advertise the = locally available state to the SIP/IP core.=20 The first four bytes of the USD state value SHALL be the specific = identifier string; "usd1" in order to distinguish the USD state from the = possible bytecode uploaded for the Universal Decompressor Virtual = Machine (UDVM)." >=20 > The simplest implementation of B on receipt of the advert for=20 > d1c7 would decide it knows nothing about d1c7 as is the case=20 > with any other state advert about which it knows nothing. >=20 > A more sophisticated implementation may notice that the state=20 > being advertised has also been created in the decompressor=20 > SMS. Therefore, because it has the bytes of the state, the=20 > compressor at B *could* make use of the state. However, the=20 > compressor at endpoint B does not know what sort of state it=20 > is - it's just a bunch of bytes. Some heuristic (e.g.=20 > comparison with the next message to be compressed) could be=20 > used to decide whether or not the piece of state is useful as=20 > a reference to improve the compression ratio of the next message. =20 >=20 > Endpoint B can refer to d1c7 as long as it knows what it is=20 > (i.e. it might get pushed out of the decompressor SMS at B,=20 > at which point, B no longer has it). As mentioned above,=20 > once the state has been advertised by endpoint A, endpoint A=20 > must keep it for the duration of the compartment. Not quite if d1c7 is moved to external memory in B, which is optional = and up to B. If so, it must be indicated with explicit acking this = state. (The only problem with this solution that it fails, if you = advertise e.g. your bytecode at the same time, and B explicitly acks the = bytecode instead of d1c7. In this case, A thinks d1c7 is in external = memory, and will most probably overwrite d1c7 sooner or later. >=20 > So far, all of the above is standard rfc 3320 behaviour. =20 Yes. My example is PoC. If we talk about 3320-22 only, I have nothing to = add or modify. > When compressor A advertises the dictionary, where it stores=20 > the bytes of dictionary (inside or outside SMS) is=20 > implementation specific, though in scenarios 3 and 4 it must=20 > be accounted for in the SMS monitoring because it is=20 > mirroring the SMS at endpoint B. At endpoint B there is no=20 > requirement to do anything other than store state according=20 > to rfc 3320. Unless you want to implement some PoC standard features, as well. >=20 > I think that placing 'usd1' as the first 4 bytes of a=20 > dictionary is then a simple heuristic optimisation. If=20 > endpoint A puts 'usd1' at the beginning of the state then=20 > endpoint B has a simple way of recognising that the state=20 > will be useful as a reference. If, however, A doesn't do=20 > that, then B (if it wants to) can use some other heuristic,=20 > as it would without the optimisation. Equally, if endpoint A=20 > does put 'usd1' in the state and endpoint B doesn't look for=20 > it, both endpoints continue as if it were not there. Right. >=20 > The key point is that, whatever happens, the actual state=20 > creation and handling at both endpoints is the same,=20 > regardless of whether or not the state contains the bytes 'usd1'. =20 >=20 > Is my interpretation correct? If not, please explain my=20 > misunderstanding. Whether or not my understanding is=20 > correct, the text describing this mechanism needs=20 > clarification in the PoC specification. (I realise this is=20 > not the place for that discussion - I'm just trying to make=20 > sure I understand correctly). >=20 > Best regards, >=20 > Abbie >=20 > > >=20 > > > Sorry for the delay. I've got some questions about the PoC=20 > > > related use of > > > usds. > > >=20 > > > >=20 > > > > > 3. USD. I fully understand the usage of a USD. However, I do=20 > > > > > not understand=20 > > > > > if a USD-state should be treated any differenty then any=20 > > > > > other state created=20 > > > > > at the remote end. Is a USD per definition a shared state?=20 > > > >=20 > > > > No, it isn't. RFC 3321 says it's a regular state. POC USD is=20 > > > > something different. I would say it's a regular and a shared=20 > > > > state at the same time. > > >=20 > > > What does that actually mean? As you say 3321 says it's a=20 > > > regular state, so > > > in SigComp terms how can it be a shared state as well? > >=20 > > [zacco] In PoC, the terminal uploads the USD after saving it=20 > > in the state memory. The special advertisement lets the=20 > > server know it received a USD that it also saves in the state=20 > > memory (or outside the state memory, which must be signalled=20 > > backwards). Thus, both endpoints will have the USD and can=20 > > use it for compression. That is why I say PoC USD is a=20 > > dynamic (or regular) and shared state at the same time. > >=20 > > >=20 > > > >=20 > > > > > I'm guessing that=20 > > > > > it must be if the sending compressor is to have any=20 > > > > advantage of the=20 > > > > > USD-state at the remote end. Then, again, should the=20 > > > > > USD-state (local state)=20 > > > > > at A be considered to occupy State-memory? Should it be=20 > > > > > considered any=20 > > > > > differently then any other shared state? > > > >=20 > > > > It depends on which USD you are talking about. A regular=20 > > > > state is not saved in a state memory at the compressor side,=20 > > > > so if you go for the RFC 3321 USD, it decreases the available=20 > > > > memory at B in the state memory of compresssor at A. In case=20 > > > > POC USD is used, it must be saved as a local state, otherwise=20 > > > > the compressor at B would not be able to access it. > > >=20 > > > However, we believe that the POC definition of using USD as=20 > > > shared state is > > > not well defined and can lead to loss of synchronisation=20 > > > between the two > > > endpoints. > > >=20 > > > When you say it must be saved as 'local state', do you mean=20 > > > in the state > > > memory of the compressor at B or not in a compartment at all? > >=20 > > Not in a compartment at all (in A). However, in B it is up to=20 > > the endpoint if it saves in the state memory or not in the=20 > > compartment. > >=20 > > > >=20 > > > > > 5. (Little bit off-topic, PoC specific question): In the PoC=20 > > > > > NEMS Signalling=20 > > > > > Spec. "Signalling flows (UNI) v2.06", a procedure for=20 > > > > > establishing a USD is=20 > > > > > described. Among others it states that the four first=20 > > > bytes of the=20 > > > > > state-value should be "usd1". Can any helpful individual=20 > > > > > explain to me what=20 > > > > > the purpose might be? Should either local or remote=20 > > > > endpoint take any=20 > > > > > specific action here? > > > > > The spec says: > > > > > "For USD identification it is important that the identifier=20 > > > > > string is placed=20 > > > > > in the beginning of the state_value of the USD, therefore=20 > > > > > special attention=20 > > > > > must be paid in the case of large USD as the UDVM has a=20 > > > > > circular buffer." > > > > > I do not understand the purpose here.. > > > >=20 > > > > Suppose Endpoint 2 supports USD (without the optional=20 > > > > requirement of moving it to the local state location) and the=20 > > > > explicit acknowledgement specified in RFC 3321, too. If=20 > > > > Endpoint 2 explicitlly acks the uploaded USD state ID,=20 > > > > Endpoint 1 will think USD is moved to the local states=20 > > > > location (indication is the same as if it was an explicit=20 > > > > ack) and will not update (decrease) its remote available SMS.=20 > > > > Later on it may result in decompression failure if a state is=20 > > > > saved deleting another one in use, due to the remote=20 > > > > available SMS out of synchron. > > > >=20 > > >=20 > > > I'm a bit confused here: > > >=20 > > > By 'moving it to the local state location' I take it that you=20 > > > mean that the > > > state created at Endpoint 2's decompressor would be moved to=20 > > > Endpoint 2's > > > compressor. Is this correct? Would it be duplicated (i.e.=20 > > > still exist in > > > the decompressor) or actually moved (and therefore the=20 > > > compressor at A has > > > no control over or knowledge of when it is deleted)? > > >=20 > > It is not duplicated. I meant it was moved to the=20 > > "non-compartment" state memory. It must be remembered somehow=20 > > (implementation stuff) that the state actually belongs to a=20 > > specific compartment, so when the compartment is deleted, the=20 > > USD must also be deleted. > >=20 > > > Are you saying that the presence of the string "usd1" is an=20 > > > indicator to > > > endpoint 2 that it should move/copy the state into the compressor > > > compartment? > >=20 > > Besides the state is saved and advertised at the same time.=20 > > The reason why the usd tag was added is that this situation=20 > > might easily happen with a well-known bytecode. > >=20 > > >=20 > > > If so, this seems to be at odds with the SigComp conceptual=20 > > > model of state > > > that it is just 'some bytes'. =20 > > >=20 > >=20 > > Why do you say that? 'usd1' is not something that appears at=20 > > the beginning of a state, especially in a first message, and=20 > > especially not in a bytecode. > >=20 > > > If my understanding above is correct, then the piece of state=20 > > > presumably has > > > minimum retention priority? Care must once again be taken=20 > > due to the > > > possibility that the creation of multiple pieces of minimum=20 > > retention > > > priority state can lead to loss of synchronisation between=20 > > endpoints. > > >=20 > >=20 > > USD is just one state, which is absolutely in line with the=20 > > "one shared state at a time" concept. > >=20 > > > How does this mechanism interact with the use of shared mode=20 > > > as defined in > > > 3321? > > >=20 > >=20 > > Nothing special, as the shared state is not saved as a state=20 > > in B, only in A.=20 > >=20 > > > I also think there are some implications for=20 > > interoperability between > > > endpoints that do this and endpoints that don't. As you=20 > > > showed in your > > > example above, if there is disagreement between endpoints=20 > > > about whether or > > > not state is moved to 'local state location' (whatever that=20 > > > is) it can lead > > > to loss of synchronisation between endpoints. > > >=20 > > > Is this concept mandatory in PoC? If not, or if a non PoC=20 > > > endpoint receives > > > a state create request and an explicit advertisement, it will=20 > > > not know that > > > it should check the first 4 bytes for "usd1" and move the state so > > > synchronisation will be lost as you explained. > >=20 > > As far as I know it is mandatory, but this I should check. > >=20 > > >=20 > > > Best regards, > > >=20 > > > Abbie > > >=20 > > > --=20 > > >=20 > > > Visit our website at www.roke.co.uk > > >=20 > > > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire=20 > SO51 0ZN, UK. > > >=20 > > > The information contained in this e-mail and any attachments=20 > > > is proprietary to > > > Roke Manor Research Ltd and must not be passed to any third=20 > > > party without > > > permission. This communication is for information only and=20 > > > shall not create or > > > change any contractual relationship. > > >=20 > > >=20 > >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 02:05:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10584 for ; Fri, 15 Apr 2005 02:05:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMK71-0006Va-Nr for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 02:15:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMJkM-0002x5-TA; Fri, 15 Apr 2005 01:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9U9-0007DH-R0; Thu, 14 Apr 2005 14:54:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11911; Thu, 14 Apr 2005 14:54:32 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9e4-0004YU-GP; Thu, 14 Apr 2005 15:04:57 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3EIOUL32416; Thu, 14 Apr 2005 11:24:30 -0700 X-mProtect: <200504141824> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpd8hWsdO; Thu, 14 Apr 2005 11:24:29 PDT Message-ID: <425EBC50.2070005@iprg.nokia.com> Date: Thu, 14 Apr 2005 11:54:08 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 X-Accept-Language: en-us, en MIME-Version: 1.0 To: anacarolina.minaburo@enst-bretagne.fr References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> In-Reply-To: <29ed16a4050406063152628e54@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Apr 2005 01:52:04 -0400 Cc: nemo@ietf.org, rohc@ietf.org Subject: [rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit In general, I like the the idea of using ROHC in the tunnel between the mobile router and the home agent, to reduce the tunnel overhead. I would like to see this draft standardized. one quick comment. > As the addresses are classified as static, each time the MR changes > its attachment point the ROHC context will be initialized. wonder why? the MR could just send a binding update to the HA from the new CoA. binding updates are sent reliably. when the HA processes the binding update, its updates the ROHC context with the new CoA. once the MR receives a binding acknowledgement which shows success status, it also updates the local ROHC context with the new CoA. Vijay Ana Minaburo wrote: > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, March 16, 2005 12:09 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-minaburo-rohc-nemo-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ROHC (Robust Header Compression) in NEMO network > Author(s) : A. Minaburo, et al. > Filename : draft-minaburo-rohc-nemo-00.txt > Pages : 0 > Date : 2005-3-9 > > This document defines the use of ROHC header compression mechanisms > for the NEMO Basic Support protocol [9]. The idea is to use both > NEMO and ROHC as they have been defined without any change. The > tunneling in the NEMO Basic Support protocol will be done over > different supports (Wireless LAN, 3G or PPP) links, where ROHC > compression can work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-minaburo-rohc-nemo-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ENCODING mime > FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 03:11:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00687 for ; Fri, 15 Apr 2005 03:11:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DML8w-0000ND-QB for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 03:21:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMKtI-00061e-V7; Fri, 15 Apr 2005 03:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMKsh-0005xd-Ut for rohc@megatron.ietf.org; Fri, 15 Apr 2005 03:04:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00506 for ; Fri, 15 Apr 2005 03:04:38 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DML2i-00008P-Tf for rohc@ietf.org; Fri, 15 Apr 2005 03:15:09 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3F735jY006197; Fri, 15 Apr 2005 09:04:37 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:03:38 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:03:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] New Draft for Support of Reordering and Constant IP-ID Date: Fri, 15 Apr 2005 09:03:26 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27DA@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] New Draft for Support of Reordering and Constant IP-ID Thread-Index: AcUwm2jLoPv9AE5QSMazjNa5DU145wLeUYRAAM8s6sAACcKMMAAjRGUwAEhHYkAAFxc2EA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kapoor, Rohit" X-OriginalArrivalTime: 15 Apr 2005 07:03:46.0597 (UTC) FILETIME=[44874D50:01C54189] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, hjin@qualcomm.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Rohit, I'll try to clarify, hopefully I have corrently understood your = question. First of all, timer-based compression has to be turned on by setting the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted TS bits should always be interpreted as scaled TS bits, with the=20 assumption that the decompressor makes use of timer-based estimation, i.e. the transmitted bits might not themselves be enough to decompress the TS correctly (MSB requires a timer-based estimation). However, if NO BITS are transmitted, this means that TS do follow SN linearly as a function of TS_STRIDE, i.e.: TS_SCALED(n) =3D TS_SCALED(n-1) + SN(n) - SN(n-1) Timer-based compression is used to be able to reduce the number of extra bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. instead of having to send two or three extra bytes after a silence period, one byte will be enough. When no TS bits are sent, timer-based compression has no impact on decompression. Did that answer the question? Interpretation two is thus correct! I guess it might make sense to write a few words about this in the implementer's guide, a new section 4.8 on timer-based compression? What do others think? BR /L-E > -----Original Message----- > From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] > Sent: den 14 april 2005 21:26 > To: Lars-Erik Jonsson (LU/EAB) > Cc: hjin@qualcomm.com > Subject: RE: [rohc] New Draft for Support of Reordering and Constant > IP-ID >=20 >=20 > Lars-Erik, >=20 > Thanks. >=20 > I also have a slight confusion in the interpretation of the=20 > RFC that you may be able to clarify. Assume that for some > time the compressor is using timer-based compression to > compress RTP timestamp and uses UO-1-TS packets. Now, if > the compressor decides to send a UO-0 packet, how does > the decompressor infer the RTP timestamp from this packet? > UO-0 could either mean that "jitter is 0" (since no > timestamp bits are present) or the decompressor could > infer timestamp from RTP SN. Which interpretation will > the decompressor follow? Or is sending a UO-0 packet not > "legal" when compressing TS using timer-based compression? >=20 > The following paragraph in the RFC says something which seems=20 > to support the second interpretation. >=20 > On page 58 > If RTP Timestamp and IP Identification fields are not=20 > included in the received header, they are supposed to be > calculated from the sequence number. The IP Identifier > usually increases by the same delta as the sequence number > and the timestamp by the same delta times a fixed value.=20 > See chapters 4.5.3 and 4.5.5 for details about how these > fields are encoded in compressed headers. >=20 >=20 > Thanks, > Rohit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 03:24:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01336 for ; Fri, 15 Apr 2005 03:24:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLMB-0000oe-6A for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 03:35:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DML7I-0007zj-DI; Fri, 15 Apr 2005 03:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DML7E-0007ys-Jj; Fri, 15 Apr 2005 03:19:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01084; Fri, 15 Apr 2005 03:19:39 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLHD-0000c4-SJ; Fri, 15 Apr 2005 03:30:10 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3F7Ik98011072; Fri, 15 Apr 2005 09:18:47 +0200 (MEST) In-Reply-To: <425F11DD.6090901@eng.monash.edu.au> References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> <425EBC50.2070005@iprg.nokia.com> <425F11DD.6090901@eng.monash.edu.au> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3355b6f47b3836070b9015aca6515b30@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt Date: Fri, 15 Apr 2005 09:18:46 +0200 To: greg.daley@eng.monash.edu.au X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Carsten Bormann , "'rohc@ietf.org'" , Henrik Levkowetz X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit I'm not sure the present draft is really doing much more than pointing out a potential use for ROHC. To get interoperability, one would need to -- specify how the use of ROHC is negotiated or otherwise initiated between the parties -- specify the encapsulation -- specify how to deal with reordering (see also draft-ietf-rohc-over-reordering-02.txt, which just went to WGLC) -- possibly select a subset of the now no longer trivial gamut of ROHC profiles to choose from. A standards-track document should nail down these (and anything I might have forgotten). We can do without a rehash of ROHC fundamentals. (A couple of diagrams/examples pointing out how the result of the whole thing will look like would be nice, though.) RFC 3241 is one example for the kind of "ROHC-over-X" document needed. Clearly, the two working groups will need to collaborate on this. I don't have a strong feeling which working group should be the "home" WG. Given that similar considerations apply in other uses of ROHC in a mobile IP environment, I'd like to spend some time hallway-discussing this with the usual suspects in Paris. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 05:05:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09708 for ; Fri, 15 Apr 2005 05:05:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMw0-0004pS-Rf for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 05:16:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMMkc-0003QA-Bt; Fri, 15 Apr 2005 05:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMMka-0003Oe-Rt for rohc@megatron.ietf.org; Fri, 15 Apr 2005 05:04:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09529 for ; Fri, 15 Apr 2005 05:04:23 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMuc-0004ja-Ta for rohc@ietf.org; Fri, 15 Apr 2005 05:14:55 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3F94MOE013722 for ; Fri, 15 Apr 2005 11:04:23 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 11:03:40 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 11:03:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2005 11:03:40 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27E0@esealmw109.eemea.ericsson.se> Thread-Topic: Minor addition to the implementer's guide Thread-Index: AcVBmgN4F04N2cfVRWKgkQt3vZv0pg== From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 15 Apr 2005 09:03:39.0898 (UTC) FILETIME=[0411EDA0:01C5419A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: [rohc] Minor addition to the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable ROHCers, I've added the following to the implementer's guide, after having received questions on this offline. Let me know if there are any comments on this text: 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism for encoding of a constant Identification value in IPv4 (constant IP- ID) is defined. This mechanism is also used by the ROHC UDP-Lite profiles, RFC 4019 [4].=20 It should be noted that the "Constant IP-ID" mechanism applies to both the inner and the outer IP header, when present, meaning that there will be both a SID and a SID2 context value. I have also updated the abstract and introduction to point out that the draft contains clarifications also on RFC 3241, RFC 3843, and RFC 4019. Cheers, /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc. Senior Research Engineer Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com /"\ Phone: +46 8 404 29 61 \ / Fax: +46 920 996 21 ASCII Ribbon Campaign X Home: +46 920 999 57 against HTML email & vCards / \ My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 09:47:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00851 for ; Fri, 15 Apr 2005 09:47:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMRKW-00071g-E8 for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 09:57:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMR2n-0004sz-2P; Fri, 15 Apr 2005 09:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMR2l-0004sD-ES for rohc@megatron.ietf.org; Fri, 15 Apr 2005 09:39:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00459 for ; Fri, 15 Apr 2005 09:39:25 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMRCo-0006ix-HP for rohc@ietf.org; Fri, 15 Apr 2005 09:50:00 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3FDcdQc010522 for ; Fri, 15 Apr 2005 14:38:39 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <26RQ8L83>; Fri, 15 Apr 2005 14:39:00 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A283D@rsys004a> From: "Finking, Robert" To: rohc@ietf.org Date: Fri, 15 Apr 2005 14:38:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [rohc] FN: default_methods and control fields clarification/new usage X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab All, Whilst doing the latest lot of updates, I've found an error in the current FN draft. It is to do with the way default_methods are used. To recap, default_methods are referred to if and only if there is no encoding given for a field in a packet format. If an encoding is given for that field then there is no need to refer to the default: it is just a fall back to use when no other encoding is specified. In the Appendix B (which I'm currently editing) we have the following in an example: control_fields = scaled_seq_no; default_methods = { version_no ::= uncompressed_value(2,1); type ::= irregular(2); flow_id ::= static; reserved_flag ::= uncompressed_value(1,0); % need modulo maths to calculate scaling correctly, % due to 4 bit wrap around let(scaled_seq_no:uncomp_value == ((mod(15 - sequence_no:uncomp_value, 3) * 16 + sequence_no:uncomp_value) / 3)); scaled_seq_no ::= lsb(1,-1); }; The problem here is that the default_methods specifies not only the *default* encoding for the field (lsb), but also the binding for the uncompressed value of the field. The default encoding isn't referred to when a packet format specifies an encoding of its own - that fine. The binding for the uncompressed value however should ALWAYS be referred to, since this is what gives the control field its value. Since this binding is in default_methods, it will not always be referred to =( The way the FN draft is currently written, the solution to this problem is to move the essential bit of code (the "let" statement) into the uc_format encodings list. However, this is not a cure-all since sometimes there will be multiple uc_formats. The intuitive solution is to put the binding for the uncompressed value of the control field under the control_fields list. Apart from clarifying an issue which is currently not nailed down in the draft (whether or not a field encodings list can be specified for control_fields), it actually reads really nicely: control_fields = scaled_seq_no %[ 4 ] { % need modulo maths to calculate scaling correctly, % due to 4 bit wrap around let(scaled_seq_no:uncomp_value == ((mod(15 - sequence_no:uncomp_value, 3) * 16 + sequence_no:uncomp_value) / 3)); }; default_methods = { version_no ::= uncompressed_value(2,1); type ::= irregular(2); flow_id ::= static; reserved_flag ::= uncompressed_value(1,0); scaled_seq_no ::= lsb(1,-1); }; As an aside, since this is really just a clarification it shouldn't affect the current packet formats as far as I can see. I thought I'd better post this in case there were any objections - it strikes me this could be viewed as more than just an editing issue! Regards Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 11:20:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08735 for ; Fri, 15 Apr 2005 11:20:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSmT-00027e-4w for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 11:30:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSE9-0005F9-Qn; Fri, 15 Apr 2005 10:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSE7-0005Eq-SZ for rohc@megatron.ietf.org; Fri, 15 Apr 2005 10:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06969 for ; Fri, 15 Apr 2005 10:55:21 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSOI-000184-PW for rohc@ietf.org; Fri, 15 Apr 2005 11:05:57 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3FDsWmg026926 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 Apr 2005 15:54:38 +0200 Message-ID: <425FD5D2.6010401@effnet.com> Date: Fri, 15 Apr 2005 16:55:14 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A283D@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A283D@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi Robert, actually, this _does_ affect the current TCP packet formats (e.g. sack_var_length_enc and co_baseheader), since we have used a number of let-statements on control fields inside default_methods (at least I think these are identical cases to what you're describing). My understanding when I made the packet formats was that you always "executed" the default methods and then if new encoding for a field was present in the compressed formats, you "overwrote" the default_methods encoding. But obviously, this is not what you meant (but I haven't read the actual text in the FN for a long time). I think the change you propose looks reasonable, but I'm not yet sure how this will work for the TCP packet formats, so I'd have to think this though a bit more. Could you check the tcp packet formats and see how your change maps to the current formats (the examples I listed above)? BR, Kristofer Sandlund, Effnet AB Finking, Robert wrote: > All, > > Whilst doing the latest lot of updates, I've found an error in the current FN draft. It is to do with the way default_methods are used. To recap, default_methods are referred to if and only if there is no encoding given for a field in a packet format. If an encoding is given for that field then there is no need to refer to the default: it is just a fall back to use when no other encoding is specified. > > In the Appendix B (which I'm currently editing) we have the following in an example: > > control_fields = scaled_seq_no; > > default_methods = > { > version_no ::= uncompressed_value(2,1); > type ::= irregular(2); > flow_id ::= static; > reserved_flag ::= uncompressed_value(1,0); > > % need modulo maths to calculate scaling correctly, > % due to 4 bit wrap around > let(scaled_seq_no:uncomp_value > == ((mod(15 - sequence_no:uncomp_value, 3) * 16 > + sequence_no:uncomp_value) / 3)); > scaled_seq_no ::= lsb(1,-1); > }; > > The problem here is that the default_methods specifies not only the *default* encoding for the field (lsb), but also the binding for the uncompressed value of the field. The default encoding isn't referred to when a packet format specifies an encoding of its own - that fine. The binding for the uncompressed value however should ALWAYS be referred to, since this is what gives the control field its value. Since this binding is in default_methods, it will not always be referred to =( > > The way the FN draft is currently written, the solution to this problem is to move the essential bit of code (the "let" statement) into the uc_format encodings list. However, this is not a cure-all since sometimes there will be multiple uc_formats. > > The intuitive solution is to put the binding for the uncompressed value of the control field under the control_fields list. Apart from clarifying an issue which is currently not nailed down in the draft (whether or not a field encodings list can be specified for control_fields), it actually reads really nicely: > > control_fields = scaled_seq_no %[ 4 ] > { > % need modulo maths to calculate scaling correctly, > % due to 4 bit wrap around > let(scaled_seq_no:uncomp_value > == ((mod(15 - sequence_no:uncomp_value, 3) * 16 > + sequence_no:uncomp_value) / 3)); > }; > > default_methods = > { > version_no ::= uncompressed_value(2,1); > type ::= irregular(2); > flow_id ::= static; > reserved_flag ::= uncompressed_value(1,0); > scaled_seq_no ::= lsb(1,-1); > }; > > As an aside, since this is really just a clarification it shouldn't affect the current packet formats as far as I can see. > > I thought I'd better post this in case there were any objections - it strikes me this could be viewed as more than just an editing issue! > > Regards > > Raffles > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 11:25:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09005 for ; Fri, 15 Apr 2005 11:25:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSrg-0002Gm-57 for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 11:36:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSc1-0007Ej-Az; Fri, 15 Apr 2005 11:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSbz-0007EW-SU for rohc@megatron.ietf.org; Fri, 15 Apr 2005 11:20:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08730 for ; Fri, 15 Apr 2005 11:20:01 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSmC-00024b-M8 for rohc@ietf.org; Fri, 15 Apr 2005 11:30:37 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3FEJJmg026995 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 Apr 2005 16:19:19 +0200 Message-ID: <425FDBA1.8050201@effnet.com> Date: Fri, 15 Apr 2005 17:20:01 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2849@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2849@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: 7bit inline. Finking, Robert wrote: > Hi Kris, > > Thanks for the response. I had a quick look at the formats before my > post and there didn't seem to be a problem, since although they do use > such definitions in default_methods, they never get overridden, or else > they're overridden correctly. However I missed "sack_var_length_enc" > when I was skimming through. You're right it needs fixing, but this > needs fixing anyway, since there is currently no control fields list. To > recap any field which does NOT appear in the uncompressed header, but > that DOES have an uncompressed side, needs to be declared in a control > fields list. Disagree. See below. > This is not a big deal though, it just means replacing the > current "default_methods" line with "control_fields", so you end up with > this: > > control_fields = sack_offset %[ 32 ] > { > let (sack_offset:uncomp_value == > sack_field:uncomp_value - base); > let (sack_offset:uncomp_length == 32); > let (sack_field:uncomp_length == 32); > }; > Hmm... I think we again have some kind of disconnect regarding the control fields. As far as I remember, it was me and Ghyslain who pushed for the control fields, and our intention was that these should be "fields that are kept in context between packets", while our intention was not to have define control fields that are just using during the processing of a single packet. And this is what the WG decided in Washington, but maybe this got lost on the way to the draft. I get the feeling that you define control fields differently than that (again, I have not checked FN for some time, but I though it contained what we had decided earlier). I think this is quite an important distinction that we should keep since it helps implementers a lot to know what is actual context that is used next time and which are just used for the "current packet". If we use "my" definition, then we cannot define sack_offset as a control_field and we need another solution. > Similarly with seq_number_scaled etc. in baseheaders - they need > declaring in a control_fields list anyway. Hopefully it's a just a quick > cut and paste? These are already defined as control fields on the global level (see the start of the file). > > Note this does NOT affect fields which have no uncompressed side at all, > such as compressed side CRCs or the many flags which are used. Agreed, but as I try to describe above, what _you_ call control_fields are in _my_ mind two different categories where only one can be defined as a control_field. BR, Kristofer > > Thanks for keeping an eagle eye out =) > > Raffles > >>-----Original Message----- >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>Sent: Friday, April 15, 2005 3:55 PM >>To: Finking, Robert >>Cc: rohc@ietf.org >>Subject: Re: [rohc] FN: default_methods and control fields >>clarification/new usage >> >> >>Hi Robert, >> >>actually, this _does_ affect the current TCP packet formats (e.g. >>sack_var_length_enc and co_baseheader), since we have used a >>number of >>let-statements on control fields inside default_methods (at >>least I think these >>are identical cases to what you're describing). >> >>My understanding when I made the packet formats was that you >>always "executed" >>the default methods and then if new encoding for a field was >>present in the >>compressed formats, you "overwrote" the default_methods >>encoding. But obviously, >>this is not what you meant (but I haven't read the actual >>text in the FN for a >>long time). >>I think the change you propose looks reasonable, but I'm not >>yet sure how this >>will work for the TCP packet formats, so I'd have to think >>this though a bit >>more. Could you check the tcp packet formats and see how your >>change maps to the >>current formats (the examples I listed above)? >> >>BR, >> Kristofer Sandlund, Effnet AB >> >> >> >>Finking, Robert wrote: >> >>>All, >>> >>>Whilst doing the latest lot of updates, I've found an error >> >>in the current FN draft. It is to do with the way >>default_methods are used. To recap, default_methods are >>referred to if and only if there is no encoding given for a >>field in a packet format. If an encoding is given for that >>field then there is no need to refer to the default: it is >>just a fall back to use when no other encoding is specified. >> >>>In the Appendix B (which I'm currently editing) we have the >> >>following in an example: >> >>> control_fields = scaled_seq_no; >>> >>> default_methods = >>> { >>> version_no ::= uncompressed_value(2,1); >>> type ::= irregular(2); >>> flow_id ::= static; >>> reserved_flag ::= uncompressed_value(1,0); >>> >>> % need modulo maths to calculate scaling correctly, >>> % due to 4 bit wrap around >>> let(scaled_seq_no:uncomp_value >>> == ((mod(15 - sequence_no:uncomp_value, 3) * 16 >>> + sequence_no:uncomp_value) / 3)); >>> scaled_seq_no ::= lsb(1,-1); >>> }; >>> >>>The problem here is that the default_methods specifies not >> >>only the *default* encoding for the field (lsb), but also the >>binding for the uncompressed value of the field. The default >>encoding isn't referred to when a packet format specifies an >>encoding of its own - that fine. The binding for the >>uncompressed value however should ALWAYS be referred to, >>since this is what gives the control field its value. Since >>this binding is in default_methods, it will not always be >>referred to =( >> >>>The way the FN draft is currently written, the solution to >> >>this problem is to move the essential bit of code (the "let" >>statement) into the uc_format encodings list. However, this >>is not a cure-all since sometimes there will be multiple uc_formats. >> >>>The intuitive solution is to put the binding for the >> >>uncompressed value of the control field under the >>control_fields list. Apart from clarifying an issue which is >>currently not nailed down in the draft (whether or not a >>field encodings list can be specified for control_fields), it >>actually reads really nicely: >> >>> control_fields = scaled_seq_no %[ 4 ] >>> { >>> % need modulo maths to calculate scaling correctly, >>> % due to 4 bit wrap around >>> let(scaled_seq_no:uncomp_value >>> == ((mod(15 - sequence_no:uncomp_value, 3) * 16 >>> + sequence_no:uncomp_value) / 3)); >>> }; >>> >>> default_methods = >>> { >>> version_no ::= uncompressed_value(2,1); >>> type ::= irregular(2); >>> flow_id ::= static; >>> reserved_flag ::= uncompressed_value(1,0); >>> scaled_seq_no ::= lsb(1,-1); >>> }; >>> >>>As an aside, since this is really just a clarification it >> >>shouldn't affect the current packet formats as far as I can see. >> >>>I thought I'd better post this in case there were any >> >>objections - it strikes me this could be viewed as more than >>just an editing issue! >> >>>Regards >>> >>>Raffles >>> >>>_______________________________________________ >>>Rohc mailing list >>>Rohc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rohc >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 11:27:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09150 for ; Fri, 15 Apr 2005 11:27:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSt1-0002MT-Uh for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 11:37:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSPm-0006F0-CZ; Fri, 15 Apr 2005 11:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSPl-0006Es-1T for rohc@megatron.ietf.org; Fri, 15 Apr 2005 11:07:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07842 for ; Fri, 15 Apr 2005 11:07:21 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSZw-0001aH-S4 for rohc@ietf.org; Fri, 15 Apr 2005 11:17:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3FF6uQc003413; Fri, 15 Apr 2005 16:06:56 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Apr 2005 16:07:12 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2849@rsys004a> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVByzyDn11GyU6OQfCO8gO94PjWXAAABaqQ From: "Finking, Robert" To: "Kristofer Sandlund" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Hi Kris, Thanks for the response. I had a quick look at the formats before my post and there didn't seem to be a problem, since although they do use such definitions in default_methods, they never get overridden, or else they're overridden correctly. However I missed "sack_var_length_enc" when I was skimming through. You're right it needs fixing, but this needs fixing anyway, since there is currently no control fields list. To recap any field which does NOT appear in the uncompressed header, but that DOES have an uncompressed side, needs to be declared in a control fields list. This is not a big deal though, it just means replacing the current "default_methods" line with "control_fields", so you end up with this: control_fields =3D sack_offset %[ 32 ] { let (sack_offset:uncomp_value =3D=3D sack_field:uncomp_value - base); let (sack_offset:uncomp_length =3D=3D 32); let (sack_field:uncomp_length =3D=3D 32); }; Similarly with seq_number_scaled etc. in baseheaders - they need declaring in a control_fields list anyway. Hopefully it's a just a quick cut and paste? Note this does NOT affect fields which have no uncompressed side at all, such as compressed side CRCs or the many flags which are used. Thanks for keeping an eagle eye out =3D) Raffles > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 > Sent: Friday, April 15, 2005 3:55 PM > To: Finking, Robert > Cc: rohc@ietf.org > Subject: Re: [rohc] FN: default_methods and control fields=20 > clarification/new usage >=20 >=20 > Hi Robert, >=20 > actually, this _does_ affect the current TCP packet formats (e.g.=20 > sack_var_length_enc and co_baseheader), since we have used a=20 > number of=20 > let-statements on control fields inside default_methods (at=20 > least I think these=20 > are identical cases to what you're describing). >=20 > My understanding when I made the packet formats was that you=20 > always "executed"=20 > the default methods and then if new encoding for a field was=20 > present in the=20 > compressed formats, you "overwrote" the default_methods=20 > encoding. But obviously,=20 > this is not what you meant (but I haven't read the actual=20 > text in the FN for a=20 > long time). > I think the change you propose looks reasonable, but I'm not=20 > yet sure how this=20 > will work for the TCP packet formats, so I'd have to think=20 > this though a bit=20 > more. Could you check the tcp packet formats and see how your=20 > change maps to the=20 > current formats (the examples I listed above)? >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 >=20 >=20 > Finking, Robert wrote: > > All, > >=20 > > Whilst doing the latest lot of updates, I've found an error=20 > in the current FN draft. It is to do with the way=20 > default_methods are used. To recap, default_methods are=20 > referred to if and only if there is no encoding given for a=20 > field in a packet format. If an encoding is given for that=20 > field then there is no need to refer to the default: it is=20 > just a fall back to use when no other encoding is specified. > >=20 > > In the Appendix B (which I'm currently editing) we have the=20 > following in an example: > >=20 > > control_fields =3D scaled_seq_no; > >=20 > > default_methods =3D > > { > > version_no ::=3D uncompressed_value(2,1); > > type ::=3D irregular(2); > > flow_id ::=3D static; > > reserved_flag ::=3D uncompressed_value(1,0); > >=20 > > % need modulo maths to calculate scaling correctly, > > % due to 4 bit wrap around > > let(scaled_seq_no:uncomp_value > > =3D=3D ((mod(15 - sequence_no:uncomp_value, 3) * 16 > > + sequence_no:uncomp_value) / 3)); > > scaled_seq_no ::=3D lsb(1,-1); > > }; > >=20 > > The problem here is that the default_methods specifies not=20 > only the *default* encoding for the field (lsb), but also the=20 > binding for the uncompressed value of the field. The default=20 > encoding isn't referred to when a packet format specifies an=20 > encoding of its own - that fine. The binding for the=20 > uncompressed value however should ALWAYS be referred to,=20 > since this is what gives the control field its value. Since=20 > this binding is in default_methods, it will not always be=20 > referred to =3D( > >=20 > > The way the FN draft is currently written, the solution to=20 > this problem is to move the essential bit of code (the "let"=20 > statement) into the uc_format encodings list. However, this=20 > is not a cure-all since sometimes there will be multiple uc_formats. > >=20 > > The intuitive solution is to put the binding for the=20 > uncompressed value of the control field under the=20 > control_fields list. Apart from clarifying an issue which is=20 > currently not nailed down in the draft (whether or not a=20 > field encodings list can be specified for control_fields), it=20 > actually reads really nicely: > >=20 > > control_fields =3D scaled_seq_no %[ 4 ] > > { > > % need modulo maths to calculate scaling correctly, > > % due to 4 bit wrap around > > let(scaled_seq_no:uncomp_value > > =3D=3D ((mod(15 - sequence_no:uncomp_value, 3) * 16 > > + sequence_no:uncomp_value) / 3)); > > }; > >=20 > > default_methods =3D > > { > > version_no ::=3D uncompressed_value(2,1); > > type ::=3D irregular(2); > > flow_id ::=3D static; > > reserved_flag ::=3D uncompressed_value(1,0); > > scaled_seq_no ::=3D lsb(1,-1); > > }; > >=20 > > As an aside, since this is really just a clarification it=20 > shouldn't affect the current packet formats as far as I can see. > >=20 > > I thought I'd better post this in case there were any=20 > objections - it strikes me this could be viewed as more than=20 > just an editing issue! > >=20 > > Regards > >=20 > > Raffles > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 11:41:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12607 for ; Fri, 15 Apr 2005 11:41:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMT6k-0003C0-Eu for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 11:51:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSjL-0007ry-6P; Fri, 15 Apr 2005 11:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMShU-0007gN-Ui for rohc@megatron.ietf.org; Fri, 15 Apr 2005 11:25:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09027 for ; Fri, 15 Apr 2005 11:25:42 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSrh-0002Gn-KJ for rohc@ietf.org; Fri, 15 Apr 2005 11:36:19 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3FFPYiv021337; Fri, 15 Apr 2005 17:25:35 +0200 (MEST) In-Reply-To: <425FD5D2.6010401@effnet.com> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A283D@rsys004a> <425FD5D2.6010401@effnet.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage Date: Fri, 15 Apr 2005 17:25:34 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: "Finking, Robert" , rohc@ietf.org, Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Apr 15 2005, at 16:55 Uhr, Kristofer Sandlund wrote: > My understanding when I made the packet formats was that you always > "executed" the default methods and then if new encoding for a field > was present in the compressed formats, you "overwrote" the > default_methods encoding. Yes. This works because fields have a name. There is no way to overwrite a let statement because it does not have a name, so all let statements from the default_methods are used everywhere. (This bit us a couple of times.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 12:01:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16354 for ; Fri, 15 Apr 2005 12:01:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTAJ-0003cZ-Ty for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 11:55:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSvz-0000zW-Hs; Fri, 15 Apr 2005 11:40:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSvx-0000z0-Sf for rohc@megatron.ietf.org; Fri, 15 Apr 2005 11:40:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12167 for ; Fri, 15 Apr 2005 11:40:39 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMT63-00032A-DD for rohc@ietf.org; Fri, 15 Apr 2005 11:51:10 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3FFe3Qc012673; Fri, 15 Apr 2005 16:40:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Apr 2005 16:40:20 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A284C@rsys004a> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVBz3P2q3I5NyeVRkOIJpCaC8DKkAAAB2qQ From: "Finking, Robert" To: "Carsten Bormann" , "Kristofer Sandlund" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Eeek. Inline > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: Friday, April 15, 2005 4:26 PM > To: Kristofer Sandlund > Cc: Finking, Robert; Carsten Bormann; rohc@ietf.org > Subject: Re: [rohc] FN: default_methods and control fields=20 > clarification/new usage >=20 >=20 > On Apr 15 2005, at 16:55 Uhr, Kristofer Sandlund wrote: >=20 > > My understanding when I made the packet formats was that you always=20 > > "executed" the default methods and then if new encoding for a field=20 > > was present in the compressed formats, you "overwrote" the=20 > > default_methods encoding. >=20 > Yes. >=20 > This works because fields have a name. >=20 > There is no way to overwrite a let statement because it does=20 > not have a=20 > name, so all let statements from the default_methods are used=20 > everywhere. This is not what the FN draft says - Eilert proposed this ages ago and we discussed it (on the list for once IIRC) and ended up with what we've now got. I'll paste below what the FN draft currently says, but the nub of it is this: IFF there is no bindings specified for a field by a packet format THEN you consult the default_methods for all bindings for that field only. IFF there are let statements binding certain attributes of a field (but not all) THEN you consult the default_methods for those attributes which aren't already bound. IIRC This was because Ghyslain and I weren't happy that you had to know *how* a field was bound in order to understand the override behaviour. To put it simply, "if it's in default_methods then it should be a default". Here's what the draft says: 4.9.4.3 Default Encoding Methods - default_methods default_methods =3D { field_1 ::=3D uncompressed_value(4,1); field_2 ::=3D uncompressed_value(4,2); field_3 ::=3D lsb(3,-1); let(field_4:uncomp_length =3D=3D 4); }; The field encodings list of default_methods may also contain default bindings for individual attributes by using "let" statements. If a default binding is given for an individual attribute, that binding may be overridden by another binding for that attribute or for the field to which it belongs. The overriding binding may either be another let statement, or an encoding method. Assuming the default methods given in the example above, the first three of the following four compressed packet formats would override the default binding for "field_4:uncomp_length": co_format_1 =3D field_4 { let(field_4:uncomp_length =3D=3D 3); % set uncomp_length to 3 }; co_format_2 =3D field_4 { field_4 ::=3D irregular(3); % set uncomp_length to 3 }; co_format_3 =3D field_4 { field_4 ::=3D '1010'; % set uncomp_length to undefined }; co_format_4 =3D field_4 { let(field_4:uncomp_value =3D=3D 12); % use default uncomp_length }; It is allowed to override one default binding but still use another. Overriding one default binding does not imply that other default bindings are also being overridden. It is also allowed to supply default bindings for some but not all fields. Note that a structure's default methods are only consulted for packet formats which do not already specify an encoding for all of their fields. For the packet formats that do use the default methods, only those fields whose encoding methods are not specified are looked up in the default methods.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 12:03:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16685 for ; Fri, 15 Apr 2005 12:03:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTS4-0005BJ-1N for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 12:13:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTFL-0004il-Sx; Fri, 15 Apr 2005 12:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTFK-0004iA-74 for rohc@megatron.ietf.org; Fri, 15 Apr 2005 12:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15996 for ; Fri, 15 Apr 2005 12:00:39 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTJA-0004Ls-Ns for rohc@ietf.org; Fri, 15 Apr 2005 12:04:43 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3FFrttp002947; Fri, 15 Apr 2005 17:53:57 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A284C@rsys004a> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A284C@rsys004a> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <574cfcb4472ec2fe75e801f985af77a6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage Date: Fri, 15 Apr 2005 17:53:56 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, Kristofer Sandlund X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hmm, I missed this change. On Apr 15 2005, at 17:40 Uhr, Finking, Robert wrote: > let statements binding certain attributes How do you know that? Wnat does let(a:uncomp_value == b:uncomp_value) bind? Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 12:04:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16892 for ; Fri, 15 Apr 2005 12:04:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTTJ-0005FF-1h for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 12:15:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTF7-0004cd-NG; Fri, 15 Apr 2005 12:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTF4-0004bD-Ou for rohc@megatron.ietf.org; Fri, 15 Apr 2005 12:00:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15824 for ; Fri, 15 Apr 2005 12:00:23 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTOQ-0004i9-3h for rohc@ietf.org; Fri, 15 Apr 2005 12:10:08 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3FFx9Qc017497; Fri, 15 Apr 2005 16:59:09 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Apr 2005 16:59:25 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5EEF@rsys004a> Thread-Topic: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. Thread-Index: AcVBfvCoMRibJ1WQSP6gbUllEFhpggATW1pg From: "Surtees, Abigail" To: "Lajos Zaccomer \(IJ/ETH\)" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec Content-Transfer-Encoding: quoted-printable Hi Zacco, We've got crossed wires somewhere and I'm afraid I'm still confused. What I was trying to say is the following: 1) In standard rfc 3320 behaviour, if an endpoint advertises a piece of state to the remote endpoint, it is saying that it has that piece of state available for use for the duration of the compartment*. It is up to the implementer whether the bytes of the advertised state are uploaded to the remote endpoint and created as high priority state (i.e. stored in the compressor compartment) or are stored outside the compressor SMS in the endpoint (more likely e.g. dictionary). *Shared mode state is an exception to this. 2) The remote endpoint *can*, if it is sophisticated, notice that a piece of state has been both uploaded (i.e. the bytes are in the decompressor compartment) and advertised and, therefore, choose to use this piece of state as reference state for its return message. 3) There is no requirement on the remote endpoint to do this. 4) If the remote endpoint does this, neither endpoint has done anything other than use standard rfcs 3320 - 22 behaviour. 5) An optional mechanism that would make it easier for the remote endpoint to recognise that a piece of state is useful as a reference is to include the bytes 'usd1' as the first 4 bytes. However, addition of these bytes DOES NOT change the state processing at either endpoint. The state is stored in exactly the same way (implementer's choice at the compressor, in the SMS memory at the decompressor) as if the bytes are not there. 6) If the remote endpoint chooses to move the state from its decompressor compartment and advertise it back to the local endpoint, that is an implementation choice and is still perfectly compliant with rfcs 3320 - 22. (An endpoint choosing to do this must carefully consider the security implications.) 7) If there is anything in the intention of what is written in the PoC specification that is not covered here, please could you explain (e.g. with use of diagrams similar to the ones in my previous email) what it is that I'm missing. 8) As it stands at the moment, this part of the PoC specification is unclear, ambiguous and could lead to loss of synchronisation. Best regards, Abbie >=20 > >=20 > > Hi Zacco, > >=20 > > Once again, apologies for the delay in responding to this. > >=20 > > I am somewhat confused by some of the statements in the=20 > > discussion below and the level of indentation isn't helping. =20 > > Consequently, I'm going to state my understanding and you can=20 > > tell me where you disagree or I am wrong. I hope that's ok. =20 > > I've used text here and put some ASCII diagrams in the=20 > > attached file (they get messed up if they're in the body of=20 > > the email). > >=20 > > Let's start with basic SigComp operation (to ensure we're all=20 > > clear on the terminology and interpretation of pictures -=20 > > using a 2 byte partial hash to identify state): > >=20 > > Scenario 1: > > Endpoint A sends a message to endpoint B requesting two=20 > > pieces of state to be created and feedback to be returned: > >=20 > > Bytecode with hash bcbc > > Buffer state with hash bff1 > >=20 > > The state handler at B has no idea what the pieces of state=20 > > are - they are just chunks of bytes. Endpoint B includes the=20 > > feedback in its return message, thus endpoint A can refer to=20 > > both pieces of state in its next message. > >=20 > > Scenario 2: > >=20 > > Endpoint A knows about a dictionary (with hash d1c7). It=20 > > sends a message to endpoint B requesting state creation and=20 > > feedback as in scenario 1, but also advertising d1c7. > >=20 > > If endpoint B doesn't know anything about d1c7, then the=20 > > advertisement will be ignored and the return message will not=20 > > refer to it. > >=20 > > If endpoint B does know about d1c7 and has the capacity to=20 > > use it, then the return message will refer to it. > >=20 > > Scenario 3: > > Endpoint A knows about dictionary (with hash d1c7) and wants=20 > > to be able to use it for compression itself, so it uploads it=20 > > to endpoint B as another piece of state. > >=20 > > Scenario 4: > > Endpoint A knows about dictionary (with hash d1c7) and wants=20 > > to be able to refer to it at endpoint B AND it thinks B may=20 > > be a sophisticated implementation. Therefore endpoint A not=20 > > only uploads the dictionary (as in scenario 3) but also=20 > > advertises its presence at endpoint A, allowing B to refer to=20 > > it. N.B. By advertising it, endpoint A is saying that the=20 > > dictionary will be available for the duration of the=20 > > compartment (this may be in memory external to the compressor=20 > > SMS, or it may be created within the compartment e.g. at=20 > > sufficiently high priority in the compressor A SMS that it=20 > > will not be pushed out by other state - compressor A has full=20 > > control of both alternatives). >=20 > [zacco] In PoC, state d1c7 is called a USD and is stored in=20 > memory external to the compressor. >=20 > OMA-POC-2004-0655-CP-SigComp 5.X.1.2 says: > "The USD is a locally available state, [RFC3320], at the PoC=20 > Client and to improve the compression efficiency in the=20 > uplink the PoC Client MAY upload the USD to its SIP/IP Core=20 > compartment. To increase the compression efficiency in the=20 > downlink, the PoC client MAY advertise the locally available=20 > state to the SIP/IP core.=20 > The first four bytes of the USD state value SHALL be the=20 > specific identifier string; "usd1" in order to distinguish=20 > the USD state from the possible bytecode uploaded for the=20 > Universal Decompressor Virtual Machine (UDVM)." >=20 > >=20 > > The simplest implementation of B on receipt of the advert for=20 > > d1c7 would decide it knows nothing about d1c7 as is the case=20 > > with any other state advert about which it knows nothing. > >=20 > > A more sophisticated implementation may notice that the state=20 > > being advertised has also been created in the decompressor=20 > > SMS. Therefore, because it has the bytes of the state, the=20 > > compressor at B *could* make use of the state. However, the=20 > > compressor at endpoint B does not know what sort of state it=20 > > is - it's just a bunch of bytes. Some heuristic (e.g.=20 > > comparison with the next message to be compressed) could be=20 > > used to decide whether or not the piece of state is useful as=20 > > a reference to improve the compression ratio of the next message. =20 > >=20 > > Endpoint B can refer to d1c7 as long as it knows what it is=20 > > (i.e. it might get pushed out of the decompressor SMS at B,=20 > > at which point, B no longer has it). As mentioned above,=20 > > once the state has been advertised by endpoint A, endpoint A=20 > > must keep it for the duration of the compartment. >=20 > Not quite if d1c7 is moved to external memory in B, which is=20 > optional and up to B. If so, it must be indicated with=20 > explicit acking this state. (The only problem with this=20 > solution that it fails, if you advertise e.g. your bytecode=20 > at the same time, and B explicitly acks the bytecode instead=20 > of d1c7. In this case, A thinks d1c7 is in external memory,=20 > and will most probably overwrite d1c7 sooner or later. >=20 > >=20 > > So far, all of the above is standard rfc 3320 behaviour. =20 >=20 > Yes. My example is PoC. If we talk about 3320-22 only, I have=20 > nothing to add or modify. >=20 > > When compressor A advertises the dictionary, where it stores=20 > > the bytes of dictionary (inside or outside SMS) is=20 > > implementation specific, though in scenarios 3 and 4 it must=20 > > be accounted for in the SMS monitoring because it is=20 > > mirroring the SMS at endpoint B. At endpoint B there is no=20 > > requirement to do anything other than store state according=20 > > to rfc 3320. >=20 > Unless you want to implement some PoC standard features, as well. >=20 > >=20 > > I think that placing 'usd1' as the first 4 bytes of a=20 > > dictionary is then a simple heuristic optimisation. If=20 > > endpoint A puts 'usd1' at the beginning of the state then=20 > > endpoint B has a simple way of recognising that the state=20 > > will be useful as a reference. If, however, A doesn't do=20 > > that, then B (if it wants to) can use some other heuristic,=20 > > as it would without the optimisation. Equally, if endpoint A=20 > > does put 'usd1' in the state and endpoint B doesn't look for=20 > > it, both endpoints continue as if it were not there. >=20 > Right. >=20 > >=20 > > The key point is that, whatever happens, the actual state=20 > > creation and handling at both endpoints is the same,=20 > > regardless of whether or not the state contains the bytes 'usd1'. =20 > >=20 > > Is my interpretation correct? If not, please explain my=20 > > misunderstanding. Whether or not my understanding is=20 > > correct, the text describing this mechanism needs=20 > > clarification in the PoC specification. (I realise this is=20 > > not the place for that discussion - I'm just trying to make=20 > > sure I understand correctly). > >=20 > > Best regards, > >=20 > > Abbie > >=20 > > > >=20 > > > > Sorry for the delay. I've got some questions about the PoC=20 > > > > related use of > > > > usds. > > > >=20 > > > > >=20 > > > > > > 3. USD. I fully understand the usage of a USD.=20 > However, I do=20 > > > > > > not understand=20 > > > > > > if a USD-state should be treated any differenty then any=20 > > > > > > other state created=20 > > > > > > at the remote end. Is a USD per definition a shared state?=20 > > > > >=20 > > > > > No, it isn't. RFC 3321 says it's a regular state. POC USD is=20 > > > > > something different. I would say it's a regular and a shared=20 > > > > > state at the same time. > > > >=20 > > > > What does that actually mean? As you say 3321 says it's a=20 > > > > regular state, so > > > > in SigComp terms how can it be a shared state as well? > > >=20 > > > [zacco] In PoC, the terminal uploads the USD after saving it=20 > > > in the state memory. The special advertisement lets the=20 > > > server know it received a USD that it also saves in the state=20 > > > memory (or outside the state memory, which must be signalled=20 > > > backwards). Thus, both endpoints will have the USD and can=20 > > > use it for compression. That is why I say PoC USD is a=20 > > > dynamic (or regular) and shared state at the same time. > > >=20 > > > >=20 > > > > >=20 > > > > > > I'm guessing that=20 > > > > > > it must be if the sending compressor is to have any=20 > > > > > advantage of the=20 > > > > > > USD-state at the remote end. Then, again, should the=20 > > > > > > USD-state (local state)=20 > > > > > > at A be considered to occupy State-memory? Should it be=20 > > > > > > considered any=20 > > > > > > differently then any other shared state? > > > > >=20 > > > > > It depends on which USD you are talking about. A regular=20 > > > > > state is not saved in a state memory at the compressor side,=20 > > > > > so if you go for the RFC 3321 USD, it decreases the available=20 > > > > > memory at B in the state memory of compresssor at A. In case=20 > > > > > POC USD is used, it must be saved as a local state, otherwise=20 > > > > > the compressor at B would not be able to access it. > > > >=20 > > > > However, we believe that the POC definition of using USD as=20 > > > > shared state is > > > > not well defined and can lead to loss of synchronisation=20 > > > > between the two > > > > endpoints. > > > >=20 > > > > When you say it must be saved as 'local state', do you mean=20 > > > > in the state > > > > memory of the compressor at B or not in a compartment at all? > > >=20 > > > Not in a compartment at all (in A). However, in B it is up to=20 > > > the endpoint if it saves in the state memory or not in the=20 > > > compartment. > > >=20 > > > > >=20 > > > > > > 5. (Little bit off-topic, PoC specific question):=20 > In the PoC=20 > > > > > > NEMS Signalling=20 > > > > > > Spec. "Signalling flows (UNI) v2.06", a procedure for=20 > > > > > > establishing a USD is=20 > > > > > > described. Among others it states that the four first=20 > > > > bytes of the=20 > > > > > > state-value should be "usd1". Can any helpful individual=20 > > > > > > explain to me what=20 > > > > > > the purpose might be? Should either local or remote=20 > > > > > endpoint take any=20 > > > > > > specific action here? > > > > > > The spec says: > > > > > > "For USD identification it is important that the identifier=20 > > > > > > string is placed=20 > > > > > > in the beginning of the state_value of the USD, therefore=20 > > > > > > special attention=20 > > > > > > must be paid in the case of large USD as the UDVM has a=20 > > > > > > circular buffer." > > > > > > I do not understand the purpose here.. > > > > >=20 > > > > > Suppose Endpoint 2 supports USD (without the optional=20 > > > > > requirement of moving it to the local state location) and the=20 > > > > > explicit acknowledgement specified in RFC 3321, too. If=20 > > > > > Endpoint 2 explicitlly acks the uploaded USD state ID,=20 > > > > > Endpoint 1 will think USD is moved to the local states=20 > > > > > location (indication is the same as if it was an explicit=20 > > > > > ack) and will not update (decrease) its remote available SMS.=20 > > > > > Later on it may result in decompression failure if a state is=20 > > > > > saved deleting another one in use, due to the remote=20 > > > > > available SMS out of synchron. > > > > >=20 > > > >=20 > > > > I'm a bit confused here: > > > >=20 > > > > By 'moving it to the local state location' I take it that you=20 > > > > mean that the > > > > state created at Endpoint 2's decompressor would be moved to=20 > > > > Endpoint 2's > > > > compressor. Is this correct? Would it be duplicated (i.e.=20 > > > > still exist in > > > > the decompressor) or actually moved (and therefore the=20 > > > > compressor at A has > > > > no control over or knowledge of when it is deleted)? > > > >=20 > > > It is not duplicated. I meant it was moved to the=20 > > > "non-compartment" state memory. It must be remembered somehow=20 > > > (implementation stuff) that the state actually belongs to a=20 > > > specific compartment, so when the compartment is deleted, the=20 > > > USD must also be deleted. > > >=20 > > > > Are you saying that the presence of the string "usd1" is an=20 > > > > indicator to > > > > endpoint 2 that it should move/copy the state into the=20 > compressor > > > > compartment? > > >=20 > > > Besides the state is saved and advertised at the same time.=20 > > > The reason why the usd tag was added is that this situation=20 > > > might easily happen with a well-known bytecode. > > >=20 > > > >=20 > > > > If so, this seems to be at odds with the SigComp conceptual=20 > > > > model of state > > > > that it is just 'some bytes'. =20 > > > >=20 > > >=20 > > > Why do you say that? 'usd1' is not something that appears at=20 > > > the beginning of a state, especially in a first message, and=20 > > > especially not in a bytecode. > > >=20 > > > > If my understanding above is correct, then the piece of state=20 > > > > presumably has > > > > minimum retention priority? Care must once again be taken=20 > > > due to the > > > > possibility that the creation of multiple pieces of minimum=20 > > > retention > > > > priority state can lead to loss of synchronisation between=20 > > > endpoints. > > > >=20 > > >=20 > > > USD is just one state, which is absolutely in line with the=20 > > > "one shared state at a time" concept. > > >=20 > > > > How does this mechanism interact with the use of shared mode=20 > > > > as defined in > > > > 3321? > > > >=20 > > >=20 > > > Nothing special, as the shared state is not saved as a state=20 > > > in B, only in A.=20 > > >=20 > > > > I also think there are some implications for=20 > > > interoperability between > > > > endpoints that do this and endpoints that don't. As you=20 > > > > showed in your > > > > example above, if there is disagreement between endpoints=20 > > > > about whether or > > > > not state is moved to 'local state location' (whatever that=20 > > > > is) it can lead > > > > to loss of synchronisation between endpoints. > > > >=20 > > > > Is this concept mandatory in PoC? If not, or if a non PoC=20 > > > > endpoint receives > > > > a state create request and an explicit advertisement, it will=20 > > > > not know that > > > > it should check the first 4 bytes for "usd1" and move=20 > the state so > > > > synchronisation will be lost as you explained. > > >=20 > > > As far as I know it is mandatory, but this I should check. > > >=20 > > > >=20 > > > > Best regards, > > > >=20 > > > > Abbie > > > >=20 > > > > --=20 > > > >=20 > > > > Visit our website at www.roke.co.uk > > > >=20 > > > > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire=20 > > SO51 0ZN, UK. > > > >=20 > > > > The information contained in this e-mail and any attachments=20 > > > > is proprietary to > > > > Roke Manor Research Ltd and must not be passed to any third=20 > > > > party without > > > > permission. This communication is for information only and=20 > > > > shall not create or > > > > change any contractual relationship. > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 12:06:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17093 for ; Fri, 15 Apr 2005 12:06:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTVQ-0005M1-Ns for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 12:17:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTFc-0004rO-4V; Fri, 15 Apr 2005 12:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTFa-0004qe-LC for rohc@megatron.ietf.org; Fri, 15 Apr 2005 12:00:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16206 for ; Fri, 15 Apr 2005 12:00:54 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTDI-0003nk-ER for rohc@ietf.org; Fri, 15 Apr 2005 11:58:37 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3FFlnQc014801; Fri, 15 Apr 2005 16:47:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Apr 2005 16:47:56 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A284F@rsys004a> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVBzqnzDIs9IixGQxCUAetb1li/HgAAMTrQ From: "Finking, Robert" To: "Kristofer Sandlund" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: quoted-printable Hi Kris, Again, thanks. I think the real issue here is the default methods! I can understand what you mean about the control_fields, but you have to ask yourself what that means formally. In order to be able to refer back to the previous header in the flow, you need to have context and that means you need to have an uncompressed part. I don't think there's an easy way to define whether you use the context or not. The FN just doesn't work like that. Therefore the FN draft merely requires that you declare a context i.e. an uncompressed side. Does that make sense? Raffles > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 > Sent: Friday, April 15, 2005 4:20 PM > To: Finking, Robert > Cc: rohc@ietf.org > Subject: Re: [rohc] FN: default_methods and control fields=20 > clarification/new usage >=20 >=20 > inline. >=20 > Finking, Robert wrote: > > Hi Kris, > >=20 > > Thanks for the response. I had a quick look at the formats before my > > post and there didn't seem to be a problem, since although=20 > they do use > > such definitions in default_methods, they never get=20 > overridden, or else > > they're overridden correctly. However I missed "sack_var_length_enc" > > when I was skimming through. You're right it needs fixing, but this > > needs fixing anyway, since there is currently no control=20 > fields list. To > > recap any field which does NOT appear in the uncompressed=20 > header, but > > that DOES have an uncompressed side, needs to be declared=20 > in a control > > fields list. >=20 > Disagree. See below. >=20 > > This is not a big deal though, it just means replacing the > > current "default_methods" line with "control_fields", so=20 > you end up with > > this: > >=20 > > control_fields =3D sack_offset %[ 32 ] > > { > > let (sack_offset:uncomp_value =3D=3D > > sack_field:uncomp_value - base); > > let (sack_offset:uncomp_length =3D=3D 32); > > let (sack_field:uncomp_length =3D=3D 32); > > }; > >=20 >=20 > Hmm... I think we again have some kind of disconnect=20 > regarding the control=20 > fields. As far as I remember, it was me and Ghyslain who=20 > pushed for the control=20 > fields, and our intention was that these should be "fields=20 > that are kept in=20 > context between packets", while our intention was not to have=20 > define control=20 > fields that are just using during the processing of a single=20 > packet. And this is=20 > what the WG decided in Washington, but maybe this got lost on=20 > the way to the=20 > draft. I get the feeling that you define control fields=20 > differently than that=20 > (again, I have not checked FN for some time, but I though it=20 > contained what we=20 > had decided earlier). > I think this is quite an important distinction that we should=20 > keep since it=20 > helps implementers a lot to know what is actual context that=20 > is used next time=20 > and which are just used for the "current packet". >=20 > If we use "my" definition, then we cannot define sack_offset=20 > as a control_field=20 > and we need another solution. >=20 > > Similarly with seq_number_scaled etc. in baseheaders - they need > > declaring in a control_fields list anyway. Hopefully it's a=20 > just a quick > > cut and paste? >=20 > These are already defined as control fields on the global=20 > level (see the start=20 > of the file). >=20 > >=20 > > Note this does NOT affect fields which have no uncompressed=20 > side at all, > > such as compressed side CRCs or the many flags which are used. >=20 > Agreed, but as I try to describe above, what _you_ call=20 > control_fields are in=20 > _my_ mind two different categories where only one can be=20 > defined as a control_field. >=20 > BR, > Kristofer >=20 > >=20 > > Thanks for keeping an eagle eye out =3D) > >=20 > > Raffles > >=20 > >>-----Original Message----- > >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 > >>Sent: Friday, April 15, 2005 3:55 PM > >>To: Finking, Robert > >>Cc: rohc@ietf.org > >>Subject: Re: [rohc] FN: default_methods and control fields=20 > >>clarification/new usage > >> > >> > >>Hi Robert, > >> > >>actually, this _does_ affect the current TCP packet formats (e.g.=20 > >>sack_var_length_enc and co_baseheader), since we have used a=20 > >>number of=20 > >>let-statements on control fields inside default_methods (at=20 > >>least I think these=20 > >>are identical cases to what you're describing). > >> > >>My understanding when I made the packet formats was that you=20 > >>always "executed"=20 > >>the default methods and then if new encoding for a field was=20 > >>present in the=20 > >>compressed formats, you "overwrote" the default_methods=20 > >>encoding. But obviously,=20 > >>this is not what you meant (but I haven't read the actual=20 > >>text in the FN for a=20 > >>long time). > >>I think the change you propose looks reasonable, but I'm not=20 > >>yet sure how this=20 > >>will work for the TCP packet formats, so I'd have to think=20 > >>this though a bit=20 > >>more. Could you check the tcp packet formats and see how your=20 > >>change maps to the=20 > >>current formats (the examples I listed above)? > >> > >>BR, > >> Kristofer Sandlund, Effnet AB > >> > >> > >> > >>Finking, Robert wrote: > >> > >>>All, > >>> > >>>Whilst doing the latest lot of updates, I've found an error=20 > >> > >>in the current FN draft. It is to do with the way=20 > >>default_methods are used. To recap, default_methods are=20 > >>referred to if and only if there is no encoding given for a=20 > >>field in a packet format. If an encoding is given for that=20 > >>field then there is no need to refer to the default: it is=20 > >>just a fall back to use when no other encoding is specified. > >> > >>>In the Appendix B (which I'm currently editing) we have the=20 > >> > >>following in an example: > >> > >>> control_fields =3D scaled_seq_no; > >>> > >>> default_methods =3D > >>> { > >>> version_no ::=3D uncompressed_value(2,1); > >>> type ::=3D irregular(2); > >>> flow_id ::=3D static; > >>> reserved_flag ::=3D uncompressed_value(1,0); > >>> > >>> % need modulo maths to calculate scaling correctly, > >>> % due to 4 bit wrap around > >>> let(scaled_seq_no:uncomp_value > >>> =3D=3D ((mod(15 - sequence_no:uncomp_value, 3) * 16 > >>> + sequence_no:uncomp_value) / 3)); > >>> scaled_seq_no ::=3D lsb(1,-1); > >>> }; > >>> > >>>The problem here is that the default_methods specifies not=20 > >> > >>only the *default* encoding for the field (lsb), but also the=20 > >>binding for the uncompressed value of the field. The default=20 > >>encoding isn't referred to when a packet format specifies an=20 > >>encoding of its own - that fine. The binding for the=20 > >>uncompressed value however should ALWAYS be referred to,=20 > >>since this is what gives the control field its value. Since=20 > >>this binding is in default_methods, it will not always be=20 > >>referred to =3D( > >> > >>>The way the FN draft is currently written, the solution to=20 > >> > >>this problem is to move the essential bit of code (the "let"=20 > >>statement) into the uc_format encodings list. However, this=20 > >>is not a cure-all since sometimes there will be multiple uc_formats. > >> > >>>The intuitive solution is to put the binding for the=20 > >> > >>uncompressed value of the control field under the=20 > >>control_fields list. Apart from clarifying an issue which is=20 > >>currently not nailed down in the draft (whether or not a=20 > >>field encodings list can be specified for control_fields), it=20 > >>actually reads really nicely: > >> > >>> control_fields =3D scaled_seq_no %[ 4 ] > >>> { > >>> % need modulo maths to calculate scaling correctly, > >>> % due to 4 bit wrap around > >>> let(scaled_seq_no:uncomp_value > >>> =3D=3D ((mod(15 - sequence_no:uncomp_value, 3) * 16 > >>> + sequence_no:uncomp_value) / 3)); > >>> }; > >>> > >>> default_methods =3D > >>> { > >>> version_no ::=3D uncompressed_value(2,1); > >>> type ::=3D irregular(2); > >>> flow_id ::=3D static; > >>> reserved_flag ::=3D uncompressed_value(1,0); > >>> scaled_seq_no ::=3D lsb(1,-1); > >>> }; > >>> > >>>As an aside, since this is really just a clarification it=20 > >> > >>shouldn't affect the current packet formats as far as I can see. > >> > >>>I thought I'd better post this in case there were any=20 > >> > >>objections - it strikes me this could be viewed as more than=20 > >>just an editing issue! > >> > >>>Regards > >>> > >>>Raffles > >>> > >>>_______________________________________________ > >>>Rohc mailing list > >>>Rohc@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/rohc > >> >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 15 14:41:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00352 for ; Fri, 15 Apr 2005 14:41:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVvT-0005xg-FL for rohc-web-archive@ietf.org; Fri, 15 Apr 2005 14:52:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVZv-0005Vs-Ds; Fri, 15 Apr 2005 14:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVZt-0005UR-Cu; Fri, 15 Apr 2005 14:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29201; Fri, 15 Apr 2005 14:30:03 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVk8-0005DQ-BA; Fri, 15 Apr 2005 14:40:40 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3FISw604702; Fri, 15 Apr 2005 11:28:58 -0700 (PDT) Message-Id: <200504151828.j3FISw604702@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Apr 2005 11:28:58 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: rohc@ietf.org, rfc-editor@rfc-editor.org Subject: [rohc] RFC 4019 on RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4019 Title: RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite Author: G. Pelletier Date: April 2005 Mailbox: ghyslain.pelletier@ericsson.com Pages: 23 Characters: 46896 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-udp-lite-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4019.txt This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. This document is a product of the Robust Header Compression Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050415112522.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4019 --OtherAccess Content-Type: Message/External-body; name="rfc4019.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050415112522.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Mon Apr 18 04:09:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25162 for ; Mon, 18 Apr 2005 04:09:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNRUM-0002rC-Ss for rohc-archive@ietf.org; Mon, 18 Apr 2005 04:20:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNRJX-0007RO-Dd; Mon, 18 Apr 2005 04:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNRJU-0007NP-Ay for rohc@megatron.ietf.org; Mon, 18 Apr 2005 04:09:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25155 for ; Mon, 18 Apr 2005 04:08:58 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNRUF-0002lr-7C for rohc@ietf.org; Mon, 18 Apr 2005 04:20:08 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3I783mg006785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Apr 2005 09:08:09 +0200 Message-ID: <42636B04.3060506@effnet.com> Date: Mon, 18 Apr 2005 10:08:36 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A284F@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A284F@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Content-Transfer-Encoding: 7bit Hi Robert, comments inline. Finking, Robert wrote: > Hi Kris, > > Again, thanks. I think the real issue here is the default methods! I can > understand what you mean about the control_fields, but you have to ask > yourself what that means formally. In order to be able to refer back to > the previous header in the flow, you need to have context and that means > you need to have an uncompressed part. I disagree. If we take the example with sack_offset, that field does not refer to any field in a previous header, it is just a field calculated from another field in the same header. It has an uncompressed side, but clearly, it does not have context. Therefore, this field cannot be a control_field as per how the WG discussed them in Washington (and I haven't seen any discussion that we have updated that decision). With your proposal, this would have to be defined as a control field. Btw, the minutes from the meeting is not really clear on which interpretation to use, so I can understand if you interpreted it differently. > > I don't think there's an easy way to define whether you use the context > or not. The FN just doesn't work like that. Therefore the FN draft > merely requires that you declare a context i.e. an uncompressed side. I think it seems quite easy to define that, if you take the current text: The control fields list specifies all fields that do not appear in the uncompressed header but which have an uncompressed value (specifically those with a non-zero uncomp_length). and add something like: and the value of the field is persistent between packets (i.e. have context). After all, the only thing such a definition does is to narrow down where the profile creator is allowed to define control fields and not. You do not have to define what "have context" means, right? If we don't add that kind of text, this is something that is going to cause both possible profile writers and even more profile users to start asking question regarding which fields are to be stored in context and I'd like to avoid having to have a "FN user's guide". > > Does that make sense? Unfortunately, no :) BR, Kristofer Sandlund, Effnet AB > > Raffles > > >>-----Original Message----- >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>Sent: Friday, April 15, 2005 4:20 PM >>To: Finking, Robert >>Cc: rohc@ietf.org >>Subject: Re: [rohc] FN: default_methods and control fields >>clarification/new usage >> >> >>inline. >> >>Finking, Robert wrote: >> >>>Hi Kris, >>> >>>Thanks for the response. I had a quick look at the formats before my >>>post and there didn't seem to be a problem, since although >> >>they do use >> >>>such definitions in default_methods, they never get >> >>overridden, or else >> >>>they're overridden correctly. However I missed "sack_var_length_enc" >>>when I was skimming through. You're right it needs fixing, but this >>>needs fixing anyway, since there is currently no control >> >>fields list. To >> >>>recap any field which does NOT appear in the uncompressed >> >>header, but >> >>>that DOES have an uncompressed side, needs to be declared >> >>in a control >> >>>fields list. >> >>Disagree. See below. >> >> >>>This is not a big deal though, it just means replacing the >>>current "default_methods" line with "control_fields", so >> >>you end up with >> >>>this: >>> >>> control_fields = sack_offset %[ 32 ] >>> { >>> let (sack_offset:uncomp_value == >>> sack_field:uncomp_value - base); >>> let (sack_offset:uncomp_length == 32); >>> let (sack_field:uncomp_length == 32); >>> }; >>> >> >>Hmm... I think we again have some kind of disconnect >>regarding the control >>fields. As far as I remember, it was me and Ghyslain who >>pushed for the control >>fields, and our intention was that these should be "fields >>that are kept in >>context between packets", while our intention was not to have >>define control >>fields that are just using during the processing of a single >>packet. And this is >>what the WG decided in Washington, but maybe this got lost on >>the way to the >>draft. I get the feeling that you define control fields >>differently than that >>(again, I have not checked FN for some time, but I though it >>contained what we >>had decided earlier). >>I think this is quite an important distinction that we should >>keep since it >>helps implementers a lot to know what is actual context that >>is used next time >>and which are just used for the "current packet". >> >>If we use "my" definition, then we cannot define sack_offset >>as a control_field >>and we need another solution. >> >> >>>Similarly with seq_number_scaled etc. in baseheaders - they need >>>declaring in a control_fields list anyway. Hopefully it's a >> >>just a quick >> >>>cut and paste? >> >>These are already defined as control fields on the global >>level (see the start >>of the file). >> >> >>>Note this does NOT affect fields which have no uncompressed >> >>side at all, >> >>>such as compressed side CRCs or the many flags which are used. >> >>Agreed, but as I try to describe above, what _you_ call >>control_fields are in >>_my_ mind two different categories where only one can be >>defined as a control_field. >> >>BR, >> Kristofer >> >> >>>Thanks for keeping an eagle eye out =) >>> >>>Raffles >>> >>> >>>>-----Original Message----- >>>>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>>>Sent: Friday, April 15, 2005 3:55 PM >>>>To: Finking, Robert >>>>Cc: rohc@ietf.org >>>>Subject: Re: [rohc] FN: default_methods and control fields >>>>clarification/new usage >>>> >>>> >>>>Hi Robert, >>>> >>>>actually, this _does_ affect the current TCP packet formats (e.g. >>>>sack_var_length_enc and co_baseheader), since we have used a >>>>number of >>>>let-statements on control fields inside default_methods (at >>>>least I think these >>>>are identical cases to what you're describing). >>>> >>>>My understanding when I made the packet formats was that you >>>>always "executed" >>>>the default methods and then if new encoding for a field was >>>>present in the >>>>compressed formats, you "overwrote" the default_methods >>>>encoding. But obviously, >>>>this is not what you meant (but I haven't read the actual >>>>text in the FN for a >>>>long time). >>>>I think the change you propose looks reasonable, but I'm not >>>>yet sure how this >>>>will work for the TCP packet formats, so I'd have to think >>>>this though a bit >>>>more. Could you check the tcp packet formats and see how your >>>>change maps to the >>>>current formats (the examples I listed above)? >>>> >>>>BR, >>>> Kristofer Sandlund, Effnet AB >>>> >>>> >>>> >>>>Finking, Robert wrote: >>>> >>>> >>>>>All, >>>>> >>>>>Whilst doing the latest lot of updates, I've found an error >>>> >>>>in the current FN draft. It is to do with the way >>>>default_methods are used. To recap, default_methods are >>>>referred to if and only if there is no encoding given for a >>>>field in a packet format. If an encoding is given for that >>>>field then there is no need to refer to the default: it is >>>>just a fall back to use when no other encoding is specified. >>>> >>>> >>>>>In the Appendix B (which I'm currently editing) we have the >>>> >>>>following in an example: >>>> >>>> >>>>> control_fields = scaled_seq_no; >>>>> >>>>> default_methods = >>>>> { >>>>> version_no ::= uncompressed_value(2,1); >>>>> type ::= irregular(2); >>>>> flow_id ::= static; >>>>> reserved_flag ::= uncompressed_value(1,0); >>>>> >>>>> % need modulo maths to calculate scaling correctly, >>>>> % due to 4 bit wrap around >>>>> let(scaled_seq_no:uncomp_value >>>>> == ((mod(15 - sequence_no:uncomp_value, 3) * 16 >>>>> + sequence_no:uncomp_value) / 3)); >>>>> scaled_seq_no ::= lsb(1,-1); >>>>> }; >>>>> >>>>>The problem here is that the default_methods specifies not >>>> >>>>only the *default* encoding for the field (lsb), but also the >>>>binding for the uncompressed value of the field. The default >>>>encoding isn't referred to when a packet format specifies an >>>>encoding of its own - that fine. The binding for the >>>>uncompressed value however should ALWAYS be referred to, >>>>since this is what gives the control field its value. Since >>>>this binding is in default_methods, it will not always be >>>>referred to =( >>>> >>>> >>>>>The way the FN draft is currently written, the solution to >>>> >>>>this problem is to move the essential bit of code (the "let" >>>>statement) into the uc_format encodings list. However, this >>>>is not a cure-all since sometimes there will be multiple uc_formats. >>>> >>>> >>>>>The intuitive solution is to put the binding for the >>>> >>>>uncompressed value of the control field under the >>>>control_fields list. Apart from clarifying an issue which is >>>>currently not nailed down in the draft (whether or not a >>>>field encodings list can be specified for control_fields), it >>>>actually reads really nicely: >>>> >>>> >>>>> control_fields = scaled_seq_no %[ 4 ] >>>>> { >>>>> % need modulo maths to calculate scaling correctly, >>>>> % due to 4 bit wrap around >>>>> let(scaled_seq_no:uncomp_value >>>>> == ((mod(15 - sequence_no:uncomp_value, 3) * 16 >>>>> + sequence_no:uncomp_value) / 3)); >>>>> }; >>>>> >>>>> default_methods = >>>>> { >>>>> version_no ::= uncompressed_value(2,1); >>>>> type ::= irregular(2); >>>>> flow_id ::= static; >>>>> reserved_flag ::= uncompressed_value(1,0); >>>>> scaled_seq_no ::= lsb(1,-1); >>>>> }; >>>>> >>>>>As an aside, since this is really just a clarification it >>>> >>>>shouldn't affect the current packet formats as far as I can see. >>>> >>>> >>>>>I thought I'd better post this in case there were any >>>> >>>>objections - it strikes me this could be viewed as more than >>>>just an editing issue! >>>> >>>> >>>>>Regards >>>>> >>>>>Raffles >>>>> >>>>>_______________________________________________ >>>>>Rohc mailing list >>>>>Rohc@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/rohc >>>> > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 05:09:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29106 for ; Mon, 18 Apr 2005 05:09:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNSRC-0006L9-Ac for rohc-archive@ietf.org; Mon, 18 Apr 2005 05:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSGG-0004u3-PA; Mon, 18 Apr 2005 05:09:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSGD-0004tu-D2 for rohc@megatron.ietf.org; Mon, 18 Apr 2005 05:09:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29076 for ; Mon, 18 Apr 2005 05:09:39 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNSQy-0006Kb-Up for rohc@ietf.org; Mon, 18 Apr 2005 05:20:50 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3I99PQc017317; Mon, 18 Apr 2005 10:09:25 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <26RQ8N3Y>; Mon, 18 Apr 2005 10:09:49 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2859@rsys004a> From: "Finking, Robert" To: "'Carsten Bormann'" , rohc@ietf.org Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Mon, 18 Apr 2005 10:09:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > > let statements binding certain attributes > > How do you know that? > > What does > > let(a:uncomp_value == b:uncomp_value) > > bind? I think Eilert asked this very question during the original discussion =) It binds both a:uncomp_value and b:uncomp_value (to each other). _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 05:27:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00169 for ; Mon, 18 Apr 2005 05:27:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNSiI-0007Hs-Bp for rohc-archive@ietf.org; Mon, 18 Apr 2005 05:38:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSW9-00069U-Ch; Mon, 18 Apr 2005 05:26:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSW6-00069M-7R for rohc@megatron.ietf.org; Mon, 18 Apr 2005 05:26:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00083 for ; Mon, 18 Apr 2005 05:26:04 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNSgr-0007FR-CA for rohc@ietf.org; Mon, 18 Apr 2005 05:37:15 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3I9PgQc022857; Mon, 18 Apr 2005 10:25:42 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <26RQ8NP8>; Mon, 18 Apr 2005 10:26:06 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A285A@rsys004a> From: "Finking, Robert" To: "'Kristofer Sandlund'" Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Mon, 18 Apr 2005 10:25:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi Kris, I think I'll hang back on this whilst we re-thrash-out the default methods thing - the two issues are related and I don't want to presuppose the outcome of the default methods. However, it's probably worth pointing out that: > Therefore, this field cannot be a control_field as per how > the WG discussed them > in Washington (and I haven't seen any discussion that we have > updated that > decision). With your proposal, this would have to be defined > as a control field. > Btw, the minutes from the meeting is not really clear on > which interpretation > to use, so I can understand if you interpreted it differently. Although you may not have seen the discussion, we did have one! It was really aimed at clarifying what was decided I think - that is how we ended up with what is in the document. In fact the text in the control fields section has been discussed a couple of times and IIRC has been updated for clarity after review comments, so it's not like nobody's been reading it. > I think it seems quite easy to define that, if you take the > current text: > > The control fields list specifies all fields that do not > appear in the > uncompressed header but which have an uncompressed value > (specifically those with a non-zero uncomp_length). > > and add something like: > and the value of the field is persistent between packets > (i.e. have context). > Yes, it's easy to "say", but my concern is what it *means*. This is about 3095 compatibility. What does "control field" mean in 3095? Can't 3095 control fields have context? Are we about to break something? I'm no 3095 expert as you know, so help me out here =) Anyway, probably best to hold fire on this (except maybe to clarify the 3095 side of things) till we've sorted out the default_methods discussion. Thanks for your input - much appreciated Regards Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 05:57:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01954 for ; Mon, 18 Apr 2005 05:57:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNTAv-00018D-Vo for rohc-archive@ietf.org; Mon, 18 Apr 2005 06:08:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSqV-0000kk-3C; Mon, 18 Apr 2005 05:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSqT-0000kf-5H for rohc@megatron.ietf.org; Mon, 18 Apr 2005 05:47:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01476 for ; Mon, 18 Apr 2005 05:47:07 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNT1D-0000Of-TJ for rohc@ietf.org; Mon, 18 Apr 2005 05:58:18 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3I8kJmg007155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Apr 2005 10:46:20 +0200 Message-ID: <4263820E.9040300@effnet.com> Date: Mon, 18 Apr 2005 11:46:54 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN: default_methods and control fields clarification/n ew usage References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A285A@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A285A@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Hi! comments inline. Finking, Robert wrote: > Hi Kris, > > I think I'll hang back on this whilst we re-thrash-out the default methods thing - the two issues are related and I don't want to presuppose the outcome of the default methods. However, it's probably worth pointing out that: > > >>Therefore, this field cannot be a control_field as per how >>the WG discussed them >>in Washington (and I haven't seen any discussion that we have >>updated that >>decision). With your proposal, this would have to be defined >>as a control field. >> Btw, the minutes from the meeting is not really clear on >>which interpretation >>to use, so I can understand if you interpreted it differently. > > > Although you may not have seen the discussion, we did have one! It was really aimed at clarifying what was decided I think - that is how we ended up with what is in the document. In fact the text in the control fields section has been discussed a couple of times and IIRC has been updated for clarity after review comments, so it's not like nobody's been reading it. Ok, so you're saying that you have explicitly changed this, I thought that the "wrong" text had just gotten in there. My bad, I did not mean to sound like I was accusing you. Then I wonder what's the point of control fields. All they do then is help with scoping, and I thought the important point was to separate what is persistent or not... > > >>I think it seems quite easy to define that, if you take the >>current text: >> >> The control fields list specifies all fields that do not >>appear in the >> uncompressed header but which have an uncompressed value >> (specifically those with a non-zero uncomp_length). >> >>and add something like: >> and the value of the field is persistent between packets >>(i.e. have context). >> > > > Yes, it's easy to "say", but my concern is what it *means*. This is about 3095 compatibility. What does "control field" mean in 3095? Can't 3095 control fields have context? Are we about to break something? I'm no 3095 expert as you know, so help me out here =) Well, if it is normative text in an RFC, it really *means* what it *says* :) > > Anyway, probably best to hold fire on this (except maybe to clarify the 3095 side of things) till we've sorted out the default_methods discussion. > Nope, there is no concept of control fields in 3095, that's a term we came up with so that we could point out what was to be in context. In 3095, the fields that are "context-persistent" are not very well defined in the normative parts themselves (for example, search for RND and see where that flag is actually defined), but there's a list of what the context should look like in 6.3. I'd like us to do a bit better than that. /Kristofer > Thanks for your input - much appreciated > > Regards > > Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 06:04:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02537 for ; Mon, 18 Apr 2005 06:04:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNTIO-0001dR-07 for rohc-archive@ietf.org; Mon, 18 Apr 2005 06:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSyR-00013F-94; Mon, 18 Apr 2005 05:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNSyG-00012u-L4 for rohc@megatron.ietf.org; Mon, 18 Apr 2005 05:55:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01796 for ; Mon, 18 Apr 2005 05:55:10 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNT92-00011K-Ek for rohc@ietf.org; Mon, 18 Apr 2005 06:06:22 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3I9t5OK007598; Mon, 18 Apr 2005 11:55:09 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 11:53:44 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 11:54:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage Date: Mon, 18 Apr 2005 11:54:23 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27EB@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVD+QoyodSsN6ALSwCoGAf0SzSJjAAAK1jQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Finking, Robert" , "Kristofer Sandlund" X-OriginalArrivalTime: 18 Apr 2005 09:54:04.0162 (UTC) FILETIME=[8DE93E20:01C543FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable > Yes, it's easy to "say", but my concern is what it *means*.=20 > This is about 3095 compatibility. What does "control field"=20 > mean in 3095? Can't 3095 control fields have context? Are we=20 > about to break something? I'm no 3095 expert as you know, so=20 > help me out here =3D) The only compatibility with 3095 we have to care about is=20 defined by profile specifications, which have to make sure there are no packet type collisions, i.e. that profile common packet formats are properly defined. There are also concerns related to feedback handling and other "framework issues",=20 but they are all part of the profile specification. The FN is only about how to define formats, not about what to put in them, so I see no 3095 compatibility issues with the FN. When it comes to the term "control field", it does not even exist in RFC 3095. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 07:09:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07453 for ; Mon, 18 Apr 2005 07:09:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNUJK-0005hZ-Uv for rohc-archive@ietf.org; Mon, 18 Apr 2005 07:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNTta-0007Jd-3V; Mon, 18 Apr 2005 06:54:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNTtX-0007JY-GQ for rohc@megatron.ietf.org; Mon, 18 Apr 2005 06:54:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06658 for ; Mon, 18 Apr 2005 06:54:20 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNU4I-0004l3-Se for rohc@ietf.org; Mon, 18 Apr 2005 07:05:33 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3IAs5Qc014825; Mon, 18 Apr 2005 11:54:05 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 18 Apr 2005 11:54:29 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A285D@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , Kristofer Sandlund Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Mon, 18 Apr 2005 11:53:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab In a shocking reversal of his previous statement: "I think I'll hang back on this", FN editor "Raffles" said, "well in that case let's sort this whole thing out right now". Seriously, I had somehow completely missed the original intent - probably absence from the meeting didn't help ;-) Since there are no 3095 implications, let's go ahead and clarify exactly what was originally intended and the motivations behind it. I'll state my personal concerns and we can thrash it out properly to reduce the chance of revisiting this again! * The intent was to mark out fields which are not part of the uncompressed header and which use context information (that's my interpretation of "to separate what is persistent or not...") * The motivation for this is presumably that it is very useful to the implementer to know if a field needs context? (Otherwise they have to infer this from all the different encoding methods used for the field in all the different packet formats?) * We also adopted control fields as a scoping mechanism to allow one part of a profile to "communicate" with another, without having to pass structure parameters across layers of the protocol stack (messy). * "Control field" had previously meant *any* field which does not appear in the uncompressed header (I think this is where my misunderstanding came from) * It is not just "control fields" (see definition in previous bullet) which may have no need for context, but there are also fields in the uncompressed header which similarly have no need for context * Knowing which fields need context is very useful for the implementer, so given the above points, why not have some syntax which indicates explicitly for all fields whether or not they need context/don't need context? Regards Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Monday, April 18, 2005 10:54 AM > To: Finking, Robert; Kristofer Sandlund > Cc: rohc@ietf.org > Subject: RE: [rohc] FN: default_methods and control fields > clarification/new usage > > > > Yes, it's easy to "say", but my concern is what it *means*. > > This is about 3095 compatibility. What does "control field" > > mean in 3095? Can't 3095 control fields have context? Are we > > about to break something? I'm no 3095 expert as you know, so > > help me out here =) > > The only compatibility with 3095 we have to care about is > defined by profile specifications, which have to make sure > there are no packet type collisions, i.e. that profile common > packet formats are properly defined. There are also concerns > related to feedback handling and other "framework issues", > but they are all part of the profile specification. > > The FN is only about how to define formats, not about what to > put in them, so I see no 3095 compatibility issues with the FN. > > When it comes to the term "control field", it does not even > exist in RFC 3095. > > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 08:10:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12729 for ; Mon, 18 Apr 2005 08:10:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNVFe-0001cg-IP for rohc-archive@ietf.org; Mon, 18 Apr 2005 08:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNV4e-0005kT-TB; Mon, 18 Apr 2005 08:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNV4d-0005it-CY for rohc@megatron.ietf.org; Mon, 18 Apr 2005 08:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12696 for ; Mon, 18 Apr 2005 08:09:54 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNVFQ-0001bl-V9 for rohc@ietf.org; Mon, 18 Apr 2005 08:21:05 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3IB91mg007634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Apr 2005 13:09:02 +0200 Message-ID: <4263A382.8030207@effnet.com> Date: Mon, 18 Apr 2005 14:09:38 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN: default_methods and control fields clarification/n ew usage References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A285D@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A285D@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Hi Robert, thanks for trying to clear this up. Comments inline. Finking, Robert wrote: > In a shocking reversal of his previous statement: "I think I'll hang back on this", FN editor "Raffles" said, "well in that case let's sort this whole thing out right now". > > Seriously, I had somehow completely missed the original intent - probably absence from the meeting didn't help ;-) Since there are no 3095 implications, let's go ahead and clarify exactly what was originally intended and the motivations behind it. I'll state my personal concerns and we can thrash it out properly to reduce the chance of revisiting this again! > > * The intent was to mark out fields which are not part of the uncompressed header and which use context information (that's my interpretation of "to separate what is persistent or not...") agreed > > * The motivation for this is presumably that it is very useful to the implementer to know if a field needs context? (Otherwise they have to infer this from all the different encoding methods used for the field in all the different packet formats?) Yep. > > * We also adopted control fields as a scoping mechanism to allow one part of a profile to "communicate" with another, without having to pass structure parameters across layers of the protocol stack (messy). Agreed. > > * "Control field" had previously meant *any* field which does not appear in the uncompressed header (I think this is where my misunderstanding came from) > > * It is not just "control fields" (see definition in previous bullet) which may have no need for context, but there are also fields in the uncompressed header which similarly have no need for context Not sure exactly what you mean here. I'd say that "inferred" and fields that are always transmitted "in full" for all packet types would fall into this category (TCP checksum, PSH bit and possibly something else in ROHC-TCP). Or do you mean something else here? > > * Knowing which fields need context is very useful for the implementer, so given the above points, why not have some syntax which indicates explicitly for all fields whether or not they need context/don't need context? > That's a possible solution, but maybe a bit overkill depending on what it would look like. Do you have some suggestion of how to accomplish this that you could show before I say if I think it's a good idea or not? I think that if we define control_fields in text as I suggested earlier, it might be sufficient, but maybe it needs to be made more formal like you said? BR, Kristofer Sandlund, Effnet AB > > Regards > > Raffles > > > > >>-----Original Message----- >>From: Lars-Erik Jonsson (LU/EAB) >>[mailto:lars-erik.jonsson@ericsson.com] >>Sent: Monday, April 18, 2005 10:54 AM >>To: Finking, Robert; Kristofer Sandlund >>Cc: rohc@ietf.org >>Subject: RE: [rohc] FN: default_methods and control fields >>clarification/new usage >> >> >> >>>Yes, it's easy to "say", but my concern is what it *means*. >>>This is about 3095 compatibility. What does "control field" >>>mean in 3095? Can't 3095 control fields have context? Are we >>>about to break something? I'm no 3095 expert as you know, so >>>help me out here =) >> >>The only compatibility with 3095 we have to care about is >>defined by profile specifications, which have to make sure >>there are no packet type collisions, i.e. that profile common >>packet formats are properly defined. There are also concerns >>related to feedback handling and other "framework issues", >>but they are all part of the profile specification. >> >>The FN is only about how to define formats, not about what to >>put in them, so I see no 3095 compatibility issues with the FN. >> >>When it comes to the term "control field", it does not even >>exist in RFC 3095. >> >>/L-E >> > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 09:23:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17669 for ; Mon, 18 Apr 2005 09:23:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNWP2-0005ih-9D for rohc-archive@ietf.org; Mon, 18 Apr 2005 09:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNW8u-0004WL-HJ; Mon, 18 Apr 2005 09:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNW8s-0004WG-0e for rohc@megatron.ietf.org; Mon, 18 Apr 2005 09:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17385 for ; Mon, 18 Apr 2005 09:18:20 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNWJe-0005Yi-HX for rohc@ietf.org; Mon, 18 Apr 2005 09:29:33 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3IDHwhW014446 for ; Mon, 18 Apr 2005 15:18:18 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:18:12 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:18:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2005 15:18:17 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27F1@esealmw109.eemea.ericsson.se> Thread-Topic: FW: What to do with "draft-ietf-rohc-tcp-field-behavior-04.txt"? Thread-Index: AcVEFPJ6ih+5yST0Qyi7sD6pXSM39QAAKmagAACtPQA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 18 Apr 2005 13:18:12.0626 (UTC) FILETIME=[12908720:01C54419] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Subject: [rohc] FW: Change proposal for "draft-ietf-rohc-tcp-field-behavior-04.txt"? X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable ROHC-TCP folks, As a response to some review comments from tcpm individuals, the following change proposal will be sent along with the document, when put in front of the IESG. Rgds, /Lars-Erik -----Original Message----- From: Lars-Erik Jonsson (LU/EAB)=20 Sent: den 18 april 2005 15:10 To: 'Allison Mankin' Subject: Change proposal for "draft-ietf-rohc-tcp-field-behavior-04.txt"?=20 CHANGE #1: Section 2.1.1, IPv6 "Next Header" OLD: =20 This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header. Only when extension headers are sometimes present and sometimes not, will the field change its value during the lifetime of the stream. The field is therefore classified as STATIC. The classification of STATIC is inherited from RFC 3095 [36]. However, it should be pointed out that the next header field is actually determined by the type of the following header. Thus, it might be more appropriate to view this as an inference, although this depends upon the specific implementation of the compression scheme. NEW: =20 This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header. Only when extension headers are sometimes present and sometimes not, will the field change its value during the lifetime of the > stream. Whether or not such a change would cause the sequence > of packets to be treated as a new flow (for header compression) > is an issue for profile design. ROHC profiles must be able to > cope with extension headers and tunnelling, but the choice of > strategy is outside the scope of this document. The field is > therefore classified as STATIC, as in RFC 3095 [36]. However, it should be pointed out that the next header field is actually determined by the type of the following header. Thus, it might be more appropriate to view this as an inference, although this depends upon the specific implementation of the compression scheme. CHANGE #2: Section 2.1.1, IPv6 "Version" OLD: =20 The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC. NEW: =20 > The version field states which IP version is used, and packets > with different values in this field must be handled as different > flows. Accordingly, the field is classified as STATIC-DEF. =20 CHANGE #3: Section 2.1.2, IPv4 "Version" OLD: =20 The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC. NEW: =20 > The version field states which IP version is used, and packets > with different values in this field must be handled as different > flows. Accordingly, the field is classified as STATIC-DEF. =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 10:02:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21148 for ; Mon, 18 Apr 2005 10:02:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNX0N-0008JR-Ps for rohc-archive@ietf.org; Mon, 18 Apr 2005 10:13:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWe7-0007ti-49; Mon, 18 Apr 2005 09:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWe4-0007td-Ae for rohc@megatron.ietf.org; Mon, 18 Apr 2005 09:50:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20097 for ; Mon, 18 Apr 2005 09:50:34 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNWor-0007bn-VG for rohc@ietf.org; Mon, 18 Apr 2005 10:01:47 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3IDnrQc029259; Mon, 18 Apr 2005 14:49:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 18 Apr 2005 14:50:10 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2867@rsys004a> Thread-Topic: [rohc] FN: default_methods and control fields clarification/n ew usage Thread-Index: AcVED6K4XUMdku4TSsOkVlmxyxmFaAACHnIg From: "Finking, Robert" To: "Kristofer Sandlund" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Hi Kris, > thanks for trying to clear this up. Thanks for helping =3D) > >=20 > > * "Control field" had previously meant *any* field which=20 > does not appear in the uncompressed header (I think this is=20 > where my misunderstanding came from) > >=20 > > * It is not just "control fields" (see definition in=20 > previous bullet) which may have no need for context, but=20 > there are also fields in the uncompressed header which=20 > similarly have no need for context >=20 > Not sure exactly what you mean here. I'd say that "inferred"=20 > and fields that are=20 > always transmitted "in full" for all packet types would fall=20 > into this category=20 > (TCP checksum, PSH bit and possibly something else in=20 > ROHC-TCP). Or do you mean=20 > something else here? Yes, if you look at the old versions of the draft (i.e. before I even came on the scene), you'll see things like this: "control fields, i.e. fields which appear in the compressed header to control the compression in some way and do not appear in the uncompressed header at all". However there's no reason not to cater for such inferred fields separately from control fields - in fact those early versions of the draft had a concept of "inferred" encoding methods in them. Here are my current thoughts: * It seems like a useful thing to be able to indicate the need for context, but I don't understand why we are only interested in doing it for fields which don't appear in the uncompressed header. Is there some motivation that I'm missing? What problem are we solving here that doesn't need solving for fields which reside in the uncompressed header? * It strikes me that there are quite a few different types of field, (e.g. "inferred" fields), which we are currently not being explicit about, either in the FN or in the TCP draft. The notation (and hence the TCP draft) would be easier to read if we were explicit about these things. At present we are disguising them as other things, which is confusing (to me at least). To bring this discussion full circle one such example is a non-default statement appearing in a default list. >=20 > >=20 > > * Knowing which fields need context is very useful for the=20 > implementer, so given the above points, why not have some=20 > syntax which indicates explicitly for all fields whether or=20 > not they need context/don't need context? > >=20 >=20 > That's a possible solution, but maybe a bit overkill=20 > depending on what it would=20 > look like. Do you have some suggestion of how to accomplish=20 > this that you could=20 > show before I say if I think it's a good idea or not? > I think that if we define control_fields in text as I=20 > suggested earlier, it=20 > might be sufficient, but maybe it needs to be made more=20 > formal like you said? OK, I'll get my thinking cap on about some example syntax while you all have a think about my bullets =3D) Cheers Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 18 11:31:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29501 for ; Mon, 18 Apr 2005 11:31:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNYOv-0006MX-7H for rohc-archive@ietf.org; Mon, 18 Apr 2005 11:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNY8n-0001QR-12; Mon, 18 Apr 2005 11:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNY8k-0001QJ-PJ for rohc@megatron.ietf.org; Mon, 18 Apr 2005 11:26:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29051 for ; Mon, 18 Apr 2005 11:26:20 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNYJa-0005s3-6E for rohc@ietf.org; Mon, 18 Apr 2005 11:37:34 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3IFQ7Qc021518 for ; Mon, 18 Apr 2005 16:26:07 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 18 Apr 2005 16:26:31 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A286B@rsys004a> From: "Finking, Robert" To: rohc@ietf.org Date: Mon, 18 Apr 2005 16:26:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [rohc] FN new syntax example X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Hi All, Here's my first stab at an alternative syntax as requested by Kris. First, here are all the categories of encoding I could think of: "uc_format" : bindings which are associated directly with a particular uncompressed format, but could apply to any co_format. "co_format" : bindings which are associated directly with a particular compressed format, but could apply to any uc_format. "invariant" : bindings which always apply across all formats. You only need to specify these if you have multiple uncompressed formats as is the case with IP in the tcp-pf for example - otherwise you can specify these bindings under the sole "uc_format". "inferred" : bindings for fields/attributes which are calculated entirely from other fields "co_only" : bindings for fields which are only present in the compressed header, such as CRCs on the compressed packet. These fields have no notion of having a "compressed" and "uncompressed" value - they only have one value. "default" : fall back bindings to be used if no others are specified for a given field or attribute - purpose: to reduce complexity of other formats. Second, I observe that the need to use context or not is orthogonal to the above classifications. That is, each of the above bindings may or may not require the use of context. Having written all the above out, I can't see that we have any need to distinguish between fields whose bindings require context and those that don't. I'm happy to hear a good reason though! Thirdly, I observe that as we currently allow multiple uc_ and co_formats, with "let" statement guards to differentiate them, there is no reason not to do the same thing with any of the other formats - including defaults. It probably seems like I'm trying to add stuff here, but actually I'm trying to simplify it by making the same rules apply everywhere. Here's an example from the tcp-pf rewritten with new syntax: sack_var_length_enc (base) === { uc_format = sack_field; %[ 32 ] { let (sack_field:uncomp_length == 32); } inferred = sack_offset %[ 32 ] { let (sack_offset:uncomp_value == sack_field:uncomp_value - base); let (sack_offset:uncomp_length == 32); }; co_format_lsb_15 = discriminator, %[ 1 ] sack_offset, %[ 15 ] { discriminator ::= '0'; sack_offset ::= lsb (15, -1); }; co_format_lsb_22 = discriminator, %[ 2 ] sack_offset, %[ 22 ] { discriminator ::= '10'; sack_offset ::= lsb (22, -1); }; co_format_lsb_30 = discriminator, %[ 2 ] sack_offset, %[ 30 ] { discriminator ::= '11'; sack_offset ::= lsb (30, -1); }; }; Here's another one from appendix B of the FN draft: eg_header === { uc_format = version_no, %[ 2 ] type, %[ 2 ] flow_id, %[ 4 ] sequence_no, %[ 4 ] abc_flag_bits, %[ 3 ] reserved_flag; %[ 1 ] inferred = scaled_seq_no %[ 4 ] { % need modulo maths to calculate scaling correctly, % due to 4 bit wrap around scaled_seq_no ::= uncompressed_value (4, (mod(15 - sequence_no:uncomp_value, 3) * 16 + sequence_no:uncomp_value) / 3); }; default = { version_no ::= uncompressed_value(2,1); type ::= irregular(2); flow_id ::= static; reserved_flag ::= uncompressed_value(1,0); scaled_seq_no ::= lsb(1,-1); }; co_format_irregular = discriminator, %[ 2 ] type, %[ 2 ] flow_id, %[ 4 ] scaled_seq_no, %[ 4 ] abc_flag_bits %[ 3 ] { discriminator ::= '00'; flow_id ::= irregular(4); % overrides default scaled_seq_no ::= irregular(4); % overrides default abc_flag_bits ::= irregular(3); }; co_format_flags_set = discriminator, %[ 2 ] type, %[ 2 ] scaled_seq_no %[ 1 ] { discriminator ::= '01'; abc_flag_bits ::= uncompressed_value(3,7); }; co_format_flags_static = discriminator, %[ 1 ] type, %[ 2 ] scaled_seq_no %[ 1 ] { discriminator ::= '1'; abc_flag_bits ::= static; }; }; Thoughts please, particularly on clarity of notation. As regards the inertia in the current tcp-pf I contend that the changes required would be minimal, to the point that I will volunteer to do them if that's seen as the only obstacle (provided somebody agrees to check my updates). Regards Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 04:01:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15725 for ; Tue, 19 Apr 2005 04:01:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNnrC-0002Tv-NZ for rohc-archive@ietf.org; Tue, 19 Apr 2005 04:13:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNnfK-0003TE-Jx; Tue, 19 Apr 2005 04:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNnfH-0003Si-DH for rohc@megatron.ietf.org; Tue, 19 Apr 2005 04:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15625 for ; Tue, 19 Apr 2005 04:00:56 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNnqB-0002SE-Kf for rohc@ietf.org; Tue, 19 Apr 2005 04:12:17 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3J80UOa003008; Tue, 19 Apr 2005 10:00:41 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 10:00:37 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 10:00:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Tue, 19 Apr 2005 10:00:34 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27F4@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/n ew usage Thread-Index: AcVED6K4XUMdku4TSsOkVlmxyxmFaAACHnIgACZUhqA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Finking, Robert" , "Kristofer Sandlund" X-OriginalArrivalTime: 19 Apr 2005 08:00:37.0712 (UTC) FILETIME=[DF5D2500:01C544B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable > Here are my current thoughts: >=20 > * It seems like a useful thing to be able to indicate the need for > context, but I don't understand why we are only interested in doing it > for fields which don't appear in the uncompressed header. Is=20 > there some motivation that I'm missing? What problem are we solving > here that doesn't need solving for fields which reside in the=20 > uncompressed header? To me it looks really useful to make this distinction. Fields that=20 are "created" and used only on a per-packet basis do not require an explicit control-field declaration, but would be declared as part of the compressed header, with a let declaration that creates the mapping between the created field and original uncompressed field(s). However, control fields are different because they are not necessarily created directly out of uncompressed fields, at least not on a per-packet basis, and they do require context. This is why we agreed they should be explicitly declared as "control fields". I see three kind of fields, original fields, per-packet created fields, and context-requiring created fields (control-fields). =20 > * It strikes me that there are quite a few different types of field, > (e.g. "inferred" fields), which we are currently not being explicit > about, either in the FN or in the TCP draft. The notation=20 > (and hence the TCP draft) would be easier to read if we were > explicit about these things. At present we are disguising them as > other things, which is confusing (to me at least). To bring this > discussion full circle one such example is a non-default statement > appearing in a default list. I see what you mean, but this also worries me, as I think we would open up the classic can of worms if we start doing these things. We are *very* close to finalizing the FN, and I do not want to run another round of redefining things that we have actually agreed are ok. Just sort out the control-fields and default-methods stuff, and then let's try to close this document once and for all. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 05:38:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22031 for ; Tue, 19 Apr 2005 05:38:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNpN2-0005vu-HF for rohc-archive@ietf.org; Tue, 19 Apr 2005 05:50:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNpB0-0008Lh-MZ; Tue, 19 Apr 2005 05:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNpAx-0008KT-S7 for rohc@megatron.ietf.org; Tue, 19 Apr 2005 05:37:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21903 for ; Tue, 19 Apr 2005 05:37:45 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNpLx-0005r0-13 for rohc@ietf.org; Tue, 19 Apr 2005 05:49:09 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3J9bHQ5000291; Tue, 19 Apr 2005 11:37:43 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 11:37:32 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 11:37:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Date: Tue, 19 Apr 2005 11:37:32 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27F5@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] New Draft for Support of Reordering and Constant IP-ID Thread-Index: AcUwm2jLoPv9AE5QSMazjNa5DU145wLeUYRAAM8s6sAACcKMMAAjRGUwAEhHYkAAFxc2EADPLIDQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kapoor, Rohit" X-OriginalArrivalTime: 19 Apr 2005 09:37:32.0399 (UTC) FILETIME=[692FF7F0:01C544C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, hjin@qualcomm.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable To follow up on this question, I suggest adding the following section to the implementer's guide: 4.8. Using timer-based compression =20 Timer-based compression of the RTP timestamp, as described in section 4.5.4, can be used to reduce the number of transmitted timestamp bits (bytes) needed when the timestamp can not be inferred from the SN. It should thus be noted that timer-based compression has no influence on decompression of packets where no timestamp bits are sent, in that case the timestamp is just linearly inferred from the SN (see section 4.2 of this document). Whether to use timer-based compression or not is controlled by the TIME_STRIDE control field, which can be set either by an IR, an IR-DYN, or by a compressed packet with extension 3. Setting TIME_STRIDE to a value > 0 enables timer-based compression. Any comments on this? /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Lars-Erik Jonsson (LU/EAB) > Sent: den 15 april 2005 09:03 > To: Kapoor, Rohit > Cc: rohc@ietf.org; hjin@qualcomm.com > Subject: RE: [rohc] New Draft for Support of Reordering and Constant > IP-ID >=20 >=20 > Rohit, >=20 > I'll try to clarify, hopefully I have corrently understood=20 > your question. >=20 > First of all, timer-based compression has to be turned on by setting > the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted > TS bits should always be interpreted as scaled TS bits, with the=20 > assumption that the decompressor makes use of timer-based estimation, > i.e. the transmitted bits might not themselves be enough to decompress > the TS correctly (MSB requires a timer-based estimation). >=20 > However, if NO BITS are transmitted, this means that TS do follow SN > linearly as a function of TS_STRIDE, i.e.: > TS_SCALED(n) =3D TS_SCALED(n-1) + SN(n) - SN(n-1) >=20 > Timer-based compression is used to be able to reduce the=20 > number of extra > bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. instead of having > to send two or three extra bytes after a silence period, one byte will > be enough. When no TS bits are sent, timer-based compression has no > impact on decompression. >=20 > Did that answer the question? Interpretation two is thus correct! >=20 > I guess it might make sense to write a few words about this in the > implementer's guide, a new section 4.8 on timer-based compression? > What do others think? >=20 > BR > /L-E >=20 >=20 > > -----Original Message----- > > From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] > > Sent: den 14 april 2005 21:26 > > To: Lars-Erik Jonsson (LU/EAB) > > Cc: hjin@qualcomm.com > > Subject: RE: [rohc] New Draft for Support of Reordering and Constant > > IP-ID > >=20 > >=20 > > Lars-Erik, > >=20 > > Thanks. > >=20 > > I also have a slight confusion in the interpretation of the=20 > > RFC that you may be able to clarify. Assume that for some > > time the compressor is using timer-based compression to > > compress RTP timestamp and uses UO-1-TS packets. Now, if > > the compressor decides to send a UO-0 packet, how does > > the decompressor infer the RTP timestamp from this packet? > > UO-0 could either mean that "jitter is 0" (since no > > timestamp bits are present) or the decompressor could > > infer timestamp from RTP SN. Which interpretation will > > the decompressor follow? Or is sending a UO-0 packet not > > "legal" when compressing TS using timer-based compression? > >=20 > > The following paragraph in the RFC says something which seems=20 > > to support the second interpretation. > >=20 > > On page 58 > > If RTP Timestamp and IP Identification fields are not=20 > > included in the received header, they are supposed to be > > calculated from the sequence number. The IP Identifier > > usually increases by the same delta as the sequence number > > and the timestamp by the same delta times a fixed value.=20 > > See chapters 4.5.3 and 4.5.5 for details about how these > > fields are encoded in compressed headers. > >=20 > >=20 > > Thanks, > > Rohit >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 06:47:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27199 for ; Tue, 19 Apr 2005 06:47:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNqRD-0000Ex-5g for rohc-archive@ietf.org; Tue, 19 Apr 2005 06:58:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNqDx-00009n-1F; Tue, 19 Apr 2005 06:44:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNqDu-00009Z-Ht for rohc@megatron.ietf.org; Tue, 19 Apr 2005 06:44:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27050 for ; Tue, 19 Apr 2005 06:44:51 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNqOu-000064-He for rohc@ietf.org; Tue, 19 Apr 2005 06:56:17 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3JAiRQc012673; Tue, 19 Apr 2005 11:44:28 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Apr 2005 11:44:53 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2873@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , Kristofer Sandlund Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Tue, 19 Apr 2005 11:44:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi L-E, All, I've just had a phone call with Kris to clarify a few things from a TCP profile point of view, but OK yes I basically agree to your suggestion. Comments in-line below to include the clarifications from the phone call - Kris please feel free to add anything I've forgotten (which I must have done). Regards Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > > To me it looks really useful to make this distinction. Fields that > are "created" and used only on a per-packet basis do not require an > explicit control-field declaration, but would be declared as part of > the compressed header, with a let declaration that creates the > mapping between the created field and original uncompressed field(s). > > However, control fields are different because they are not > necessarily created directly out of uncompressed fields, at least not > on a per-packet basis, and they do require context. This is why we > agreed they should be explicitly declared as "control fields". > > I see three kind of fields, original fields, per-packet > created fields, > and context-requiring created fields (control-fields). > Yes OK, I've been convinced that we can stick with just these three. We already have syntax for "original" fields: "uc_format". We also have syntax for "context-requiring" fields: "control_fields". We don't have syntax for "created" fields. These are very important and need defining explicitly in the FN draft, because they are like no other kind of field: they can be compressed using "static", "lsb" etc. but *without* using context of their own - they use the context of the field(s) which they are derived from. I suggest that we call these "derived_fields". This then is the only new syntactical element which we need. "default_methods" can then be used exclusively for storing defaults, as described in the current FN draft. > > > * It strikes me that there are quite a few different types of field, > > (e.g. "inferred" fields), which we are currently not being explicit > > about, either in the FN or in the TCP draft. The notation > > (and hence the TCP draft) would be easier to read if we were > > explicit about these things. At present we are disguising them as > > other things, which is confusing (to me at least). To bring this > > discussion full circle one such example is a non-default statement > > appearing in a default list. > > I see what you mean, but this also worries me, as I think we would > open up the classic can of worms if we start doing these things. We > are *very* close to finalizing the FN, and I do not want to run > another round of redefining things that we have actually agreed are > ok. Just sort out the control-fields and default-methods stuff, and > then let's try to close this document once and for all. Yes, I agree, my boss was asking me only this morning about how much more effort this was going to take to get finished! Hopefully we can all agree on the above solution? This is a good step forward for both the TCP profile and also the FN I think. Thanks! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 07:41:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00803 for ; Tue, 19 Apr 2005 07:41:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNrHl-0002QL-7a for rohc-archive@ietf.org; Tue, 19 Apr 2005 07:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNr69-0007wu-Nl; Tue, 19 Apr 2005 07:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNr67-0007wS-TG for rohc@megatron.ietf.org; Tue, 19 Apr 2005 07:40:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00730 for ; Tue, 19 Apr 2005 07:40:54 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNrH8-0002Jr-8I for rohc@ietf.org; Tue, 19 Apr 2005 07:52:18 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3JAeAmg011346 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2005 12:40:11 +0200 Message-ID: <4264EE42.4030007@effnet.com> Date: Tue, 19 Apr 2005 13:40:50 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN: default_methods and control fields clarification/n ew usage References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2873@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2873@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Robert, I think you covered what we discussed, but maybe we should also say that a reason for having the derived_fields definition is so that we _can_ declare these in a global scope to help with the accesses between structures. We don't believe that this will be used for the TCP profile, but we don't want to rule it out of the FN. BR, Kristofer Finking, Robert wrote: > Hi L-E, All, > > I've just had a phone call with Kris to clarify a few things from a TCP profile point of view, but OK yes I basically agree to your suggestion. Comments in-line below to include the clarifications from the phone call - Kris please feel free to add anything I've forgotten (which I must have done). > > Regards > > Raffles > > >>-----Original Message----- >>From: Lars-Erik Jonsson (LU/EAB) >> >>To me it looks really useful to make this distinction. Fields that >>are "created" and used only on a per-packet basis do not require an >>explicit control-field declaration, but would be declared as part of >>the compressed header, with a let declaration that creates the >>mapping between the created field and original uncompressed field(s). >> >>However, control fields are different because they are not >>necessarily created directly out of uncompressed fields, at least not >>on a per-packet basis, and they do require context. This is why we >>agreed they should be explicitly declared as "control fields". >> >>I see three kind of fields, original fields, per-packet >>created fields, >>and context-requiring created fields (control-fields). >> > > > Yes OK, I've been convinced that we can stick with just these three. > We already have syntax for "original" fields: "uc_format". We also > have syntax for "context-requiring" fields: "control_fields". We don't > have syntax for "created" fields. These are very important and need > defining explicitly in the FN draft, because they are like no other > kind of field: they can be compressed using "static", "lsb" etc. but > *without* using context of their own - they use the context of the > field(s) which they are derived from. I suggest that we call these > "derived_fields". This then is the only new syntactical element which > we need. > > "default_methods" can then be used exclusively for storing defaults, > as described in the current FN draft. > > > > >> >> >>>* It strikes me that there are quite a few different types of field, >>>(e.g. "inferred" fields), which we are currently not being explicit >>>about, either in the FN or in the TCP draft. The notation >>>(and hence the TCP draft) would be easier to read if we were >>>explicit about these things. At present we are disguising them as >>>other things, which is confusing (to me at least). To bring this >>>discussion full circle one such example is a non-default statement >>>appearing in a default list. >> >>I see what you mean, but this also worries me, as I think we would >>open up the classic can of worms if we start doing these things. We >>are *very* close to finalizing the FN, and I do not want to run >>another round of redefining things that we have actually agreed are >>ok. Just sort out the control-fields and default-methods stuff, and >>then let's try to close this document once and for all. > > > Yes, I agree, my boss was asking me only this morning about how much > more effort this was going to take to get finished! > > Hopefully we can all agree on the above solution? This is a good step > forward for both the TCP profile and also the FN I think. Thanks! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 07:57:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01989 for ; Tue, 19 Apr 2005 07:57:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNrXc-0003Ca-C1 for rohc-archive@ietf.org; Tue, 19 Apr 2005 08:09:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNrLh-0002y7-8N; Tue, 19 Apr 2005 07:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNrLe-0002xm-IR for rohc@megatron.ietf.org; Tue, 19 Apr 2005 07:57:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01909 for ; Tue, 19 Apr 2005 07:56:56 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNrWe-0003BW-Bw for rohc@ietf.org; Tue, 19 Apr 2005 08:08:21 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3JAuDmg011382 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2005 12:56:13 +0200 Message-ID: <4264F205.6050005@effnet.com> Date: Tue, 19 Apr 2005 13:56:53 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lars-Erik Jonsson (LU/EAB)" Subject: Re: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) References: <026F8EEDAD2C4342A993203088C1FC051C27F5@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC051C27F5@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, hjin@qualcomm.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Hi L-E, If we're going to provide clarifying text on this topic, I think we should also point out that the TIME_STRIDE cannot be set to a non-zero value before the clock resolution on the channel has been set by feedback. So, maybe a change like: OLD: > Whether to use timer-based compression or not is controlled by > the TIME_STRIDE control field, which can be set either by an IR, > an IR-DYN, or by a compressed packet with extension 3. Setting > TIME_STRIDE to a value > 0 enables timer-based compression. NEW: Whether to use timer-based compression or not is controlled by the TIME_STRIDE and the decompressor's clock resolution. A non-zero TIME_STRIDE indicates timer-based compression is being used, but setting TIME_STRIDE to a non-zero value can only be done after the decompressor has declared its clock resolution. The clock resolution is declared by sending a CLOCK feedback for any CID on the channel. After the resoution is known, the TIME_STRIDE can be set either by an IR, an IR-DYN, or by a compressed packet with extension 3. Or something along those lines, feel free to improve that, it turned out to be not-so-great text. But I think you know what I'm trying to say... BR, Kristofer Sandlund, Effnet AB Lars-Erik Jonsson (LU/EAB) wrote: > To follow up on this question, I suggest adding the following section > to the implementer's guide: > > > 4.8. Using timer-based compression > > Timer-based compression of the RTP timestamp, as described in > section 4.5.4, can be used to reduce the number of transmitted > timestamp bits (bytes) needed when the timestamp can not be > inferred from the SN. It should thus be noted that timer-based > compression has no influence on decompression of packets where > no timestamp bits are sent, in that case the timestamp is just > linearly inferred from the SN (see section 4.2 of this document). > > Whether to use timer-based compression or not is controlled by > the TIME_STRIDE control field, which can be set either by an IR, > an IR-DYN, or by a compressed packet with extension 3. Setting > TIME_STRIDE to a value > 0 enables timer-based compression. > > > Any comments on this? > > /L-E > > > > >>-----Original Message----- >>From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of >>Lars-Erik Jonsson (LU/EAB) >>Sent: den 15 april 2005 09:03 >>To: Kapoor, Rohit >>Cc: rohc@ietf.org; hjin@qualcomm.com >>Subject: RE: [rohc] New Draft for Support of Reordering and Constant >>IP-ID >> >> >>Rohit, >> >>I'll try to clarify, hopefully I have corrently understood >>your question. >> >>First of all, timer-based compression has to be turned on by setting >>the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted >>TS bits should always be interpreted as scaled TS bits, with the >>assumption that the decompressor makes use of timer-based estimation, >>i.e. the transmitted bits might not themselves be enough to decompress >>the TS correctly (MSB requires a timer-based estimation). >> >>However, if NO BITS are transmitted, this means that TS do follow SN >>linearly as a function of TS_STRIDE, i.e.: >> TS_SCALED(n) = TS_SCALED(n-1) + SN(n) - SN(n-1) >> >>Timer-based compression is used to be able to reduce the >>number of extra >>bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. instead of having >>to send two or three extra bytes after a silence period, one byte will >>be enough. When no TS bits are sent, timer-based compression has no >>impact on decompression. >> >>Did that answer the question? Interpretation two is thus correct! >> >>I guess it might make sense to write a few words about this in the >>implementer's guide, a new section 4.8 on timer-based compression? >>What do others think? >> >>BR >>/L-E >> >> >> >>>-----Original Message----- >>>From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] >>>Sent: den 14 april 2005 21:26 >>>To: Lars-Erik Jonsson (LU/EAB) >>>Cc: hjin@qualcomm.com >>>Subject: RE: [rohc] New Draft for Support of Reordering and Constant >>>IP-ID >>> >>> >>>Lars-Erik, >>> >>>Thanks. >>> >>>I also have a slight confusion in the interpretation of the >>>RFC that you may be able to clarify. Assume that for some >>>time the compressor is using timer-based compression to >>>compress RTP timestamp and uses UO-1-TS packets. Now, if >>>the compressor decides to send a UO-0 packet, how does >>>the decompressor infer the RTP timestamp from this packet? >>>UO-0 could either mean that "jitter is 0" (since no >>>timestamp bits are present) or the decompressor could >>>infer timestamp from RTP SN. Which interpretation will >>>the decompressor follow? Or is sending a UO-0 packet not >>>"legal" when compressing TS using timer-based compression? >>> >>>The following paragraph in the RFC says something which seems >>>to support the second interpretation. >>> >>>On page 58 >>> If RTP Timestamp and IP Identification fields are not >>> included in the received header, they are supposed to be >>> calculated from the sequence number. The IP Identifier >>> usually increases by the same delta as the sequence number >>> and the timestamp by the same delta times a fixed value. >>> See chapters 4.5.3 and 4.5.5 for details about how these >>> fields are encoded in compressed headers. >>> >>> >>>Thanks, >>>Rohit >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 09:02:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06960 for ; Tue, 19 Apr 2005 09:02:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNsXy-00063x-NO for rohc-archive@ietf.org; Tue, 19 Apr 2005 09:13:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNsMr-0004Lj-8w; Tue, 19 Apr 2005 09:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNsMn-0004LB-Mr for rohc@megatron.ietf.org; Tue, 19 Apr 2005 09:02:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06933 for ; Tue, 19 Apr 2005 09:02:11 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNsXm-00063Z-UX for rohc@ietf.org; Tue, 19 Apr 2005 09:13:36 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3JD1UQS016413; Tue, 19 Apr 2005 15:02:09 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 15:02:09 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 15:02:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Date: Tue, 19 Apr 2005 15:02:08 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27F7@esealmw109.eemea.ericsson.se> Thread-Topic: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Thread-Index: AcVE1t4zT+fePbvCR7W0WEugsIAQYwACRhLA From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kristofer Sandlund" X-OriginalArrivalTime: 19 Apr 2005 13:02:09.0396 (UTC) FILETIME=[FED90B40:01C544DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, hjin@qualcomm.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable Sounds good! Thanks, /L-E > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 19 april 2005 13:57 > To: Lars-Erik Jonsson (LU/EAB) > Cc: Kapoor, Rohit; rohc@ietf.org; hjin@qualcomm.com > Subject: Re: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) >=20 >=20 > Hi L-E, >=20 > If we're going to provide clarifying text on this topic, I=20 > think we should also=20 > point out that the TIME_STRIDE cannot be set to a non-zero=20 > value before the=20 > clock resolution on the channel has been set by feedback. So,=20 > maybe a change like: >=20 > OLD: > > Whether to use timer-based compression or not is controlled by > > the TIME_STRIDE control field, which can be set either by an IR, > > an IR-DYN, or by a compressed packet with extension 3. Setting > > TIME_STRIDE to a value > 0 enables timer-based compression. >=20 > NEW: > Whether to use timer-based compression or not is controlled by > the TIME_STRIDE and the decompressor's clock=20 > resolution. A non-zero > TIME_STRIDE indicates timer-based compression is being used, but > setting TIME_STRIDE to a non-zero value can only be=20 > done after the > decompressor has declared its clock resolution. The=20 > clock resolution > is declared by sending a CLOCK feedback for any CID on=20 > the channel. > After the resoution is known, the TIME_STRIDE can be set either > by an IR, an IR-DYN, or by a compressed packet with extension 3. >=20 > Or something along those lines, feel free to improve that, it=20 > turned out to be=20 > not-so-great text. But I think you know what I'm trying to say... >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > Lars-Erik Jonsson (LU/EAB) wrote: > > To follow up on this question, I suggest adding the=20 > following section > > to the implementer's guide: > >=20 > >=20 > > 4.8. Using timer-based compression > > =20 > > Timer-based compression of the RTP timestamp, as described in > > section 4.5.4, can be used to reduce the number of transmitted > > timestamp bits (bytes) needed when the timestamp can not be > > inferred from the SN. It should thus be noted that timer-based > > compression has no influence on decompression of packets where > > no timestamp bits are sent, in that case the timestamp is just > > linearly inferred from the SN (see section 4.2 of this document). > >=20 > > Whether to use timer-based compression or not is controlled by > > the TIME_STRIDE control field, which can be set either by an IR, > > an IR-DYN, or by a compressed packet with extension 3. Setting > > TIME_STRIDE to a value > 0 enables timer-based compression. > >=20 > >=20 > > Any comments on this? > >=20 > > /L-E > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: rohc-bounces@ietf.org=20 > [mailto:rohc-bounces@ietf.org]On Behalf Of > >>Lars-Erik Jonsson (LU/EAB) > >>Sent: den 15 april 2005 09:03 > >>To: Kapoor, Rohit > >>Cc: rohc@ietf.org; hjin@qualcomm.com > >>Subject: RE: [rohc] New Draft for Support of Reordering and Constant > >>IP-ID > >> > >> > >>Rohit, > >> > >>I'll try to clarify, hopefully I have corrently understood=20 > >>your question. > >> > >>First of all, timer-based compression has to be turned on by setting > >>the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted > >>TS bits should always be interpreted as scaled TS bits, with the=20 > >>assumption that the decompressor makes use of timer-based=20 > estimation, > >>i.e. the transmitted bits might not themselves be enough to=20 > decompress > >>the TS correctly (MSB requires a timer-based estimation). > >> > >>However, if NO BITS are transmitted, this means that TS do follow SN > >>linearly as a function of TS_STRIDE, i.e.: > >> TS_SCALED(n) =3D TS_SCALED(n-1) + SN(n) - SN(n-1) > >> > >>Timer-based compression is used to be able to reduce the=20 > >>number of extra > >>bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e.=20 > instead of having > >>to send two or three extra bytes after a silence period,=20 > one byte will > >>be enough. When no TS bits are sent, timer-based compression has no > >>impact on decompression. > >> > >>Did that answer the question? Interpretation two is thus correct! > >> > >>I guess it might make sense to write a few words about this in the > >>implementer's guide, a new section 4.8 on timer-based compression? > >>What do others think? > >> > >>BR > >>/L-E > >> > >> > >> > >>>-----Original Message----- > >>>From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] > >>>Sent: den 14 april 2005 21:26 > >>>To: Lars-Erik Jonsson (LU/EAB) > >>>Cc: hjin@qualcomm.com > >>>Subject: RE: [rohc] New Draft for Support of Reordering=20 > and Constant > >>>IP-ID > >>> > >>> > >>>Lars-Erik, > >>> > >>>Thanks. > >>> > >>>I also have a slight confusion in the interpretation of the=20 > >>>RFC that you may be able to clarify. Assume that for some > >>>time the compressor is using timer-based compression to > >>>compress RTP timestamp and uses UO-1-TS packets. Now, if > >>>the compressor decides to send a UO-0 packet, how does > >>>the decompressor infer the RTP timestamp from this packet? > >>>UO-0 could either mean that "jitter is 0" (since no > >>>timestamp bits are present) or the decompressor could > >>>infer timestamp from RTP SN. Which interpretation will > >>>the decompressor follow? Or is sending a UO-0 packet not > >>>"legal" when compressing TS using timer-based compression? > >>> > >>>The following paragraph in the RFC says something which seems=20 > >>>to support the second interpretation. > >>> > >>>On page 58 > >>> If RTP Timestamp and IP Identification fields are not=20 > >>> included in the received header, they are supposed to be > >>> calculated from the sequence number. The IP Identifier > >>> usually increases by the same delta as the sequence number > >>> and the timestamp by the same delta times a fixed value.=20 > >>> See chapters 4.5.3 and 4.5.5 for details about how these > >>> fields are encoded in compressed headers. > >>> > >>> > >>>Thanks, > >>>Rohit > >> > >>_______________________________________________ > >>Rohc mailing list > >>Rohc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rohc > >> > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 09:03:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07097 for ; Tue, 19 Apr 2005 09:03:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNsZ2-00066S-D6 for rohc-archive@ietf.org; Tue, 19 Apr 2005 09:14:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNsMh-0004J7-85; Tue, 19 Apr 2005 09:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNsMf-0004J1-6a for rohc@megatron.ietf.org; Tue, 19 Apr 2005 09:02:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06924 for ; Tue, 19 Apr 2005 09:02:03 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNsXf-0005yY-Sj for rohc@ietf.org; Tue, 19 Apr 2005 09:13:28 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3JD1UQ2016413; Tue, 19 Apr 2005 15:01:58 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 15:01:46 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 15:01:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Tue, 19 Apr 2005 15:01:45 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27F6@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/n ew usage Thread-Index: AcVE1KDz8MpxFCUXT8SRrfKT75KGvAACzJpQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kristofer Sandlund" , "Finking, Robert" X-OriginalArrivalTime: 19 Apr 2005 13:01:46.0027 (UTC) FILETIME=[F0EB37B0:01C544DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Excellent that you managed to come up with a resolution. To me this = sounds fine! /L-E > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 19 april 2005 13:41 > To: Finking, Robert > Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > Subject: Re: [rohc] FN: default_methods and control fields > clarification/n ew usage >=20 >=20 > Robert, >=20 > I think you covered what we discussed, but maybe we should=20 > also say that a=20 > reason for having the derived_fields definition is so that we=20 > _can_ declare=20 > these in a global scope to help with the accesses between=20 > structures. We don't=20 > believe that this will be used for the TCP profile, but we=20 > don't want to rule it=20 > out of the FN. >=20 > BR, > Kristofer >=20 > Finking, Robert wrote: > > Hi L-E, All, > >=20 > > I've just had a phone call with Kris to clarify a few=20 > things from a TCP profile point of view, but OK yes I=20 > basically agree to your suggestion. Comments in-line below to=20 > include the clarifications from the phone call - Kris please=20 > feel free to add anything I've forgotten (which I must have done). > >=20 > > Regards > >=20 > > Raffles > >=20 > >=20 > >>-----Original Message----- > >>From: Lars-Erik Jonsson (LU/EAB) > >> > >>To me it looks really useful to make this distinction. Fields that=20 > >>are "created" and used only on a per-packet basis do not require an > >>explicit control-field declaration, but would be declared as part of > >>the compressed header, with a let declaration that creates the > >>mapping between the created field and original uncompressed=20 > field(s). > >> > >>However, control fields are different because they are not > >>necessarily created directly out of uncompressed fields, at=20 > least not > >>on a per-packet basis, and they do require context. This is why we > >>agreed they should be explicitly declared as "control fields". > >> > >>I see three kind of fields, original fields, per-packet=20 > >>created fields, > >>and context-requiring created fields (control-fields). > >> > >=20 > >=20 > > Yes OK, I've been convinced that we can stick with just these three. > > We already have syntax for "original" fields: "uc_format". We also > > have syntax for "context-requiring" fields:=20 > "control_fields". We don't > > have syntax for "created" fields. These are very important and need > > defining explicitly in the FN draft, because they are like no other > > kind of field: they can be compressed using "static", "lsb" etc. but > > *without* using context of their own - they use the context of the > > field(s) which they are derived from. I suggest that we call these > > "derived_fields". This then is the only new syntactical=20 > element which > > we need. > >=20 > > "default_methods" can then be used exclusively for storing defaults, > > as described in the current FN draft. > >=20 > >=20 > > =20 > >=20 > >>=20 > >> > >>>* It strikes me that there are quite a few different types=20 > of field, > >>>(e.g. "inferred" fields), which we are currently not being explicit > >>>about, either in the FN or in the TCP draft. The notation=20 > >>>(and hence the TCP draft) would be easier to read if we were > >>>explicit about these things. At present we are disguising them as > >>>other things, which is confusing (to me at least). To bring this > >>>discussion full circle one such example is a non-default statement > >>>appearing in a default list. > >> > >>I see what you mean, but this also worries me, as I think we would > >>open up the classic can of worms if we start doing these things. We > >>are *very* close to finalizing the FN, and I do not want to run > >>another round of redefining things that we have actually agreed are > >>ok. Just sort out the control-fields and default-methods stuff, and > >>then let's try to close this document once and for all. > >=20 > >=20 > > Yes, I agree, my boss was asking me only this morning about how much > > more effort this was going to take to get finished! > >=20 > > Hopefully we can all agree on the above solution? This is a=20 > good step > > forward for both the TCP profile and also the FN I think. Thanks! >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 09:10:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07720 for ; Tue, 19 Apr 2005 09:10:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNsfx-0006MI-IV for rohc-archive@ietf.org; Tue, 19 Apr 2005 09:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNsU9-00065c-UN; Tue, 19 Apr 2005 09:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNsU7-00065U-W6 for rohc@megatron.ietf.org; Tue, 19 Apr 2005 09:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07678 for ; Tue, 19 Apr 2005 09:09:45 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNsf7-0006LB-VJ for rohc@ietf.org; Tue, 19 Apr 2005 09:21:11 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3JD9RQc019047; Tue, 19 Apr 2005 14:09:28 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Apr 2005 14:09:53 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2883@rsys004a> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] FN: default_methods and control fields clarification/n ew usage Date: Tue, 19 Apr 2005 14:09:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Great, is that consensus? Carsten? Eilert? Cheers Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Tuesday, April 19, 2005 2:02 PM > To: Kristofer Sandlund; Finking, Robert > Cc: rohc@ietf.org > Subject: RE: [rohc] FN: default_methods and control fields > clarification/n ew usage > > > Excellent that you managed to come up with a resolution. To > me this sounds fine! > > /L-E > > > > -----Original Message----- > > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > > Sent: den 19 april 2005 13:41 > > To: Finking, Robert > > Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > > Subject: Re: [rohc] FN: default_methods and control fields > > clarification/n ew usage > > > > > > Robert, > > > > I think you covered what we discussed, but maybe we should > > also say that a > > reason for having the derived_fields definition is so that we > > _can_ declare > > these in a global scope to help with the accesses between > > structures. We don't > > believe that this will be used for the TCP profile, but we > > don't want to rule it > > out of the FN. > > > > BR, > > Kristofer > > > > Finking, Robert wrote: > > > Hi L-E, All, > > > > > > I've just had a phone call with Kris to clarify a few > > things from a TCP profile point of view, but OK yes I > > basically agree to your suggestion. Comments in-line below to > > include the clarifications from the phone call - Kris please > > feel free to add anything I've forgotten (which I must have done). > > > > > > Regards > > > > > > Raffles > > > > > > > > >>-----Original Message----- > > >>From: Lars-Erik Jonsson (LU/EAB) > > >> > > >>To me it looks really useful to make this distinction. > Fields that > > >>are "created" and used only on a per-packet basis do not > require an > > >>explicit control-field declaration, but would be declared > as part of > > >>the compressed header, with a let declaration that creates the > > >>mapping between the created field and original uncompressed > > field(s). > > >> > > >>However, control fields are different because they are not > > >>necessarily created directly out of uncompressed fields, at > > least not > > >>on a per-packet basis, and they do require context. This is why we > > >>agreed they should be explicitly declared as "control fields". > > >> > > >>I see three kind of fields, original fields, per-packet > > >>created fields, > > >>and context-requiring created fields (control-fields). > > >> > > > > > > > > > Yes OK, I've been convinced that we can stick with just > these three. > > > We already have syntax for "original" fields: "uc_format". We also > > > have syntax for "context-requiring" fields: > > "control_fields". We don't > > > have syntax for "created" fields. These are very > important and need > > > defining explicitly in the FN draft, because they are > like no other > > > kind of field: they can be compressed using "static", > "lsb" etc. but > > > *without* using context of their own - they use the context of the > > > field(s) which they are derived from. I suggest that we call these > > > "derived_fields". This then is the only new syntactical > > element which > > > we need. > > > > > > "default_methods" can then be used exclusively for > storing defaults, > > > as described in the current FN draft. > > > > > > > > > > > > > > >> > > >> > > >>>* It strikes me that there are quite a few different types > > of field, > > >>>(e.g. "inferred" fields), which we are currently not > being explicit > > >>>about, either in the FN or in the TCP draft. The notation > > >>>(and hence the TCP draft) would be easier to read if we were > > >>>explicit about these things. At present we are disguising them as > > >>>other things, which is confusing (to me at least). To bring this > > >>>discussion full circle one such example is a non-default > statement > > >>>appearing in a default list. > > >> > > >>I see what you mean, but this also worries me, as I think we would > > >>open up the classic can of worms if we start doing these > things. We > > >>are *very* close to finalizing the FN, and I do not want to run > > >>another round of redefining things that we have actually > agreed are > > >>ok. Just sort out the control-fields and default-methods > stuff, and > > >>then let's try to close this document once and for all. > > > > > > > > > Yes, I agree, my boss was asking me only this morning > about how much > > > more effort this was going to take to get finished! > > > > > > Hopefully we can all agree on the above solution? This is a > > good step > > > forward for both the TCP profile and also the FN I think. Thanks! > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Apr 19 14:05:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03143 for ; Tue, 19 Apr 2005 14:05:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNxHd-0008HL-IN for rohc-archive@ietf.org; Tue, 19 Apr 2005 14:17:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNx49-0007MX-IH; Tue, 19 Apr 2005 14:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNx46-0007MM-Mv for rohc@megatron.ietf.org; Tue, 19 Apr 2005 14:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02686 for ; Tue, 19 Apr 2005 14:03:12 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNxFA-00087M-CW for rohc@ietf.org; Tue, 19 Apr 2005 14:14:41 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3JI2uHa008152; Tue, 19 Apr 2005 11:02:56 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3JI2UIf014289; Tue, 19 Apr 2005 11:02:49 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 11:03:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Date: Tue, 19 Apr 2005 11:02:36 -0700 Message-ID: Thread-Topic: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Thread-Index: AcVE1t4zT+fePbvCR7W0WEugsIAQYwACRhLAAApOtmA= From: "Jin, Haipeng" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 19 Apr 2005 18:03:01.0458 (UTC) FILETIME=[06B71B20:01C5450A] X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, hjin@qualcomm.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: quoted-printable Hi, Lars-Erik and Kristofer, The proposed text does not allow setting TIME_STRIDE to non-zero value before receiving CLOCK feedback in the case where the compressor has advanced knowledge of the decompressor's clock resolution. Can we append the following sentence after the text proposed by Kristofer? ----START-------- However, if the compressor has learned the clock resolution of the decompressor from external means (e.g., when both compressor and decompressor are synchronized to the same timing source), then TIME_STRIDE can be set to non-zero value even when no CLOCK feedback is received.=20 -----END--------- Thanks, Haipeng -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Tuesday, April 19, 2005 6:02 AM To: Kristofer Sandlund Cc: Kapoor, Rohit; rohc@ietf.org; hjin@qualcomm.com Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Sounds good! Thanks, /L-E > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 19 april 2005 13:57 > To: Lars-Erik Jonsson (LU/EAB) > Cc: Kapoor, Rohit; rohc@ietf.org; hjin@qualcomm.com > Subject: Re: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) >=20 >=20 > Hi L-E, >=20 > If we're going to provide clarifying text on this topic, I think we=20 > should also point out that the TIME_STRIDE cannot be set to a non-zero > value before the clock resolution on the channel has been set by=20 > feedback. So, maybe a change like: >=20 > OLD: > > Whether to use timer-based compression or not is controlled by > > the TIME_STRIDE control field, which can be set either by an IR, > > an IR-DYN, or by a compressed packet with extension 3. Setting > > TIME_STRIDE to a value > 0 enables timer-based compression. >=20 > NEW: > Whether to use timer-based compression or not is controlled by > the TIME_STRIDE and the decompressor's clock resolution. A=20 > non-zero > TIME_STRIDE indicates timer-based compression is being used, but > setting TIME_STRIDE to a non-zero value can only be done after=20 > the > decompressor has declared its clock resolution. The clock=20 > resolution > is declared by sending a CLOCK feedback for any CID on the=20 > channel. > After the resoution is known, the TIME_STRIDE can be set either > by an IR, an IR-DYN, or by a compressed packet with extension 3. >=20 > Or something along those lines, feel free to improve that, it turned=20 > out to be not-so-great text. But I think you know what I'm trying to=20 > say... >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > Lars-Erik Jonsson (LU/EAB) wrote: > > To follow up on this question, I suggest adding the > following section > > to the implementer's guide: > >=20 > >=20 > > 4.8. Using timer-based compression > > =20 > > Timer-based compression of the RTP timestamp, as described in > > section 4.5.4, can be used to reduce the number of transmitted > > timestamp bits (bytes) needed when the timestamp can not be > > inferred from the SN. It should thus be noted that timer-based > > compression has no influence on decompression of packets where > > no timestamp bits are sent, in that case the timestamp is just > > linearly inferred from the SN (see section 4.2 of this document). > >=20 > > Whether to use timer-based compression or not is controlled by > > the TIME_STRIDE control field, which can be set either by an IR, > > an IR-DYN, or by a compressed packet with extension 3. Setting > > TIME_STRIDE to a value > 0 enables timer-based compression. > >=20 > >=20 > > Any comments on this? > >=20 > > /L-E > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: rohc-bounces@ietf.org > [mailto:rohc-bounces@ietf.org]On Behalf Of > >>Lars-Erik Jonsson (LU/EAB) > >>Sent: den 15 april 2005 09:03 > >>To: Kapoor, Rohit > >>Cc: rohc@ietf.org; hjin@qualcomm.com > >>Subject: RE: [rohc] New Draft for Support of Reordering and Constant > >>IP-ID > >> > >> > >>Rohit, > >> > >>I'll try to clarify, hopefully I have corrently understood your=20 > >>question. > >> > >>First of all, timer-based compression has to be turned on by setting > >>the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted=20 > >>TS bits should always be interpreted as scaled TS bits, with the=20 > >>assumption that the decompressor makes use of timer-based > estimation, > >>i.e. the transmitted bits might not themselves be enough to > decompress > >>the TS correctly (MSB requires a timer-based estimation). > >> > >>However, if NO BITS are transmitted, this means that TS do follow SN > >>linearly as a function of TS_STRIDE, i.e.: > >> TS_SCALED(n) =3D TS_SCALED(n-1) + SN(n) - SN(n-1) > >> > >>Timer-based compression is used to be able to reduce the number of=20 > >>extra bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. > instead of having > >>to send two or three extra bytes after a silence period, > one byte will > >>be enough. When no TS bits are sent, timer-based compression has no=20 > >>impact on decompression. > >> > >>Did that answer the question? Interpretation two is thus correct! > >> > >>I guess it might make sense to write a few words about this in the=20 > >>implementer's guide, a new section 4.8 on timer-based compression? > >>What do others think? > >> > >>BR > >>/L-E > >> > >> > >> > >>>-----Original Message----- > >>>From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] > >>>Sent: den 14 april 2005 21:26 > >>>To: Lars-Erik Jonsson (LU/EAB) > >>>Cc: hjin@qualcomm.com > >>>Subject: RE: [rohc] New Draft for Support of Reordering > and Constant > >>>IP-ID > >>> > >>> > >>>Lars-Erik, > >>> > >>>Thanks. > >>> > >>>I also have a slight confusion in the interpretation of the RFC=20 > >>>that you may be able to clarify. Assume that for some time the=20 > >>>compressor is using timer-based compression to compress RTP=20 > >>>timestamp and uses UO-1-TS packets. Now, if the compressor decides=20 > >>>to send a UO-0 packet, how does the decompressor infer the RTP=20 > >>>timestamp from this packet? > >>>UO-0 could either mean that "jitter is 0" (since no timestamp bits=20 > >>>are present) or the decompressor could infer timestamp from RTP SN. > >>>Which interpretation will the decompressor follow? Or is sending a=20 > >>>UO-0 packet not "legal" when compressing TS using timer-based=20 > >>>compression? > >>> > >>>The following paragraph in the RFC says something which seems to=20 > >>>support the second interpretation. > >>> > >>>On page 58 > >>> If RTP Timestamp and IP Identification fields are not=20 > >>> included in the received header, they are supposed to be > >>> calculated from the sequence number. The IP Identifier > >>> usually increases by the same delta as the sequence number > >>> and the timestamp by the same delta times a fixed value.=20 > >>> See chapters 4.5.3 and 4.5.5 for details about how these > >>> fields are encoded in compressed headers. > >>> > >>> > >>>Thanks, > >>>Rohit > >> > >>_______________________________________________ > >>Rohc mailing list > >>Rohc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rohc > >> > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 02:45:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07719 for ; Wed, 20 Apr 2005 02:45:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO998-0007Zb-La for rohc-archive@ietf.org; Wed, 20 Apr 2005 02:57:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO8vt-0000La-LC; Wed, 20 Apr 2005 02:43:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO8vr-0000LV-Hj for rohc@megatron.ietf.org; Wed, 20 Apr 2005 02:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07576 for ; Wed, 20 Apr 2005 02:43:30 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO971-0007U9-Az for rohc@ietf.org; Wed, 20 Apr 2005 02:55:04 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3K5gZmg014342 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2005 07:42:35 +0200 Message-ID: <4265FA00.1020100@effnet.com> Date: Wed, 20 Apr 2005 08:43:12 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jin, Haipeng" Subject: Re: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, hjin@qualcomm.com, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: 7bit Hi Haipeng, comments inline. Jin, Haipeng wrote: > Hi, Lars-Erik and Kristofer, > > The proposed text does not allow setting TIME_STRIDE to non-zero value > before receiving CLOCK feedback in the case where the compressor has > advanced knowledge of the decompressor's clock resolution. Can we append > the following sentence after the text proposed by Kristofer? > > ----START-------- > However, if the compressor has learned the clock resolution of the > decompressor from external means (e.g., when both compressor and > decompressor are synchronized to the same timing source), then > TIME_STRIDE can be set to non-zero value even when no CLOCK feedback is > received. > -----END--------- This change would be in violation of 3095 (section 6.5.1, which specifies that the initial value of the clock resolution is set to 0). It is a big advantage to have the timer-based compression specified this way, since BOTH compressor and decompressor must make an explicit action to start using timer-based compression, and your proposed text would make it mandatory for the decompressor to support timer-based compression. The point of the implementer's guide is to clarify things without changing intended behavior, so I'm going to have to oppose the text suggested above. BR, Kristofer Sandlund, Effnet AB > > Thanks, > Haipeng > > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Tuesday, April 19, 2005 6:02 AM > To: Kristofer Sandlund > Cc: Kapoor, Rohit; rohc@ietf.org; hjin@qualcomm.com > Subject: RE: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) > > Sounds good! > > Thanks, > /L-E > > > >>-----Original Message----- >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>Sent: den 19 april 2005 13:57 >>To: Lars-Erik Jonsson (LU/EAB) >>Cc: Kapoor, Rohit; rohc@ietf.org; hjin@qualcomm.com >>Subject: Re: Clarification on timer-based compression (was: Re: [rohc] > > >>New Draft for Support of Reordering and Constant IP-ID) >> >> >>Hi L-E, >> >>If we're going to provide clarifying text on this topic, I think we >>should also point out that the TIME_STRIDE cannot be set to a non-zero > > >>value before the clock resolution on the channel has been set by >>feedback. So, maybe a change like: >> >>OLD: >> > Whether to use timer-based compression or not is controlled by >> > the TIME_STRIDE control field, which can be set either by an IR, >> > an IR-DYN, or by a compressed packet with extension 3. Setting >> > TIME_STRIDE to a value > 0 enables timer-based compression. >> >>NEW: >> Whether to use timer-based compression or not is controlled by >> the TIME_STRIDE and the decompressor's clock resolution. A >>non-zero >> TIME_STRIDE indicates timer-based compression is being used, but >> setting TIME_STRIDE to a non-zero value can only be done after >>the >> decompressor has declared its clock resolution. The clock >>resolution >> is declared by sending a CLOCK feedback for any CID on the >>channel. >> After the resoution is known, the TIME_STRIDE can be set either >> by an IR, an IR-DYN, or by a compressed packet with extension 3. >> >>Or something along those lines, feel free to improve that, it turned >>out to be not-so-great text. But I think you know what I'm trying to >>say... >> >>BR, >> Kristofer Sandlund, Effnet AB >> >>Lars-Erik Jonsson (LU/EAB) wrote: >> >>>To follow up on this question, I suggest adding the >> >>following section >> >>>to the implementer's guide: >>> >>> >>>4.8. Using timer-based compression >>> >>> Timer-based compression of the RTP timestamp, as described in >>> section 4.5.4, can be used to reduce the number of transmitted >>> timestamp bits (bytes) needed when the timestamp can not be >>> inferred from the SN. It should thus be noted that timer-based >>> compression has no influence on decompression of packets where >>> no timestamp bits are sent, in that case the timestamp is just >>> linearly inferred from the SN (see section 4.2 of this document). >>> >>> Whether to use timer-based compression or not is controlled by >>> the TIME_STRIDE control field, which can be set either by an IR, >>> an IR-DYN, or by a compressed packet with extension 3. Setting >>> TIME_STRIDE to a value > 0 enables timer-based compression. >>> >>> >>>Any comments on this? >>> >>>/L-E >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: rohc-bounces@ietf.org >> >>[mailto:rohc-bounces@ietf.org]On Behalf Of >> >>>>Lars-Erik Jonsson (LU/EAB) >>>>Sent: den 15 april 2005 09:03 >>>>To: Kapoor, Rohit >>>>Cc: rohc@ietf.org; hjin@qualcomm.com >>>>Subject: RE: [rohc] New Draft for Support of Reordering and Constant > > >>>>IP-ID >>>> >>>> >>>>Rohit, >>>> >>>>I'll try to clarify, hopefully I have corrently understood your >>>>question. >>>> >>>>First of all, timer-based compression has to be turned on by setting > > >>>>the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted >>>>TS bits should always be interpreted as scaled TS bits, with the >>>>assumption that the decompressor makes use of timer-based >> >>estimation, >> >>>>i.e. the transmitted bits might not themselves be enough to >> >>decompress >> >>>>the TS correctly (MSB requires a timer-based estimation). >>>> >>>>However, if NO BITS are transmitted, this means that TS do follow SN > > >>>>linearly as a function of TS_STRIDE, i.e.: >>>> TS_SCALED(n) = TS_SCALED(n-1) + SN(n) - SN(n-1) >>>> >>>>Timer-based compression is used to be able to reduce the number of >>>>extra bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. >> >>instead of having >> >>>>to send two or three extra bytes after a silence period, >> >>one byte will >> >>>>be enough. When no TS bits are sent, timer-based compression has no >>>>impact on decompression. >>>> >>>>Did that answer the question? Interpretation two is thus correct! >>>> >>>>I guess it might make sense to write a few words about this in the >>>>implementer's guide, a new section 4.8 on timer-based compression? >>>>What do others think? >>>> >>>>BR >>>>/L-E >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Kapoor, Rohit [mailto:rkapoor@qualcomm.com] >>>>>Sent: den 14 april 2005 21:26 >>>>>To: Lars-Erik Jonsson (LU/EAB) >>>>>Cc: hjin@qualcomm.com >>>>>Subject: RE: [rohc] New Draft for Support of Reordering >> >>and Constant >> >>>>>IP-ID >>>>> >>>>> >>>>>Lars-Erik, >>>>> >>>>>Thanks. >>>>> >>>>>I also have a slight confusion in the interpretation of the RFC >>>>>that you may be able to clarify. Assume that for some time the >>>>>compressor is using timer-based compression to compress RTP >>>>>timestamp and uses UO-1-TS packets. Now, if the compressor decides >>>>>to send a UO-0 packet, how does the decompressor infer the RTP >>>>>timestamp from this packet? >>>>>UO-0 could either mean that "jitter is 0" (since no timestamp bits >>>>>are present) or the decompressor could infer timestamp from RTP SN. > > >>>>>Which interpretation will the decompressor follow? Or is sending a >>>>>UO-0 packet not "legal" when compressing TS using timer-based >>>>>compression? >>>>> >>>>>The following paragraph in the RFC says something which seems to >>>>>support the second interpretation. >>>>> >>>>>On page 58 >>>>> If RTP Timestamp and IP Identification fields are not >>>>> included in the received header, they are supposed to be >>>>> calculated from the sequence number. The IP Identifier >>>>> usually increases by the same delta as the sequence number >>>>> and the timestamp by the same delta times a fixed value. >>>>> See chapters 4.5.3 and 4.5.5 for details about how these >>>>> fields are encoded in compressed headers. >>>>> >>>>> >>>>>Thanks, >>>>>Rohit >>>> >>>>_______________________________________________ >>>>Rohc mailing list >>>>Rohc@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/rohc >>>> >>> >>> >>>_______________________________________________ >>>Rohc mailing list >>>Rohc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rohc >> > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 03:24:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10375 for ; Wed, 20 Apr 2005 03:24:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO9kT-0000Ah-As for rohc-archive@ietf.org; Wed, 20 Apr 2005 03:35:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9XG-0004Uh-IO; Wed, 20 Apr 2005 03:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9XF-0004Ub-5G for rohc@megatron.ietf.org; Wed, 20 Apr 2005 03:22:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10196 for ; Wed, 20 Apr 2005 03:22:07 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO9iP-00005w-AW for rohc@ietf.org; Wed, 20 Apr 2005 03:33:42 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3K7LwOC000849; Wed, 20 Apr 2005 09:21:59 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 09:21:51 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 09:21:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Date: Wed, 20 Apr 2005 09:21:50 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27F9@esealmw109.eemea.ericsson.se> Thread-Topic: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Thread-Index: AcVFdEBnJttv5RtwSimD64WMVLbrMAAAJ57w From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kristofer Sandlund" , "Jin, Haipeng" X-OriginalArrivalTime: 20 Apr 2005 07:21:50.0713 (UTC) FILETIME=[9EC70690:01C54579] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Haipeng and Kristofer, I believe Kristofer is correct in that the enabling of timer-based compression as a two-step process involving initiatives from both decompressor and compressor also serves the purpose of making timer- based compression an optional mechanism. We have always considered timer-based as an optional mechanism, requiring CLOCK-OPTION + enabling from the compressor before it can be used. That was the purpose when writing it and that is what has always been the assumption, even if 3095 (as often) is not very clear on this. We see this being reflected in the example implementation structure described in 6.5.1, where clock resolution is initially set to 0. To summarize, I believe the requirement to have received a CLOCK feedback option before timer-based compression can be turned on, is correct. I made a minor re-write of the text, making it more compact. The result became as follows: ---------------------------------------------------------------- 4.8. Using timer-based compression =20 Timer-based compression of the RTP timestamp, as described in section 4.5.4, may be used to reduce the number of transmitted timestamp bits (bytes) needed when the timestamp can not be inferred from the SN. It should thus be noted that timer-based compression has no influence on decompression of packets where no timestamp bits are sent, in that case the timestamp is just linearly inferred from the SN (see section 4.2 of this document). Whether to use timer-based compression or not is controlled by the TIME_STRIDE control field, which can be set either by an IR, an IR- DYN, or by a compressed packet with extension 3. The compressor turns on timer-based compression by setting TIME_STRIDE to a value > 0, but that can be done first after the decompressor has declared its clock resolution, which is done by sending a CLOCK feedback option for any CID on the channel.=20 ----------------------------------------------------------------- Rgds, /L-E > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 20 april 2005 08:43 > To: Jin, Haipeng > Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org; hjin@qualcomm.com > Subject: Re: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) >=20 >=20 > Hi Haipeng, >=20 > comments inline. >=20 > Jin, Haipeng wrote: > > Hi, Lars-Erik and Kristofer, > >=20 > > The proposed text does not allow setting TIME_STRIDE to=20 > non-zero value > > before receiving CLOCK feedback in the case where the compressor has > > advanced knowledge of the decompressor's clock resolution.=20 > Can we append > > the following sentence after the text proposed by Kristofer? > >=20 > > ----START-------- > > However, if the compressor has learned the clock resolution of the > > decompressor from external means (e.g., when both compressor and > > decompressor are synchronized to the same timing source), then > > TIME_STRIDE can be set to non-zero value even when no CLOCK=20 > feedback is > > received.=20 > > -----END--------- >=20 > This change would be in violation of 3095 (section 6.5.1,=20 > which specifies that=20 > the initial value of the clock resolution is set to 0). > It is a big advantage to have the timer-based compression=20 > specified this way,=20 > since BOTH compressor and decompressor must make an explicit=20 > action to start=20 > using timer-based compression, and your proposed text would=20 > make it mandatory=20 > for the decompressor to support timer-based compression. >=20 > The point of the implementer's guide is to clarify things=20 > without changing=20 > intended behavior, so I'm going to have to oppose the text=20 > suggested above. >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > >=20 > > Thanks, > > Haipeng _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 03:45:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12293 for ; Wed, 20 Apr 2005 03:45:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOA4f-0000mt-D9 for rohc-archive@ietf.org; Wed, 20 Apr 2005 03:56:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9sG-00073R-4W; Wed, 20 Apr 2005 03:43:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9sD-00072z-Or for rohc@megatron.ietf.org; Wed, 20 Apr 2005 03:43:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12079 for ; Wed, 20 Apr 2005 03:43:48 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOA3O-0000jv-FF for rohc@ietf.org; Wed, 20 Apr 2005 03:55:23 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3K7hegi016726; Wed, 20 Apr 2005 09:43:47 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 09:43:32 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 09:43:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage Date: Wed, 20 Apr 2005 09:43:32 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA83@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVE4Tvd3bhg5gH9QkSapkkojWD1wAAmN67Q From: "Ghyslain Pelletier \(LU/EAB\)" To: "Finking, Robert" , "Carsten Bormann" X-OriginalArrivalTime: 20 Apr 2005 07:43:31.0977 (UTC) FILETIME=[A6642790:01C5457C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: quoted-printable Hi all, Sorry or the slow turnaround time to answer on this matter. Unfortunately, I do not agree. I _thought_ that we agreed in Washington that control fields have the = exact same properties as uncompressed fields (that is, they can have = attributes, can be compressed, and must be defined within a scope) but = that they would be used to defined any field that is not part of the = uncompressed header. For me, persistency in the context is not something that is related to = the formal notation. This is something that is up to the profile to = state when defining what controls fields are used and what they are for. = Pushing this further, I think that it is just as innapropriate to define = a requirement related to context and persistency in the context for = control fields as it would be to do this for other fields. The problem that I see is that a declaration using "let" does not have = anything to do about if the field would have a "lifetime" longer than = compressing one single packet or a longer lifetime. For example, would = let create a binding from a control field to a mathematical expression = then the lifetime of the control field is per-packet, would the binding = be using a coding method that requires the maintenance of a value in the = context than suddenly it would become a "context-requiring" field. > > > >>I see three kind of fields, original fields, per-packet=20 > > > >>created fields, > > > >>and context-requiring created fields (control-fields). I cannot see that this distinction is useful for formally notating and = parsing of packet formats, which is the objective of the FN. Context = requirements is outside the scope of the FN and we have strived as much = as possible so far to avoid making such distinction in the notation. = Someone explains me why this is suddenly needed for the FN. In short, I do not agree with the latest proposal. I propose that control fields be defined as follow: There are three types of fields: uncompressed fields, control fields and = compressed fields. Control fields share the exact same properties as = uncompressed fields in that they can have attributes, they can be = compressed, and must be defined within their useful scope. The = difference from uncompressed fields is that they are not part of the = uncompressed header but rather created to help in the compression of = uncompressed fields, and may be sent as part of the compressed header in = packet formats. Just like other fields, profile may have to specify in = some way how their value is maintain in the compressor and decompressor = context (this is based on the usage of the control field - e.g. if it's = definition and usage depends only of uncompressed values that are always = present in the uncompressed header, or if the field can sometimes be = compressed and sent along in the compressed header). I.e. this also means that the :uncomp attribute of control fields _may_ = be undefined, as long as this attribute is not used explicitly within = the definition of packet formats (the use of undefined value is = undefined) and as long as the control field is not compressed. Since I cannot really grasp exactly why this discussion led to this = proposal, I might be somewhat off the problem, but I feel that the above = summarizes the consensus that we had in Washington and I see no need to = revisit that consensus without making a change that is not right. Best regards, /Ghyslain > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Finking, Robert > Sent: den 19 april 2005 15:09 > To: 'Carsten Bormann' > Cc: rohc@ietf.org > Subject: RE: [rohc] FN: default_methods and control fields > clarification/new usage >=20 >=20 > Great, is that consensus? Carsten? Eilert? >=20 > Cheers >=20 > Raffles >=20 > > -----Original Message----- > > From: Lars-Erik Jonsson (LU/EAB)=20 > > [mailto:lars-erik.jonsson@ericsson.com]=20 > > Sent: Tuesday, April 19, 2005 2:02 PM > > To: Kristofer Sandlund; Finking, Robert > > Cc: rohc@ietf.org > > Subject: RE: [rohc] FN: default_methods and control fields=20 > > clarification/n ew usage > >=20 > >=20 > > Excellent that you managed to come up with a resolution. To=20 > > me this sounds fine! > >=20 > > /L-E > >=20 > >=20 > > > -----Original Message----- > > > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > > > Sent: den 19 april 2005 13:41 > > > To: Finking, Robert > > > Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > > > Subject: Re: [rohc] FN: default_methods and control fields > > > clarification/n ew usage > > >=20 > > >=20 > > > Robert, > > >=20 > > > I think you covered what we discussed, but maybe we should=20 > > > also say that a=20 > > > reason for having the derived_fields definition is so that we=20 > > > _can_ declare=20 > > > these in a global scope to help with the accesses between=20 > > > structures. We don't=20 > > > believe that this will be used for the TCP profile, but we=20 > > > don't want to rule it=20 > > > out of the FN. > > >=20 > > > BR, > > > Kristofer > > >=20 > > > Finking, Robert wrote: > > > > Hi L-E, All, > > > >=20 > > > > I've just had a phone call with Kris to clarify a few=20 > > > things from a TCP profile point of view, but OK yes I=20 > > > basically agree to your suggestion. Comments in-line below to=20 > > > include the clarifications from the phone call - Kris please=20 > > > feel free to add anything I've forgotten (which I must have done). > > > >=20 > > > > Regards > > > >=20 > > > > Raffles > > > >=20 > > > >=20 > > > >>-----Original Message----- > > > >>From: Lars-Erik Jonsson (LU/EAB) > > > >> > > > >>To me it looks really useful to make this distinction.=20 > > Fields that=20 > > > >>are "created" and used only on a per-packet basis do not=20 > > require an > > > >>explicit control-field declaration, but would be declared=20 > > as part of > > > >>the compressed header, with a let declaration that creates the > > > >>mapping between the created field and original uncompressed=20 > > > field(s). > > > >> > > > >>However, control fields are different because they are not > > > >>necessarily created directly out of uncompressed fields, at=20 > > > least not > > > >>on a per-packet basis, and they do require context.=20 > This is why we > > > >>agreed they should be explicitly declared as "control fields". > > > >> > > > >>I see three kind of fields, original fields, per-packet=20 > > > >>created fields, > > > >>and context-requiring created fields (control-fields). > > > >> > > > >=20 > > > >=20 > > > > Yes OK, I've been convinced that we can stick with just=20 > > these three. > > > > We already have syntax for "original" fields:=20 > "uc_format". We also > > > > have syntax for "context-requiring" fields:=20 > > > "control_fields". We don't > > > > have syntax for "created" fields. These are very=20 > > important and need > > > > defining explicitly in the FN draft, because they are=20 > > like no other > > > > kind of field: they can be compressed using "static",=20 > > "lsb" etc. but > > > > *without* using context of their own - they use the=20 > context of the > > > > field(s) which they are derived from. I suggest that we=20 > call these > > > > "derived_fields". This then is the only new syntactical=20 > > > element which > > > > we need. > > > >=20 > > > > "default_methods" can then be used exclusively for=20 > > storing defaults, > > > > as described in the current FN draft. > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > >>=20 > > > >> > > > >>>* It strikes me that there are quite a few different types=20 > > > of field, > > > >>>(e.g. "inferred" fields), which we are currently not=20 > > being explicit > > > >>>about, either in the FN or in the TCP draft. The notation=20 > > > >>>(and hence the TCP draft) would be easier to read if we were > > > >>>explicit about these things. At present we are=20 > disguising them as > > > >>>other things, which is confusing (to me at least). To=20 > bring this > > > >>>discussion full circle one such example is a non-default=20 > > statement > > > >>>appearing in a default list. > > > >> > > > >>I see what you mean, but this also worries me, as I=20 > think we would > > > >>open up the classic can of worms if we start doing these=20 > > things. We > > > >>are *very* close to finalizing the FN, and I do not want to run > > > >>another round of redefining things that we have actually=20 > > agreed are > > > >>ok. Just sort out the control-fields and default-methods=20 > > stuff, and > > > >>then let's try to close this document once and for all. > > > >=20 > > > >=20 > > > > Yes, I agree, my boss was asking me only this morning=20 > > about how much > > > > more effort this was going to take to get finished! > > > >=20 > > > > Hopefully we can all agree on the above solution? This is a=20 > > > good step > > > > forward for both the TCP profile and also the FN I=20 > think. Thanks! > > >=20 > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 04:35:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16447 for ; Wed, 20 Apr 2005 04:35:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOArB-0002Wi-ER for rohc-archive@ietf.org; Wed, 20 Apr 2005 04:46:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOAbb-000535-IQ; Wed, 20 Apr 2005 04:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOAbZ-000530-By for rohc@megatron.ietf.org; Wed, 20 Apr 2005 04:30:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16045 for ; Wed, 20 Apr 2005 04:30:39 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOAmk-0002Oz-MM for rohc@ietf.org; Wed, 20 Apr 2005 04:42:15 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3K8U8iX002792 for ; Wed, 20 Apr 2005 10:30:39 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 10:30:21 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 10:30:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Lessons learned from 5 years of 3095 experience Date: Wed, 20 Apr 2005 10:30:20 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C27FA@esealmw109.eemea.ericsson.se> Thread-Topic: Lessons learned from 5 years of 3095 experience Thread-Index: AcU2j1Prk9HYBxB2Rfikz0LR8TlFmAOVtoQA From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 20 Apr 2005 08:30:21.0173 (UTC) FILETIME=[30CD7250:01C54583] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Instead of waiting for others to contribute to this, I guess I better start off with the obvious things that have already been discussed by Rohit and others. We have talked about reordering support and constant IP-ID, and while looking at constant IP-ID I think it is worth noting also the other two fixes we did for the IP profile, multiple-IP support and the CONTEXT_MEMORY feedback option. Adding these to the "Meaning of CC=3D0" already present would give an appendix B of the implementer's guide with the following content. --------------------------------------------------------------------- Appendix B - Potential improvements in updated profiles B.1. Minor improvements B.1.1. Meaning of CC=3D0 for CSRC list presence Regarding the CC field and CSRC list, the following interpretation has been proposed as an improvement: "It should be noted that when the value of this CC field is equal to zero, there is no Generic CSRC list present in the dynamic chain, i.e. the field comment should have said "variable length, present if CC > 0". " B.2. Improvements already applied to the IP-only and UPL-Lite profiles B.2.1. Handling Multiple Levels of IP Headers The profiles in RFC 3095 can only handle compression of packet streams with at most two IP headers. The IP-only profile defines a generic way of handling multiple IP headers (see section 3.2 of [3]). B.2.2. The CONTEXT_MEMORY Feedback Option To provide means for a decompressor implementation to have an upper limit on its available context memory size, the IP-only profile defines an additional feedback option to use (see section 3.7 of [3]). The CONTEXT_MEMORY option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream, as the stream is currently compressed.=20 B.2.3. Compression of constant IP-ID (IPv4 only) Most IPv4 stacks assign an IP-ID according to the value of a counter, increasing by one for each outgoing packet. ROHC-RTP therefore compresses the IP-ID field using offset IP-ID encoding based on the RTP SN. For stacks generating IP-ID values using a pseudo-random number generator, the field is not compressed and is sent as-is in its entirety as additional octets after the compressed header. Cases have also been found where an IPv4 stack uses a constant value for the IP Identifier. When the IP-ID field is constant, it cannot be compressed using offset IP-ID encoding and the field must be sent in its entirety, although it is completely static and could had been completely omitted in compressed headers. The IP-only profile addresses this problem and defines an additional mechanism to cope efficiently with constant IP-ID (see section 3.3 of [3]). B.3. Adding tolerance to reordering between compressor and decompressor RFC 3095 was written based on the assumption of in-order packet delivery between compressor and decompressor. Since the publication of RFC 3095, is has been clear that using ROHC would be desirable also in environments where in-order delivery can not be guaranteed. The challenges associated with such usage have been analysed in an informational ROHC WG document "ROHC over channels that can reorder packets" [6], and the finding of that document should be used as a basis when developing an enhanced ROHC that can tolerate a certain amount of reordering, possibly a configurable reordering tolerance. --------------------------------------------------------------------- I guess it could make sense to make appendix B a separate document at some point, but for now let's keep it in the implementer's guide. Comments? /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Lars-Erik Jonsson (LU/EAB) > Sent: den 1 april 2005 09:49 > To: rohc@ietf.org > Subject: [rohc] Lessons learned from 5 years of 3095 experience >=20 >=20 > ROHCers, >=20 > In the ROHC implementer's guide, we have collected clarifications > to ambiguities, inconsistencies, and other specification flaws of > RFC 3095. The purpose of this has been to guide implementer's towards > interoperability and functional operation, but not to introduce=20 > changes to any well specified mechanisms, even if we have seen > potential for improvements. The implementer's guide therefore got > an appendix B where additional ideas for improvements, based on > experience, could be collected. However, there is currently not much > in this appendix. >=20 > Now with 5 years of RFC 3095 experience, I think it would be a proper > time to start collecting additional experience-based ideas also for > appendix B. We should do this while we have implementer's actively > involved in the working group, and before we all start forgetting > what we have disliked in 3095. When doing ROHC TCP, we have already > taken our 3095 experiences into account, so we can probably identify > the most important ideas by looking into what we have done different > with ROHC TCP. However, there are probably additional RTP-specific=20 > issues that are also worth paying attention to and document. >=20 > So, please contribute with your reflections and ideas! >=20 > BR > /L-E =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 05:32:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19752 for ; Wed, 20 Apr 2005 05:32:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOBkE-00041y-PH for rohc-archive@ietf.org; Wed, 20 Apr 2005 05:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOBXW-0003Gr-CS; Wed, 20 Apr 2005 05:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOBXM-0003Gb-HY for rohc@megatron.ietf.org; Wed, 20 Apr 2005 05:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19630 for ; Wed, 20 Apr 2005 05:30:20 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOBiW-0003vu-3A for rohc@ietf.org; Wed, 20 Apr 2005 05:41:57 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3K8TXmg014998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2005 10:29:33 +0200 Message-ID: <42662123.1000108@effnet.com> Date: Wed, 20 Apr 2005 11:30:11 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage References: <026F8EEDAD2C4342A993203088C1FC0527DA83@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0527DA83@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: 7bit Cc: "Finking, Robert" , rohc@ietf.org, Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: 7bit Hi Ghyslain, predictably, I'm not in agreement with you. Resoning follows: First of all, I have a very different opinion on what the consensus in Washington was. I just read the slides and the minutes from the meeting, but from that I cannot read it one way or the other. So, instead I'll just point towards what is actually in the ROHC-TCP draft right now. The nottion that control_fields were meant to include "all fields not in the uncompressed header" is not supported by section 6.3 (tcp-09), which lists the actual control fields that "have context", which is tha same separartionas in the packet formats in the draft. I know that the FN text contradicts this, but it seems like we simply did not know what we had consensus on. For that reason, as well as the lack of _clear_ documentation for what we had consensus on, it is not only valid, but important to re-open the discussion. Like I said to you offline yesterday, to me it is important that the TCP spec becomes as readable as possible to the implementer and that the text and packet format definitions are consistent with each other. And clearly, the fields that _I_ refer to as control_fields need to be treated differently than "simple flags" in the PROFILE. And the packet formats included in the rohc-tcp draft _are_ a part of the profile, and therefore should separate the same way as the text. Therefore, the FN needs to provide provisions for "FN code" to provide this separation. If the FN provides this separation, it still does NOT mean that it messes with "context updating" or other concepts, it is just a separation of fields to provide readability and consistency. So, I guess we need input on this from more people to be able to resolve things, so please jump in even if you're not in agreement with me :) BR, Kristofer Sandlund, Effnet AB Ghyslain Pelletier (LU/EAB) wrote: > Hi all, > > Sorry or the slow turnaround time to answer on this matter. > > Unfortunately, I do not agree. > > I _thought_ that we agreed in Washington that control fields have the exact same properties as uncompressed fields (that is, they can have attributes, can be compressed, and must be defined within a scope) but that they would be used to defined any field that is not part of the uncompressed header. > > For me, persistency in the context is not something that is related to the formal notation. This is something that is up to the profile to state when defining what controls fields are used and what they are for. Pushing this further, I think that it is just as innapropriate to define a requirement related to context and persistency in the context for control fields as it would be to do this for other fields. > > The problem that I see is that a declaration using "let" does not have anything to do about if the field would have a "lifetime" longer than compressing one single packet or a longer lifetime. For example, would let create a binding from a control field to a mathematical expression then the lifetime of the control field is per-packet, would the binding be using a coding method that requires the maintenance of a value in the context than suddenly it would become a "context-requiring" field. > > >>>>>>I see three kind of fields, original fields, per-packet >>>>>>created fields, >>>>>>and context-requiring created fields (control-fields). > > > I cannot see that this distinction is useful for formally notating and parsing of packet formats, which is the objective of the FN. Context requirements is outside the scope of the FN and we have strived as much as possible so far to avoid making such distinction in the notation. Someone explains me why this is suddenly needed for the FN. > > In short, I do not agree with the latest proposal. > > I propose that control fields be defined as follow: > > There are three types of fields: uncompressed fields, control fields and compressed fields. Control fields share the exact same properties as uncompressed fields in that they can have attributes, they can be compressed, and must be defined within their useful scope. The difference from uncompressed fields is that they are not part of the uncompressed header but rather created to help in the compression of uncompressed fields, and may be sent as part of the compressed header in packet formats. Just like other fields, profile may have to specify in some way how their value is maintain in the compressor and decompressor context (this is based on the usage of the control field - e.g. if it's definition and usage depends only of uncompressed values that are always present in the uncompressed header, or if the field can sometimes be compressed and sent along in the compressed header). > > I.e. this also means that the :uncomp attribute of control fields _may_ be undefined, as long as this attribute is not used explicitly within the definition of packet formats (the use of undefined value is undefined) and as long as the control field is not compressed. > > Since I cannot really grasp exactly why this discussion led to this proposal, I might be somewhat off the problem, but I feel that the above summarizes the consensus that we had in Washington and I see no need to revisit that consensus without making a change that is not right. > > Best regards, > > /Ghyslain > > >>-----Original Message----- >>From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of >>Finking, Robert >>Sent: den 19 april 2005 15:09 >>To: 'Carsten Bormann' >>Cc: rohc@ietf.org >>Subject: RE: [rohc] FN: default_methods and control fields >>clarification/new usage >> >> >>Great, is that consensus? Carsten? Eilert? >> >>Cheers >> >>Raffles >> >> >>>-----Original Message----- >>>From: Lars-Erik Jonsson (LU/EAB) >>>[mailto:lars-erik.jonsson@ericsson.com] >>>Sent: Tuesday, April 19, 2005 2:02 PM >>>To: Kristofer Sandlund; Finking, Robert >>>Cc: rohc@ietf.org >>>Subject: RE: [rohc] FN: default_methods and control fields >>>clarification/n ew usage >>> >>> >>>Excellent that you managed to come up with a resolution. To >>>me this sounds fine! >>> >>>/L-E >>> >>> >>> >>>>-----Original Message----- >>>>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>>>Sent: den 19 april 2005 13:41 >>>>To: Finking, Robert >>>>Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org >>>>Subject: Re: [rohc] FN: default_methods and control fields >>>>clarification/n ew usage >>>> >>>> >>>>Robert, >>>> >>>>I think you covered what we discussed, but maybe we should >>>>also say that a >>>>reason for having the derived_fields definition is so that we >>>>_can_ declare >>>>these in a global scope to help with the accesses between >>>>structures. We don't >>>>believe that this will be used for the TCP profile, but we >>>>don't want to rule it >>>>out of the FN. >>>> >>>>BR, >>>> Kristofer >>>> >>>>Finking, Robert wrote: >>>> >>>>>Hi L-E, All, >>>>> >>>>>I've just had a phone call with Kris to clarify a few >>>> >>>>things from a TCP profile point of view, but OK yes I >>>>basically agree to your suggestion. Comments in-line below to >>>>include the clarifications from the phone call - Kris please >>>>feel free to add anything I've forgotten (which I must have done). >>>> >>>>>Regards >>>>> >>>>>Raffles >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Lars-Erik Jonsson (LU/EAB) >>>>>> >>>>>>To me it looks really useful to make this distinction. >>> >>>Fields that >>> >>>>>>are "created" and used only on a per-packet basis do not >>> >>>require an >>> >>>>>>explicit control-field declaration, but would be declared >>> >>>as part of >>> >>>>>>the compressed header, with a let declaration that creates the >>>>>>mapping between the created field and original uncompressed >>>> >>>>field(s). >>>> >>>>>>However, control fields are different because they are not >>>>>>necessarily created directly out of uncompressed fields, at >>>> >>>>least not >>>> >>>>>>on a per-packet basis, and they do require context. >> >>This is why we >> >>>>>>agreed they should be explicitly declared as "control fields". >>>>>> >>>>>>I see three kind of fields, original fields, per-packet >>>>>>created fields, >>>>>>and context-requiring created fields (control-fields). >>>>>> >>>>> >>>>> >>>>>Yes OK, I've been convinced that we can stick with just >>> >>>these three. >>> >>>>>We already have syntax for "original" fields: >> >>"uc_format". We also >> >>>>>have syntax for "context-requiring" fields: >>>> >>>>"control_fields". We don't >>>> >>>>>have syntax for "created" fields. These are very >>> >>>important and need >>> >>>>>defining explicitly in the FN draft, because they are >>> >>>like no other >>> >>>>>kind of field: they can be compressed using "static", >>> >>>"lsb" etc. but >>> >>>>>*without* using context of their own - they use the >> >>context of the >> >>>>>field(s) which they are derived from. I suggest that we >> >>call these >> >>>>>"derived_fields". This then is the only new syntactical >>>> >>>>element which >>>> >>>>>we need. >>>>> >>>>>"default_methods" can then be used exclusively for >>> >>>storing defaults, >>> >>>>>as described in the current FN draft. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>>* It strikes me that there are quite a few different types >>>> >>>>of field, >>>> >>>>>>>(e.g. "inferred" fields), which we are currently not >>> >>>being explicit >>> >>>>>>>about, either in the FN or in the TCP draft. The notation >>>>>>>(and hence the TCP draft) would be easier to read if we were >>>>>>>explicit about these things. At present we are >> >>disguising them as >> >>>>>>>other things, which is confusing (to me at least). To >> >>bring this >> >>>>>>>discussion full circle one such example is a non-default >>> >>>statement >>> >>>>>>>appearing in a default list. >>>>>> >>>>>>I see what you mean, but this also worries me, as I >> >>think we would >> >>>>>>open up the classic can of worms if we start doing these >>> >>>things. We >>> >>>>>>are *very* close to finalizing the FN, and I do not want to run >>>>>>another round of redefining things that we have actually >>> >>>agreed are >>> >>>>>>ok. Just sort out the control-fields and default-methods >>> >>>stuff, and >>> >>>>>>then let's try to close this document once and for all. >>>>> >>>>> >>>>>Yes, I agree, my boss was asking me only this morning >>> >>>about how much >>> >>>>>more effort this was going to take to get finished! >>>>> >>>>>Hopefully we can all agree on the above solution? This is a >>>> >>>>good step >>>> >>>>>forward for both the TCP profile and also the FN I >> >>think. Thanks! >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 06:01:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21332 for ; Wed, 20 Apr 2005 06:01:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOCCS-0004i6-12 for rohc-archive@ietf.org; Wed, 20 Apr 2005 06:12:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOC0K-0005xY-Uz; Wed, 20 Apr 2005 06:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOC0G-0005xA-Fk for rohc@megatron.ietf.org; Wed, 20 Apr 2005 06:00:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21291 for ; Wed, 20 Apr 2005 06:00:14 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOCBR-0004hL-2J for rohc@ietf.org; Wed, 20 Apr 2005 06:11:51 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KA0COC014331; Wed, 20 Apr 2005 12:00:12 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 11:59:52 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 11:59:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage Date: Wed, 20 Apr 2005 11:59:50 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA87@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVFi5EBAr2Le4tESMCqpeEO5Y6EXwAASsvA From: "Ghyslain Pelletier \(LU/EAB\)" To: "Kristofer Sandlund" , "Carsten Bormann" X-OriginalArrivalTime: 20 Apr 2005 09:59:51.0904 (UTC) FILETIME=[B201F600:01C5458F] X-Spam-Score: 0.0 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Content-Transfer-Encoding: quoted-printable Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Content-Transfer-Encoding: quoted-printable Hi kristoffer, > So, instead I'll just point towards what is actually in the=20 > ROHC-TCP draft right now. In general, I don't think that the fact that some text already exists is = a motivation to move on with a specific solution. As you've mainly work = with the packet formats (which provide one interpretation of the = Washington agreement) and I mainly worked on the text in FN than it is = of no surprise that these contradicts. At least we agree on this. On the = other end, I don't think that reviews of the packet formats focused on = that part at all so I would not understand this as representing any = agreement. > For that reason, as well as the lack of _clear_=20 > documentation for what we had consensus on, it > is not only valid, but important to re-open the > discussion. I am certainly in favor of discussing this and clarifying this. That's why I have proposed a simple definition that I hope was clear = enough. > clearly, the fields that _I_ refer to as > control_fields need to be treated differently=20 > than "simple flags" in the PROFILE. I don't know that we have consensus on this "clearly". I actually agree that in the implementation, they will be treated = differently, but I firmly believe that it is not of the FN to define = such difference. The FN specifies packet formats formally, e.g. how to = compress each field based on coding methods and assertive statements to = generate the butts on the wire, but I believe it is of the scope of the = profile definition to define where and how the context information = required to choose and generate the actual packets. So, I'd rather say that for the FN to fullfil its goals there is no need = to handle the two types that you defined in a different ways. In terms = of properties, controls fields (including what you call simple flags) = are no different than uncompressed fields, also as uncompressed fields = can be used themselves as simple flags and as control fields may be = compressed themselves and be sent in the compressed header. As a sideline, and this is maybe why Lars-Erik and myself couldnot agree = regarding the "overloading" of the "let" statement in a previous = discussion, it clarifies I believe that a let cannot be used to define a = field, but can be used to bind the value of a field attribute or can be = used as a simple assertive statement. > this separation. If the FN provides this separation, it still=20 > does NOT mean that it messes with "context updating" or other > concepts, it is just a separation of fields to provide > readability and consistency. I don't really get you here. I am not talking about context updating, I = am talking about properties related to their persistency in the context, = what you previously referred to as "fields" with requirements on the = context. Further, I think that this messes up much more than it helps, because = the requirements that a field as with respect to the context is in large = part related to coding methods and/or the presence of information onto = which it depends within the uncompressed header. That is, you'd = introduce rules as to that a field used as a flag cannot be the = left-hand side of an assignment that has state, such as a binding to a = stateful coding method or a binding to an expression that requires state = to be kept. I believe that the definition that I have provided is much cleaner (and = clearer for that matter) as all fields not part of the uncompressed = header are treated the same manner, only that those that you'd like to = use as flags would have some attributes being undefined (which is ok by = FN) as long as you don't use these attributes in expression (would lead = to an undefined result, which is not allowed). I'd welcome also more input in this discussion as I feel that, with the = distinction that has been proposed, we are stepping over the scope of = the FN into the scope of the profiles. And that I want to avoid. /Ghyslain > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 20 april 2005 11:30 > To: Ghyslain Pelletier (LU/EAB) > Cc: Finking, Robert; Carsten Bormann; rohc@ietf.org > Subject: Re: [rohc] FN: default_methods and control fields > clarification/new usage >=20 >=20 > Hi Ghyslain, >=20 > predictably, I'm not in agreement with you. Resoning follows: >=20 > First of all, I have a very different opinion on what the=20 > consensus in=20 > Washington was. I just read the slides and the minutes from=20 > the meeting, but=20 > from that I cannot read it one way or the other. > So, instead I'll just point towards what is actually in the=20 > ROHC-TCP draft=20 > right now. The nottion that control_fields were meant to=20 > include "all fields not=20 > in the uncompressed header" is not supported by section 6.3=20 > (tcp-09), which=20 > lists the actual control fields that "have context", which is=20 > tha same=20 > separartionas in the packet formats in the draft. I know that=20 > the FN text=20 > contradicts this, but it seems like we simply did not know=20 > what we had consensus=20 > on. For that reason, as well as the lack of _clear_=20 > documentation for what we=20 > had consensus on, it is not only valid, but important to=20 > re-open the discussion. >=20 > Like I said to you offline yesterday, to me it is important=20 > that the TCP spec=20 > becomes as readable as possible to the implementer and that=20 > the text and packet=20 > format definitions are consistent with each other. And=20 > clearly, the fields that=20 > _I_ refer to as control_fields need to be treated differently=20 > than "simple=20 > flags" in the PROFILE. And the packet formats included in the=20 > rohc-tcp draft=20 > _are_ a part of the profile, and therefore should separate=20 > the same way as the=20 > text. Therefore, the FN needs to provide provisions for "FN=20 > code" to provide=20 > this separation. If the FN provides this separation, it still=20 > does NOT mean that=20 > it messes with "context updating" or other concepts, it is=20 > just a separation of=20 > fields to provide readability and consistency. >=20 > So, I guess we need input on this from more people to be able=20 > to resolve things,=20 > so please jump in even if you're not in agreement with me :) >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 >=20 >=20 > Ghyslain Pelletier (LU/EAB) wrote: > > Hi all, > >=20 > > Sorry or the slow turnaround time to answer on this matter. > >=20 > > Unfortunately, I do not agree. > >=20 > > I _thought_ that we agreed in Washington that control=20 > fields have the exact same properties as uncompressed fields=20 > (that is, they can have attributes, can be compressed, and=20 > must be defined within a scope) but that they would be used=20 > to defined any field that is not part of the uncompressed header. > >=20 > > For me, persistency in the context is not something that is=20 > related to the formal notation. This is something that is up=20 > to the profile to state when defining what controls fields=20 > are used and what they are for. Pushing this further, I think=20 > that it is just as innapropriate to define a requirement=20 > related to context and persistency in the context for control=20 > fields as it would be to do this for other fields. > >=20 > > The problem that I see is that a declaration using "let"=20 > does not have anything to do about if the field would have a=20 > "lifetime" longer than compressing one single packet or a=20 > longer lifetime. For example, would let create a binding from=20 > a control field to a mathematical expression then the=20 > lifetime of the control field is per-packet, would the=20 > binding be using a coding method that requires the=20 > maintenance of a value in the context than suddenly it would=20 > become a "context-requiring" field. > >=20 > >=20 > >>>>>>I see three kind of fields, original fields, per-packet=20 > >>>>>>created fields, > >>>>>>and context-requiring created fields (control-fields). > >=20 > >=20 > > I cannot see that this distinction is useful for formally=20 > notating and parsing of packet formats, which is the=20 > objective of the FN. Context requirements is outside the=20 > scope of the FN and we have strived as much as possible so=20 > far to avoid making such distinction in the notation. Someone=20 > explains me why this is suddenly needed for the FN. > >=20 > > In short, I do not agree with the latest proposal. > >=20 > > I propose that control fields be defined as follow: > >=20 > > There are three types of fields: uncompressed fields,=20 > control fields and compressed fields. Control fields share=20 > the exact same properties as uncompressed fields in that they=20 > can have attributes, they can be compressed, and must be=20 > defined within their useful scope. The difference from=20 > uncompressed fields is that they are not part of the=20 > uncompressed header but rather created to help in the=20 > compression of uncompressed fields, and may be sent as part=20 > of the compressed header in packet formats. Just like other=20 > fields, profile may have to specify in some way how their=20 > value is maintain in the compressor and decompressor context=20 > (this is based on the usage of the control field - e.g. if=20 > it's definition and usage depends only of uncompressed values=20 > that are always present in the uncompressed header, or if the=20 > field can sometimes be compressed and sent along in the=20 > compressed header). > >=20 > > I.e. this also means that the :uncomp attribute of control=20 > fields _may_ be undefined, as long as this attribute is not=20 > used explicitly within the definition of packet formats (the=20 > use of undefined value is undefined) and as long as the=20 > control field is not compressed. > >=20 > > Since I cannot really grasp exactly why this discussion led=20 > to this proposal, I might be somewhat off the problem, but I=20 > feel that the above summarizes the consensus that we had in=20 > Washington and I see no need to revisit that consensus=20 > without making a change that is not right. > >=20 > > Best regards, > >=20 > > /Ghyslain > >=20 > >=20 > >>-----Original Message----- > >>From: rohc-bounces@ietf.org=20 > [mailto:rohc-bounces@ietf.org]On Behalf Of > >>Finking, Robert > >>Sent: den 19 april 2005 15:09 > >>To: 'Carsten Bormann' > >>Cc: rohc@ietf.org > >>Subject: RE: [rohc] FN: default_methods and control fields > >>clarification/new usage > >> > >> > >>Great, is that consensus? Carsten? Eilert? > >> > >>Cheers > >> > >>Raffles > >> > >> > >>>-----Original Message----- > >>>From: Lars-Erik Jonsson (LU/EAB)=20 > >>>[mailto:lars-erik.jonsson@ericsson.com]=20 > >>>Sent: Tuesday, April 19, 2005 2:02 PM > >>>To: Kristofer Sandlund; Finking, Robert > >>>Cc: rohc@ietf.org > >>>Subject: RE: [rohc] FN: default_methods and control fields=20 > >>>clarification/n ew usage > >>> > >>> > >>>Excellent that you managed to come up with a resolution. To=20 > >>>me this sounds fine! > >>> > >>>/L-E > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > >>>>Sent: den 19 april 2005 13:41 > >>>>To: Finking, Robert > >>>>Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > >>>>Subject: Re: [rohc] FN: default_methods and control fields > >>>>clarification/n ew usage > >>>> > >>>> > >>>>Robert, > >>>> > >>>>I think you covered what we discussed, but maybe we should=20 > >>>>also say that a=20 > >>>>reason for having the derived_fields definition is so that we=20 > >>>>_can_ declare=20 > >>>>these in a global scope to help with the accesses between=20 > >>>>structures. We don't=20 > >>>>believe that this will be used for the TCP profile, but we=20 > >>>>don't want to rule it=20 > >>>>out of the FN. > >>>> > >>>>BR, > >>>> Kristofer > >>>> > >>>>Finking, Robert wrote: > >>>> > >>>>>Hi L-E, All, > >>>>> > >>>>>I've just had a phone call with Kris to clarify a few=20 > >>>> > >>>>things from a TCP profile point of view, but OK yes I=20 > >>>>basically agree to your suggestion. Comments in-line below to=20 > >>>>include the clarifications from the phone call - Kris please=20 > >>>>feel free to add anything I've forgotten (which I must have done). > >>>> > >>>>>Regards > >>>>> > >>>>>Raffles > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Lars-Erik Jonsson (LU/EAB) > >>>>>> > >>>>>>To me it looks really useful to make this distinction.=20 > >>> > >>>Fields that=20 > >>> > >>>>>>are "created" and used only on a per-packet basis do not=20 > >>> > >>>require an > >>> > >>>>>>explicit control-field declaration, but would be declared=20 > >>> > >>>as part of > >>> > >>>>>>the compressed header, with a let declaration that creates the > >>>>>>mapping between the created field and original uncompressed=20 > >>>> > >>>>field(s). > >>>> > >>>>>>However, control fields are different because they are not > >>>>>>necessarily created directly out of uncompressed fields, at=20 > >>>> > >>>>least not > >>>> > >>>>>>on a per-packet basis, and they do require context.=20 > >> > >>This is why we > >> > >>>>>>agreed they should be explicitly declared as "control fields". > >>>>>> > >>>>>>I see three kind of fields, original fields, per-packet=20 > >>>>>>created fields, > >>>>>>and context-requiring created fields (control-fields). > >>>>>> > >>>>> > >>>>> > >>>>>Yes OK, I've been convinced that we can stick with just=20 > >>> > >>>these three. > >>> > >>>>>We already have syntax for "original" fields:=20 > >> > >>"uc_format". We also > >> > >>>>>have syntax for "context-requiring" fields:=20 > >>>> > >>>>"control_fields". We don't > >>>> > >>>>>have syntax for "created" fields. These are very=20 > >>> > >>>important and need > >>> > >>>>>defining explicitly in the FN draft, because they are=20 > >>> > >>>like no other > >>> > >>>>>kind of field: they can be compressed using "static",=20 > >>> > >>>"lsb" etc. but > >>> > >>>>>*without* using context of their own - they use the=20 > >> > >>context of the > >> > >>>>>field(s) which they are derived from. I suggest that we=20 > >> > >>call these > >> > >>>>>"derived_fields". This then is the only new syntactical=20 > >>>> > >>>>element which > >>>> > >>>>>we need. > >>>>> > >>>>>"default_methods" can then be used exclusively for=20 > >>> > >>>storing defaults, > >>> > >>>>>as described in the current FN draft. > >>>>> > >>>>> > >>>>>=20 > >>>>> > >>>>> > >>>>>> > >>>>>>>* It strikes me that there are quite a few different types=20 > >>>> > >>>>of field, > >>>> > >>>>>>>(e.g. "inferred" fields), which we are currently not=20 > >>> > >>>being explicit > >>> > >>>>>>>about, either in the FN or in the TCP draft. The notation=20 > >>>>>>>(and hence the TCP draft) would be easier to read if we were > >>>>>>>explicit about these things. At present we are=20 > >> > >>disguising them as > >> > >>>>>>>other things, which is confusing (to me at least). To=20 > >> > >>bring this > >> > >>>>>>>discussion full circle one such example is a non-default=20 > >>> > >>>statement > >>> > >>>>>>>appearing in a default list. > >>>>>> > >>>>>>I see what you mean, but this also worries me, as I=20 > >> > >>think we would > >> > >>>>>>open up the classic can of worms if we start doing these=20 > >>> > >>>things. We > >>> > >>>>>>are *very* close to finalizing the FN, and I do not want to run > >>>>>>another round of redefining things that we have actually=20 > >>> > >>>agreed are > >>> > >>>>>>ok. Just sort out the control-fields and default-methods=20 > >>> > >>>stuff, and > >>> > >>>>>>then let's try to close this document once and for all. > >>>>> > >>>>> > >>>>>Yes, I agree, my boss was asking me only this morning=20 > >>> > >>>about how much > >>> > >>>>>more effort this was going to take to get finished! > >>>>> > >>>>>Hopefully we can all agree on the above solution? This is a=20 > >>>> > >>>>good step > >>>> > >>>>>forward for both the TCP profile and also the FN I=20 > >> > >>think. Thanks! > >> > >>_______________________________________________ > >>Rohc mailing list > >>Rohc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rohc > >> > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 06:16:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22661 for ; Wed, 20 Apr 2005 06:16:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOCRg-0005F8-HE for rohc-archive@ietf.org; Wed, 20 Apr 2005 06:28:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOCFD-0007QG-Gl; Wed, 20 Apr 2005 06:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOCFC-0007QA-PX for rohc@megatron.ietf.org; Wed, 20 Apr 2005 06:15:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22555 for ; Wed, 20 Apr 2005 06:15:40 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOCQP-0005DC-5e for rohc@ietf.org; Wed, 20 Apr 2005 06:27:17 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KAEdiE023642; Wed, 20 Apr 2005 12:15:40 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 12:15:13 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 12:15:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/newusage Date: Wed, 20 Apr 2005 12:15:10 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA88@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/newusage Thread-Index: AcVFi5EBAr2Le4tESMCqpeEO5Y6EXwAASsvAAAE8vXA= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" , "Carsten Bormann" X-OriginalArrivalTime: 20 Apr 2005 10:15:12.0802 (UTC) FILETIME=[D6E7D820:01C54591] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable ...at one point in my previous posting it should've read "bits"... oups. : ) /Ghyslain > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Ghyslain Pelletier (LU/EAB) > Sent: den 20 april 2005 12:00 > To: Kristofer Sandlund; Carsten Bormann > Cc: Finking, Robert; rohc@ietf.org > Subject: RE: [rohc] FN: default_methods and control fields > clarification/newusage >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 07:13:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26554 for ; Wed, 20 Apr 2005 07:13:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DODKZ-0006qs-G7 for rohc-archive@ietf.org; Wed, 20 Apr 2005 07:25:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOD6q-0003jw-Ty; Wed, 20 Apr 2005 07:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOD6p-0003jr-3D for rohc@megatron.ietf.org; Wed, 20 Apr 2005 07:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26479 for ; Wed, 20 Apr 2005 07:11:03 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DODHy-0006mU-8H for rohc@ietf.org; Wed, 20 Apr 2005 07:22:41 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3KAA9mg015317 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2005 12:10:10 +0200 Message-ID: <426638B9.3040500@effnet.com> Date: Wed, 20 Apr 2005 13:10:49 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage References: <026F8EEDAD2C4342A993203088C1FC0527DA87@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0527DA87@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, "Finking, Robert" , Lars-Erik Jonsson X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Content-Transfer-Encoding: 7bit >>this separation. If the FN provides this separation, it still >> does NOT mean that it messes with "context updating" or other >> concepts, it is just a separation of fields to provide >> readability and consistency. > >I don't really get you here. I am not talking about context updating, I am >talking about properties related to their persistency in the context, what you >previously referred to as "fields" with requirements on the context. Ok, so let's try to explain this another way. I guess you agree that in the _text_ in rohc-tcp, the fields "with context" needs to be explained explicitly and separate from other type of field (as section 6.3 does). Then, if the text calls them "control fields", "persistent control fields" or "monkeys from outer space" does not matter the least to me. I know we have had requests for those textual descriptions before we added it and I hope you agree that in the text, that separation is necessary. So assuming that, my point is: Why shouln't the FN give me provisions to have this separation reflected in the FN code? The "user" will first read the draft's text and see that "ooooh, these fields have a different meaning, and where do I find them in the FN code?". If we have the same definition for these and other not-in-the-uncompressed-header-fields, we make it harder on the user and that's what I specifically do not want to do. Yes, the FN becomes slightly more complex if it contains one more "class" of field, but I'd rather have the complexity logded there than having harder-to-read FN code. Hope that makes my motivations more clear to you even if you don't agree with them. BR, Kristofer Ghyslain Pelletier (LU/EAB) wrote: > Hi kristoffer, > > >> So, instead I'll just point towards what is actually in the >> ROHC-TCP draft right now. > > > In general, I don't think that the fact that some text already exists is a motivation to move on with a specific solution. As you've mainly work with the packet formats (which provide one interpretation of the Washington agreement) and I mainly worked on the text in FN than it is of no surprise that these contradicts. At least we agree on this. On the other end, I don't think that reviews of the packet formats focused on that part at all so I would not understand this as representing any agreement. > > >>For that reason, as well as the lack of _clear_ >>documentation for what we had consensus on, it >>is not only valid, but important to re-open the >>discussion. > > > I am certainly in favor of discussing this and clarifying this. > That's why I have proposed a simple definition that I hope was clear enough. > > >>clearly, the fields that _I_ refer to as >>control_fields need to be treated differently >>than "simple flags" in the PROFILE. > > > I don't know that we have consensus on this "clearly". > > I actually agree that in the implementation, they will be treated differently, but I firmly believe that it is not of the FN to define such difference. The FN specifies packet formats formally, e.g. how to compress each field based on coding methods and assertive statements to generate the butts on the wire, but I believe it is of the scope of the profile definition to define where and how the context information required to choose and generate the actual packets. > > So, I'd rather say that for the FN to fullfil its goals there is no need to handle the two types that you defined in a different ways. In terms of properties, controls fields (including what you call simple flags) are no different than uncompressed fields, also as uncompressed fields can be used themselves as simple flags and as control fields may be compressed themselves and be sent in the compressed header. > > As a sideline, and this is maybe why Lars-Erik and myself couldnot agree regarding the "overloading" of the "let" statement in a previous discussion, it clarifies I believe that a let cannot be used to define a field, but can be used to bind the value of a field attribute or can be used as a simple assertive statement. > > >>this separation. If the FN provides this separation, it still >>does NOT mean that it messes with "context updating" or other >>concepts, it is just a separation of fields to provide >>readability and consistency. > > > I don't really get you here. I am not talking about context updating, I am talking about properties related to their persistency in the context, what you previously referred to as "fields" with requirements on the context. > > Further, I think that this messes up much more than it helps, because the requirements that a field as with respect to the context is in large part related to coding methods and/or the presence of information onto which it depends within the uncompressed header. That is, you'd introduce rules as to that a field used as a flag cannot be the left-hand side of an assignment that has state, such as a binding to a stateful coding method or a binding to an expression that requires state to be kept. > > I believe that the definition that I have provided is much cleaner (and clearer for that matter) as all fields not part of the uncompressed header are treated the same manner, only that those that you'd like to use as flags would have some attributes being undefined (which is ok by FN) as long as you don't use these attributes in expression (would lead to an undefined result, which is not allowed). > > I'd welcome also more input in this discussion as I feel that, with the distinction that has been proposed, we are stepping over the scope of the FN into the scope of the profiles. And that I want to avoid. > > /Ghyslain > > >>-----Original Message----- >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>Sent: den 20 april 2005 11:30 >>To: Ghyslain Pelletier (LU/EAB) >>Cc: Finking, Robert; Carsten Bormann; rohc@ietf.org >>Subject: Re: [rohc] FN: default_methods and control fields >>clarification/new usage >> >> >>Hi Ghyslain, >> >>predictably, I'm not in agreement with you. Resoning follows: >> >>First of all, I have a very different opinion on what the >>consensus in >>Washington was. I just read the slides and the minutes from >>the meeting, but >>from that I cannot read it one way or the other. >> So, instead I'll just point towards what is actually in the >>ROHC-TCP draft >>right now. The nottion that control_fields were meant to >>include "all fields not >>in the uncompressed header" is not supported by section 6.3 >>(tcp-09), which >>lists the actual control fields that "have context", which is >>tha same >>separartionas in the packet formats in the draft. I know that >>the FN text >>contradicts this, but it seems like we simply did not know >>what we had consensus >>on. For that reason, as well as the lack of _clear_ >>documentation for what we >>had consensus on, it is not only valid, but important to >>re-open the discussion. >> >>Like I said to you offline yesterday, to me it is important >>that the TCP spec >>becomes as readable as possible to the implementer and that >>the text and packet >>format definitions are consistent with each other. And >>clearly, the fields that >>_I_ refer to as control_fields need to be treated differently >>than "simple >>flags" in the PROFILE. And the packet formats included in the >>rohc-tcp draft >>_are_ a part of the profile, and therefore should separate >>the same way as the >>text. Therefore, the FN needs to provide provisions for "FN >>code" to provide >>this separation. If the FN provides this separation, it still >>does NOT mean that >>it messes with "context updating" or other concepts, it is >>just a separation of >>fields to provide readability and consistency. >> >>So, I guess we need input on this from more people to be able >>to resolve things, >>so please jump in even if you're not in agreement with me :) >> >>BR, >> Kristofer Sandlund, Effnet AB >> >> >> >>Ghyslain Pelletier (LU/EAB) wrote: >> >>>Hi all, >>> >>>Sorry or the slow turnaround time to answer on this matter. >>> >>>Unfortunately, I do not agree. >>> >>>I _thought_ that we agreed in Washington that control >> >>fields have the exact same properties as uncompressed fields >>(that is, they can have attributes, can be compressed, and >>must be defined within a scope) but that they would be used >>to defined any field that is not part of the uncompressed header. >> >>>For me, persistency in the context is not something that is >> >>related to the formal notation. This is something that is up >>to the profile to state when defining what controls fields >>are used and what they are for. Pushing this further, I think >>that it is just as innapropriate to define a requirement >>related to context and persistency in the context for control >>fields as it would be to do this for other fields. >> >>>The problem that I see is that a declaration using "let" >> >>does not have anything to do about if the field would have a >>"lifetime" longer than compressing one single packet or a >>longer lifetime. For example, would let create a binding from >>a control field to a mathematical expression then the >>lifetime of the control field is per-packet, would the >>binding be using a coding method that requires the >>maintenance of a value in the context than suddenly it would >>become a "context-requiring" field. >> >>> >>>>>>>>I see three kind of fields, original fields, per-packet >>>>>>>>created fields, >>>>>>>>and context-requiring created fields (control-fields). >>> >>> >>>I cannot see that this distinction is useful for formally >> >>notating and parsing of packet formats, which is the >>objective of the FN. Context requirements is outside the >>scope of the FN and we have strived as much as possible so >>far to avoid making such distinction in the notation. Someone >>explains me why this is suddenly needed for the FN. >> >>>In short, I do not agree with the latest proposal. >>> >>>I propose that control fields be defined as follow: >>> >>>There are three types of fields: uncompressed fields, >> >>control fields and compressed fields. Control fields share >>the exact same properties as uncompressed fields in that they >>can have attributes, they can be compressed, and must be >>defined within their useful scope. The difference from >>uncompressed fields is that they are not part of the >>uncompressed header but rather created to help in the >>compression of uncompressed fields, and may be sent as part >>of the compressed header in packet formats. Just like other >>fields, profile may have to specify in some way how their >>value is maintain in the compressor and decompressor context >>(this is based on the usage of the control field - e.g. if >>it's definition and usage depends only of uncompressed values >>that are always present in the uncompressed header, or if the >>field can sometimes be compressed and sent along in the >>compressed header). >> >>>I.e. this also means that the :uncomp attribute of control >> >>fields _may_ be undefined, as long as this attribute is not >>used explicitly within the definition of packet formats (the >>use of undefined value is undefined) and as long as the >>control field is not compressed. >> >>>Since I cannot really grasp exactly why this discussion led >> >>to this proposal, I might be somewhat off the problem, but I >>feel that the above summarizes the consensus that we had in >>Washington and I see no need to revisit that consensus >>without making a change that is not right. >> >>>Best regards, >>> >>>/Ghyslain >>> >>> >>> >>>>-----Original Message----- >>>>From: rohc-bounces@ietf.org >> >>[mailto:rohc-bounces@ietf.org]On Behalf Of >> >>>>Finking, Robert >>>>Sent: den 19 april 2005 15:09 >>>>To: 'Carsten Bormann' >>>>Cc: rohc@ietf.org >>>>Subject: RE: [rohc] FN: default_methods and control fields >>>>clarification/new usage >>>> >>>> >>>>Great, is that consensus? Carsten? Eilert? >>>> >>>>Cheers >>>> >>>>Raffles >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Lars-Erik Jonsson (LU/EAB) >>>>>[mailto:lars-erik.jonsson@ericsson.com] >>>>>Sent: Tuesday, April 19, 2005 2:02 PM >>>>>To: Kristofer Sandlund; Finking, Robert >>>>>Cc: rohc@ietf.org >>>>>Subject: RE: [rohc] FN: default_methods and control fields >>>>>clarification/n ew usage >>>>> >>>>> >>>>>Excellent that you managed to come up with a resolution. To >>>>>me this sounds fine! >>>>> >>>>>/L-E >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>>>>>Sent: den 19 april 2005 13:41 >>>>>>To: Finking, Robert >>>>>>Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org >>>>>>Subject: Re: [rohc] FN: default_methods and control fields >>>>>>clarification/n ew usage >>>>>> >>>>>> >>>>>>Robert, >>>>>> >>>>>>I think you covered what we discussed, but maybe we should >>>>>>also say that a >>>>>>reason for having the derived_fields definition is so that we >>>>>>_can_ declare >>>>>>these in a global scope to help with the accesses between >>>>>>structures. We don't >>>>>>believe that this will be used for the TCP profile, but we >>>>>>don't want to rule it >>>>>>out of the FN. >>>>>> >>>>>>BR, >>>>>> Kristofer >>>>>> >>>>>>Finking, Robert wrote: >>>>>> >>>>>> >>>>>>>Hi L-E, All, >>>>>>> >>>>>>>I've just had a phone call with Kris to clarify a few >>>>>> >>>>>>things from a TCP profile point of view, but OK yes I >>>>>>basically agree to your suggestion. Comments in-line below to >>>>>>include the clarifications from the phone call - Kris please >>>>>>feel free to add anything I've forgotten (which I must have done). >>>>>> >>>>>> >>>>>>>Regards >>>>>>> >>>>>>>Raffles >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Lars-Erik Jonsson (LU/EAB) >>>>>>>> >>>>>>>>To me it looks really useful to make this distinction. >>>>> >>>>>Fields that >>>>> >>>>> >>>>>>>>are "created" and used only on a per-packet basis do not >>>>> >>>>>require an >>>>> >>>>> >>>>>>>>explicit control-field declaration, but would be declared >>>>> >>>>>as part of >>>>> >>>>> >>>>>>>>the compressed header, with a let declaration that creates the >>>>>>>>mapping between the created field and original uncompressed >>>>>> >>>>>>field(s). >>>>>> >>>>>> >>>>>>>>However, control fields are different because they are not >>>>>>>>necessarily created directly out of uncompressed fields, at >>>>>> >>>>>>least not >>>>>> >>>>>> >>>>>>>>on a per-packet basis, and they do require context. >>>> >>>>This is why we >>>> >>>> >>>>>>>>agreed they should be explicitly declared as "control fields". >>>>>>>> >>>>>>>>I see three kind of fields, original fields, per-packet >>>>>>>>created fields, >>>>>>>>and context-requiring created fields (control-fields). >>>>>>>> >>>>>>> >>>>>>> >>>>>>>Yes OK, I've been convinced that we can stick with just >>>>> >>>>>these three. >>>>> >>>>> >>>>>>>We already have syntax for "original" fields: >>>> >>>>"uc_format". We also >>>> >>>> >>>>>>>have syntax for "context-requiring" fields: >>>>>> >>>>>>"control_fields". We don't >>>>>> >>>>>> >>>>>>>have syntax for "created" fields. These are very >>>>> >>>>>important and need >>>>> >>>>> >>>>>>>defining explicitly in the FN draft, because they are >>>>> >>>>>like no other >>>>> >>>>> >>>>>>>kind of field: they can be compressed using "static", >>>>> >>>>>"lsb" etc. but >>>>> >>>>> >>>>>>>*without* using context of their own - they use the >>>> >>>>context of the >>>> >>>> >>>>>>>field(s) which they are derived from. I suggest that we >>>> >>>>call these >>>> >>>> >>>>>>>"derived_fields". This then is the only new syntactical >>>>>> >>>>>>element which >>>>>> >>>>>> >>>>>>>we need. >>>>>>> >>>>>>>"default_methods" can then be used exclusively for >>>>> >>>>>storing defaults, >>>>> >>>>> >>>>>>>as described in the current FN draft. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>* It strikes me that there are quite a few different types >>>>>> >>>>>>of field, >>>>>> >>>>>> >>>>>>>>>(e.g. "inferred" fields), which we are currently not >>>>> >>>>>being explicit >>>>> >>>>> >>>>>>>>>about, either in the FN or in the TCP draft. The notation >>>>>>>>>(and hence the TCP draft) would be easier to read if we were >>>>>>>>>explicit about these things. At present we are >>>> >>>>disguising them as >>>> >>>> >>>>>>>>>other things, which is confusing (to me at least). To >>>> >>>>bring this >>>> >>>> >>>>>>>>>discussion full circle one such example is a non-default >>>>> >>>>>statement >>>>> >>>>> >>>>>>>>>appearing in a default list. >>>>>>>> >>>>>>>>I see what you mean, but this also worries me, as I >>>> >>>>think we would >>>> >>>> >>>>>>>>open up the classic can of worms if we start doing these >>>>> >>>>>things. We >>>>> >>>>> >>>>>>>>are *very* close to finalizing the FN, and I do not want to run >>>>>>>>another round of redefining things that we have actually >>>>> >>>>>agreed are >>>>> >>>>> >>>>>>>>ok. Just sort out the control-fields and default-methods >>>>> >>>>>stuff, and >>>>> >>>>> >>>>>>>>then let's try to close this document once and for all. >>>>>>> >>>>>>> >>>>>>>Yes, I agree, my boss was asking me only this morning >>>>> >>>>>about how much >>>>> >>>>> >>>>>>>more effort this was going to take to get finished! >>>>>>> >>>>>>>Hopefully we can all agree on the above solution? This is a >>>>>> >>>>>>good step >>>>>> >>>>>> >>>>>>>forward for both the TCP profile and also the FN I >>>> >>>>think. Thanks! >>>> >>>>_______________________________________________ >>>>Rohc mailing list >>>>Rohc@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/rohc >>>> >>> >>> >>>_______________________________________________ >>>Rohc mailing list >>>Rohc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rohc >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 07:47:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28977 for ; Wed, 20 Apr 2005 07:47:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DODrd-0007m2-54 for rohc-archive@ietf.org; Wed, 20 Apr 2005 07:59:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DODfM-0006Ui-RY; Wed, 20 Apr 2005 07:46:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DODfL-0006UT-9D for rohc@megatron.ietf.org; Wed, 20 Apr 2005 07:46:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28924 for ; Wed, 20 Apr 2005 07:46:46 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DODqY-0007kf-4A for rohc@ietf.org; Wed, 20 Apr 2005 07:58:22 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KBkiO6011827; Wed, 20 Apr 2005 13:46:45 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 13:46:44 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 13:46:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/new usage Date: Wed, 20 Apr 2005 13:46:43 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA89@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/new usage Thread-Index: AcVFmZgqfJ54R69cROeNQ95d30Wm0gAAxazA From: "Ghyslain Pelletier \(LU/EAB\)" To: "Kristofer Sandlund" , "Carsten Bormann" , "Finking, Robert" , "Lars-Erik Jonsson \(LU/EAB\)" X-OriginalArrivalTime: 20 Apr 2005 11:46:44.0787 (UTC) FILETIME=[A0624030:01C5459E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable > >>this separation. If the FN provides this separation, it still > >> does NOT mean that it messes with "context updating" or other > >> concepts, it is just a separation of fields to provide > >> readability and consistency. > > > >I don't really get you here. I am not talking about context = updating, I am=20 > >talking about properties related to their persistency in the = context, what you=20 > >previously referred to as "fields" with requirements on the context. >=20 > Ok, so let's try to explain this another way. > I guess you agree that in the _text_ in rohc-tcp, the fields "with = context"=20 > needs to be explained explicitly and separate from other type of field = (as=20 > section 6.3 does). Then, if the text calls them "control fields", = "persistent=20 > control fields" or "monkeys from outer space" does not matter the = least to me. I=20 > know we have had requests for those textual descriptions before we = added it and=20 > I hope you agree that in the text, that separation is necessary. Relax, I did not come up with confusing names to refer to two things = that shold be treated as the same ; ) So, I agree that this is not to be part of the FN, if necessary to have = it is of the scope of the profile. But no, I don't think that I actually agree that this separation is = necessary in the text either, at least not explicitly - I don't think = that it _needs_ to be formalized anywhere. However, I do agree that the = informational mention of the role of each control fields and how it is = to be used within the profile in the profile document is certainly = useful (but again not mandatory). I don't think that that has any = implication on the interoperability of the specification, only to the = implementer's ability to understand how to actually compress things so = that compressed formats can be chosen efficiently. But I could be = convinced otherwise, I just don't see this right now. > So assuming that, my point is: Why shouln't the FN give me provisions = to have=20 > this separation reflected in the FN code? The "user" will first read = the draft's=20 > text and see that "ooooh, these fields have a different meaning, and = where do I=20 > find them in the FN code?". If we have the same definition for these = and other=20 > not-in-the-uncompressed-header-fields, we make it harder on the user = and that's=20 > what I specifically do not want to do. Yes, the FN becomes slightly = more complex=20 > if it contains one more "class" of field, but I'd rather have the = complexity=20 > logded there than having harder-to-read FN code. So, you actually don't have technical arguments to motivate this formal = separation within the FN? Furthermore, you did not either provide any technical arguments against = my proposal. It still think that it is simpler, clearer, easier to read = and understand and easier to use for both notator and implementer. _AND_ = coherent with what we've been trying to achieve for a while now with the = FN. So yes, I feel that it will become more confusing for the notator when = writing new packet formats, since the artificial separation in the = notation will likely IMHO lead to exceptions and exclusions on how to = use each type (refer to my previous mail for the example). In short, I = think it will be more of a mess with this artificial separation within = the FN than if we treat all as the same and instead do better what we = currently do - that is specify better within profile text the role and = properties of the control fields that are most important (if not all). > Hope that makes my motivations more clear to you even if you don't = agree with them. Actually, now that I've read this I think I had guessed right, and I can = still not see the advantage of this. But yes it's clear. /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 09:24:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07355 for ; Wed, 20 Apr 2005 09:24:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFMw-0002Tw-Oa for rohc-archive@ietf.org; Wed, 20 Apr 2005 09:35:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFA6-0007rg-Ow; Wed, 20 Apr 2005 09:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFA4-0007rY-8X for rohc@megatron.ietf.org; Wed, 20 Apr 2005 09:22:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07240 for ; Wed, 20 Apr 2005 09:22:34 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFLI-0002OM-2c for rohc@ietf.org; Wed, 20 Apr 2005 09:34:12 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KDMLfq006679; Wed, 20 Apr 2005 15:22:22 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 15:22:22 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 15:22:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/newusage Date: Wed, 20 Apr 2005 15:22:21 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2801@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/newusage Thread-Index: AcVFi5EBAr2Le4tESMCqpeEO5Y6EXwAASsvAAAbvSXA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" , "Carsten Bormann" X-OriginalArrivalTime: 20 Apr 2005 13:22:21.0813 (UTC) FILETIME=[FBEAF250:01C545AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable I actually have a hard time understanding why you even care to argue so much about this issue. Personally, I can note that the current FN is not consistent in defining and describing what a control field is, but either solution presented looks good to me. In general, I agree with Kristofer who wants to make the FN easier to read and understand by separating different mechanisms, also and especially when they could be realized with one single mechanism. However, I still believe the issue about "let" to be more important to fight about, but that one I have given up. Therefore I do not care so much about this separation, which I agree looks logical in my mind, but not essential. Looking at the argumentation from Ghyslain, I can also buy that one. Adopting his definition of control_field would probably be the simplest way to move on with FN. But I can not see why going with the proposal by Kristofer and Raffles would be bad, wrong, or counterproductive. So, honestly, I can not take side in this discussion, not at this point, then someone has to bring more convincing arguments. Finally, a comment on the following: > As a sideline, and this is maybe why Lars-Erik and myself=20 > couldnot agree regarding the "overloading" of the "let"=20 > statement in a previous discussion, it clarifies I believe=20 > that a let cannot be used to define a field, but can be used=20 > to bind the value of a field attribute or can be used as a=20 > simple assertive statement. I do not agree that this was the cause of the problem we could not agree on "let". As you say yourself, let can be used to bind the value of a field attribute, or it can be used as a simple assertive statement. Every time I see a let, I have to figure out which usage it is, and I still believe having these two separated had been the right thing(tm). A toolbox becomes easier to use and understand if you have different tools for different things, where each have a name that=20 represents what it is good/used for. Actually, in the FN example on page 51, the following let statement is not correctly written, I think.=20 let(scaled_seq_no:uncomp_value =3D=3D ((mod(15 - sequence_no:uncomp_value, 3) * 16 + sequence_no:uncomp_value) / 3)); =20 Is =3D=3D the proper syntax here? Then this would be a simple assertion that would just always be false. Or have I missed something? The overloading of let makes it an ambiguous=20 mechanism. Yes, I have agreed not to argue about that again, but since you brought it up, I thought I had the right to respond. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 09:30:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07747 for ; Wed, 20 Apr 2005 09:30:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFSk-0002dQ-Nl for rohc-archive@ietf.org; Wed, 20 Apr 2005 09:41:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFFK-0008Rl-Vg; Wed, 20 Apr 2005 09:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFFJ-0008Qs-6v for rohc@megatron.ietf.org; Wed, 20 Apr 2005 09:28:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07607 for ; Wed, 20 Apr 2005 09:27:59 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFQV-0002aE-SZ for rohc@ietf.org; Wed, 20 Apr 2005 09:39:37 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KDRvh5023369; Wed, 20 Apr 2005 15:27:57 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 15:27:57 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 15:27:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN: default_methods and control fields clarification/newusage Date: Wed, 20 Apr 2005 15:27:56 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA8E@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN: default_methods and control fields clarification/newusage Thread-Index: AcVFi5EBAr2Le4tESMCqpeEO5Y6EXwAASsvAAAbvSXAAAO2nEA== From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" , "Carsten Bormann" X-OriginalArrivalTime: 20 Apr 2005 13:27:57.0330 (UTC) FILETIME=[C3E6C720:01C545AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable > Actually, in the FN example on page 51, the following let > statement is not correctly written, I think.=20 >=20 > let(scaled_seq_no:uncomp_value > =3D=3D ((mod(15 - sequence_no:uncomp_value, 3) * 16 > + sequence_no:uncomp_value) / 3)); > =20 > Is =3D=3D the proper syntax here? Then this would be a simple > assertion that would just always be false. Or have I missed > something? The overloading of let makes it an ambiguous=20 > mechanism. Yes, I have agreed not to argue about that again, > but since you brought it up, I thought I had the right to > respond. Yes, because we looked at the statement above together and wondered what = it actually really meant in light of the "=3D=3D". However, in the FN = draft, it is not said anywhere explicitly how attributes should be used = as a left-hand side of an expression, which I believe should be using = the "=3D". However, I did not want to re-open the question on the let statement - I = just what us to _clarify_ the FN properly in its current state (not = change or split syntax that allows us to reach our objectives with the = notation), then conciliate the packet formats and the FN text and move = on with the ******* thing so that we can do proper (and wider) review of = the TCP profile and packet formats. Frankly, I am tired of having everything being revisited 20 times just = because we actually don't have a unified view on the FN... /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 09:34:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08362 for ; Wed, 20 Apr 2005 09:34:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFWx-0002l0-LG for rohc-archive@ietf.org; Wed, 20 Apr 2005 09:46:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFIO-0000Ft-M0; Wed, 20 Apr 2005 09:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFIO-0000Fo-4t for rohc@megatron.ietf.org; Wed, 20 Apr 2005 09:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07879 for ; Wed, 20 Apr 2005 09:31:10 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFTY-0002eF-KD for rohc@ietf.org; Wed, 20 Apr 2005 09:42:48 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3KDUkqP016238 for ; Wed, 20 Apr 2005 14:30:46 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 20 Apr 2005 14:31:03 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B0@rsys004a> Thread-Topic: FN control fields Thread-Index: AcVFrTI6A7P60R6HQn6B5JlYwCGrCw== From: "Finking, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Subject: [rohc] FN control fields X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Hi Ghyslain, Kris, All Wow! You go to a morning meeting and while you're away the list = explodes. Many thanks to you all for your contributions. OK taking into = account the whole discussion, here are the main points as I see them: - We don't have consensus - The main obstacle is Kris and Ghyslain's disagreement - They both live in Lule=E5 Therefore I suggest an arm wrestling competition at sunset in the car = park outside Ghyslain's apartment =3D)=20 Seriously, this is a fairly involved issue and I'm very glad Ghyslain = has joined in - thanks! The main points: 1 Some want to be able to indicate need for context, others don't 2 The current state of play (CSoP) in the FN draft is the latter 3 The CSoP in the TCP-pf is the former 4 The FN draft will have to change if it adopts the former 5 The TCP-pf will NOT have to change if it adopts the latter, the FN in = the TCP-pf will be the same either way but have a subtly different = meaning 6 It would be very good if we can fix the "non-default default let = statements" bug as part of this 7 we have endeavoured to remove formal references to context from the = FN as part of the simplification we did last summer 8 "derived" fields are currently not discussed at all in the FN draft, = but since *some* mention is made of context in the draft (albeit = non-formal) we need to do something to handle them 9 The information about whether context is needed is already there in = the profile, implicitly (in terms of what encoding methods are used for = that field). Here is my suggestion, which will hopefully fit all parties to an OKish = degree: - we stick with the current syntax, which keeps things simple and = minimises the changes necessary - in the TCP-pf we can use comments to indicate that context is needed = for certain fields - we clarify in the FN draft the possibility of the existence of derived = fields and their use; again these can optionally be indicated by = comments - we clarify in the FN draft that "control_fields" sections are just = like any other section inside a structure in that they may have a field = encodings list. - we move the non-default let statements in the FN-draft AND tcp-pf out = of the default section and into either a "control_fields" field = encodings list, or a "uc_format" field encodings list if that is more = convenient. Did I give a fair summary, and how does my suggestion sit with everyone? = I'm guessing nobody will be over the moon about it, but hopefully all = can just about swallow it? Here's hoping! Raffles Robert Finking (01794 833189) Roke Manor Research (http://www.roke.co.uk) Romsey, Hampshire SO51 0ZN _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 09:47:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09225 for ; Wed, 20 Apr 2005 09:47:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFjU-0003AZ-Gs for rohc-archive@ietf.org; Wed, 20 Apr 2005 09:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFX5-0002SN-JS; Wed, 20 Apr 2005 09:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFX3-0002SI-JF for rohc@megatron.ietf.org; Wed, 20 Apr 2005 09:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09181 for ; Wed, 20 Apr 2005 09:46:20 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFiH-00035X-Ng for rohc@ietf.org; Wed, 20 Apr 2005 09:57:58 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KDjsjH027306; Wed, 20 Apr 2005 15:46:19 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 15:45:57 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 15:45:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 15:45:56 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2802@esealmw109.eemea.ericsson.se> Thread-Topic: FN control fields Thread-Index: AcVFrTI6A7P60R6HQn6B5JlYwCGrCwAAZTqw From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Finking, Robert" , X-OriginalArrivalTime: 20 Apr 2005 13:45:57.0288 (UTC) FILETIME=[479B4A80:01C545AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable And the definition of control-field would then be as given by Ghyslain? CSoP in the FN draft is the following, which does not make sense, I = think: o Control field Control fields are transmitted from a ROHC compressor to a ROHC decompressor, but are not part of the uncompressed header itself. /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Finking, Robert > Sent: den 20 april 2005 15:31 > To: rohc@ietf.org > Subject: [rohc] FN control fields >=20 >=20 > Hi Ghyslain, Kris, All >=20 > Wow! You go to a morning meeting and while you're away the=20 > list explodes. Many thanks to you all for your contributions.=20 > OK taking into account the whole discussion, here are the=20 > main points as I see them: >=20 > - We don't have consensus > - The main obstacle is Kris and Ghyslain's disagreement > - They both live in Lule=E5 >=20 > Therefore I suggest an arm wrestling competition at sunset in=20 > the car park outside Ghyslain's apartment =3D)=20 >=20 > Seriously, this is a fairly involved issue and I'm very glad=20 > Ghyslain has joined in - thanks! The main points: >=20 > 1 Some want to be able to indicate need for context, others don't > 2 The current state of play (CSoP) in the FN draft is the latter > 3 The CSoP in the TCP-pf is the former > 4 The FN draft will have to change if it adopts the former > 5 The TCP-pf will NOT have to change if it adopts the=20 > latter, the FN in the TCP-pf will be the same either way but=20 > have a subtly different meaning > 6 It would be very good if we can fix the "non-default=20 > default let statements" bug as part of this > 7 we have endeavoured to remove formal references to context=20 > from the FN as part of the simplification we did last summer > 8 "derived" fields are currently not discussed at all in the=20 > FN draft, but since *some* mention is made of context in the=20 > draft (albeit non-formal) we need to do something to handle them > 9 The information about whether context is needed is already=20 > there in the profile, implicitly (in terms of what encoding=20 > methods are used for that field). >=20 > Here is my suggestion, which will hopefully fit all parties=20 > to an OKish degree: >=20 > - we stick with the current syntax, which keeps things simple=20 > and minimises the changes necessary > - in the TCP-pf we can use comments to indicate that context=20 > is needed for certain fields > - we clarify in the FN draft the possibility of the existence=20 > of derived fields and their use; again these can optionally=20 > be indicated by comments > - we clarify in the FN draft that "control_fields" sections=20 > are just like any other section inside a structure in that=20 > they may have a field encodings list. > - we move the non-default let statements in the FN-draft AND=20 > tcp-pf out of the default section and into either a=20 > "control_fields" field encodings list, or a "uc_format" field=20 > encodings list if that is more convenient. >=20 > Did I give a fair summary, and how does my suggestion sit=20 > with everyone? I'm guessing nobody will be over the moon=20 > about it, but hopefully all can just about swallow it? >=20 > Here's hoping! >=20 > Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:02:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10573 for ; Wed, 20 Apr 2005 10:02:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFyN-0003be-64 for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:14:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFmG-0004HV-Oh; Wed, 20 Apr 2005 10:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFmF-0004HQ-F9 for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:02:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10481 for ; Wed, 20 Apr 2005 10:02:01 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFxT-0003Zx-O0 for rohc@ietf.org; Wed, 20 Apr 2005 10:13:40 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KE1Hie015445; Wed, 20 Apr 2005 16:02:01 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:01:20 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:01:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 16:01:19 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA90@esealmw109.eemea.ericsson.se> Thread-Topic: FN control fields Thread-Index: AcVFrTI6A7P60R6HQn6B5JlYwCGrCwAA+nnQ From: "Ghyslain Pelletier \(LU/EAB\)" To: "Finking, Robert" , X-OriginalArrivalTime: 20 Apr 2005 14:01:20.0472 (UTC) FILETIME=[6DDDFD80:01C545B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > 8 "derived" fields are currently not discussed at all in the=20 > FN draft, but since *some* mention is made of context in the=20 > draft (albeit non-formal) we need to do something to handle them In the FN context is mentionned not in terms of what/how things need be = maintained but rather in terms of the operations with respect to the = attributes of a field for the coding method to succeed, and we've = (naively) mentionned context as a synonym of "attribute values". We = could remove mentions of the context as this is a concept that lives in = ROHC profiles. > 9 The information about whether context is needed is already=20 > there in the profile, implicitly (in terms of what encoding=20 > methods are used for that field). Exactly. /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:03:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10693 for ; Wed, 20 Apr 2005 10:03:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFyr-0003d7-HF for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFnb-0004Sv-EA; Wed, 20 Apr 2005 10:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFna-0004SU-PD for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10678 for ; Wed, 20 Apr 2005 10:03:25 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFyo-0003ce-22 for rohc@ietf.org; Wed, 20 Apr 2005 10:15:03 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KE3JOC005705; Wed, 20 Apr 2005 16:03:23 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:02:37 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:02:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 16:02:36 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA91@esealmw109.eemea.ericsson.se> Thread-Topic: FN control fields Thread-Index: AcVFrTI6A7P60R6HQn6B5JlYwCGrCwAAZTqwAACq25A= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Finking, Robert" , X-OriginalArrivalTime: 20 Apr 2005 14:02:36.0765 (UTC) FILETIME=[9B5760D0:01C545B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable > And the definition of control-field would then be as given by=20 > Ghyslain? > CSoP in the FN draft is the following, which does not make=20 > sense, I think: >=20 > o Control field >=20 > Control fields are transmitted from a ROHC compressor to a ROHC > decompressor, but are not part of the uncompressed=20 > header itself. Yes, this is a mistake - when I updated the draft after Washington I = forgot to make the change there. I think however that I made the changes = in other parts of the draft (at that time, I don't not what's the state = now). /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:04:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10944 for ; Wed, 20 Apr 2005 10:04:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOG0A-0003jW-CG for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:16:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFlg-0004D0-By; Wed, 20 Apr 2005 10:01:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFlf-0004Cv-Vy for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:01:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10407 for ; Wed, 20 Apr 2005 10:01:26 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFwt-0003YM-D7 for rohc@ietf.org; Wed, 20 Apr 2005 10:13:04 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3KE0dqP023775; Wed, 20 Apr 2005 15:00:39 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 15:00:56 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B2@rsys004a> Thread-Topic: [rohc] FN control fields Thread-Index: AcVFr4BUeG/zKnCKR1ux6LU/C1RRKQAAG23w From: "Finking, Robert" To: "Lars-Erik Jonsson \(LU/EAB\)" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable That is the definition in the terminology section, terse I'll admit, but = it makes sense to me - feel free to suggest alternative words though. = The Control Fields section says: 4.9.5 Control Fields Control fields are defined using the "control_fields" list. The control = fields list specifies all fields that do not appear in the uncompressed = header but which have an uncompressed value (specifically those with a = non-zero uncomp_length). Such fields may be used to help compress fields = from the uncompressed header more efficiently. A control field could be = used to improve efficiency by representing some commonality between a = number of the uncompressed fields, or by representing some information = about the flow that is not explicitly contained in the protocol headers. For example in IP, the behaviour of the IP-ID field in a flow varies = depending on how the endpoints handle IP-IDs. Sometimes the behaviour is = effectively random, sometimes the IP-ID follows a predictable sequence, = and at other times it stays fixed at zero. The type of IP-ID behaviour = is information that is never communicated explicitly in the uncompressed = header. However, a ROHC profile can still be designed to identify the = behavior and adjust the compression strategy according to the identified = behaviour, thereby improving the compression performance. To do so, the = profile can introduce an explicit field to communicate the IP-ID = behaviour in compressed headers, and in ROHC-FN terms this is done by = introducing a control field Control fields may also be used with global scope. In this case their = declaration must be outside of any structure. They are then visible = within any structure thus allowing information to be shared between = structures directly. Which hopefully makes sense? In light of this, what do you think of the = suggestion - would you accept it? Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com]=20 > Sent: Wednesday, April 20, 2005 2:46 PM > To: Finking, Robert; rohc@ietf.org > Subject: RE: [rohc] FN control fields >=20 >=20 > And the definition of control-field would then be as given by=20 > Ghyslain? > CSoP in the FN draft is the following, which does not make=20 > sense, I think: >=20 > o Control field >=20 > Control fields are transmitted from a ROHC compressor to a ROHC > decompressor, but are not part of the uncompressed=20 > header itself. >=20 > /L-E >=20 >=20 > > -----Original Message----- > > From: rohc-bounces@ietf.org=20 > [mailto:rohc-bounces@ietf.org]On Behalf Of > > Finking, Robert > > Sent: den 20 april 2005 15:31 > > To: rohc@ietf.org > > Subject: [rohc] FN control fields > >=20 > >=20 > > Hi Ghyslain, Kris, All > >=20 > > Wow! You go to a morning meeting and while you're away the=20 > > list explodes. Many thanks to you all for your contributions.=20 > > OK taking into account the whole discussion, here are the=20 > > main points as I see them: > >=20 > > - We don't have consensus > > - The main obstacle is Kris and Ghyslain's disagreement > > - They both live in Lule=E5 > >=20 > > Therefore I suggest an arm wrestling competition at sunset in=20 > > the car park outside Ghyslain's apartment =3D)=20 > >=20 > > Seriously, this is a fairly involved issue and I'm very glad=20 > > Ghyslain has joined in - thanks! The main points: > >=20 > > 1 Some want to be able to indicate need for context, others don't > > 2 The current state of play (CSoP) in the FN draft is the latter > > 3 The CSoP in the TCP-pf is the former > > 4 The FN draft will have to change if it adopts the former > > 5 The TCP-pf will NOT have to change if it adopts the=20 > > latter, the FN in the TCP-pf will be the same either way but=20 > > have a subtly different meaning > > 6 It would be very good if we can fix the "non-default=20 > > default let statements" bug as part of this > > 7 we have endeavoured to remove formal references to context=20 > > from the FN as part of the simplification we did last summer > > 8 "derived" fields are currently not discussed at all in the=20 > > FN draft, but since *some* mention is made of context in the=20 > > draft (albeit non-formal) we need to do something to handle them > > 9 The information about whether context is needed is already=20 > > there in the profile, implicitly (in terms of what encoding=20 > > methods are used for that field). > >=20 > > Here is my suggestion, which will hopefully fit all parties=20 > > to an OKish degree: > >=20 > > - we stick with the current syntax, which keeps things simple=20 > > and minimises the changes necessary > > - in the TCP-pf we can use comments to indicate that context=20 > > is needed for certain fields > > - we clarify in the FN draft the possibility of the existence=20 > > of derived fields and their use; again these can optionally=20 > > be indicated by comments > > - we clarify in the FN draft that "control_fields" sections=20 > > are just like any other section inside a structure in that=20 > > they may have a field encodings list. > > - we move the non-default let statements in the FN-draft AND=20 > > tcp-pf out of the default section and into either a=20 > > "control_fields" field encodings list, or a "uc_format" field=20 > > encodings list if that is more convenient. > >=20 > > Did I give a fair summary, and how does my suggestion sit=20 > > with everyone? I'm guessing nobody will be over the moon=20 > > about it, but hopefully all can just about swallow it? > >=20 > > Here's hoping! > >=20 > > Raffles >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:14:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12323 for ; Wed, 20 Apr 2005 10:14:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOG9w-000429-CC for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:26:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFu3-0005bN-7k; Wed, 20 Apr 2005 10:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFu1-0005ar-Nw for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:10:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11714 for ; Wed, 20 Apr 2005 10:10:04 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOG5F-0003s6-3M for rohc@ietf.org; Wed, 20 Apr 2005 10:21:42 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KE7llq016704; Wed, 20 Apr 2005 16:10:03 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:09:17 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:09:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 16:09:16 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2803@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN control fields Thread-Index: AcVFr4BUeG/zKnCKR1ux6LU/C1RRKQAAG23wAACI7gA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Finking, Robert" , X-OriginalArrivalTime: 20 Apr 2005 14:09:17.0171 (UTC) FILETIME=[8A007C30:01C545B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > That is the definition in the terminology section, terse I'll=20 > admit, but it makes sense to me - feel free to suggest=20 > alternative words though. The Control Fields section says: It doesn't make sense, as it says control fields are transmitted from compressor to decompressor, which is not always the case. Neither is it much of a short summary of what a control field actually is. =20 > Which hopefully makes sense? In light of this, what do you=20 > think of the suggestion - would you accept it? Well, as I have said in my previous mail, I do not care. If you can get both GP and KS to agree on one single solution, then I think we can move on.=20 /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:15:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12416 for ; Wed, 20 Apr 2005 10:15:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGAW-00043D-1S for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:27:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFya-0006Lt-KA; Wed, 20 Apr 2005 10:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFyY-0006Lo-Qc for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:14:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12294 for ; Wed, 20 Apr 2005 10:14:45 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOG9n-00041s-7j for rohc@ietf.org; Wed, 20 Apr 2005 10:26:23 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3KDDvmg015933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Apr 2005 15:13:59 +0200 Message-ID: <426663CF.4090805@effnet.com> Date: Wed, 20 Apr 2005 16:14:39 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN control fields References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B0@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B0@rsys004a> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by effnet.com id j3KDDvmg015933 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Hi all, I have an even better solution, replace FN with box notation and english! From what I understand of Ghyslains solution, all fields not part of the= =20 uc_format needs to be defined as control_fields, right? If so, co_baseheader will have the following: control_fields =3D discriminator, ttl_hopl_outer_flag, seq_indicator, ack_indicator, ack_stride_indicator, window_indicator, ip_id_indicator, urg_ptr_present, tos_tc_present, ttl_hopl_present, list_present, header_crc, options_list; (not including those already defined global fields) What I'm trying to point out here is that co_baseheader has 21 different=20 co_formats, but only one place to declare the control_fields, and of the = fields=20 above, almost all are for co_common, and the other 20 formats need to "se= e" the=20 other variables in their scope just because of this new way of having con= trol=20 fields. This is supposed to make things more clearer and simpler? (it works, sure= , but=20 this will clutter things to a point where I want to throw up). This solution seems to me like we have to declare everything one scope ou= tside=20 of where it is needed. Ugly! I hope someone with access to the CVS that isn't me makes these ugly chan= ges to=20 the tcp-pf *grumpy* /Kristofer Finking, Robert wrote: > Hi Ghyslain, Kris, All >=20 > Wow! You go to a morning meeting and while you're away the list explode= s. Many thanks to you all for your contributions. OK taking into account = the whole discussion, here are the main points as I see them: >=20 > - We don't have consensus > - The main obstacle is Kris and Ghyslain's disagreement > - They both live in Lule=E5 >=20 > Therefore I suggest an arm wrestling competition at sunset in the car p= ark outside Ghyslain's apartment =3D)=20 >=20 > Seriously, this is a fairly involved issue and I'm very glad Ghyslain h= as joined in - thanks! The main points: >=20 > 1 Some want to be able to indicate need for context, others don't > 2 The current state of play (CSoP) in the FN draft is the latter > 3 The CSoP in the TCP-pf is the former > 4 The FN draft will have to change if it adopts the former > 5 The TCP-pf will NOT have to change if it adopts the latter, the FN i= n the TCP-pf will be the same either way but have a subtly different mean= ing > 6 It would be very good if we can fix the "non-default default let sta= tements" bug as part of this > 7 we have endeavoured to remove formal references to context from the = FN as part of the simplification we did last summer > 8 "derived" fields are currently not discussed at all in the FN draft,= but since *some* mention is made of context in the draft (albeit non-for= mal) we need to do something to handle them > 9 The information about whether context is needed is already there in = the profile, implicitly (in terms of what encoding methods are used for t= hat field). >=20 > Here is my suggestion, which will hopefully fit all parties to an OKish= degree: >=20 > - we stick with the current syntax, which keeps things simple and minim= ises the changes necessary > - in the TCP-pf we can use comments to indicate that context is needed = for certain fields > - we clarify in the FN draft the possibility of the existence of derive= d fields and their use; again these can optionally be indicated by commen= ts > - we clarify in the FN draft that "control_fields" sections are just li= ke any other section inside a structure in that they may have a field enc= odings list. > - we move the non-default let statements in the FN-draft AND tcp-pf out= of the default section and into either a "control_fields" field encoding= s list, or a "uc_format" field encodings list if that is more convenient. >=20 > Did I give a fair summary, and how does my suggestion sit with everyone= ? I'm guessing nobody will be over the moon about it, but hopefully all c= an just about swallow it? >=20 > Here's hoping! >=20 > Raffles >=20 >=20 >=20 > Robert Finking (01794 833189) > Roke Manor Research (http://www.roke.co.uk) > Romsey, Hampshire SO51 0ZN >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:17:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12699 for ; Wed, 20 Apr 2005 10:17:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGCT-00045i-Oq for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:29:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOG0f-0006bA-4w; Wed, 20 Apr 2005 10:16:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOG0e-0006b5-CQ for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:16:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12627 for ; Wed, 20 Apr 2005 10:16:54 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGBr-00045C-Qq for rohc@ietf.org; Wed, 20 Apr 2005 10:28:33 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3KEG9kh002679; Wed, 20 Apr 2005 16:16:53 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:16:52 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:16:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 16:16:52 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2804@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN control fields Thread-Index: AcVFs2N/N1J4ExqZTVSG5j50c8JaAwAABK5Q From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Finking, Robert" , X-OriginalArrivalTime: 20 Apr 2005 14:16:52.0762 (UTC) FILETIME=[998E27A0:01C545B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable > > It doesn't make sense, as it says control fields are transmitted > > from compressor to decompressor, which is not always the case. > > Neither is it much of a short summary of what a control field > > actually is. >=20 > Oops, yes good point! Please do suggest alternative text -=20 > you have made lots of other useful suggestions during the=20 > review process! I leave that to Ghyslain! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:18:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12794 for ; Wed, 20 Apr 2005 10:18:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGD0-00046X-0A for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:29:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFzK-0006Rd-8G; Wed, 20 Apr 2005 10:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFzI-0006RY-JZ for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:15:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12434 for ; Wed, 20 Apr 2005 10:15:31 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGAV-000430-SX for rohc@ietf.org; Wed, 20 Apr 2005 10:27:09 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3KEFEqP028419; Wed, 20 Apr 2005 15:15:14 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 15:15:41 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B4@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , rohc@ietf.org Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 15:15:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > It doesn't make sense, as it says control fields are transmitted > from compressor to decompressor, which is not always the case. > Neither is it much of a short summary of what a control field > actually is. Oops, yes good point! Please do suggest alternative text - you have made lots of other useful suggestions during the review process! > > > > Which hopefully makes sense? In light of this, what do you > > think of the suggestion - would you accept it? > > Well, as I have said in my previous mail, I do not care. If you > can get both GP and KS to agree on one single solution, then I > think we can move on. OK - thank you. I'm sorry that it is not ideal! Regards Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 10:24:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13616 for ; Wed, 20 Apr 2005 10:24:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGIk-0004Lx-HM for rohc-archive@ietf.org; Wed, 20 Apr 2005 10:35:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOG3o-00079w-Nv; Wed, 20 Apr 2005 10:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOG3n-00079j-SZ for rohc@megatron.ietf.org; Wed, 20 Apr 2005 10:20:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13154 for ; Wed, 20 Apr 2005 10:20:10 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGF2-0004F0-6Q for rohc@ietf.org; Wed, 20 Apr 2005 10:31:48 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3KEJiqP029663; Wed, 20 Apr 2005 15:19:47 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 15:20:11 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B5@rsys004a> From: "Finking, Robert" To: "'Kristofer Sandlund'" Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 15:19:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable LOL thanks for having a good sense of humour =3D) Inline Raffles > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 > Sent: Wednesday, April 20, 2005 3:15 PM > To: Finking, Robert > Cc: rohc@ietf.org > Subject: Re: [rohc] FN control fields >=20 >=20 > Hi all, >=20 > > I have an even better solution, replace FN with box notation=20 > and english! > >=20 > From what I understand of Ghyslains solution, all fields not=20 > part of the=20 > uc_format needs to be defined as control_fields, right? No, that's not correct, only those with an uncompressed side = (specifically those with a greater than zero uncomp_length). Which I = think means almost all of those in your list dissapear - phew! > If so, co_baseheader will have the following: > control_fields =3D > discriminator, > ttl_hopl_outer_flag, > seq_indicator, > ack_indicator, > ack_stride_indicator, > window_indicator, > ip_id_indicator, > urg_ptr_present, > tos_tc_present, > ttl_hopl_present, > list_present, > header_crc, > options_list; > (not including those already defined global fields) >=20 > What I'm trying to point out here is that co_baseheader has=20 > 21 different=20 > co_formats, but only one place to declare the control_fields,=20 > and of the fields=20 > above, almost all are for co_common, and the other 20 formats=20 > need to "see" the=20 > other variables in their scope just because of this new way=20 > of having control=20 > fields. > This is supposed to make things more clearer and simpler? (it=20 > works, sure, but=20 > this will clutter things to a point where I want to throw up). >=20 > This solution seems to me like we have to declare everything=20 > one scope outside=20 > of where it is needed. Ugly! >=20 > I hope someone with access to the CVS that isn't me makes=20 > these ugly changes to=20 > the tcp-pf *grumpy* >=20 > /Kristofer >=20 >=20 >=20 > Finking, Robert wrote: > > Hi Ghyslain, Kris, All > >=20 > > Wow! You go to a morning meeting and while you're away the=20 > list explodes. Many thanks to you all for your contributions.=20 > OK taking into account the whole discussion, here are the=20 > main points as I see them: > >=20 > > - We don't have consensus > > - The main obstacle is Kris and Ghyslain's disagreement > > - They both live in Lule=E5 > >=20 > > Therefore I suggest an arm wrestling competition at sunset=20 > in the car park outside Ghyslain's apartment =3D)=20 > >=20 > > Seriously, this is a fairly involved issue and I'm very=20 > glad Ghyslain has joined in - thanks! The main points: > >=20 > > 1 Some want to be able to indicate need for context, others don't > > 2 The current state of play (CSoP) in the FN draft is the latter > > 3 The CSoP in the TCP-pf is the former > > 4 The FN draft will have to change if it adopts the former > > 5 The TCP-pf will NOT have to change if it adopts the=20 > latter, the FN in the TCP-pf will be the same either way but=20 > have a subtly different meaning > > 6 It would be very good if we can fix the "non-default=20 > default let statements" bug as part of this > > 7 we have endeavoured to remove formal references to=20 > context from the FN as part of the simplification we did last summer > > 8 "derived" fields are currently not discussed at all in=20 > the FN draft, but since *some* mention is made of context in=20 > the draft (albeit non-formal) we need to do something to handle them > > 9 The information about whether context is needed is > already there in the profile, implicitly (in terms of what=20 > encoding methods are used for that field). > >=20 > > Here is my suggestion, which will hopefully fit all parties=20 > to an OKish degree: > >=20 > > - we stick with the current syntax, which keeps things=20 > simple and minimises the changes necessary > > - in the TCP-pf we can use comments to indicate that=20 > context is needed for certain fields > > - we clarify in the FN draft the possibility of the=20 > existence of derived fields and their use; again these can=20 > optionally be indicated by comments > > - we clarify in the FN draft that "control_fields" sections=20 > are just like any other section inside a structure in that=20 > they may have a field encodings list. > > - we move the non-default let statements in the FN-draft=20 > AND tcp-pf out of the default section and into either a=20 > "control_fields" field encodings list, or a "uc_format" field=20 > encodings list if that is more convenient. > >=20 > > Did I give a fair summary, and how does my suggestion sit=20 > with everyone? I'm guessing nobody will be over the moon=20 > about it, but hopefully all can just about swallow it? > >=20 > > Here's hoping! > >=20 > > Raffles > >=20 > >=20 > >=20 > > Robert Finking (01794 833189) > > Roke Manor Research (http://www.roke.co.uk) > > Romsey, Hampshire SO51 0ZN > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 11:01:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17630 for ; Wed, 20 Apr 2005 11:01:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGtF-0005g8-NW for rohc-archive@ietf.org; Wed, 20 Apr 2005 11:13:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGgr-0004Au-D3; Wed, 20 Apr 2005 11:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGgp-0004Ah-MX for rohc@megatron.ietf.org; Wed, 20 Apr 2005 11:00:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17513 for ; Wed, 20 Apr 2005 11:00:29 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGs4-0005bq-Jd for rohc@ietf.org; Wed, 20 Apr 2005 11:12:09 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3KF0Hu3014148; Wed, 20 Apr 2005 17:00:19 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B2@rsys004a> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28B2@rsys004a> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] FN control fields Date: Wed, 20 Apr 2005 17:00:17 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit The control_field section we invented at IETF61 were a way to say, for a field: the uncompressed side of the field is somehow supplied by the profile/state machine. (Without the control_field section, this would have to be expressed by parameters and let statements, which for nested encoding methods can become awkward quickly, so this is a welcome shorthand). Now let's see: > > 4.9.5 Control Fields > > Control fields are defined using the "control_fields" list. The > control fields list specifies all fields that do not appear in the > uncompressed header Well, typically, they don't. (This is not a requirement.) > but which have an uncompressed value all fields do. > (specifically those with a non-zero uncomp_length). That's what you mean, OK. > Such fields may be used to help compress fields from the uncompressed > header more efficiently. (I hope that's true of everything we can do in FN.) > A control field could be used to improve efficiency by representing > some commonality between a number of the uncompressed fields, or by > representing some information about the flow that is not explicitly > contained in the protocol headers. This seems to be alluding to the fact that the information supplied by the profile/state machine is often something we have called context in earlier documents. I think we long agreed that we didn't know how to represent context in FN, so control_fields was a good way to punt this issue. > For example in IP, the behaviour of the IP-ID field in a flow varies > depending on how the endpoints handle IP-IDs. Sometimes the behaviour > is effectively random, sometimes the IP-ID follows a predictable > sequence, and at other times it stays fixed at zero. The type of IP-ID > behaviour is information that is never communicated explicitly in the > uncompressed header. However, a ROHC profile can still be designed to > identify the behavior and adjust the compression strategy according to > the identified behaviour, thereby improving the compression > performance. To do so, the profile can introduce an explicit field to > communicate the IP-ID behaviour in compressed headers, and in ROHC-FN > terms this is done by introducing a control field Wait, wait, wait. First of all, this is another example of mixing definition with example. (We have to make sure all examples are clearly identified as such!) Second: This text seems to suggest we send a bit or two in every compressed packet that identifies the IP-ID encoding variant being used. Of course the point here is that the profile/state machine can remember and supply this information -- as a control_fields field! > Control fields may also be used with global scope. In this case their > declaration must be outside of any structure. They are then visible > within any structure thus allowing information to be shared between > structures directly. Essentially, I think this is saying that a globally declared control_fields field is visible in every structure. (Which is fine, as field that isn't used does not harm.) It also means that the profile/state machine has to supply these values for every "call" to a structure (i.e., the field becomes an implicit part of the interface between the part specified by the FN specification and the profile/state machine). This can sometimes hurt a bit, but I think is mitigated by the fact that if a control_fields field is not used, it does not matter what is being supplied here. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 11:15:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18698 for ; Wed, 20 Apr 2005 11:15:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOH6v-00066j-0H for rohc-archive@ietf.org; Wed, 20 Apr 2005 11:27:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGuP-0005yv-MU; Wed, 20 Apr 2005 11:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGuO-0005yZ-GA for rohc@megatron.ietf.org; Wed, 20 Apr 2005 11:14:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18583 for ; Wed, 20 Apr 2005 11:14:30 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOH5d-00064s-D6 for rohc@ietf.org; Wed, 20 Apr 2005 11:26:09 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3KFEKqP012360; Wed, 20 Apr 2005 16:14:20 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 16:14:47 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28BC@rsys004a> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] FN control fields Date: Wed, 20 Apr 2005 16:14:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Hi Carsten, Many thanks for the input. The review comments on the control field section are useful as always. Can I ask you specifically about the current proposal (from the head of this thread - rationale contained therein): - we stick with the current syntax, which keeps things simple and minimises the changes necessary - in the TCP-pf we can use comments to indicate that context is needed for certain fields - we clarify in the FN draft the possibility of the existence of derived fields and their use; again these can optionally be indicated by comments - we clarify in the FN draft that "control_fields" sections are just like any other section inside a structure in that they may have a field encodings list. - we move the non-default let statements in the FN-draft AND tcp-pf out of the default section and into either a "control_fields" field encodings list, or a "uc_format" field encodings list if that is more convenient. Even if this is not ideal from your point of view, are you prepared to accept this? L-E and Kris (offline) have accepted it so far, albeit in a "not really what I wanted" sort of way! I'm hoping Ghyslain will be happy with it since it is very close to what he wants (I think maybe he may prefer it to apply to *all* fields which aren't in the compressed header though, not just those which have greater than zero uncomp_length). Thanks again for your input everybody - this would be taking months otherwise! Cheers Raffles > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, April 20, 2005 4:00 PM > To: Finking, Robert > Cc: Lars-Erik Jonsson (LU/EAB); Carsten Bormann; rohc@ietf.org > Subject: Re: [rohc] FN control fields > > > The control_field section we invented at IETF61 were a way to > say, for > a field: the uncompressed side of the field is somehow > supplied by the > profile/state machine. > (Without the control_field section, this would have to be > expressed by > parameters and let statements, which for nested encoding methods can > become awkward quickly, so this is a welcome shorthand). > > Now let's see: > > > > > 4.9.5 Control Fields > > > > Control fields are defined using the "control_fields" list. The > > control fields list specifies all fields that do not appear in the > > uncompressed header > > Well, typically, they don't. (This is not a requirement.) > > > but which have an uncompressed value > > all fields do. > > > (specifically those with a non-zero uncomp_length). > > That's what you mean, OK. > > > Such fields may be used to help compress fields from the > uncompressed > > header more efficiently. > > (I hope that's true of everything we can do in FN.) > > > A control field could be used to improve efficiency by representing > > some commonality between a number of the uncompressed fields, or by > > representing some information about the flow that is not explicitly > > contained in the protocol headers. > > This seems to be alluding to the fact that the information > supplied by > the profile/state machine is often something we have called > context in > earlier documents. > I think we long agreed that we didn't know how to represent > context in > FN, so control_fields was a good way to punt this issue. > > > For example in IP, the behaviour of the IP-ID field in a > flow varies > > depending on how the endpoints handle IP-IDs. Sometimes the > behaviour > > is effectively random, sometimes the IP-ID follows a predictable > > sequence, and at other times it stays fixed at zero. The > type of IP-ID > > behaviour is information that is never communicated > explicitly in the > > uncompressed header. However, a ROHC profile can still be > designed to > > identify the behavior and adjust the compression strategy > according to > > the identified behaviour, thereby improving the compression > > performance. To do so, the profile can introduce an > explicit field to > > communicate the IP-ID behaviour in compressed headers, and > in ROHC-FN > > terms this is done by introducing a control field > > Wait, wait, wait. > First of all, this is another example of mixing definition > with example. > (We have to make sure all examples are clearly identified as such!) > Second: This text seems to suggest we send a bit or two in every > compressed packet that identifies the IP-ID encoding variant being > used. > Of course the point here is that the profile/state machine > can remember > and supply this information -- as a control_fields field! > > > Control fields may also be used with global scope. In this > case their > > declaration must be outside of any structure. They are then visible > > within any structure thus allowing information to be shared between > > structures directly. > > Essentially, I think this is saying that a globally declared > control_fields field is visible in every structure. > (Which is fine, as field that isn't used does not harm.) > It also means that the profile/state machine has to supply > these values > for every "call" to a structure (i.e., the field becomes an implicit > part of the interface between the part specified by the FN > specification and the profile/state machine). This can > sometimes hurt > a bit, but I think is mitigated by the fact that if a control_fields > field is not used, it does not matter what is being supplied here. > > Gruesse, Carsten > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Apr 20 12:24:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24508 for ; Wed, 20 Apr 2005 12:24:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOIBY-0008Fl-R2 for rohc-archive@ietf.org; Wed, 20 Apr 2005 12:36:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHzo-0007fd-TD; Wed, 20 Apr 2005 12:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOHzk-0007f1-Si for rohc@megatron.ietf.org; Wed, 20 Apr 2005 12:24:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24419 for ; Wed, 20 Apr 2005 12:24:06 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOIAz-0008EZ-G8 for rohc@ietf.org; Wed, 20 Apr 2005 12:35:46 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3KGNlqP031327; Wed, 20 Apr 2005 17:23:49 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 17:24:14 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5F15@rsys004a> From: "Surtees, Abigail" To: "'Lepine, Jean-Pierre'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation and the state retention priorit y Date: Wed, 20 Apr 2005 17:23:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.9 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0380238972==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0380238972== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C545C5.1825CBF2" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C545C5.1825CBF2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre, =20 You are correct that a newer piece of low priority state can push out = an older piece of high priority state. It does indeed mean that a = compressor must be careful with both priority and order of state = creation requests. I'm afraid I don't recall what the motivation for = this was. =20 Best regards, =20 Abbie -----Original Message----- From: Lepine, Jean-Pierre [mailto:jeanpierre.lepine@smisrd.com]=20 Sent: Tuesday, April 12, 2005 1:31 PM To: rohc@ietf.org Subject: [rohc] SigComp state creation and the state retention priority Hi everybody, =20 I sent the following email almost 2 weeks ago but I didn't get any = feedback on it. I would really appreciate a follow-up on this. Thanks. =20 -----Message d'origine----- De : Lepine, Jean-Pierre=20 Envoy=E9 : 31 mars, 2005 08:58 =C0 : rohc@ietf.org Objet : SigComp state creation and the state retention priority Hi all, =20 I would just like to confirm something regarding SigComp state creation = and the state retention priority. =20 Initially, I thought that trying to create a state item in a = compartment could NEVER push state items with a higher priority out of = the compartment. In particular, suppose a compartment uses its full = amount of SMS with state items of priority 1, I thought that trying to = create a state item with priority 0 would fail without any effect on = the compartment's content. =20 However, after reviewing RFC 3320, I now understand that for the above = example, one or more state items of priority 1 MUST be pushed out of = the compartment (freed) until enough memory is available to create the = state item of priority 0. More generally, a state item with a given = priority, even the highest, CAN be pushed out of a compartment by the = creation of state items with lower priorities. In other words, a newer = state item is considered more important than an older state item, even = if the older one has a higher priority. =20 Am I right ? =20 If so, I guess there are some key motivations behind this design choice = but I don't really see them. I find this to be not very practical as a = compressor must be careful not only with the chosen state priorities, = but also with the order of state creation requests.=20 =20 ------_=_NextPart_001_01C545C5.1825CBF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi  Jean-Pierre,
 
You=20 are correct that a newer piece of low priority state can push out an = older piece=20 of high priority state.  It does indeed mean that a compressor = must be=20 careful with both priority and order of state creation requests.  = I'm=20 afraid I don't recall what the motivation for this = was.
 
Best=20 regards,
 
Abbie
-----Original Message-----
From: = Lepine,=20 Jean-Pierre [mailto:jeanpierre.lepine@smisrd.com]
Sent: = Tuesday,=20 April 12, 2005 1:31 PM
To: rohc@ietf.org
Subject: = [rohc]=20 SigComp state creation and the state retention = priority

Hi=20 everybody,
 
I=20 sent the following email almost 2 weeks ago but I didn't get any = feedback on=20 it.
I=20 would really appreciate a follow-up on this.
Thanks.
 
-----Message d'origine-----
De : Lepine, = Jean-Pierre=20
Envoy=E9 : 31 mars, 2005 08:58
=C0 :=20 rohc@ietf.org
Objet : SigComp state creation and the = state=20 retention priority

Hi=20 all,
 
I = would just like=20 to confirm something regarding SigComp state creation and the state = retention=20 priority.
 
Initially, I=20 thought that trying to create a state item in a compartment could = NEVER push=20 state items with a higher priority out of the compartment. In = particular,=20 suppose a compartment uses its full amount of SMS with state items of = priority=20 1, I thought that trying to create a state item with priority 0 would = fail=20 without any effect on the compartment's content.
 
However, after=20 reviewing RFC 3320, I now understand that for the above example, one = or more=20 state items of priority 1 MUST be pushed out of the compartment = (freed) until=20 enough memory is available to create the state item of priority 0.=20 More=20 generally, a state item with a given priority, even the highest, CAN = be pushed=20 out of a compartment by the creation of state items with lower=20 priorities. In other words, a newer state item is considered more = important=20 than an older state item, even if the older one has a higher=20 priority.
 
Am = I right=20 ?
 
If = so, I guess=20 there are some key motivations behind this design choice but I don't = really=20 see them. I find this to be not very practical as a compressor must = be careful=20 not only with the chosen state priorities, but also with the order of = state=20 creation requests.
 
------_=_NextPart_001_01C545C5.1825CBF2-- --===============0380238972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0380238972==-- From rohc-bounces@ietf.org Thu Apr 21 04:36:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05738 for ; Thu, 21 Apr 2005 04:36:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXMQ-0007Wi-SP for rohc-archive@ietf.org; Thu, 21 Apr 2005 04:48:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXAl-0001Ao-KD; Thu, 21 Apr 2005 04:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXAj-0001AW-7U for rohc@megatron.ietf.org; Thu, 21 Apr 2005 04:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05672 for ; Thu, 21 Apr 2005 04:36:27 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXM6-0007V1-OP for rohc@ietf.org; Thu, 21 Apr 2005 04:48:15 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3L7Zimg018910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Apr 2005 09:35:44 +0200 Message-ID: <42676606.2050409@effnet.com> Date: Thu, 21 Apr 2005 10:36:22 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Subject: [rohc] Proposed changes to rohc-tcp-09 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Hi all! I've gone through on rohc-tcp-09 and found once more a lot of room for improvements. Probably lots more than those I've listed here! First of all, I have already done two changes to the tcp-pf document in the CVS, which have both been decided on long ago, these are: - Fixed IPID-behavior (symbolic constant use and IPv6 using RANDOM) (v.1.39) in the CVS as discussed earlier. - Removed "list_tcp_options". This syntax is no longer in FN spec, and we need to define this in English in the tcp-draft instead. Changed so that the list_tcp_options is a reference at the start of the definitions. (v.1.40) Apart from that, the packet formats still have a couple of open issues regarding notating the scaled encoding and the moving of let-statements out of default_methods. TEXT ADDITIONS/CHANGES FOR LIST COMPRESSION ---- - 7.2.4 should not have any references to ROHC-FN. - New section between 7.2.3 and 7.2.4 describing the format of type 0 lists header in box notation. Must also describe how to put together the xi list and the item list. I can volunteer to write this stuff, but could it be possible that we can put the source for this in the CVS (even if it is still in word) so that we can get some speed up on the editing? I'm not fond of the "centralized" editing we've been doing on this document. OTHER CHANGES TO TCP-09 --- (mostly structural changes, since we kind of rushed out -09 for the draft deadline and me and Ghyslain had different opinions on how to divide the chapters) - 4.6.1 should be 4.7. - "5.1.4.2. Optional Acknowledgements (ACKs), Upward Transition", why have the word "optional" in the section title, the fact that they are optional is probably enough to have in the section text itself. - "5.1.4.4. Negative ACKs (NACKs), Downward Transition" - is the text and title correct? A NACK does not necessarily take the compressor to IR-state, a STATIC-NACK does. A regular NACK will just require an IR-DYN to be sent. Need to polish this text to cover both types of nacks. - Should we really mention k_1/n_1 and k_2/n_2 for the downward transitions. We know that putting names to these things caused quite awkward discussions in certain other standards bodies (no names), so why not just talk about "confidence that context is invalid" or something like that. The k_1 stuff is too much of an implementation choice to be mentioned. - I know this was discussed on the list a couple of years ago, but why do we need "5.1.5. State Machine Supporting Context Replication"? This state machine is already described in the CR draft itself.... Maybe I should extend this question to "why do we even need any state machines, they just describe a specific way of implementing things and not actually much normative logic", but maybe some people want states to be able to relate to 3095 (where they are equally pointless)? - Move section 7.1 (chains) to before 6.1 - Move section 7.2 to either inside 6.1 or to a new section directly before 6.1. - Move section 6.2 (feedback considerations) somewhere inside section 5, perhaps combine it with feedback logic in 5.2.7? - Rename section 6.3 from "Control Fields..." to something like "Context Persistent Fields" due to the (silly) change of the meaning of control_fields in the FN. Otherwise, we're overloading the term. - Section "6.5 Initialization" should be section in 5. Seems like it really covers the same territory as to 5.1.1 and 5.2.4 and should be merged in there somehow. - Rename section 6, but to what? "Fields encodings and Context"? It will only contain the profile-specific encodings, the control fields and the crc section with the changes above. - Rename section 7 to "Structure of ROHC-TCP Packets" or something else (if the above is done, then we only have 7.3-7.5 here, which seems like a good chapter division. - Is it really a point in dividing the FN-definitions in section 8.2-8.9 into sections? Isn't that like dividing MIB code into sections (and at least the ROHC-MIB is not divided that way)? After all, this is code, even if it is our own make-belive FN language! - Next time the tcp-pf.txt is copied into the draft, DO NOT remove the box notation (for all the people I have made read the document, I've had to give them the tcp-pf document so that they could get easy reference to how things work), and DO NOT remove the initial part of the file with the references to profile-specific encodings. - Swap places of 8.9.2.6 and 8.9.2.7 It the source ends up in the CVS, I can take a stab at editing most of these changes the next few days so we can get some progress after standing still with this document for quite some time now. Comments, please! BR, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 05:02:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07782 for ; Thu, 21 Apr 2005 05:02:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXky-00081U-Jn for rohc-archive@ietf.org; Thu, 21 Apr 2005 05:13:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXW9-0003YP-Mz; Thu, 21 Apr 2005 04:58:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXW6-0003YF-Tx for rohc@megatron.ietf.org; Thu, 21 Apr 2005 04:58:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07487 for ; Thu, 21 Apr 2005 04:58:32 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXhT-0007wd-Qc for rohc@ietf.org; Thu, 21 Apr 2005 05:10:21 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3L8w2h8011345; Thu, 21 Apr 2005 10:58:30 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 10:58:28 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 10:58:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Thu, 21 Apr 2005 10:58:27 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA97@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN control fields Thread-Index: AcVFtKi6vFc1G6/KRvymAP1tIyG15wAmkP1Q From: "Ghyslain Pelletier \(LU/EAB\)" To: "Finking, Robert" , "Kristofer Sandlund" X-OriginalArrivalTime: 21 Apr 2005 08:58:28.0052 (UTC) FILETIME=[48AC8140:01C54650] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable > > From what I understand of Ghyslains solution, all fields not=20 > > part of the=20 > > uc_format needs to be defined as control_fields, right? >=20 > No, that's not correct, only those with an uncompressed side=20 > (specifically those with a greater than zero uncomp_length).=20 > Which I think means almost all of those in your list dissapear - phew! =20 So far, I have only discussed about properties of control fields, that I = thought that we had agreed before that they have the same properties as = uncompressed fields and can be used in the same manner. I also want to = avoid talking about context (what the implementation needs to remember) = in the FN. Defining the fields in the notation in my understanding we were already = doing as Robert explained, which also correspond to what I thought we = had agreed. This is what I meant when I wrote that the uncomp value of = control fields can be undefined (ok in FN) but that this attribute = cannot then be used in an expression since it would also be undefined = (not allowed in FN). So Robert's answer does correspond to what I = previously understood was the agreement. My proposal to define control fields was the following: > I propose that control fields be defined as follow: >=20 > There are three types of fields: uncompressed fields, control=20 > fields and compressed fields. Control fields share the exact=20 > same properties as uncompressed fields in that they can have=20 > attributes, they can be compressed, and must be defined=20 > within their useful scope. The difference from uncompressed=20 > fields is that they are not part of the uncompressed header=20 > but rather created to help in the compression of uncompressed=20 > fields, and may be sent as part of the compressed header in=20 > packet formats. Just like other fields, profile may have to=20 > specify in some way how their value is maintain in the=20 > compressor and decompressor context (this is based on the=20 > usage of the control field - e.g. if it's definition and=20 > usage depends only of uncompressed values that are always=20 > present in the uncompressed header, or if the field can=20 > sometimes be compressed and sent along in the compressed header). >=20 > I.e. this also means that the :uncomp attribute of control=20 > fields _may_ be undefined, as long as this attribute is not=20 > used explicitly within the definition of packet formats (the=20 > use of undefined value is undefined) and as long as the=20 > control field is not compressed. So, as you can't see actually I did not proposed anyting regarding how = they can be defined, but this of course should be clarified somewhere in = the FN. /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 05:05:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08077 for ; Thu, 21 Apr 2005 05:05:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXnn-00085l-O5 for rohc-archive@ietf.org; Thu, 21 Apr 2005 05:16:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXbh-00048L-Cq; Thu, 21 Apr 2005 05:04:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXbg-00047m-2Q for rohc@megatron.ietf.org; Thu, 21 Apr 2005 05:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07986 for ; Thu, 21 Apr 2005 05:04:18 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXn4-00084Y-El for rohc@ietf.org; Thu, 21 Apr 2005 05:16:06 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3L94Hfo012441; Thu, 21 Apr 2005 11:04:17 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:04:16 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:04:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Thu, 21 Apr 2005 11:04:15 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2807@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 Thread-Index: AcVGTo73pKL0jIYmQ9ClZ/gTovZ4AQAAfpgA From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kristofer Sandlund" , X-OriginalArrivalTime: 21 Apr 2005 09:04:16.0258 (UTC) FILETIME=[18388620:01C54651] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > I can volunteer to write this stuff, but could it be possible=20 > that we can put the source for this in the CVS (even if it is > still in word) so that we can get some speed up on the editing? > I'm not fond of the "centralized" editing we've been doing on > this document. Kristofer, Feel free to discuss with the editor about helping out with the editing of this document, but it is up to the editor how to do this. I will hold the editor responsible for all changes, and for making sure that all changes are based on what has been agreed, even if he gets help from others with writing text. Rgds, /L-E (Big chair hat on) _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 05:10:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08742 for ; Thu, 21 Apr 2005 05:10:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXsy-0008DD-40 for rohc-archive@ietf.org; Thu, 21 Apr 2005 05:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXfU-0004U2-97; Thu, 21 Apr 2005 05:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOXfQ-0004Tw-77 for rohc@megatron.ietf.org; Thu, 21 Apr 2005 05:08:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08271 for ; Thu, 21 Apr 2005 05:08:10 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOXqo-00089B-FR for rohc@ietf.org; Thu, 21 Apr 2005 05:19:59 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3L97uh9001634; Thu, 21 Apr 2005 11:08:10 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:08:07 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:08:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FN control fields Date: Thu, 21 Apr 2005 11:08:07 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA98@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] FN control fields Thread-Index: AcVFu7SaURtP2DOfQhmInKAtjA1GdQAkksNw From: "Ghyslain Pelletier \(LU/EAB\)" To: "Finking, Robert" , "Carsten Bormann" X-OriginalArrivalTime: 21 Apr 2005 09:08:07.0492 (UTC) FILETIME=[A20C0840:01C54651] X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable Carsten, Robert, Robert, thanks for summarizing and bringing order to this discussion. And thanks Carsten for clarifying what we had agreed in Washington, I = think corresponds with what I tried (but obviously failed to) explain = clearly since it seem to agree with treating control_fields just like = uncompressed fields in terms of their properties, as well as avoiding = talking anything related to context and persistency of fields thereof. Comments inline. /Ghyslain > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Finking, Robert > Sent: den 20 april 2005 17:14 > To: 'Carsten Bormann' > Cc: rohc@ietf.org; Lars-Erik Jonsson (LU/EAB) > Subject: RE: [rohc] FN control fields >=20 >=20 > Hi Carsten, >=20 > Many thanks for the input. The review comments on the control=20 > field section are useful as always. Can I ask you=20 > specifically about the current proposal (from the head of=20 > this thread - rationale contained therein): >=20 > - we stick with the current syntax, which keeps things simple=20 > and minimises the changes necessary Yes please. > - in the TCP-pf we can use comments to indicate that context=20 > is needed for certain fields Ok. This is in the profile document, thus the correct scope in my = opinion. > - we clarify in the FN draft the possibility of the existence=20 > of derived fields and their use; again these can optionally=20 > be indicated by comments No, I disagree. But we could mention that it is up to the profile = specification to provide guidelines on = lifetime/persistency/updating/whatever how different values of = attributes of different types of fields need to be maintained. But = please don't define something new with new terms e.g. "derived fields" = without have any formal meaning or use in the FN. > - we clarify in the FN draft that "control_fields" sections=20 > are just like any other section inside a structure in that=20 > they may have a field encodings list. Yes please. > - we move the non-default let statements in the FN-draft AND=20 > tcp-pf out of the default section and into either a=20 > "control_fields" field encodings list, or a "uc_format" field=20 > encodings list if that is more convenient. This seems to address the issue that started it all properly. =20 > Even if this is not ideal from your point of view, are you=20 > prepared to accept this? L-E and Kris (offline) have accepted=20 > it so far, albeit in a "not really what I wanted" sort of=20 > way! I'm hoping Ghyslain will be happy with it since it is=20 > very close to what he wants (I think maybe he may prefer it=20 > to apply to *all* fields which aren't in the compressed=20 > header though, not just those which have greater than zero=20 > uncomp_length). No no, this is a misunderstanding that was created from Kristoffer's = interpretation of what I wrote! See my previous mail(s). =20 > Thanks again for your input everybody - this would be taking=20 > months otherwise! Thanks Robert. Case closed? =20 > Cheers >=20 > Raffles >=20 >=20 > > -----Original Message----- > > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > > Sent: Wednesday, April 20, 2005 4:00 PM > > To: Finking, Robert > > Cc: Lars-Erik Jonsson (LU/EAB); Carsten Bormann; rohc@ietf.org > > Subject: Re: [rohc] FN control fields > >=20 > >=20 > > The control_field section we invented at IETF61 were a way to=20 > > say, for=20 > > a field: the uncompressed side of the field is somehow=20 > > supplied by the=20 > > profile/state machine. > > (Without the control_field section, this would have to be=20 > > expressed by=20 > > parameters and let statements, which for nested encoding=20 > methods can=20 > > become awkward quickly, so this is a welcome shorthand). > >=20 > > Now let's see: > >=20 > > > > > > 4.9.5 Control Fields > > > > > > Control fields are defined using the "control_fields" list. The=20 > > > control fields list specifies all fields that do not=20 > appear in the=20 > > > uncompressed header > >=20 > > Well, typically, they don't. (This is not a requirement.) > >=20 > > > but which have an uncompressed value > >=20 > > all fields do. > >=20 > > > (specifically those with a non-zero uncomp_length). > >=20 > > That's what you mean, OK. > >=20 > > > Such fields may be used to help compress fields from the=20 > > uncompressed=20 > > > header more efficiently. > >=20 > > (I hope that's true of everything we can do in FN.) > >=20 > > > A control field could be used to improve efficiency by=20 > representing=20 > > > some commonality between a number of the uncompressed=20 > fields, or by=20 > > > representing some information about the flow that is not=20 > explicitly=20 > > > contained in the protocol headers. > >=20 > > This seems to be alluding to the fact that the information=20 > > supplied by=20 > > the profile/state machine is often something we have called=20 > > context in=20 > > earlier documents. > > I think we long agreed that we didn't know how to represent=20 > > context in=20 > > FN, so control_fields was a good way to punt this issue. > >=20 > > > For example in IP, the behaviour of the IP-ID field in a=20 > > flow varies=20 > > > depending on how the endpoints handle IP-IDs. Sometimes the=20 > > behaviour=20 > > > is effectively random, sometimes the IP-ID follows a predictable=20 > > > sequence, and at other times it stays fixed at zero. The=20 > > type of IP-ID=20 > > > behaviour is information that is never communicated=20 > > explicitly in the=20 > > > uncompressed header. However, a ROHC profile can still be=20 > > designed to=20 > > > identify the behavior and adjust the compression strategy=20 > > according to=20 > > > the identified behaviour, thereby improving the compression=20 > > > performance. To do so, the profile can introduce an=20 > > explicit field to=20 > > > communicate the IP-ID behaviour in compressed headers, and=20 > > in ROHC-FN=20 > > > terms this is done by introducing a control field > >=20 > > Wait, wait, wait. > > First of all, this is another example of mixing definition=20 > > with example. > > (We have to make sure all examples are clearly identified as such!) > > Second: This text seems to suggest we send a bit or two in every=20 > > compressed packet that identifies the IP-ID encoding variant being=20 > > used. > > Of course the point here is that the profile/state machine=20 > > can remember=20 > > and supply this information -- as a control_fields field! > >=20 > > > Control fields may also be used with global scope. In this=20 > > case their=20 > > > declaration must be outside of any structure. They are=20 > then visible=20 > > > within any structure thus allowing information to be=20 > shared between=20 > > > structures directly. > >=20 > > Essentially, I think this is saying that a globally declared=20 > > control_fields field is visible in every structure. > > (Which is fine, as field that isn't used does not harm.) > > It also means that the profile/state machine has to supply=20 > > these values=20 > > for every "call" to a structure (i.e., the field becomes an=20 > implicit=20 > > part of the interface between the part specified by the FN=20 > > specification and the profile/state machine). This can=20 > > sometimes hurt=20 > > a bit, but I think is mitigated by the fact that if a=20 > control_fields=20 > > field is not used, it does not matter what is being supplied here. > >=20 > > Gruesse, Carsten > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 07:34:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16786 for ; Thu, 21 Apr 2005 07:34:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOa83-0003Zh-Pp for rohc-archive@ietf.org; Thu, 21 Apr 2005 07:45:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOZu6-0001tA-B4; Thu, 21 Apr 2005 07:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOZu4-0001sK-DU for rohc@megatron.ietf.org; Thu, 21 Apr 2005 07:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11608 for ; Thu, 21 Apr 2005 05:56:56 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOYc1-0000g5-Gw for rohc@ietf.org; Thu, 21 Apr 2005 06:08:46 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3L9ucqP021223; Thu, 21 Apr 2005 10:56:41 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Apr 2005 10:57:06 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28C0@rsys004a> From: "Finking, Robert" To: "'Ghyslain Pelletier (LU/EAB)'" , Carsten Bormann Subject: RE: [rohc] FN control fields Date: Thu, 21 Apr 2005 10:56:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Excellent - thanks! OK I'm happy to accept that, including your amendment, but since this was over an issue nobody else seems interested in I don't think there will be any objections. Sorry for the misunderstanding, and thanks once again *everybody* for contributing. Raffles > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB) > [mailto:ghyslain.pelletier@ericsson.com] > Sent: Thursday, April 21, 2005 10:08 AM > To: Finking, Robert; Carsten Bormann > Cc: rohc@ietf.org; Lars-Erik Jonsson (LU/EAB) > Subject: RE: [rohc] FN control fields > > > Carsten, Robert, > > Robert, thanks for summarizing and bringing order to this discussion. > And thanks Carsten for clarifying what we had agreed in > Washington, I think corresponds with what I tried (but > obviously failed to) explain clearly since it seem to agree > with treating control_fields just like uncompressed fields in > terms of their properties, as well as avoiding talking > anything related to context and persistency of fields thereof. > > Comments inline. > > /Ghyslain > > > -----Original Message----- > > From: rohc-bounces@ietf.org > [mailto:rohc-bounces@ietf.org]On Behalf Of > > Finking, Robert > > Sent: den 20 april 2005 17:14 > > To: 'Carsten Bormann' > > Cc: rohc@ietf.org; Lars-Erik Jonsson (LU/EAB) > > Subject: RE: [rohc] FN control fields > > > > > > Hi Carsten, > > > > Many thanks for the input. The review comments on the control > > field section are useful as always. Can I ask you > > specifically about the current proposal (from the head of > > this thread - rationale contained therein): > > > > - we stick with the current syntax, which keeps things simple > > and minimises the changes necessary > > Yes please. > > > - in the TCP-pf we can use comments to indicate that context > > is needed for certain fields > > Ok. This is in the profile document, thus the correct scope > in my opinion. > > > - we clarify in the FN draft the possibility of the existence > > of derived fields and their use; again these can optionally > > be indicated by comments > > No, I disagree. But we could mention that it is up to the > profile specification to provide guidelines on > lifetime/persistency/updating/whatever how different values > of attributes of different types of fields need to be > maintained. But please don't define something new with new > terms e.g. "derived fields" without have any formal meaning > or use in the FN. > > > - we clarify in the FN draft that "control_fields" sections > > are just like any other section inside a structure in that > > they may have a field encodings list. > > Yes please. > > > - we move the non-default let statements in the FN-draft AND > > tcp-pf out of the default section and into either a > > "control_fields" field encodings list, or a "uc_format" field > > encodings list if that is more convenient. > > This seems to address the issue that started it all properly. > > > Even if this is not ideal from your point of view, are you > > prepared to accept this? L-E and Kris (offline) have accepted > > it so far, albeit in a "not really what I wanted" sort of > > way! I'm hoping Ghyslain will be happy with it since it is > > very close to what he wants (I think maybe he may prefer it > > to apply to *all* fields which aren't in the compressed > > header though, not just those which have greater than zero > > uncomp_length). > > No no, this is a misunderstanding that was created from > Kristoffer's interpretation of what I wrote! See my previous mail(s). > > > Thanks again for your input everybody - this would be taking > > months otherwise! > > Thanks Robert. Case closed? > > > Cheers > > > > Raffles > > > > > > > -----Original Message----- > > > From: Carsten Bormann [mailto:cabo@tzi.org] > > > Sent: Wednesday, April 20, 2005 4:00 PM > > > To: Finking, Robert > > > Cc: Lars-Erik Jonsson (LU/EAB); Carsten Bormann; rohc@ietf.org > > > Subject: Re: [rohc] FN control fields > > > > > > > > > The control_field section we invented at IETF61 were a way to > > > say, for > > > a field: the uncompressed side of the field is somehow > > > supplied by the > > > profile/state machine. > > > (Without the control_field section, this would have to be > > > expressed by > > > parameters and let statements, which for nested encoding > > methods can > > > become awkward quickly, so this is a welcome shorthand). > > > > > > Now let's see: > > > > > > > > > > > 4.9.5 Control Fields > > > > > > > > Control fields are defined using the "control_fields" list. The > > > > control fields list specifies all fields that do not > > appear in the > > > > uncompressed header > > > > > > Well, typically, they don't. (This is not a requirement.) > > > > > > > but which have an uncompressed value > > > > > > all fields do. > > > > > > > (specifically those with a non-zero uncomp_length). > > > > > > That's what you mean, OK. > > > > > > > Such fields may be used to help compress fields from the > > > uncompressed > > > > header more efficiently. > > > > > > (I hope that's true of everything we can do in FN.) > > > > > > > A control field could be used to improve efficiency by > > representing > > > > some commonality between a number of the uncompressed > > fields, or by > > > > representing some information about the flow that is not > > explicitly > > > > contained in the protocol headers. > > > > > > This seems to be alluding to the fact that the information > > > supplied by > > > the profile/state machine is often something we have called > > > context in > > > earlier documents. > > > I think we long agreed that we didn't know how to represent > > > context in > > > FN, so control_fields was a good way to punt this issue. > > > > > > > For example in IP, the behaviour of the IP-ID field in a > > > flow varies > > > > depending on how the endpoints handle IP-IDs. Sometimes the > > > behaviour > > > > is effectively random, sometimes the IP-ID follows a > predictable > > > > sequence, and at other times it stays fixed at zero. The > > > type of IP-ID > > > > behaviour is information that is never communicated > > > explicitly in the > > > > uncompressed header. However, a ROHC profile can still be > > > designed to > > > > identify the behavior and adjust the compression strategy > > > according to > > > > the identified behaviour, thereby improving the compression > > > > performance. To do so, the profile can introduce an > > > explicit field to > > > > communicate the IP-ID behaviour in compressed headers, and > > > in ROHC-FN > > > > terms this is done by introducing a control field > > > > > > Wait, wait, wait. > > > First of all, this is another example of mixing definition > > > with example. > > > (We have to make sure all examples are clearly identified > as such!) > > > Second: This text seems to suggest we send a bit or two in every > > > compressed packet that identifies the IP-ID encoding > variant being > > > used. > > > Of course the point here is that the profile/state machine > > > can remember > > > and supply this information -- as a control_fields field! > > > > > > > Control fields may also be used with global scope. In this > > > case their > > > > declaration must be outside of any structure. They are > > then visible > > > > within any structure thus allowing information to be > > shared between > > > > structures directly. > > > > > > Essentially, I think this is saying that a globally declared > > > control_fields field is visible in every structure. > > > (Which is fine, as field that isn't used does not harm.) > > > It also means that the profile/state machine has to supply > > > these values > > > for every "call" to a structure (i.e., the field becomes an > > implicit > > > part of the interface between the part specified by the FN > > > specification and the profile/state machine). This can > > > sometimes hurt > > > a bit, but I think is mitigated by the fact that if a > > control_fields > > > field is not used, it does not matter what is being supplied here. > > > > > > Gruesse, Carsten > > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 08:40:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21454 for ; Thu, 21 Apr 2005 08:40:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOb9p-0005Bq-Do for rohc-archive@ietf.org; Thu, 21 Apr 2005 08:51:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOax0-0000Uq-FH; Thu, 21 Apr 2005 08:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOawz-0000Ul-Fn for rohc@megatron.ietf.org; Thu, 21 Apr 2005 08:38:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21385 for ; Thu, 21 Apr 2005 08:38:32 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOb8P-0005AN-21 for rohc@ietf.org; Thu, 21 Apr 2005 08:50:21 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3LBbhmg019721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Apr 2005 13:37:44 +0200 Message-ID: <42679EC0.5020506@effnet.com> Date: Thu, 21 Apr 2005 14:38:24 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] FN control fields References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28C0@rsys004a> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28C0@rsys004a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, "'Ghyslain Pelletier \(LU/EAB\)'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: 7bit Ok everyone. I've reluctantly updated tha packet formats with the changes discussed in this thread. Therefore: - sack_offset in sack_var_length_enc is now a control fields (to my great dismay) - There are no let-statements in default_methods So, now the packet formats are up to date with this. I'm going to write a mail with the remaining issues in a few minutes time. /Kristofer Finking, Robert wrote: > Excellent - thanks! > > OK I'm happy to accept that, including your amendment, but since this was over an issue nobody else seems interested in I don't think there will be any objections. > > Sorry for the misunderstanding, and thanks once again *everybody* for contributing. > > Raffles > > >>-----Original Message----- >>From: Ghyslain Pelletier (LU/EAB) >>[mailto:ghyslain.pelletier@ericsson.com] >>Sent: Thursday, April 21, 2005 10:08 AM >>To: Finking, Robert; Carsten Bormann >>Cc: rohc@ietf.org; Lars-Erik Jonsson (LU/EAB) >>Subject: RE: [rohc] FN control fields >> >> >>Carsten, Robert, >> >>Robert, thanks for summarizing and bringing order to this discussion. >>And thanks Carsten for clarifying what we had agreed in >>Washington, I think corresponds with what I tried (but >>obviously failed to) explain clearly since it seem to agree >>with treating control_fields just like uncompressed fields in >>terms of their properties, as well as avoiding talking >>anything related to context and persistency of fields thereof. >> >>Comments inline. >> >>/Ghyslain >> >> >>>-----Original Message----- >>>From: rohc-bounces@ietf.org >> >>[mailto:rohc-bounces@ietf.org]On Behalf Of >> >>>Finking, Robert >>>Sent: den 20 april 2005 17:14 >>>To: 'Carsten Bormann' >>>Cc: rohc@ietf.org; Lars-Erik Jonsson (LU/EAB) >>>Subject: RE: [rohc] FN control fields >>> >>> >>>Hi Carsten, >>> >>>Many thanks for the input. The review comments on the control >>>field section are useful as always. Can I ask you >>>specifically about the current proposal (from the head of >>>this thread - rationale contained therein): >>> >>>- we stick with the current syntax, which keeps things simple >>>and minimises the changes necessary >> >>Yes please. >> >> >>>- in the TCP-pf we can use comments to indicate that context >>>is needed for certain fields >> >>Ok. This is in the profile document, thus the correct scope >>in my opinion. >> >> >>>- we clarify in the FN draft the possibility of the existence >>>of derived fields and their use; again these can optionally >>>be indicated by comments >> >>No, I disagree. But we could mention that it is up to the >>profile specification to provide guidelines on >>lifetime/persistency/updating/whatever how different values >>of attributes of different types of fields need to be >>maintained. But please don't define something new with new >>terms e.g. "derived fields" without have any formal meaning >>or use in the FN. >> >> >>>- we clarify in the FN draft that "control_fields" sections >>>are just like any other section inside a structure in that >>>they may have a field encodings list. >> >>Yes please. >> >> >>>- we move the non-default let statements in the FN-draft AND >>>tcp-pf out of the default section and into either a >>>"control_fields" field encodings list, or a "uc_format" field >>>encodings list if that is more convenient. >> >>This seems to address the issue that started it all properly. >> >> >>>Even if this is not ideal from your point of view, are you >>>prepared to accept this? L-E and Kris (offline) have accepted >>>it so far, albeit in a "not really what I wanted" sort of >>>way! I'm hoping Ghyslain will be happy with it since it is >>>very close to what he wants (I think maybe he may prefer it >>>to apply to *all* fields which aren't in the compressed >>>header though, not just those which have greater than zero >>>uncomp_length). >> >>No no, this is a misunderstanding that was created from >>Kristoffer's interpretation of what I wrote! See my previous mail(s). >> >> >>>Thanks again for your input everybody - this would be taking >>>months otherwise! >> >>Thanks Robert. Case closed? >> >> >>>Cheers >>> >>>Raffles >>> >>> >>> >>>>-----Original Message----- >>>>From: Carsten Bormann [mailto:cabo@tzi.org] >>>>Sent: Wednesday, April 20, 2005 4:00 PM >>>>To: Finking, Robert >>>>Cc: Lars-Erik Jonsson (LU/EAB); Carsten Bormann; rohc@ietf.org >>>>Subject: Re: [rohc] FN control fields >>>> >>>> >>>>The control_field section we invented at IETF61 were a way to >>>>say, for >>>>a field: the uncompressed side of the field is somehow >>>>supplied by the >>>>profile/state machine. >>>>(Without the control_field section, this would have to be >>>>expressed by >>>>parameters and let statements, which for nested encoding >>> >>>methods can >>> >>>>become awkward quickly, so this is a welcome shorthand). >>>> >>>>Now let's see: >>>> >>>> >>>>> >>>>>4.9.5 Control Fields >>>>> >>>>>Control fields are defined using the "control_fields" list. The >>>>>control fields list specifies all fields that do not >>> >>>appear in the >>> >>>>>uncompressed header >>>> >>>>Well, typically, they don't. (This is not a requirement.) >>>> >>>> >>>>>but which have an uncompressed value >>>> >>>>all fields do. >>>> >>>> >>>>>(specifically those with a non-zero uncomp_length). >>>> >>>>That's what you mean, OK. >>>> >>>> >>>>>Such fields may be used to help compress fields from the >>>> >>>>uncompressed >>>> >>>>>header more efficiently. >>>> >>>>(I hope that's true of everything we can do in FN.) >>>> >>>> >>>>>A control field could be used to improve efficiency by >>> >>>representing >>> >>>>>some commonality between a number of the uncompressed >>> >>>fields, or by >>> >>>>>representing some information about the flow that is not >>> >>>explicitly >>> >>>>>contained in the protocol headers. >>>> >>>>This seems to be alluding to the fact that the information >>>>supplied by >>>>the profile/state machine is often something we have called >>>>context in >>>>earlier documents. >>>>I think we long agreed that we didn't know how to represent >>>>context in >>>>FN, so control_fields was a good way to punt this issue. >>>> >>>> >>>>>For example in IP, the behaviour of the IP-ID field in a >>>> >>>>flow varies >>>> >>>>>depending on how the endpoints handle IP-IDs. Sometimes the >>>> >>>>behaviour >>>> >>>>>is effectively random, sometimes the IP-ID follows a >> >>predictable >> >>>>>sequence, and at other times it stays fixed at zero. The >>>> >>>>type of IP-ID >>>> >>>>>behaviour is information that is never communicated >>>> >>>>explicitly in the >>>> >>>>>uncompressed header. However, a ROHC profile can still be >>>> >>>>designed to >>>> >>>>>identify the behavior and adjust the compression strategy >>>> >>>>according to >>>> >>>>>the identified behaviour, thereby improving the compression >>>>>performance. To do so, the profile can introduce an >>>> >>>>explicit field to >>>> >>>>>communicate the IP-ID behaviour in compressed headers, and >>>> >>>>in ROHC-FN >>>> >>>>>terms this is done by introducing a control field >>>> >>>>Wait, wait, wait. >>>>First of all, this is another example of mixing definition >>>>with example. >>>>(We have to make sure all examples are clearly identified >> >>as such!) >> >>>>Second: This text seems to suggest we send a bit or two in every >>>>compressed packet that identifies the IP-ID encoding >> >>variant being >> >>>>used. >>>>Of course the point here is that the profile/state machine >>>>can remember >>>>and supply this information -- as a control_fields field! >>>> >>>> >>>>>Control fields may also be used with global scope. In this >>>> >>>>case their >>>> >>>>>declaration must be outside of any structure. They are >>> >>>then visible >>> >>>>>within any structure thus allowing information to be >>> >>>shared between >>> >>>>>structures directly. >>>> >>>>Essentially, I think this is saying that a globally declared >>>>control_fields field is visible in every structure. >>>>(Which is fine, as field that isn't used does not harm.) >>>>It also means that the profile/state machine has to supply >>>>these values >>>>for every "call" to a structure (i.e., the field becomes an >>> >>>implicit >>> >>>>part of the interface between the part specified by the FN >>>>specification and the profile/state machine). This can >>>>sometimes hurt >>>>a bit, but I think is mitigated by the fact that if a >>> >>>control_fields >>> >>>>field is not used, it does not matter what is being supplied here. >>>> >>>>Gruesse, Carsten >>>> >>> >>>_______________________________________________ >>>Rohc mailing list >>>Rohc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rohc >>> >> > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 09:01:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23236 for ; Thu, 21 Apr 2005 09:01:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DObUb-0005gx-Pf for rohc-archive@ietf.org; Thu, 21 Apr 2005 09:13:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObGC-0002DD-Ro; Thu, 21 Apr 2005 08:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObGB-0002D5-8n for rohc@megatron.ietf.org; Thu, 21 Apr 2005 08:58:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22816 for ; Thu, 21 Apr 2005 08:58:22 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DObRb-0005bI-Qf for rohc@ietf.org; Thu, 21 Apr 2005 09:10:12 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3LBvdmg019799 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 21 Apr 2005 13:57:40 +0200 Message-ID: <4267A36C.5000306@effnet.com> Date: Thu, 21 Apr 2005 14:58:20 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Subject: [rohc] Expressing scaaled compression of fields in ROHC-FN. X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Hi all! The main obstacle remaining in expressing the TCP packet formats in ROHC-FN seems to be the one related to the scaled sequence and ack numbers (previously discussed on the list a number of times regarind division by zero etc). And for a packet with an unscaled sequence number (for example co_format_rnd_1), we would need to have some kind of if-statement so that we can say (because of the zero-divison issue): if (payload_size == 0) let (seq_number_residue:uncomp_value == seq_number:uncomp_value); let (seq_number_scaled:uncomp_value == 0); else let (seq_number_residue:uncomp_value == mod(seq_number:uncomp_value, payload_size)); let (seq_number:uncomp_value == seq_number_scaled:uncomp_value * payload_size + seq_number_residue:uncomp_value); Currently, these expressions are placed in the control_fields of co_baseheader like this: control_fields = { let (seq_number_scaled:uncomp_value == seq_number:uncomp_value / payload_size); let (seq_number_residue:uncomp_value == mod(seq_number:uncomp_value, payload_size)); }; But, as anyone can see, the payload of zero will fail to bind for all packet formats with this. So, we thought about having two different control_field definitions like this: control_fields_no_payload = { let(payload_size == 0); let (seq_number_residue:uncomp_value == seq_number:uncomp_value); let (seq_number_scaled:uncomp_value == 0); }; control_fields_with_payload = { let(payload_size != 0); let(seq_number_residue:uncomp_value == mod(seq_number:uncomp_value, payload_size)); let(seq_number:uncomp_value == seq_number_scaled:uncomp_value * payload_size + seq_number_residue:uncomp_value); }; But, this approach does NOT scale. Since we have two fields to handle (seq/ack), then we're up to 4 control_fields definitions and one more field takes us to 8, so no, this is not going to scale in a way that makes FN usable. Therefore, we need to be able to express if-statements in ROHC-FN. Yes, I know we've had this discussion multiple times before and gotten around it, but we can't just keep patching things when we all the time get back to the fact that if-statements will make this easier! I've discussed this with both Robert and Ghyslain offline, and we got no further than to if-statements. So, the syntax we would like to add is: control_fields = { let(payload_size == 0) { let (seq_number_residue:uncomp_value == seq_number:uncomp_value); let (seq_number_scaled:uncomp_value == 0); } let(payload_size != 0) { let(seq_number_residue:uncomp_value == mod(seq_number:uncomp_value, payload_size)); let(seq_number:uncomp_value == seq_number_scaled:uncomp_value * payload_size + seq_number_residue:uncomp_value); } } So that each let _can_ contain a block-statement and we can bind to one of these . If that wrecks havc with the FN syntax, We just replace the "conditional let" with "if", which I guess would be reasonably easy to define. Feedback, please. With this addition, I think we would be done with the FN draft and the TCP packet formats will be syntactically finished (even if the content can still be discussed). BR, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 09:23:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28284 for ; Thu, 21 Apr 2005 09:23:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DObqK-0007Cp-UA for rohc-archive@ietf.org; Thu, 21 Apr 2005 09:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObda-0000kl-W7; Thu, 21 Apr 2005 09:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObdY-0000kM-BH for rohc@megatron.ietf.org; Thu, 21 Apr 2005 09:22:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28128 for ; Thu, 21 Apr 2005 09:22:31 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DObox-00079E-Oh for rohc@ietf.org; Thu, 21 Apr 2005 09:34:21 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LDMIqP011760; Thu, 21 Apr 2005 14:22:18 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 14:22:35 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28CC@rsys004a> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGcflciw9M4iXiTu6rODNDmvC6BgAAKLvg From: "Finking, Robert" To: "Kristofer Sandlund" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Hi Kris, Thanks for posting on this. Comments inline below: Raffles > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 >=20 > control_fields =3D > { > let(payload_size =3D=3D 0) > { > let (seq_number_residue:uncomp_value =3D=3D=20 > seq_number:uncomp_value); > let (seq_number_scaled:uncomp_value =3D=3D 0); > } > let(payload_size !=3D 0) > { > let(seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let(seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); > } >=20 > } A couple of things, first a tiny one. I'm thinking of it syntactically as the encodings-list being part of the let-statement (same as other encodings lists are part of their parents), so that would mean that the semi-colon associated with the let would appear after the close brace. Second, there is no reason we should restrict the condition to being a let statement, we could use any binding as a condition. E.g. we could do: { foo ::=3D uncompressed_value(6,4) { blah }; foo ::=3D lsb(3,0) { blah }; foo ::=3D irregular(6) { blah }; } However we see a problem with the above, which is also an issue with let statements, though less obviously so: you may want to make two (or more) alternatives mutually exclusive. In the above, the irregular form will always succeed, so what happens if lsb also succeeds? We need syntax to list alternatives. Your earlier if-else syntax seems to fit the bill (did I hear a cheer from L-E?): { if foo ::=3D uncompressed_value(6,4) { blah } elsif foo ::=3D lsb(3,0) { blah } else { foo ::=3D irregular(6) blah }; }; Maybe this is overkill though? >=20 > So that each let _can_ contain a block-statement and we can=20 > bind to one of these=20 > . If that wrecks havc with the FN syntax, We just replace the=20 > "conditional let"=20 > with "if", which I guess would be reasonably easy to define. >=20 > Feedback, please. With this addition, I think we would be=20 > done with the FN draft=20 > and the TCP packet formats will be syntactically finished=20 > (even if the content=20 > can still be discussed). >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 09:35:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29492 for ; Thu, 21 Apr 2005 09:35:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOc1a-0007dy-CN for rohc-archive@ietf.org; Thu, 21 Apr 2005 09:47:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObol-0002ui-RI; Thu, 21 Apr 2005 09:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObok-0002ud-Ho for rohc@megatron.ietf.org; Thu, 21 Apr 2005 09:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29347 for ; Thu, 21 Apr 2005 09:34:05 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOc0A-0007b5-2S for rohc@ietf.org; Thu, 21 Apr 2005 09:45:55 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3LDXgPG016655; Thu, 21 Apr 2005 15:34:02 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 15:33:52 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 15:33:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 15:33:51 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA9E@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGcklr0FfYmbNdRdSsUKOxuV0bugABBRgg From: "Ghyslain Pelletier \(LU/EAB\)" To: "Kristofer Sandlund" , X-OriginalArrivalTime: 21 Apr 2005 13:33:52.0249 (UTC) FILETIME=[C1DCDE90:01C54676] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Kristoffer, I rethought about this. The issue is not about having a conditional, but = rather an issue on scoping. I think the "let" statement that "fails" the = entire scope of the packet format is needed and shouldn't be changed. = What you are after is to assert one part of the scope of a packet format = without "failing" the entire format. I suggest instead that we allow the use of a scoping operater, e.g. the = braces "{" and "}" that we already use could be used to add one scoping = level to englobe the let as a conditional that does not fail the entire = scope of the packet format. Thoughts? /Ghyslain=20 > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Kristofer Sandlund > Sent: den 21 april 2005 14:58 > To: rohc@ietf.org > Subject: [rohc] Expressing scaaled compression of fields in ROHC-FN. >=20 >=20 > Hi all! >=20 > The main obstacle remaining in expressing the TCP packet=20 > formats in ROHC-FN=20 > seems to be the one related to the scaled sequence and ack=20 > numbers (previously=20 > discussed on the list a number of times regarind division by=20 > zero etc). >=20 > And for a packet with an unscaled sequence number (for=20 > example co_format_rnd_1),=20 > we would need to have some kind of if-statement so that we=20 > can say (because of=20 > the zero-divison issue): > if (payload_size =3D=3D 0) > let (seq_number_residue:uncomp_value =3D=3D=20 > seq_number:uncomp_value); > let (seq_number_scaled:uncomp_value =3D=3D 0); > else > let (seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let (seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); >=20 >=20 > Currently, these expressions are placed in the control_fields=20 > of co_baseheader=20 > like this: >=20 > control_fields =3D > { > let (seq_number_scaled:uncomp_value =3D=3D > seq_number:uncomp_value / payload_size); > let (seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > }; >=20 > But, as anyone can see, the payload of zero will fail to bind=20 > for all packet=20 > formats with this. So, we thought about having two different=20 > control_field=20 > definitions like this: >=20 > control_fields_no_payload =3D > { > let(payload_size =3D=3D 0); > let (seq_number_residue:uncomp_value =3D=3D > seq_number:uncomp_value); >=20 > let (seq_number_scaled:uncomp_value =3D=3D 0); > }; >=20 > control_fields_with_payload =3D > { > let(payload_size !=3D 0); > let(seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let(seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); > }; >=20 > But, this approach does NOT scale. Since we have two fields=20 > to handle (seq/ack),=20 > then we're up to 4 control_fields definitions and one more=20 > field takes us to 8,=20 > so no, this is not going to scale in a way that makes FN usable. >=20 > Therefore, we need to be able to express if-statements in=20 > ROHC-FN. Yes, I know=20 > we've had this discussion multiple times before and gotten=20 > around it, but we=20 > can't just keep patching things when we all the time get back=20 > to the fact that=20 > if-statements will make this easier! I've discussed this with=20 > both Robert and=20 > Ghyslain offline, and we got no further than to=20 > if-statements. So, the syntax we=20 > would like to add is: >=20 > control_fields =3D > { > let(payload_size =3D=3D 0) > { > let (seq_number_residue:uncomp_value =3D=3D=20 > seq_number:uncomp_value); > let (seq_number_scaled:uncomp_value =3D=3D 0); > } > let(payload_size !=3D 0) > { > let(seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let(seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); > } >=20 > } >=20 > So that each let _can_ contain a block-statement and we can=20 > bind to one of these=20 > . If that wrecks havc with the FN syntax, We just replace the=20 > "conditional let"=20 > with "if", which I guess would be reasonably easy to define. >=20 > Feedback, please. With this addition, I think we would be=20 > done with the FN draft=20 > and the TCP packet formats will be syntactically finished=20 > (even if the content=20 > can still be discussed). >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 09:45:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00491 for ; Thu, 21 Apr 2005 09:45:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcB4-0007z9-SR for rohc-archive@ietf.org; Thu, 21 Apr 2005 09:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObxS-0004Az-6q; Thu, 21 Apr 2005 09:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObxR-00049v-EV for rohc@megatron.ietf.org; Thu, 21 Apr 2005 09:43:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00314 for ; Thu, 21 Apr 2005 09:43:03 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOc8r-0007uc-TC for rohc@ietf.org; Thu, 21 Apr 2005 09:54:54 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3LCgKmg019928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Apr 2005 14:42:21 +0200 Message-ID: <4267ADE6.9040300@effnet.com> Date: Thu, 21 Apr 2005 15:43:02 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] Expressing scaaled compression of fields in ROHC-FN. References: <026F8EEDAD2C4342A993203088C1FC0527DA9E@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0527DA9E@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Hej! If I understand you correctly you suggest syntax like: co_format_example { { let(value == 0) blah ::= static; } { let(value != 0) blah ::= irregular; } } If so, that seems to work. I'd _like_ for it to be more explicit on when things are mutually exclusive and when both can match, since more complex conditions will probably be easy to mess up for the profile writer. But it's not a "show stopper", so I can accept whichever of these two most people like. /Kristofer Ghyslain Pelletier (LU/EAB) wrote: > Kristoffer, > > I rethought about this. The issue is not about having a conditional, but rather an issue on scoping. I think the "let" statement that "fails" the entire scope of the packet format is needed and shouldn't be changed. What you are after is to assert one part of the scope of a packet format without "failing" the entire format. > > I suggest instead that we allow the use of a scoping operater, e.g. the braces "{" and "}" that we already use could be used to add one scoping level to englobe the let as a conditional that does not fail the entire scope of the packet format. > > Thoughts? > > /Ghyslain > > >>-----Original Message----- >>From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of >>Kristofer Sandlund >>Sent: den 21 april 2005 14:58 >>To: rohc@ietf.org >>Subject: [rohc] Expressing scaaled compression of fields in ROHC-FN. >> >> >>Hi all! >> >>The main obstacle remaining in expressing the TCP packet >>formats in ROHC-FN >>seems to be the one related to the scaled sequence and ack >>numbers (previously >>discussed on the list a number of times regarind division by >>zero etc). >> >>And for a packet with an unscaled sequence number (for >>example co_format_rnd_1), >>we would need to have some kind of if-statement so that we >>can say (because of >>the zero-divison issue): >> if (payload_size == 0) >> let (seq_number_residue:uncomp_value == >>seq_number:uncomp_value); >> let (seq_number_scaled:uncomp_value == 0); >> else >> let (seq_number_residue:uncomp_value == >> mod(seq_number:uncomp_value, payload_size)); >> let (seq_number:uncomp_value == >> seq_number_scaled:uncomp_value * payload_size + >> seq_number_residue:uncomp_value); >> >> >>Currently, these expressions are placed in the control_fields >>of co_baseheader >>like this: >> >> control_fields = >> { >> let (seq_number_scaled:uncomp_value == >> seq_number:uncomp_value / payload_size); >> let (seq_number_residue:uncomp_value == >> mod(seq_number:uncomp_value, payload_size)); >> }; >> >>But, as anyone can see, the payload of zero will fail to bind >>for all packet >>formats with this. So, we thought about having two different >>control_field >>definitions like this: >> >> control_fields_no_payload = >> { >> let(payload_size == 0); >> let (seq_number_residue:uncomp_value == >> seq_number:uncomp_value); >> >> let (seq_number_scaled:uncomp_value == 0); >> }; >> >> control_fields_with_payload = >> { >> let(payload_size != 0); >> let(seq_number_residue:uncomp_value == >> mod(seq_number:uncomp_value, payload_size)); >> let(seq_number:uncomp_value == >> seq_number_scaled:uncomp_value * payload_size + >> seq_number_residue:uncomp_value); >> }; >> >>But, this approach does NOT scale. Since we have two fields >>to handle (seq/ack), >>then we're up to 4 control_fields definitions and one more >>field takes us to 8, >>so no, this is not going to scale in a way that makes FN usable. >> >>Therefore, we need to be able to express if-statements in >>ROHC-FN. Yes, I know >>we've had this discussion multiple times before and gotten >>around it, but we >>can't just keep patching things when we all the time get back >>to the fact that >>if-statements will make this easier! I've discussed this with >>both Robert and >>Ghyslain offline, and we got no further than to >>if-statements. So, the syntax we >>would like to add is: >> >>control_fields = >>{ >> let(payload_size == 0) >> { >> let (seq_number_residue:uncomp_value == >>seq_number:uncomp_value); >> let (seq_number_scaled:uncomp_value == 0); >> } >> let(payload_size != 0) >> { >> let(seq_number_residue:uncomp_value == >> mod(seq_number:uncomp_value, payload_size)); >> let(seq_number:uncomp_value == >> seq_number_scaled:uncomp_value * payload_size + >> seq_number_residue:uncomp_value); >> } >> >>} >> >>So that each let _can_ contain a block-statement and we can >>bind to one of these >>. If that wrecks havc with the FN syntax, We just replace the >>"conditional let" >>with "if", which I guess would be reasonably easy to define. >> >>Feedback, please. With this addition, I think we would be >>done with the FN draft >>and the TCP packet formats will be syntactically finished >>(even if the content >>can still be discussed). >> >>BR, >> Kristofer Sandlund, Effnet AB >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 09:46:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00638 for ; Thu, 21 Apr 2005 09:46:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcCF-00082R-GL for rohc-archive@ietf.org; Thu, 21 Apr 2005 09:58:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObzw-0004QU-S4; Thu, 21 Apr 2005 09:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObzv-0004QM-88 for rohc@megatron.ietf.org; Thu, 21 Apr 2005 09:45:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00524 for ; Thu, 21 Apr 2005 09:45:37 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcBH-0007zD-QY for rohc@ietf.org; Thu, 21 Apr 2005 09:57:28 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LDjKqP017203; Thu, 21 Apr 2005 14:45:20 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 14:45:37 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28CE@rsys004a> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGd0KsgkA1dLFxRWilC4siNK3/ZgAAC50A From: "Finking, Robert" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Hi Ghyslain, Just to clarify what you mean, to rewrite my example in your syntax: { { foo ::=3D uncompressed_value(6,4) blah }; { foo ::=3D lsb(3,0) blah }; { foo ::=3D irregular(6) blah }; } Here, each of the items in braces would fail if either the encoding of foo failed or blah failed (in which case all would fail as they all contain blah). Is that what you mean? Thanks Raffles > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB)=20 > [mailto:ghyslain.pelletier@ericsson.com]=20 > Sent: Thursday, April 21, 2005 2:34 PM > To: Kristofer Sandlund; rohc@ietf.org > Subject: RE: [rohc] Expressing scaaled compression of fields=20 > in ROHC-FN. >=20 >=20 > Kristoffer, >=20 > I rethought about this. The issue is not about having a=20 > conditional, but rather an issue on scoping. I think the=20 > "let" statement that "fails" the entire scope of the packet=20 > format is needed and shouldn't be changed. What you are after=20 > is to assert one part of the scope of a packet format without=20 > "failing" the entire format. >=20 > I suggest instead that we allow the use of a scoping=20 > operater, e.g. the braces "{" and "}" that we already use=20 > could be used to add one scoping level to englobe the let as=20 > a conditional that does not fail the entire scope of the=20 > packet format. >=20 > Thoughts? >=20 > /Ghyslain=20 >=20 > > -----Original Message----- > > From: rohc-bounces@ietf.org=20 > [mailto:rohc-bounces@ietf.org]On Behalf Of > > Kristofer Sandlund > > Sent: den 21 april 2005 14:58 > > To: rohc@ietf.org > > Subject: [rohc] Expressing scaaled compression of fields in ROHC-FN. > >=20 > >=20 > > Hi all! > >=20 > > The main obstacle remaining in expressing the TCP packet=20 > > formats in ROHC-FN=20 > > seems to be the one related to the scaled sequence and ack=20 > > numbers (previously=20 > > discussed on the list a number of times regarind division by=20 > > zero etc). > >=20 > > And for a packet with an unscaled sequence number (for=20 > > example co_format_rnd_1),=20 > > we would need to have some kind of if-statement so that we=20 > > can say (because of=20 > > the zero-divison issue): > > if (payload_size =3D=3D 0) > > let (seq_number_residue:uncomp_value =3D=3D=20 > > seq_number:uncomp_value); > > let (seq_number_scaled:uncomp_value =3D=3D 0); > > else > > let (seq_number_residue:uncomp_value =3D=3D > > mod(seq_number:uncomp_value, payload_size)); > > let (seq_number:uncomp_value =3D=3D > > seq_number_scaled:uncomp_value * payload_size + > > seq_number_residue:uncomp_value); > >=20 > >=20 > > Currently, these expressions are placed in the control_fields=20 > > of co_baseheader=20 > > like this: > >=20 > > control_fields =3D > > { > > let (seq_number_scaled:uncomp_value =3D=3D > > seq_number:uncomp_value / payload_size); > > let (seq_number_residue:uncomp_value =3D=3D > > mod(seq_number:uncomp_value, payload_size)); > > }; > >=20 > > But, as anyone can see, the payload of zero will fail to bind=20 > > for all packet=20 > > formats with this. So, we thought about having two different=20 > > control_field=20 > > definitions like this: > >=20 > > control_fields_no_payload =3D > > { > > let(payload_size =3D=3D 0); > > let (seq_number_residue:uncomp_value =3D=3D > > seq_number:uncomp_value); > >=20 > > let (seq_number_scaled:uncomp_value =3D=3D 0); > > }; > >=20 > > control_fields_with_payload =3D > > { > > let(payload_size !=3D 0); > > let(seq_number_residue:uncomp_value =3D=3D > > mod(seq_number:uncomp_value, payload_size)); > > let(seq_number:uncomp_value =3D=3D > > seq_number_scaled:uncomp_value * payload_size + > > seq_number_residue:uncomp_value); > > }; > >=20 > > But, this approach does NOT scale. Since we have two fields=20 > > to handle (seq/ack),=20 > > then we're up to 4 control_fields definitions and one more=20 > > field takes us to 8,=20 > > so no, this is not going to scale in a way that makes FN usable. > >=20 > > Therefore, we need to be able to express if-statements in=20 > > ROHC-FN. Yes, I know=20 > > we've had this discussion multiple times before and gotten=20 > > around it, but we=20 > > can't just keep patching things when we all the time get back=20 > > to the fact that=20 > > if-statements will make this easier! I've discussed this with=20 > > both Robert and=20 > > Ghyslain offline, and we got no further than to=20 > > if-statements. So, the syntax we=20 > > would like to add is: > >=20 > > control_fields =3D > > { > > let(payload_size =3D=3D 0) > > { > > let (seq_number_residue:uncomp_value =3D=3D=20 > > seq_number:uncomp_value); > > let (seq_number_scaled:uncomp_value =3D=3D 0); > > } > > let(payload_size !=3D 0) > > { > > let(seq_number_residue:uncomp_value =3D=3D > > mod(seq_number:uncomp_value, payload_size)); > > let(seq_number:uncomp_value =3D=3D > > seq_number_scaled:uncomp_value * payload_size + > > seq_number_residue:uncomp_value); > > } > >=20 > > } > >=20 > > So that each let _can_ contain a block-statement and we can=20 > > bind to one of these=20 > > . If that wrecks havc with the FN syntax, We just replace the=20 > > "conditional let"=20 > > with "if", which I guess would be reasonably easy to define. > >=20 > > Feedback, please. With this addition, I think we would be=20 > > done with the FN draft=20 > > and the TCP packet formats will be syntactically finished=20 > > (even if the content=20 > > can still be discussed). > >=20 > > BR, > > Kristofer Sandlund, Effnet AB > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 10:35:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05067 for ; Thu, 21 Apr 2005 10:35:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcxZ-0000q9-1o for rohc-archive@ietf.org; Thu, 21 Apr 2005 10:47:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOch5-0000wI-Q4; Thu, 21 Apr 2005 10:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOch4-0000w4-Sn for rohc@megatron.ietf.org; Thu, 21 Apr 2005 10:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04302 for ; Thu, 21 Apr 2005 10:30:13 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcqa-0000Wc-Mt for rohc@ietf.org; Thu, 21 Apr 2005 10:40:06 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3LES5Ab029143; Thu, 21 Apr 2005 16:28:06 +0200 (MEST) In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0527DA98@esealmw109.eemea.ericsson.se> References: <026F8EEDAD2C4342A993203088C1FC0527DA98@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5a0e310cd367ba609fdb9bc00aee2c05@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] FN control fields Date: Thu, 21 Apr 2005 16:28:05 +0200 To: "Ghyslain Pelletier \(LU/EAB\)" X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "Finking, Robert" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit It's nice that we seem to have consensus, but I still don't know what > uncompressed fields are. All fields have a compressed and an uncompressed side. Do you mean a field whose uncompressed side actually is being used in an uncompressed format field list? Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 10:42:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05828 for ; Thu, 21 Apr 2005 10:42:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOd4E-00014w-PO for rohc-archive@ietf.org; Thu, 21 Apr 2005 10:54:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOcrv-0002I0-00; Thu, 21 Apr 2005 10:41:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOcrt-0002Ht-5Y for rohc@megatron.ietf.org; Thu, 21 Apr 2005 10:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05709 for ; Thu, 21 Apr 2005 10:41:23 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOd3I-00012Y-SK for rohc@ietf.org; Thu, 21 Apr 2005 10:53:15 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LEf5qP032260; Thu, 21 Apr 2005 15:41:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 15:41:21 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28D0@rsys004a> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGeENrWem4kGE3ThabaQl5VgYQSQABZiDQ From: "Finking, Robert" To: "Kristofer Sandlund" , "Ghyslain Pelletier \(LU/EAB\)" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Hej =3D) Looks like we both posted at the same time, but since we both have the same understanding, I'll assume we got it right. I like this syntax as it is simple and requires nothing more than allowing nesting of encodings lists. However... inline Regards Raffles > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 > Sent: Thursday, April 21, 2005 2:43 PM > To: Ghyslain Pelletier (LU/EAB) > Cc: rohc@ietf.org > Subject: Re: [rohc] Expressing scaaled compression of fields=20 > in ROHC-FN. >=20 >=20 > Hej! >=20 > If I understand you correctly you suggest syntax like: >=20 > co_format_example > { > { > let(value =3D=3D 0) > blah ::=3D static; > } > { > let(value !=3D 0) > blah ::=3D irregular; > } > } >=20 > If so, that seems to work. > I'd _like_ for it to be more explicit on when things are=20 > mutually exclusive and=20 > when both can match, since more complex conditions will=20 > probably be easy to mess=20 > up for the profile writer.=20 I heartily agree. It's not just the writer either, but the reader of the profile who needs to be able to see the intent clearly. I'd like to suggest a very subtle change of syntax to allow mutual exclusivity to be communicated. At the structure level, we currently use a collection of labels which start with the same prefix (e.g. "co_format"). Instead of having a collection of separate items, why not make them into a single list of items? This means 1. they must follow one after another, instead of allowing e.g. "default_methods" to appear half way through the list 2. only one semi-colon is needed at the very end of the list. To give an example from the TCP-PF: variable_length_16_enc(flag) =3D=3D=3D { uc_format =3D field; %[ 16 ] co_format_not_present =3D field, %[ 0 ] { let(flag =3D=3D 0); field ::=3D static; } co_format_8_bit =3D field, %[ 8 ] { let(flag =3D=3D 1); field ::=3D lsb(8, 63); } co_format_16_bit =3D field, %[ 16 ] { let(flag =3D=3D 2); field ::=3D irregular(16); }; }; All that has happened here is that the three individual encoding methods for 0 bit, 8 bit and 16 bit, have become a list of encoding methods. Using Ghyslain's modification (allowing nesting) on Kris' example, if we want to indicate explicitly that they're mutually exclusive: co_format_example { alternative_1 =3D { let(value =3D=3D 0) blah ::=3D static; } alternative 2 =3D { let(value !=3D 0) blah ::=3D irregular; }; } If they're not mutually exclusive: co_format_example { alternative_1 =3D { let(value =3D=3D 0) blah ::=3D static; }; alternative 2 =3D { let(value2 !=3D 0) blah ::=3D irregular; }; } PS nice to see others using "blah" far superior to "bar" =3D) How does this sit with everyone? (incidentally I much prefer it to my own previous suggestion) Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 10:49:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06326 for ; Thu, 21 Apr 2005 10:49:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdB9-0001K0-7k for rohc-archive@ietf.org; Thu, 21 Apr 2005 11:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOcy3-0003OM-Pa; Thu, 21 Apr 2005 10:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOcy2-0003OH-7t for rohc@megatron.ietf.org; Thu, 21 Apr 2005 10:47:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06222 for ; Thu, 21 Apr 2005 10:47:44 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOd9S-0001G3-EC for rohc@ietf.org; Thu, 21 Apr 2005 10:59:36 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LElSqP001617; Thu, 21 Apr 2005 15:47:28 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 15:47:43 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28D1@rsys004a> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGgG+7roPBi1+3RCmH0rYUTBuYbAAAFpQg From: "Finking, Robert" To: "Finking, Robert" , "Kristofer Sandlund" , "Ghyslain Pelletier \(LU/EAB\)" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Apologies, correction to my final example (note the labels don't share a prefix): co_format_example { a_block =3D { let(value =3D=3D 0) blah ::=3D static; }; different_block =3D { let(value2 !=3D 0) blah ::=3D irregular; }; } _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 10:59:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07227 for ; Thu, 21 Apr 2005 10:59:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdKT-0001bg-Nl for rohc-archive@ietf.org; Thu, 21 Apr 2005 11:10:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOd5R-0004VM-5Y; Thu, 21 Apr 2005 10:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOd5P-0004VE-L9 for rohc@megatron.ietf.org; Thu, 21 Apr 2005 10:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06883 for ; Thu, 21 Apr 2005 10:55:21 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdGq-0001VH-9r for rohc@ietf.org; Thu, 21 Apr 2005 11:07:13 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LEt7qP002992; Thu, 21 Apr 2005 15:55:07 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Apr 2005 15:55:36 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28D2@rsys004a> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 15:55:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Carsten, Feel free to note also the missing parameters for irregular encoding and missing final semi-colon if you're feeling extra nitpicky today! ;-) Without Kris and I rewriting our running example with field lists, do you think you could see past the minor imperfections in the to the question being asked? Or does the lack of field order lists impact the example in some way that I've missed? - that was a serious question by the way; I'm perfectly capable of major imperfections as well as minor ones ;-) Regards Raffles > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, April 21, 2005 3:46 PM > To: Finking, Robert > Cc: Carsten Bormann > Subject: Re: [rohc] Expressing scaaled compression of fields > in ROHC-FN. > > > On Apr 21 2005, at 16:41 Uhr, Finking, Robert wrote: > > > How does this sit with everyone? > > Your examples are missing the field lists. > > Gruesse, Carsten > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 11:41:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10212 for ; Thu, 21 Apr 2005 11:41:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdzv-0002ck-Hn for rohc-archive@ietf.org; Thu, 21 Apr 2005 11:53:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdm5-000233-JJ; Thu, 21 Apr 2005 11:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdm3-00022v-LW for rohc@megatron.ietf.org; Thu, 21 Apr 2005 11:39:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10044 for ; Thu, 21 Apr 2005 11:39:25 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdxV-0002Yr-Bl for rohc@ietf.org; Thu, 21 Apr 2005 11:51:17 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LFdDqP014505 for ; Thu, 21 Apr 2005 16:39:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Thu, 21 Apr 2005 16:39:30 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28D6@rsys004a> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGgvzNdxS3ThpHTSmvkQw8dllkNwABODng From: "Finking, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Hi, You're right, it wasn't entirely obvious that it wasn't entirely obvious. I guess the fact that I needed to clarify that it wasn't entirely obvious that it wasn't entirely obvious, means that from your point of view it wasn't entirely obvious that it wasn't entirely obvious that it wasn't entirely obvious =3D) You're asking do we have this: co_format_example =3D blah { a_block =3D { let(value =3D=3D 0) blah ::=3D static; }; different_block =3D { let(value2 !=3D 0) blah ::=3D irregular; }; }; or this: co_format_example =3D { a_block =3D blah { let(value =3D=3D 0) blah ::=3D static; }; different_block =3D blah { let(value2 !=3D 0) blah ::=3D irregular; }; }; ? I have assumed the former, otherwise, where do we put the field order info for stuff in the following example: co_format_example =3D=20 { a_block =3D blah { let(value =3D=3D 0) blah ::=3D static; }; different_block =3D blah { let(value2 !=3D 0) blah ::=3D irregular; }; stuff ::=3D lsb(9,9); }; ? I guess you could do it recursively: co_format_example =3D stuff, a_block, different_block { a_block =3D blah { let(value =3D=3D 0) blah ::=3D static; }; different_block =3D blah { let(value2 !=3D 0) blah ::=3D irregular; }; stuff ::=3D lsb(9,9); }; And if you had a list of alternatives you then give the prefix of the list as the label, which would be nice because it would mean you'd declared the label prefix somewhere: co_format_example =3D stuff, a_block { a_block_1 =3D blah { let(value =3D=3D 0) blah ::=3D static; } a_block_2 =3D blah { let(value2 !=3D 0) blah ::=3D irregular; }; stuff ::=3D lsb(9,9); }; now that I like! Simple and powerfully expressive. What does everyone else think? Raffles > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: Thursday, April 21, 2005 4:01 PM > To: Finking, Robert > Cc: Carsten Bormann > Subject: Re: [rohc] Expressing scaaled compression of fields=20 > in ROHC-FN. >=20 >=20 > On Apr 21 2005, at 16:55 Uhr, Finking, Robert wrote: >=20 > > does the lack of field order lists impact the example in=20 > some way that=20 > > I've missed >=20 > I'd just like to know where you want to put them (in case it's not=20 > obvious, this is not entirely obvious). > (The semicola I can place :-) >=20 > Gruesse, Carsten >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 11:47:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10663 for ; Thu, 21 Apr 2005 11:47:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOe5B-0002lt-6H for rohc-archive@ietf.org; Thu, 21 Apr 2005 11:59:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdt5-0002sE-5t; Thu, 21 Apr 2005 11:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdt4-0002s9-Fq for rohc@megatron.ietf.org; Thu, 21 Apr 2005 11:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10594 for ; Thu, 21 Apr 2005 11:46:40 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOe4V-0002kg-LG for rohc@ietf.org; Thu, 21 Apr 2005 11:58:32 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3LFkTqP016503 for ; Thu, 21 Apr 2005 16:46:29 +0100 Received: from [193.118.193.100] (193.118.193.100 [193.118.193.100]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JF3JW4TN; Thu, 21 Apr 2005 16:46:54 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Thu, 21 Apr 2005 16:40:14 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8806C417F-100000@rsys004a> Thread-Topic: Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVGiVeNWc/HovWTSoyhGTfz/fJ9Wg== From: "West, Mark" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Subject: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010212288==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 This is a multi-part message in MIME format. --===============2010212288== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54689.575B6B00" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C54689.575B6B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, After various holidays, illnesses and assorted other panics, I have now had sufficient time to both re-read the 're-ordering' draft and collate = my comments. (I deliberately did not read the other committed document review so as not to bias my own reading. However, I have not filtered = my review against it either, so apologies if I have duplicated some = comments as a result!) I have a couple of possibly significant comments, some minor comments = and a couple of nits. Hopefully they're not too confused... I'm basically pretty happy with the document: I like the analysis and implications and it reads well. However, I'd like the more significant comments, at least, to be addressed. Cheers, Mark. * Significant Comments - External sequence numbers There is no discussion of how ROHC can be run over a re-ordering channel when there is an external sequence number present (for example when running over IPsec ESP). I accept that this requires no modification at the compressor [other than the knowledge that this is being done], but = it would require modification at the decompressor. It may be argued that this technique is 'out of scope' or merely 'trivial', but I'm slightly surprised that it isn't even mentioned... - Discard or Decompress? Overall, I didn't see much discussion about whether the aim is to (i) detect sequentially late packets and discard them; or (ii) detect sequentially late packets and decompress them correctly. If (i) then the description given appears to be fairly complete. (Although it's not clear whether 'discard' is automatic on decoding of a sequentially late SN, or based solely on the CRC; the latter of which seems obviously less robust...) If (ii) then, unless I've missed something, there's no discussion of 'rarely changing' fields, for example -- a 'static' field can be considered to be LSB encoded with a fixed interpretation interval [lsb(0,0)]. Consider (where '--' =3D=3D 'not sent' or 'static'): Pkt# 1 2 3 4 5 7 6 8 TTL 62 62 62 -- -- 61 -- 61 then Pkt#7 is sequentially early (i.e. indistinguishable from loss), but Pkt#6 is detectably sequentially late. We can, in this case, either: i) rely on the CRC (U/O-mode) to catch the error; ii) discard the packet on detection of it being sequentially late; iii) discard the packet on detection of it being sequentially late *iff* there has been an update received that is now known to be sequentially early; or iv) cache updates at the decompressor and decompress against the correct context, having detected the sequentially late nature of the packet. Again, whatever the recommendation is, I would have thought that these options should at least be presented? * Minor Comments 1. Introduction Asserts that, despite RFC 3095 stating to the contrary, ROHC's inability to cope with re-ordering is a misconception. Section 3.2 then points out profiles (including some defined in RFC 3095) for which "reordered = packets cannot be decompressed" [without special considerations]. I guess it depends what your definition of 'cope with' is, but I'm having a bit of difficulty reconciling those two statements! 2. Terminology Cites RFC 2119 but, unless I've mis-grepped, conspicuously fails to use any capitalised keywords (there are a bunch of lower-case 'must's, 'should's, etc.; but these may just be red herrings!) [Is this document actually intending to use 'standards' language (should it?)] "Updating packet" -- IR/IR-DYN packets do not have a CRC computed over = the *uncompressed* packet? But are updating..? (almost just a nit!) 5.2.1 Functionality Incompatible with Reordering Timer-based compression is quoted under "functionality incompatible with reordering", but is (as stated correctly in the body of the draft) just something that impacts the jitter (i.e. the impact is already legislated for within RFC 3095) -- so I don't see why this is necessarily 'incompatible'... 6.1.1.1 Reordering and the Optimistic Approach Regarding increasing the number of repetitions of each context update: = Is this really necessary? What's the relationship between loss and re-ordering? I haven't really thought this one through fully, but I'm slightly suspicious... 6.1.1.3 Robust Selection of Compressed Header I'm not completely convinced about the phase, "the interpretation = interval for the LSB encoded sequence number could be adjusted..." I'd prefer something more explicit, such as, "packet formats could be chosen with = an interpretation interval for the LSB encoded sequence number that..." * nits 6.1 "may however lower" -> "may, however, lower" 6.1.2.2 'effiency' -> 'efficiency' ------_=_NextPart_001_01C54689.575B6B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-rohc-over-reordering-02.txt

Hi all,

After various holidays, illnesses and assorted other = panics, I have now
had sufficient time to both re-read the 're-ordering' = draft and collate my
comments.  (I deliberately did not read the = other committed document
review so as not to bias my own reading.  = However, I have not filtered my
review against it either, so apologies if I have = duplicated some comments
as a result!)

I have a couple of possibly significant comments, some = minor comments and
a couple of nits.  Hopefully they're not too = confused...

I'm basically pretty happy with the document: I like = the analysis and
implications and it reads well.  However, I'd = like the more significant
comments, at least, to be addressed.

Cheers,

Mark.



* Significant Comments

- External sequence numbers

There is no discussion of how ROHC can be run over a = re-ordering channel
when there is an external sequence number present = (for example when
running over IPsec ESP).  I accept that this = requires no modification at
the compressor [other than the knowledge that this is = being done], but it
would require modification at the decompressor.  = It may be argued that
this technique is 'out of scope' or merely 'trivial', = but I'm slightly
surprised that it isn't even mentioned...


- Discard or Decompress?

Overall, I didn't see much discussion about whether = the aim is to (i)
detect sequentially late packets and discard them; or = (ii) detect
sequentially late packets and decompress them = correctly.

If (i) then the description given appears to be fairly = complete.
(Although it's not clear whether 'discard' is = automatic on decoding of a
sequentially late SN, or based solely on the CRC; the = latter of which
seems obviously less robust...)

If (ii) then, unless I've missed something, there's no = discussion of
'rarely changing' fields, for example -- a 'static' = field can be
considered to be LSB encoded with a fixed = interpretation interval
[lsb(0,0)]. Consider (where '--' =3D=3D 'not sent' or = 'static'):

  Pkt#   1   2   = 3   4   5   7   6   = 8
  TTL   62  62  62  = --  --  61  --  61

then Pkt#7 is sequentially early (i.e. = indistinguishable from loss), but
Pkt#6 is detectably sequentially late.  We can, = in this case, either:

i) rely on the CRC (U/O-mode) to catch the = error;
ii) discard the packet on detection of it being = sequentially late;
iii) discard the packet on detection of it being = sequentially late *iff*
there has been an update received that is now known = to be sequentially
early; or
iv) cache updates at the decompressor and decompress = against the correct
context, having detected the sequentially late nature = of the packet.

Again, whatever the recommendation is, I would have = thought that these
options should at least be presented?


* Minor Comments

1. Introduction

Asserts that, despite RFC 3095 stating to the = contrary, ROHC's inability
to cope with re-ordering is a misconception. Section = 3.2 then points out
profiles (including some defined in RFC 3095) for = which "reordered packets
cannot be decompressed" [without special = considerations].  I guess it
depends what your definition of 'cope with' is, but = I'm having a bit of
difficulty reconciling those two statements!

2. Terminology

Cites RFC 2119 but, unless I've mis-grepped, = conspicuously fails to use
any capitalised keywords (there are a bunch of = lower-case 'must's,
'should's, etc.; but these may just be red herrings!) = [Is this document
actually intending to use 'standards' language = (should it?)]

"Updating packet" -- IR/IR-DYN packets do = not have a CRC computed over the
*uncompressed* packet?  But are updating..? = (almost just a nit!)

5.2.1 Functionality Incompatible with = Reordering

Timer-based compression is quoted under = "functionality incompatible with
reordering", but is (as stated correctly in the = body of the draft) just
something that impacts the jitter (i.e. the impact is = already legislated
for within RFC 3095) -- so I don't see why this is = necessarily
'incompatible'...

6.1.1.1 Reordering and the Optimistic Approach

Regarding increasing the number of repetitions of each = context update: Is
this really necessary?  What's the relationship = between loss and
re-ordering?  I haven't really thought this one = through fully, but I'm
slightly suspicious...

6.1.1.3 Robust Selection of Compressed Header

I'm not completely convinced about the phase, = "the interpretation interval
for the LSB encoded sequence number could be = adjusted..."  I'd prefer
something more explicit, such as, "packet = formats could be chosen with an
interpretation interval for the LSB encoded sequence = number that..."


* nits

6.1 "may however lower" -> "may, = however, lower"

6.1.2.2 'effiency' -> 'efficiency'

------_=_NextPart_001_01C54689.575B6B00-- --===============2010212288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============2010212288==-- From rohc-bounces@ietf.org Thu Apr 21 12:15:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13039 for ; Thu, 21 Apr 2005 12:15:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOeWe-0003T2-02 for rohc-archive@ietf.org; Thu, 21 Apr 2005 12:27:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeHZ-0005j2-Gd; Thu, 21 Apr 2005 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeHX-0005iq-9d for rohc@megatron.ietf.org; Thu, 21 Apr 2005 12:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12655 for ; Thu, 21 Apr 2005 12:11:57 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOeSy-0003LC-54 for rohc@ietf.org; Thu, 21 Apr 2005 12:23:50 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LGBeIP002695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Apr 2005 09:11:41 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3LGAhg3026185 for ; Thu, 21 Apr 2005 09:11:37 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 09:11:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Apr 2005 09:11:00 -0700 Message-ID: <7E8073C6DC0F294E997FE1407F81577B0A3A06@NAEX01.na.qualcomm.com> Thread-Topic: Comment on Reordering Draft Thread-Index: AcVGjLVv2rE4wfiDQZmxEpZj7M5pTA== From: "Kapoor, Rohit" To: X-OriginalArrivalTime: 21 Apr 2005 16:11:30.0661 (UTC) FILETIME=[C7840150:01C5468C] X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.5 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "Jin, Haipeng" Subject: [rohc] Comment on Reordering Draft X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0386217751==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a multi-part message in MIME format. --===============0386217751== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5468C.C08B19BE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5468C.C08B19BE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars-Erik, =20 I have a comment regarding the following paragraph in the RoHC over = reordering channels draft. =20 5.2.1. Functionality Incompatible with Reordering =20 Timer-based compression of RTP TS (see [2], section 4.5.4) is built on an assumption of timely (minimal jitter) delivery. When using this encoding method, the decompressor discards packets arriving with an arrival time that is outside the estimated upper bound for the estimated jitter. Therefore it should be used with care over links where reordering can occur, with respect to the amount of jitter that can be introduced by reordering. =20 Timer-based compression is not really incompatible with reordering. In = fact, the only requirement is one of e2e jitter to be bounded for = timer-based to work. Even though the paragraph says at the end that "it = should be used with care over links where reordering can occur", I think = inclusion of this paragraph under the "Functionality Incompatible with = Reordering" section can cause confusion. My suggestion would be to = include this under a separate section, potentially entitled something = like "Things to Keep in Mind when using RoHC over Reordering Channels" = or something along these lines. =20 Thanks, Rohit ------_=_NextPart_001_01C5468C.C08B19BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Lars-Erik,
=0A=
 
=0A=
I have a comment = regarding the =0A= following paragraph in the RoHC over reordering channels = draft.
=0A=
 
=0A=
5.2.1. Functionality = Incompatible =0A= with Reordering
=0A=
 
=0A=
   = Timer-based compression =0A= of RTP TS (see [2], section 4.5.4) is built
   on an = assumption of =0A= timely (minimal jitter) delivery. When using this
   = encoding =0A= method, the decompressor discards packets arriving with = an
   =0A= arrival time that is outside the estimated upper bound for = the
   =0A= estimated jitter. Therefore it should be used with care over =0A= links
   where reordering can occur, with respect to the = amount of =0A= jitter that
   can be introduced by = reordering.
=0A=

 
=0A=
Timer-based compression is not really incompatible with reordering. = In =0A= fact, the only requirement is one of e2e jitter to be bounded for = timer-based to =0A= work. Even though the paragraph says at the end that "it should be used = with =0A= care over links where reordering can occur", I think inclusion of this = paragraph =0A= under the "Functionality Incompatible with Reordering" section can cause =0A= confusion. My suggestion would be to include this under a separate = section, =0A= potentially entitled something like "Things to Keep in Mind when using = RoHC over =0A= Reordering Channels" or something along these lines.
=0A=
 
=0A=
Thanks,
Rohit
------_=_NextPart_001_01C5468C.C08B19BE-- --===============0386217751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0386217751==-- From rohc-bounces@ietf.org Thu Apr 21 12:52:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16614 for ; Thu, 21 Apr 2005 12:52:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOf62-0004ZB-EA for rohc-archive@ietf.org; Thu, 21 Apr 2005 13:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOetQ-0004iL-KI; Thu, 21 Apr 2005 12:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOetP-0004iG-8V for rohc@megatron.ietf.org; Thu, 21 Apr 2005 12:51:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16465 for ; Thu, 21 Apr 2005 12:51:04 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOf4W-0004VK-Qb for rohc@ietf.org; Thu, 21 Apr 2005 13:02:58 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3LGnJQi013720; Thu, 21 Apr 2005 18:50:37 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 18:49:39 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 15:25:32 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 15:24:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Thu, 21 Apr 2005 15:24:05 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DA9D@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 Thread-Index: AcVGTo73pKL0jIYmQ9ClZ/gTovZ4AQAAfpgAAAkiwLA= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" , X-OriginalArrivalTime: 21 Apr 2005 13:24:06.0689 (UTC) FILETIME=[64D78110:01C54675] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable > > I can volunteer to write this stuff, but could it be possible=20 > > that we can put the source for this in the CVS (even if it is > > still in word) so that we can get some speed up on the editing? > > I'm not fond of the "centralized" editing we've been doing on > > this document. You've given exactly 3h45mins for the editor to react to your mail with = suggested changes before complaining about the "centralized editing" of = the RoHC-TCP draft. Or are there other changes that you've sent recently = that I've not noticed? /Ghyslain > Kristofer, >=20 > Feel free to discuss with the editor about helping out with the > editing of this document, but it is up to the editor how to do > this. I will hold the editor responsible for all changes, and > for making sure that all changes are based on what has been > agreed, even if he gets help from others with writing text. >=20 > Rgds, > /L-E (Big chair hat on) >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 21 18:26:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24208 for ; Thu, 21 Apr 2005 18:26:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOkJ8-0007Lh-4n for rohc-archive@ietf.org; Thu, 21 Apr 2005 18:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOk5r-0004DL-Iq; Thu, 21 Apr 2005 18:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOk5q-0004DG-9P for rohc@megatron.ietf.org; Thu, 21 Apr 2005 18:24:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24103 for ; Thu, 21 Apr 2005 18:24:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOkHL-0007ID-F9 for rohc@ietf.org; Thu, 21 Apr 2005 18:36:12 -0400 Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1DOjpr-0007RU-8D for rohc@ietf.org; Thu, 21 Apr 2005 18:07:47 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j3LM3Wbo008704 for ; Thu, 21 Apr 2005 18:06:11 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.2.052) id 426289720014C929 for rohc@ietf.org; Thu, 21 Apr 2005 18:06:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 17:06:12 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA8C7A@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt Thread-Index: AcVGsK+ZB2HmnyVzRdmKlM478mx93gAB+qAAAAFCAXAAACNPsAAABc3A From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [rohc] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Hi All, Please review and comment on the (significantly) updated draft "Protocol Extensions for Header Compression over MPLS" (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol -00.txt). Here is a brief background and overview/explanation of the updates: Work on requirements for header compression over MPLS (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-mpls-reqs-03.txt) is complete, and work on protocol extensions for header compression over MPLS is underway (previous draft at http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-0 2.txt). Chartering of the protocol work in the AVT working group has been submitted for approval with the following milestone: Dec 05: Submit any extensions for RTP HC on MPLS networks for Proposed Standard There has been considerable discussion on the previous protocol extensions draft (http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol- 02.txt) in the last couple of months. I presented the update on the header compression over MPLS protocol extensions work at the AVT meeting at IETF-62; slides and minutes are available at https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=3D= 6 2 (look under AVT for minutes and slides). The recent discussion and issues regarding the basic approach are summarized in the slides. Header compression experts in the AVT and ROHC working groups wish to re-use, and extend, the existing layer 2 approaches for assignment of context identification (CID) and header compression parameter negotiation. In a multipoint-to-point MPLS environment, one approach would be to have the various header compressors assign CIDs as they do now, with the possible need to resolve CID conflicts/collisions at the header decompressor. Some comments were made that current header compression methods do not have to resolve CID collisions, however the synchronization source (SSRC) assigned in RTP could need collision/conflict resolution. A second approach, suggested by Andy Malis and Loa Andersson, is to use pseudowires and/or targeted LDP to create 'point-to-point' sessions between header compressor and header decompressor, thereby avoiding any issue of CID collision. The disadvantage of this approach is that it requires an additional 4-byte label to be carried with each packet. =20 The updated draft based on the second approach is available at http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol- 00.txt. Once again, please review and comment on the updated draft. Thanks, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, April 21, 2005 3:39 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol Extensions for Header Compression over MPLS Author(s) : J. Ash, et al. Filename : draft-ash-avt-hc-over-mpls-protocol-00.txt Pages : 12 Date : 2005-4-21 =09 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the pseudowires define a point to point instance of each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol- 00.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 02:17:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11289 for ; Fri, 22 Apr 2005 02:17:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOrfT-0000te-Ok for rohc-archive@ietf.org; Fri, 22 Apr 2005 02:29:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOrRL-0002P6-GZ; Fri, 22 Apr 2005 02:14:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOrRI-0002NX-HV for rohc@megatron.ietf.org; Fri, 22 Apr 2005 02:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08628 for ; Fri, 22 Apr 2005 02:14:55 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOrcq-0000oj-Jk for rohc@ietf.org; Fri, 22 Apr 2005 02:26:54 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3M5E4mg022644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Apr 2005 07:14:05 +0200 Message-ID: <42689650.5060900@effnet.com> Date: Fri, 22 Apr 2005 08:14:40 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] Proposed changes to rohc-tcp-09 References: <026F8EEDAD2C4342A993203088C1FC0527DA9D@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0527DA9D@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Ghyslain, I did not mean that you had been neglecting you duties as editor, so apologies if I made it sound that way. My intention was only to help take some load off your shoulders on the editing by doing some of the edits myself. /Kristofer Ghyslain Pelletier (LU/EAB) wrote: >>>I can volunteer to write this stuff, but could it be possible >>>that we can put the source for this in the CVS (even if it is >>>still in word) so that we can get some speed up on the editing? >>>I'm not fond of the "centralized" editing we've been doing on >>>this document. > > > You've given exactly 3h45mins for the editor to react to your mail with suggested changes before complaining about the "centralized editing" of the RoHC-TCP draft. Or are there other changes that you've sent recently that I've not noticed? > > /Ghyslain > > >>Kristofer, >> >>Feel free to discuss with the editor about helping out with the >>editing of this document, but it is up to the editor how to do >>this. I will hold the editor responsible for all changes, and >>for making sure that all changes are based on what has been >>agreed, even if he gets help from others with writing text. >> >>Rgds, >>/L-E (Big chair hat on) >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 03:06:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18802 for ; Fri, 22 Apr 2005 03:06:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOsR7-0001vC-Ss for rohc-archive@ietf.org; Fri, 22 Apr 2005 03:18:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOs9m-0001Jj-0E; Fri, 22 Apr 2005 03:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOs9j-0001Je-RR for rohc@megatron.ietf.org; Fri, 22 Apr 2005 03:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18215 for ; Fri, 22 Apr 2005 03:00:50 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOsLJ-0001im-07 for rohc@ietf.org; Fri, 22 Apr 2005 03:12:50 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3M607mg022736 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 22 Apr 2005 08:00:08 +0200 Message-ID: <4268A11C.1000304@effnet.com> Date: Fri, 22 Apr 2005 09:00:44 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [rohc] Unused references in ROHC-TCP draft X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi! After more reading in rohc-tcp-09, I found a lot of Informative references that are never referred to. I see no point in referring to such documents, so I suggest removing them for the next revision of the draft. These would be: 7 The standards process 13 TCP long delay 16 T/TCP 17 Partial order 18 RTP 19 TCP slow start 24 Fast Retransmit Anyone wants to keep any of these? Also, the reference [6] to the TCP spec is unused, but I think it would be silly to remove that one, better then to actually refer to it! Also, both reference [1] and [8] are for RFC2119, and even though it is an important document, having one reference seems enough :) /Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 04:26:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24575 for ; Fri, 22 Apr 2005 04:26:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOtfs-0003xo-P3 for rohc-archive@ietf.org; Fri, 22 Apr 2005 04:38:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOtTb-0006fY-Bf; Fri, 22 Apr 2005 04:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOtTY-0006fO-6A for rohc@megatron.ietf.org; Fri, 22 Apr 2005 04:25:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24500 for ; Fri, 22 Apr 2005 04:25:22 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOtf8-0003we-Hb for rohc@ietf.org; Fri, 22 Apr 2005 04:37:23 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3M8Ohgm009734; Fri, 22 Apr 2005 10:25:22 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 10:24:53 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 10:24:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Fri, 22 Apr 2005 10:24:45 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DAA7@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVGgvzNdxS3ThpHTSmvkQw8dllkNwABODngACLgRHA= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Finking, Robert" , X-OriginalArrivalTime: 22 Apr 2005 08:24:51.0935 (UTC) FILETIME=[C16336F0:01C54714] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Hi Robert, I could like the idea of this being solved in a similar fashion as for = lists, by using the prefix of the block name to make things mutually = exclusive. But I don't understand what you meant by "doing it = recursively". However, I thought that we only needed to fix scoping for let = statements, why do we want to add the notion of mutually exclusive - is = this necessary? Another question, is this instead of the earlier proposal of using = brackets to scope the "let" so that only the alternative fails and not = the entire format? /Ghyslain > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Finking, Robert > Sent: den 21 april 2005 17:40 > To: rohc@ietf.org > Subject: RE: [rohc] Expressing scaaled compression of fields=20 > in ROHC-FN. >=20 >=20 > Hi, >=20 > You're right, it wasn't entirely obvious that it wasn't entirely > obvious. I guess the fact that I needed to clarify that it wasn't > entirely obvious that it wasn't entirely obvious, means that from your > point of view it wasn't entirely obvious that it wasn't=20 > entirely obvious > that it wasn't entirely obvious =3D) >=20 > You're asking do we have this: >=20 > co_format_example =3D blah > { > a_block =3D > { > let(value =3D=3D 0) > blah ::=3D static; > }; >=20 > different_block =3D > { > let(value2 !=3D 0) > blah ::=3D irregular; > }; > }; >=20 > or this: >=20 > co_format_example =3D > { > a_block =3D blah > { > let(value =3D=3D 0) > blah ::=3D static; > }; >=20 > different_block =3D blah > { > let(value2 !=3D 0) > blah ::=3D irregular; > }; > }; >=20 > ? I have assumed the former, otherwise, where do we put the=20 > field order > info for stuff in the following example: >=20 > co_format_example =3D=20 > { > a_block =3D blah > { > let(value =3D=3D 0) > blah ::=3D static; > }; >=20 > different_block =3D blah > { > let(value2 !=3D 0) > blah ::=3D irregular; > }; >=20 > stuff ::=3D lsb(9,9); > }; >=20 > ? I guess you could do it recursively: >=20 > co_format_example =3D stuff, > a_block, > different_block > { > a_block =3D blah > { > let(value =3D=3D 0) > blah ::=3D static; > }; >=20 > different_block =3D blah > { > let(value2 !=3D 0) > blah ::=3D irregular; > }; >=20 > stuff ::=3D lsb(9,9); > }; >=20 > And if you had a list of alternatives you then give the prefix of the > list as the label, which would be nice because it would mean you'd > declared the label prefix somewhere: >=20 > co_format_example =3D stuff, > a_block > { > a_block_1 =3D blah > { > let(value =3D=3D 0) > blah ::=3D static; > } > a_block_2 =3D blah > { > let(value2 !=3D 0) > blah ::=3D irregular; > }; >=20 > stuff ::=3D lsb(9,9); > }; >=20 > now that I like! Simple and powerfully expressive. What does everyone > else think? >=20 > Raffles >=20 > > -----Original Message----- > > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > > Sent: Thursday, April 21, 2005 4:01 PM > > To: Finking, Robert > > Cc: Carsten Bormann > > Subject: Re: [rohc] Expressing scaaled compression of fields=20 > > in ROHC-FN. > >=20 > >=20 > > On Apr 21 2005, at 16:55 Uhr, Finking, Robert wrote: > >=20 > > > does the lack of field order lists impact the example in=20 > > some way that=20 > > > I've missed > >=20 > > I'd just like to know where you want to put them (in case it's not=20 > > obvious, this is not entirely obvious). > > (The semicola I can place :-) > >=20 > > Gruesse, Carsten > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 06:18:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01454 for ; Fri, 22 Apr 2005 06:18:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOvQs-0006Hj-OO for rohc-archive@ietf.org; Fri, 22 Apr 2005 06:30:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOvB0-0003Qs-Cw; Fri, 22 Apr 2005 06:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOvAy-0003Qn-Sg for rohc@megatron.ietf.org; Fri, 22 Apr 2005 06:14:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00936 for ; Fri, 22 Apr 2005 06:14:18 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOvMZ-00068Y-C2 for rohc@ietf.org; Fri, 22 Apr 2005 06:26:21 -0400 Received: from [192.168.100.150] (nat.effnet.com [194.237.235.17]) by effnet.com (8.12.3/8.12.3) with ESMTP id j3M9DZmf023330 for ; Fri, 22 Apr 2005 11:13:35 +0200 Message-ID: <4268CE70.40901@effnet.com> Date: Fri, 22 Apr 2005 12:14:08 +0200 From: Aniruddha Kulkarni User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, I have following comments on the draft, I have tried not to repeat the comments made by others but there may still be some repetitions. 1. section 5.1.2.1 "The compressor removes values smaller than..." this should be "...older than...". 2. section 5.2.1 "When using this encoding method, the decompressor discards...". This should be "..., the compressor discards..." (refer 3095 section 4.5.4, para 4). I agree with others on the point that timer-based compression is not "functionally incompatible" with reordering. It suffers in same way as scaled-timestamp encoding would. 3. section 6.1.1.2 , Avoiding the "missing reference" problem If the decompressor implements the context updating logic of section 6.1.2.1 and compressor is aware of that (by means of standardization), why would it delay advance in sliding window? 4. section 6.1.2.1 , Will the addition of "The decompressor should not deliver the sequentially late (with respect to the reference) non-updating packet to upper layer." handle case for both updating and non-updating packets? 5. section 6.1.2.2 "Note that if the decompressor does not make this adjustment to its feedback, packet losses or context damages will not increase". It is confusing, could it mean that "if decompressor does make the adjustment, packet losses/context damages will increase" or does it mean "even if decompressor does not make the adjustment, losses/damages will not increase". Can it be made bit clear? Aniruddha Kulkarni _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 07:54:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09419 for ; Fri, 22 Apr 2005 07:54:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOwvD-0000LH-3q for rohc-archive@ietf.org; Fri, 22 Apr 2005 08:06:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwfg-0008Vd-E2; Fri, 22 Apr 2005 07:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwff-0008VJ-6O for rohc@megatron.ietf.org; Fri, 22 Apr 2005 07:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09060 for ; Fri, 22 Apr 2005 07:50:06 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOwrE-0000E6-Dh for rohc@ietf.org; Fri, 22 Apr 2005 08:02:08 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3MBnOqP009484; Fri, 22 Apr 2005 12:49:24 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaaled compression of fields in ROHC-FN. Date: Fri, 22 Apr 2005 12:49:41 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A28E1@rsys004a> Thread-Topic: [rohc] Expressing scaaled compression of fields in ROHC-FN. Thread-Index: AcVHFOod7dVFtTUNS+WwExDl1BWy8AAGTilQ From: "Finking, Robert" To: "Ghyslain Pelletier \(LU/EAB\)" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable Hi Ghyslain, Thanks for the reply. Answers in-line =3D) Raffles > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB)=20 > [mailto:ghyslain.pelletier@ericsson.com]=20 > Sent: Friday, April 22, 2005 9:25 AM > To: Finking, Robert; rohc@ietf.org > Subject: RE: [rohc] Expressing scaaled compression of fields=20 > in ROHC-FN. >=20 >=20 > Hi Robert, >=20 > I could like the idea of this being solved in a similar=20 > fashion as for lists, by using the prefix of the block name=20 > to make things mutually exclusive. But I don't understand=20 > what you meant by "doing it recursively". All I meant was, being able to use the packet format syntax inside a packet format. That way we don't have to define special notation to handle the fixed scoping of let statements - we use the existing notation instead. >=20 > However, I thought that we only needed to fix scoping for let=20 > statements, why do we want to add the notion of mutually=20 > exclusive - is this necessary? Well strictly speaking no, we could just about get away without it for the TCP profile. However, the profile should be clearer if we can notate explicitly that two blocks are mutually exclusive: e.g. you can't have a packet that has a payload and doesn't have one. >=20 > Another question, is this instead of the earlier proposal of=20 > using brackets to scope the "let" so that only the=20 > alternative fails and not the entire format? >=20 Yes, it's an enhancement of it. Your excellent suggestion was so similar to the syntax that we use to group packet formats, why don't we use that syntax for this too? That way we don't need to have any special notation for this AND it gives us the ability to notate mutual exclusion for free. My idea of using lists was just a nicety, we could stick with the exact same syntax we have now. Here is the last example of my previous mail, rewritten with current packet format syntax (i.e. not using lists): co_format_example =3D stuff, a_block { a_block_1 =3D blah { let(value =3D=3D 0) blah ::=3D static; }; a_block_2 =3D blah { let(value2 !=3D 0) blah ::=3D irregular; }; stuff ::=3D lsb(9,9); }; Does that answer your question? It is slightly more verbose than your example, but since it uses the full packet format syntax, it is also more powerful, and yet simpler in that it just reuses part of the notation that already exists. Raffles > /Ghyslain >=20 >=20 > > -----Original Message----- > > From: rohc-bounces@ietf.org=20 > [mailto:rohc-bounces@ietf.org]On Behalf Of > > Finking, Robert > > Sent: den 21 april 2005 17:40 > > To: rohc@ietf.org > > Subject: RE: [rohc] Expressing scaaled compression of fields=20 > > in ROHC-FN. > >=20 > >=20 > > Hi, > >=20 > > You're right, it wasn't entirely obvious that it wasn't entirely > > obvious. I guess the fact that I needed to clarify that it wasn't > > entirely obvious that it wasn't entirely obvious, means=20 > that from your > > point of view it wasn't entirely obvious that it wasn't=20 > > entirely obvious > > that it wasn't entirely obvious =3D) > >=20 > > You're asking do we have this: > >=20 > > co_format_example =3D blah > > { > > a_block =3D > > { > > let(value =3D=3D 0) > > blah ::=3D static; > > }; > >=20 > > different_block =3D > > { > > let(value2 !=3D 0) > > blah ::=3D irregular; > > }; > > }; > >=20 > > or this: > >=20 > > co_format_example =3D > > { > > a_block =3D blah > > { > > let(value =3D=3D 0) > > blah ::=3D static; > > }; > >=20 > > different_block =3D blah > > { > > let(value2 !=3D 0) > > blah ::=3D irregular; > > }; > > }; > >=20 > > ? I have assumed the former, otherwise, where do we put the=20 > > field order > > info for stuff in the following example: > >=20 > > co_format_example =3D=20 > > { > > a_block =3D blah > > { > > let(value =3D=3D 0) > > blah ::=3D static; > > }; > >=20 > > different_block =3D blah > > { > > let(value2 !=3D 0) > > blah ::=3D irregular; > > }; > >=20 > > stuff ::=3D lsb(9,9); > > }; > >=20 > > ? I guess you could do it recursively: > >=20 > > co_format_example =3D stuff, > > a_block, > > different_block > > { > > a_block =3D blah > > { > > let(value =3D=3D 0) > > blah ::=3D static; > > }; > >=20 > > different_block =3D blah > > { > > let(value2 !=3D 0) > > blah ::=3D irregular; > > }; > >=20 > > stuff ::=3D lsb(9,9); > > }; > >=20 > > And if you had a list of alternatives you then give the=20 > prefix of the > > list as the label, which would be nice because it would mean you'd > > declared the label prefix somewhere: > >=20 > > co_format_example =3D stuff, > > a_block > > { > > a_block_1 =3D blah > > { > > let(value =3D=3D 0) > > blah ::=3D static; > > } > > a_block_2 =3D blah > > { > > let(value2 !=3D 0) > > blah ::=3D irregular; > > }; > >=20 > > stuff ::=3D lsb(9,9); > > }; > >=20 > > now that I like! Simple and powerfully expressive. What=20 > does everyone > > else think? > >=20 > > Raffles > >=20 > > > -----Original Message----- > > > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > > > Sent: Thursday, April 21, 2005 4:01 PM > > > To: Finking, Robert > > > Cc: Carsten Bormann > > > Subject: Re: [rohc] Expressing scaaled compression of fields=20 > > > in ROHC-FN. > > >=20 > > >=20 > > > On Apr 21 2005, at 16:55 Uhr, Finking, Robert wrote: > > >=20 > > > > does the lack of field order lists impact the example in=20 > > > some way that=20 > > > > I've missed > > >=20 > > > I'd just like to know where you want to put them (in case=20 > it's not=20 > > > obvious, this is not entirely obvious). > > > (The semicola I can place :-) > > >=20 > > > Gruesse, Carsten > > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 12:33:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02316 for ; Fri, 22 Apr 2005 12:33:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP1HX-00073c-B0 for rohc-archive@ietf.org; Fri, 22 Apr 2005 12:45:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP13y-000387-EO; Fri, 22 Apr 2005 12:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP13v-00037g-Qc for rohc@megatron.ietf.org; Fri, 22 Apr 2005 12:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02207 for ; Fri, 22 Apr 2005 12:31:24 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP1FZ-00070E-Od for rohc@ietf.org; Fri, 22 Apr 2005 12:43:30 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3MGUkqP014853; Fri, 22 Apr 2005 17:30:46 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] SigComp torture tests Date: Fri, 22 Apr 2005 17:30:55 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5F39@rsys004a> Thread-Topic: [rohc] SigComp torture tests Thread-Index: AcUowc1dwMjVQ5jfRsuBoKaBBCGtBAeiU8Gw From: "Surtees, Abigail" To: "Pekka Pessi" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, Herve Siegrist X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Hi Pekka, I've run this test and agree with its description and conclusions. I'll update it in the next version of the torture test draft. Best regards, Abbie > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]=20 > Sent: Monday, March 14, 2005 5:22 PM > To: Surtees, Abigail > Cc: 'Pekka Pessi'; rohc@ietf.org; 'Herve Siegrist' > Subject: Re: [rohc] SigComp torture tests >=20 >=20 > Hi Abigail, >=20 > "Surtees, Abigail" writes: > >I've run this torture test plus the other 2 you suggested for > >torture-tests-00.txt with the following results: >=20 > >Use 3485 state: > > Agrees with the stated output and number of cycles :-) >=20 > >Bytecode state creation: >=20 > > Message 2 does not work - the bytes given under 'Second=20 > message' are > >not the same as the ones given in the textual description=20 > higher up. The > >message in the textual description is the one that references state > >correctly. I don't think there is any need for the messages=20 > to be given > >twice and there is a good description of what the messages=20 > do before the > >bytecode so I've suggested some alternative text below. >=20 > > The output from the 2nd message I get is 0x4f4b 32=20 > (rather than 31 > >at the end). Is this correct (as far as I can see from the=20 > mnemonic code, > >it should be 32)? (This means I agree with Herve.) >=20 > A copy and paste error, I'm sorry. My own test driver uses 4f=20 > 4b 32, too. >=20 > > Again for message 3, the last byte of output I get is=20 > 32 rather than > >31. (And again, I agree with Herve.) >=20 > > The number of cycles are the same as stated. >=20 > > General comments: >=20 > > Having worked out what this bytecode does, I think the > >description is slightly misleading - the bytecode isn't=20 > self-modifying as > >the area containing bytecode is never overwritten during its=20 > execution. I > >suggest removal of the words "self-modifying byte code," from the > >description. >=20 > You are absolute right. I wrote the test case because some UDVM > implementations had problems with my bytecode, one when the > bytecode was modified, another when the bytecode state started > before 128. The contributed torture test case does not test > self-modification, only the second problematic case.=20 >=20 > Now I added a INPUT-BYTES modifying the OUTPUT() instruction, > please see the modified UDVM assembly and messages below. >=20 > > One addition to the test is that of switching=20 > the LOAD and > >first STATE-CREATE instructions. This would then also check=20 > that if the > >area to be saved is modified after the STATE-CREATE request,=20 > it still works. > >What do you think? >=20 > That sounds great.=20 >=20 > > Updated text for this test is given below. >=20 > Again... >=20 > --Pekka >=20 > 4.5 Bytecode state creation >=20 > This section gives assembly code to test storing bytecode using > END-MESSAGE and later loading the bytecode using a partial state > identifier within the SigComp header. The assembly code=20 > is designed > so that it includes testing changing bytes to be stored after the > state create request, loading byte code in special memory areas and > correct initialization order of the UDVM. > 1. Four items of bytecode state are created. The bytes=20 > to be saved > change after the first state create request. The=20 > uploaded bytecode > is modified before execution. > 2. The bytecode is loaded using partial state identifier=20 > and modified. > 3. The bytecode is loaded before 128 using partial state=20 > identifier. > 4. The bytecode is loaded using partial state identifier. Part of > the loaded memory is reserved area, which is overwritten after > loading the bytecode. > 5. The byte loading fails because partial state identifier is too > short. >=20 > at (30) > :save_area1 > set (saved_instr1, (save_area1 + (code_start2 - start_saved))) >=20 > at (80) > :save_area2 > set (saved_instr2, (save_area2 + (code_start2 - start_saved))) >=20 > at (128) > :code_start >=20 > COPY (start_saved, saved_len, save_area1) > STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10) >=20 > set (modify1, (save_area1 + 5)) > LOAD (modify1, 0x1e03) >=20 > COPY (start_saved, saved_len, save_area2) > STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10) > STATE-CREATE (saved_len, save_area2, saved_instr2, 12, 10) > JUMP (modify) >=20 > :ok1 byte (0x4f, 0x4b, 0x31) >=20 > :modify > INPUT-BYTES (1, (after_output - 1), !) > OUTPUT (ok1, 3) > :after_output >=20 > ; Save from ok1 to the opcode of END-MESSAGE=20 > set (modify_len, ((after_output + 1) - ok1)) >=20 > END-MESSAGE (0, 0, modify_len, ok1, modify, 6, 10) > =09 > set (saved_len, (end_saved - start_saved)) >=20 > :start_saved > byte (0x4f, 0x4b, 0x32) > :code_start2 > ; OUTPUT (save_area2, 3) > byte (0x22, 0xa0, 0x50, 0x03) > ; END-MESSAGE (0, 0, 0, 0, 0, 0, 0) > byte (0x23) > :end_saved >=20 >=20 > The expected outputs and cycle usages are: >=20 > Message Output Cycles > 1 0x4f4b 67 > 1 0x4f4b 31 7 > 2 0x4f4b 32 5 > 3 0x0000 32 5 > 4 None Decompression failure >=20 > First message: >=20 > 0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008 > 0xa050 a053 140a 2008 a050 a053 0c0a 1605 4f4b 311c 01a0 b39f 5522 > 0xa0a7 0323 0000 0ea0 a7a0 aa06 0a4f 4b32 22a0 5003 2302 >=20 > Second message: >=20 > 0xf953 e97f 4afd d203 >=20 > Third message: >=20 > 0xfb24 63cd ff5c f8c7 6df6 a289 ff >=20 > Fourth message: >=20 > 0xf95b 4b43 d567 83 >=20 > Fifth message: > =20 > 0xf9de 8126 1199 1f" >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 12:34:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02380 for ; Fri, 22 Apr 2005 12:34:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP1IG-00074g-9x for rohc-archive@ietf.org; Fri, 22 Apr 2005 12:46:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP13x-00037o-1b; Fri, 22 Apr 2005 12:31:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP13v-00037f-Qd for rohc@megatron.ietf.org; Fri, 22 Apr 2005 12:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02206 for ; Fri, 22 Apr 2005 12:31:24 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP1FZ-00070H-Lu for rohc@ietf.org; Fri, 22 Apr 2005 12:43:30 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3MGUJqP014601; Fri, 22 Apr 2005 17:30:19 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] SigComp torture tests Date: Fri, 22 Apr 2005 17:30:29 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5F38@rsys004a> Thread-Topic: [rohc] SigComp torture tests Thread-Index: AcUowc1l7fG2pjDDR9yIPnWh+Xn1igelCPAA From: "Surtees, Abigail" To: "Pekka Pessi" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, Herve Siegrist X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Hi Pekka, Thanks for the extra corner cases on the state create test. They are well worth testing (how long did it take you to find 2 pieces of state that have the same first 6 bytes of hash? ;-) ). I think there is also another useful test covered by the way you've written the bytecode :-) 7. Write the bytes of the identifier to the position specified in the STATE-FREE instruction after the STATE-FREE instruction has been run (and before END-MESSAGE). I have a few comments on the message listed as input (I think we might not need quite so many) but am perfectly happy with the mnemonic and bytecode. =20 > And the test messages: >=20 > Compressed message: Number of state items: UDVM cycles: > 0x00 0 13 This one doesn't do anything - do we need it? > 0x01 1 23 > 0x02 0 14 > 0x03 1 24 >=20 > 0x0400 Decompression failure =20 Is there any reason why this is 0420 rather than 0405 which would test 1 byte below the limit? =20 > 0x0420 Decompression failure =20 Is there any reason why this is 0420 rather than 0415 which would test 1 byte beyond the limit? =20 > 0x0406 No 23 change 'No' to '0' >=20 > 0x09 1 34 > 0x0a 0 25 > 0x0b 1 35 As with the previous version of the test, 0x0a and 0x0b *almost* but don't quite (if you're being strict about it) cover point 3. 0x0a recreates an existing piece of state before freeing it; 0x0b creates, frees and recreates. However, 0x1e07 and 0x1e14 below both completely cover point 3 so I'm not sure we need 0x0a and 0x0b. What do you think? >=20 > 0x1a 2 36 > 0x1e06 2 46 0x1e06 does pretty much the same as 0x1a (just with 2 attempts to free the state). However, it does make a good comparison with 0x1e07 so maybe we don't need 0x1a? > 0x1e07 0 47 > 0x1e14 0 60 > 0x1f14 1 70 Similarly, 0x1f14 doesn't really show anything that isn't already shown so I don't think we need it. What do you think? None of these is a big deal, but given that the test can be covered by a smaller number of test messages I don't see any point in over complicating it. Let me know what you think and I'll update the draft accordingly.=20 >=20 > I took the UDVM cycle count from my notoriously reliable > debugging output. Caveat emptor. Our implementation agrees with your cycle counts :-) Best regards, Abbie >=20 > --Pekka >=20 > at (64) >=20 > :byte_copy_left pad (2) > :byte_copy_right pad (2) > :states pad (1) > :states_lsb pad (1) > :min_len pad (1) > :min_len_lsb pad (1) >=20 > :state_identifier pad (20) >=20 > set (state_length, 10) >=20 > at (128) >=20 > INPUT-BYTES (1, states_lsb, !) >=20 > :test_one > LSHIFT ($states, 11) > COMPARE ($states, 32768, test_two, create_state_a2,=20 > create_state_a2) > :create_state_a2 > STATE-CREATE (state_length, state_address2, 0, 20, 0) >=20 > :test_two > LSHIFT ($states, 1) > COMPARE ($states, 32768, test_three, create_state_a,=20 > create_state_a) > :create_state_a > STATE-CREATE (state_length, state_address, 0, 20, 0) >=20 > :test_three > LSHIFT ($states, 1) > COMPARE ($states, 32768, test_four, free_state, free_state) > :free_state > INPUT-BYTES (1, min_len_lsb, !) > STATE-FREE (state_identifier, $min_len) > COPY (identifier1, $min_len, state_identifier) >=20 > :test_four > LSHIFT ($states, 1) > COMPARE ($states, 32768, test_five, free_state2, free_state2) > :free_state2 > STATE-FREE (identifier1, 6) >=20 > :test_five > LSHIFT ($states, 1) > COMPARE ($states, 32768, end, create_state_b, create_state_b) > :create_state_b > END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0) > :end > END-MESSAGE (0, 0, 0, 0, 0, 0, 0) >=20 > :identifier1 > byte (67, 122, 232, 10, 15, 220, 30, 106, 135, 193,=20 > 182, 42, 118, 118, 185, 115, 49, 140, 14, 245) >=20 > at (256) > :state_address > byte (192, 204, 63, 238, 121, 188, 252, 143, 209, 8) > :state_address2 > byte (101, 232, 3, 82, 238, 41, 119, 23, 223, 87) >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 22 18:33:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10524 for ; Fri, 22 Apr 2005 18:33:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP6uU-0002az-Tu for rohc-archive@ietf.org; Fri, 22 Apr 2005 18:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP6hq-0004vt-In; Fri, 22 Apr 2005 18:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP6ho-0004vb-G7 for rohc@megatron.ietf.org; Fri, 22 Apr 2005 18:33:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10444 for ; Fri, 22 Apr 2005 18:32:57 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP6tW-0002Y1-Ms for rohc@ietf.org; Fri, 22 Apr 2005 18:45:07 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3MMWgHa019640; Fri, 22 Apr 2005 15:32:42 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3MMWCIj017941; Fri, 22 Apr 2005 15:32:39 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 15:32:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Date: Fri, 22 Apr 2005 15:32:04 -0700 Message-ID: Thread-Topic: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Thread-Index: AcVFdEBnJttv5RtwSimD64WMVLbrMAAAJ57wAH0MO2A= From: "Jin, Haipeng" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 22 Apr 2005 22:32:10.0190 (UTC) FILETIME=[1F594EE0:01C5478B] X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Lars-Erik and Kristofer, Sorry for the late reply, but here are my comments: Sending non-zero CLOCK feedback option to turn on timer-based compression seems fine.=20 But I just want to clarify that timer-based compression is always required to be implemented in ROHC stack. It is an optional mechanism only in the sense that if the decompressor does not have timing information from a clock, then it can not be used. When the CLOCK_RESOLUTION on the decompressor side is non-zero, then timer-based compression can always be used if the compressor indicates so. In addition, if CLOCK feedback is needed to turn on timer-based compression, then we need to clarify in the implementer's guide that if the decompressor hasn't sent CLCOK feedback to the compressor, upon receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the decompressor needs to send CLOCK feedback value to indicate the CLOCK_RESOLUTION.=20 Thanks, Haipeng=20 -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Wednesday, April 20, 2005 12:22 AM To: Kristofer Sandlund; Jin, Haipeng Cc: rohc@ietf.org Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) Haipeng and Kristofer, I believe Kristofer is correct in that the enabling of timer-based compression as a two-step process involving initiatives from both decompressor and compressor also serves the purpose of making timer- based compression an optional mechanism. We have always considered timer-based as an optional mechanism, requiring CLOCK-OPTION + enabling from the compressor before it can be used. That was the purpose when writing it and that is what has always been the assumption, even if 3095 (as often) is not very clear on this. We see this being reflected in the example implementation structure described in 6.5.1, where clock resolution is initially set to 0. To summarize, I believe the requirement to have received a CLOCK feedback option before timer-based compression can be turned on, is correct. I made a minor re-write of the text, making it more compact. The result became as follows: ---------------------------------------------------------------- 4.8. Using timer-based compression =20 Timer-based compression of the RTP timestamp, as described in section 4.5.4, may be used to reduce the number of transmitted timestamp bits (bytes) needed when the timestamp can not be inferred from the SN. It should thus be noted that timer-based compression has no influence on decompression of packets where no timestamp bits are sent, in that case the timestamp is just linearly inferred from the SN (see section 4.2 of this document). Whether to use timer-based compression or not is controlled by the TIME_STRIDE control field, which can be set either by an IR, an IR- DYN, or by a compressed packet with extension 3. The compressor turns on timer-based compression by setting TIME_STRIDE to a value > 0, but that can be done first after the decompressor has declared its clock resolution, which is done by sending a CLOCK feedback option for any CID on the channel.=20 ----------------------------------------------------------------- Rgds, /L-E > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 20 april 2005 08:43 > To: Jin, Haipeng > Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org; hjin@qualcomm.com > Subject: Re: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) >=20 >=20 > Hi Haipeng, >=20 > comments inline. >=20 > Jin, Haipeng wrote: > > Hi, Lars-Erik and Kristofer, > >=20 > > The proposed text does not allow setting TIME_STRIDE to > non-zero value > > before receiving CLOCK feedback in the case where the compressor has > > advanced knowledge of the decompressor's clock resolution. > Can we append > > the following sentence after the text proposed by Kristofer? > >=20 > > ----START-------- > > However, if the compressor has learned the clock resolution of the=20 > > decompressor from external means (e.g., when both compressor and=20 > > decompressor are synchronized to the same timing source), then=20 > > TIME_STRIDE can be set to non-zero value even when no CLOCK > feedback is > > received.=20 > > -----END--------- >=20 > This change would be in violation of 3095 (section 6.5.1, which=20 > specifies that the initial value of the clock resolution is set to 0). > It is a big advantage to have the timer-based compression specified=20 > this way, since BOTH compressor and decompressor must make an explicit > action to start using timer-based compression, and your proposed text=20 > would make it mandatory for the decompressor to support timer-based=20 > compression. >=20 > The point of the implementer's guide is to clarify things without=20 > changing intended behavior, so I'm going to have to oppose the text=20 > suggested above. >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > >=20 > > Thanks, > > Haipeng _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 25 02:41:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17476 for ; Mon, 25 Apr 2005 02:41:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPxU9-0007g9-5Z for rohc-archive@ietf.org; Mon, 25 Apr 2005 02:54:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPxFM-0004cW-UQ; Mon, 25 Apr 2005 02:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPxFJ-0004c9-Ep for rohc@megatron.ietf.org; Mon, 25 Apr 2005 02:39:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17113 for ; Mon, 25 Apr 2005 02:39:03 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPxRU-0007b9-MO for rohc@ietf.org; Mon, 25 Apr 2005 02:51:41 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3P5cEmg003854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 25 Apr 2005 07:38:15 +0200 Message-ID: <426C907B.7060106@effnet.com> Date: Mon, 25 Apr 2005 08:38:51 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jin, Haipeng" Subject: Re: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Hi Haipeng, comments inline. Jin, Haipeng wrote: > Lars-Erik and Kristofer, > > Sorry for the late reply, but here are my comments: > > Sending non-zero CLOCK feedback option to turn on timer-based > compression seems fine. > > But I just want to clarify that timer-based compression is always > required to be implemented in ROHC stack. It is an optional mechanism > only in the sense that if the decompressor does not have timing > information from a clock, then it can not be used. When the > CLOCK_RESOLUTION on the decompressor side is non-zero, then timer-based > compression can always be used if the compressor indicates so. I don't agree. Timer-based compression is meant to be optional in the ROHC stack, which to me is an important "feature" to keep. The point is that to use timer-based compression, _first_ the decompressor must make an explicit action (sending CLOCK) and then the compressor must _also_ make an explicit action (sending TIS). And things should only happen in that order, not the reverse. Allowing the behavior you suggest could also cause some big interoperability problems, if the compressor could for example tries to send TIS on a unidirectional link. > > In addition, if CLOCK feedback is needed to turn on timer-based > compression, then we need to clarify in the implementer's guide that if > the decompressor hasn't sent CLCOK feedback to the compressor, upon > receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the > decompressor needs to send CLOCK feedback value to indicate the > CLOCK_RESOLUTION. The compressor is not allowed to send TIME_STRIDE until it has received the CLOCK feedback, so this situation seems moot. Do we need to clarify what the decompressor should do if this happens anyway? I don't think so, it should be detected by the decompressor that the compressor is bad and should take the same actions it normally does on failure. BR, Kristofer Sandlund, Effnet AB > > Thanks, > Haipeng > > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Wednesday, April 20, 2005 12:22 AM > To: Kristofer Sandlund; Jin, Haipeng > Cc: rohc@ietf.org > Subject: RE: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) > > Haipeng and Kristofer, > > I believe Kristofer is correct in that the enabling of timer-based > compression as a two-step process involving initiatives from both > decompressor and compressor also serves the purpose of making timer- > based compression an optional mechanism. We have always considered > timer-based as an optional mechanism, requiring CLOCK-OPTION + enabling > from the compressor before it can be used. That was the purpose when > writing it and that is what has always been the assumption, even if 3095 > (as often) is not very clear on this. We see this being reflected in the > example implementation structure described in 6.5.1, where clock > resolution is initially set to 0. > > To summarize, I believe the requirement to have received a CLOCK > feedback option before timer-based compression can be turned on, is > correct. > > I made a minor re-write of the text, making it more compact. The result > became as follows: > > ---------------------------------------------------------------- > 4.8. Using timer-based compression > > Timer-based compression of the RTP timestamp, as described in section > 4.5.4, may be used to reduce the number of transmitted timestamp bits > (bytes) needed when the timestamp can not be inferred from the SN. It > should thus be noted that timer-based compression has no influence on > decompression of packets where no timestamp bits are sent, in that > case the timestamp is just linearly inferred from the SN (see section > 4.2 of this document). > > Whether to use timer-based compression or not is controlled by the > TIME_STRIDE control field, which can be set either by an IR, an IR- > DYN, or by a compressed packet with extension 3. The compressor turns > on timer-based compression by setting TIME_STRIDE to a value > 0, but > that can be done first after the decompressor has declared its clock > resolution, which is done by sending a CLOCK feedback option for any > CID on the channel. > ----------------------------------------------------------------- > > Rgds, > /L-E > > > > >>-----Original Message----- >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>Sent: den 20 april 2005 08:43 >>To: Jin, Haipeng >>Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org; hjin@qualcomm.com >>Subject: Re: Clarification on timer-based compression (was: Re: [rohc] > > >>New Draft for Support of Reordering and Constant IP-ID) >> >> >>Hi Haipeng, >> >>comments inline. >> >>Jin, Haipeng wrote: >> >>>Hi, Lars-Erik and Kristofer, >>> >>>The proposed text does not allow setting TIME_STRIDE to >> >>non-zero value >> >>>before receiving CLOCK feedback in the case where the compressor has > > >>>advanced knowledge of the decompressor's clock resolution. >> >>Can we append >> >>>the following sentence after the text proposed by Kristofer? >>> >>>----START-------- >>>However, if the compressor has learned the clock resolution of the >>>decompressor from external means (e.g., when both compressor and >>>decompressor are synchronized to the same timing source), then >>>TIME_STRIDE can be set to non-zero value even when no CLOCK >> >>feedback is >> >>>received. >>>-----END--------- >> >>This change would be in violation of 3095 (section 6.5.1, which >>specifies that the initial value of the clock resolution is set to 0). >>It is a big advantage to have the timer-based compression specified >>this way, since BOTH compressor and decompressor must make an explicit > > >>action to start using timer-based compression, and your proposed text >>would make it mandatory for the decompressor to support timer-based >>compression. >> >>The point of the implementer's guide is to clarify things without >>changing intended behavior, so I'm going to have to oppose the text >>suggested above. >> >>BR, >> Kristofer Sandlund, Effnet AB >> >> >>>Thanks, >>>Haipeng _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 25 04:22:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23892 for ; Mon, 25 Apr 2005 04:22:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPz3d-000415-F8 for rohc-archive@ietf.org; Mon, 25 Apr 2005 04:35:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPypA-00041X-3W; Mon, 25 Apr 2005 04:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyp7-000410-Qk for rohc@megatron.ietf.org; Mon, 25 Apr 2005 04:20:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23578 for ; Mon, 25 Apr 2005 04:20:07 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPz1K-0003s4-Hg for rohc@ietf.org; Mon, 25 Apr 2005 04:32:47 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3P8IXja021551; Mon, 25 Apr 2005 10:20:07 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 10:20:05 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 10:20:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Apr 2005 10:20:04 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2817@esealmw109.eemea.ericsson.se> Thread-Topic: Clarification on timer-based compression (was: Re: [rohc] NewDraft for Support of Reordering and Constant IP-ID) Thread-Index: AcVFdEBnJttv5RtwSimD64WMVLbrMAAAJ57wAH0MO2AAgTpfkA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Jin, Haipeng" , "Kristofer Sandlund" X-OriginalArrivalTime: 25 Apr 2005 08:20:05.0182 (UTC) FILETIME=[95B56DE0:01C5496F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org Subject: [rohc] RE: Clarification on timer-based compression X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Haipeng, Timer-based compression has always been seen as an optional mechanism, i.e. optional both from a compressor and a=20 decompressor point of view. There are several reasons for this, as there can be many reasons for not being able to use it, or not wanting to use it. However, from a protocol standards point of view, it does not matter why it is used or not, the only important thing is to make sure that it will interoperate if it is used, and that the endpoints can unambiguously agree on whether to use it or not.=20 If a protocol mechanism is fully optional, it can be excluded from an implementation, and that is a feature. It is not our job as standards writers to enforce what to implement in terms of optimizations (like timer-based compression), if it is not actually needed. BR /L-E > Lars-Erik and Kristofer, >=20 > Sorry for the late reply, but here are my comments: >=20 > Sending non-zero CLOCK feedback option to turn on timer-based > compression seems fine.=20 >=20 > But I just want to clarify that timer-based compression is always > required to be implemented in ROHC stack. It is an optional mechanism > only in the sense that if the decompressor does not have timing > information from a clock, then it can not be used. When the > CLOCK_RESOLUTION on the decompressor side is non-zero, then=20 > timer-based > compression can always be used if the compressor indicates so. >=20 > In addition, if CLOCK feedback is needed to turn on timer-based > compression, then we need to clarify in the implementer's=20 > guide that if > the decompressor hasn't sent CLCOK feedback to the compressor, upon > receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the > decompressor needs to send CLOCK feedback value to indicate the > CLOCK_RESOLUTION.=20 >=20 > Thanks, > Haipeng=20 >=20 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com] >=20 > Sent: Wednesday, April 20, 2005 12:22 AM > To: Kristofer Sandlund; Jin, Haipeng > Cc: rohc@ietf.org > Subject: RE: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) >=20 > Haipeng and Kristofer, >=20 > I believe Kristofer is correct in that the enabling of timer-based > compression as a two-step process involving initiatives from both > decompressor and compressor also serves the purpose of making timer- > based compression an optional mechanism. We have always considered > timer-based as an optional mechanism, requiring CLOCK-OPTION=20 > + enabling > from the compressor before it can be used. That was the purpose when > writing it and that is what has always been the assumption,=20 > even if 3095 > (as often) is not very clear on this. We see this being=20 > reflected in the > example implementation structure described in 6.5.1, where clock > resolution is initially set to 0. >=20 > To summarize, I believe the requirement to have received a CLOCK > feedback option before timer-based compression can be turned on, is > correct. >=20 > I made a minor re-write of the text, making it more compact.=20 > The result > became as follows: >=20 > ---------------------------------------------------------------- > 4.8. Using timer-based compression > =20 > Timer-based compression of the RTP timestamp, as described=20 > in section > 4.5.4, may be used to reduce the number of transmitted=20 > timestamp bits > (bytes) needed when the timestamp can not be inferred from=20 > the SN. It > should thus be noted that timer-based compression has no=20 > influence on > decompression of packets where no timestamp bits are sent, in that > case the timestamp is just linearly inferred from the SN=20 > (see section > 4.2 of this document). >=20 > Whether to use timer-based compression or not is controlled by the > TIME_STRIDE control field, which can be set either by an IR, an IR- > DYN, or by a compressed packet with extension 3. The=20 > compressor turns > on timer-based compression by setting TIME_STRIDE to a=20 > value > 0, but > that can be done first after the decompressor has declared its clock > resolution, which is done by sending a CLOCK feedback option for any > CID on the channel.=20 > ----------------------------------------------------------------- >=20 > Rgds, > /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 25 07:24:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06745 for ; Mon, 25 Apr 2005 07:24:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ1tK-00044L-T9 for rohc-archive@ietf.org; Mon, 25 Apr 2005 07:36:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ1eQ-0008Mf-O8; Mon, 25 Apr 2005 07:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ1eP-0008M0-BE for rohc@megatron.ietf.org; Mon, 25 Apr 2005 07:21:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06544 for ; Mon, 25 Apr 2005 07:21:14 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ1qc-0003wa-R4 for rohc@ietf.org; Mon, 25 Apr 2005 07:33:56 -0400 Received: from tipau (tipau [193.175.133.74]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j3PBLET24214 for ; Mon, 25 Apr 2005 13:21:14 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau (8.12.7/8.8.8) with ESMTP id j3PBL9bb030247 for ; Mon, 25 Apr 2005 13:21:09 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j3PBL807030246 for rohc@ietf.org; Mon, 25 Apr 2005 13:21:08 +0200 From: Cristian CONSTANTIN Date: Mon, 25 Apr 2005 13:21:08 +0200 To: rohc@ietf.org Message-ID: <20050425112108.GI1276@terix.fokus.gmd.de> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [rohc] SigComp - is the bytecode representation unique? X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1210190928==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --===============1210190928== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HuXIgs6JvY9hJs5C" Content-Disposition: inline --HuXIgs6JvY9hJs5C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi! suppose you're using the assembly language for UDVM defined in draft-ietf-rohc-sigcomp-user-guide-01.txt and write a udvm program; then you translate it into bytecode. is the result of this translation unique or are there _several possible_ (correct) representations in bytecod= e=20 for _the same_ assembly program? if I refer to "Figure 10: Bytecode for a multitype (%) operand" in the SigComp RFC then, the value %0, for example, can be represented like: 0x00 on one byte, when using the first rule=20 0xA000 on two bytes, when using the seventh rule 0x800000 on three bytes, when using the eighth rule=20 are all these representations correct?=20 thanks in advance for your answer. bye now! cristian --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --HuXIgs6JvY9hJs5C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCbNKkypNgyZIZ1MERAs67AKDEPxvY+1btMXcM7YYIoPsTVqyDYACgmOIY UMPCs88s0COs5qOVvddtUP0= =N/Pf -----END PGP SIGNATURE----- --HuXIgs6JvY9hJs5C-- --===============1210190928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1210190928==-- From rohc-bounces@ietf.org Mon Apr 25 08:14:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10093 for ; Mon, 25 Apr 2005 08:14:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ2gH-0006Tv-C8 for rohc-archive@ietf.org; Mon, 25 Apr 2005 08:27:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2Rl-0003Rv-Hc; Mon, 25 Apr 2005 08:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2Rk-0003Rq-CH for rohc@megatron.ietf.org; Mon, 25 Apr 2005 08:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09918 for ; Mon, 25 Apr 2005 08:12:09 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ2dt-0006R7-CD for rohc@ietf.org; Mon, 25 Apr 2005 08:24:50 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3PCBxU1012175; Mon, 25 Apr 2005 14:12:01 +0200 (MEST) In-Reply-To: <20050425112108.GI1276@terix.fokus.gmd.de> References: <20050425112108.GI1276@terix.fokus.gmd.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] SigComp - is the bytecode representation unique? Date: Mon, 25 Apr 2005 14:11:57 +0200 To: Cristian CONSTANTIN X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On Apr 25 2005, at 13:21 Uhr, Cristian CONSTANTIN wrote: > _several possible_ (correct) representations in bytecode > for _the same_ assembly program Yes. It is up to the assembler to determine the best variant for coding each operand. Note that there may be interesting dependencies (e.g., a forward reference may cause you to generate long code which in turn causes a later back reference to require a larger operand than really necessary). For efficiency, you *need* a multipass assembler. (On a higher level of consideration, the entire assembly language thing is informative and not part of the normative standard. What we standardized was the UDVM semantics and the state management around that. We did an assembly language just to make it simpler to talk about UDVM code.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 25 09:19:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14449 for ; Mon, 25 Apr 2005 09:19:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ3hT-0000WF-N3 for rohc-archive@ietf.org; Mon, 25 Apr 2005 09:32:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ3U1-0008KK-To; Mon, 25 Apr 2005 09:18:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ3Tl-0008Jt-G1 for rohc@megatron.ietf.org; Mon, 25 Apr 2005 09:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14175 for ; Mon, 25 Apr 2005 09:18:23 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ3fz-0000TD-7N for rohc@ietf.org; Mon, 25 Apr 2005 09:31:05 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3PDIHOC007697; Mon, 25 Apr 2005 15:18:21 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 15:18:17 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 15:18:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Mon, 25 Apr 2005 15:18:16 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C281F@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 Thread-Index: AcVGTo73pKL0jIYmQ9ClZ/gTovZ4AQDSR9bQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kristofer Sandlund" , X-OriginalArrivalTime: 25 Apr 2005 13:18:17.0016 (UTC) FILETIME=[3E12A380:01C54999] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Kristofer, Sorry for not responding quicker, but here are now some comments! > TEXT ADDITIONS/CHANGES FOR LIST COMPRESSION > ---- > - 7.2.4 should not have any references to ROHC-FN. Agree! > - New section between 7.2.3 and 7.2.4 describing the format=20 > of type 0 lists header in box notation. Must also describe > how to put together the xi list and the item list. >=20 > I can volunteer to write this stuff... Yes, this is needed, I guess we would all appreciate text input. =20 > - "5.1.4.2. Optional Acknowledgements (ACKs), Upward=20 > Transition", why have the word "optional" in the section=20 > title, the fact that they are optional is probably enough to > have in the section text itself. Agree! > - "5.1.4.4. Negative ACKs (NACKs), Downward Transition" - is=20 > the text and title correct? A NACK does not necessarily take > the compressor to IR-state, a STATIC-NACK does. A regular > NACK will just require an IR-DYN to be sent. Need to=20 > polish this text to cover both types of nacks. Agree, maybe the description based on "states" is not really what we want to have. We have discussed this before, and the whole concept of states and state machines has imho caused more confusion than it has helped. > - Should we really mention k_1/n_1 and k_2/n_2 for the=20 > downward transitions. We know that putting names to these > things caused quite awkward discussions in certain other > standards bodies (no names), so why not just talk about=20 > "confidence that context is invalid" or something like that.=20 > The k_1 stuff is too much of an implementation choice to be > mentioned. Yes, I fully agree with you. > - I know this was discussed on the list a couple of years=20 > ago, but why do we need "5.1.5. State Machine Supporting > Context Replication"? This state machine is already > described in the CR draft itself.... Maybe I should extend > this question to "why do we even need any state machines, > they just describe a specific way of implementing things > and not actually much normative logic", but maybe some > people want states to be able to relate to 3095 (where > they are equally pointless)? Oooops, as I just said above, I have the same feeling about the descriptive concept with states. We should learn from=20 our mistakes with 3095 and get rid of this. > - Next time the tcp-pf.txt is copied into the draft, DO NOT=20 > remove the box notation (for all the people I have made > read the document, I've had to give them the tcp-pf document > so that they could get easy reference to how things work), > and DO NOT remove the initial part of the file with=20 > the references to profile-specific encodings. Agree, we should have the formats also in box notation, so that also ordinary humans can read this specification and get something out of it. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 25 18:02:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03592 for ; Mon, 25 Apr 2005 18:02:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQBrE-0004xB-CK for rohc-archive@ietf.org; Mon, 25 Apr 2005 18:15:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQBel-0006KJ-3m; Mon, 25 Apr 2005 18:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQBej-0006KE-Ny for rohc@megatron.ietf.org; Mon, 25 Apr 2005 18:02:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03550 for ; Mon, 25 Apr 2005 18:02:14 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQBr1-0004vs-EV for rohc@ietf.org; Mon, 25 Apr 2005 18:15:01 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3PM1tHa020485; Mon, 25 Apr 2005 15:01:55 -0700 (PDT) Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3PM16fh000820; Mon, 25 Apr 2005 15:01:49 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 15:01:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Apr 2005 15:01:12 -0700 Message-ID: Thread-Topic: Clarification on timer-based compression Thread-Index: AcVFdEBnJttv5RtwSimD64WMVLbrMAAAJ57wAH0MO2AAgTpfkAAamjLg From: "Jin, Haipeng" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 25 Apr 2005 22:01:14.0057 (UTC) FILETIME=[4C3F2390:01C549E2] X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org Subject: [rohc] RE: Clarification on timer-based compression X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Hi, Lars-Erik and Kristofer, If, as your interpretation, the decompressor is required to send CLOCK feedback first before the compressor can send non-zero TIME-STRIDE, then you can make timer-based compression optional.=20 But this is not at all clear in RFC3095. For example, with my way of interpretation, we can say that it is not optional but it is only turned on if decompressor responds with non-zero CLOCK to the non-zero TIME-STRIDE sent by the compressor. If the clock resolution is not high enough or the compressor/decompressor doesnot want to use it (for whatever reason), the compressor can simply choose not to send TIME-STRIDE or the decompressor can choose to send zero CLOCK feedback or not send feedback at all (on Unidirection link). I don't think there will be inter-op problem as long as we have one consistent way of interpretating the RFC text (as Lars-Erik pointed out).=20 With that said, I don't want to get into argument before fully understand the problem. Could you please explain the specific reasons for making timer-based compression optional for implementation?=20 Thanks, Haipeng -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Monday, April 25, 2005 1:20 AM To: Jin, Haipeng; Kristofer Sandlund Cc: rohc@ietf.org Subject: RE: Clarification on timer-based compression Haipeng, Timer-based compression has always been seen as an optional mechanism, i.e. optional both from a compressor and a decompressor point of view. There are several reasons for this, as there can be many reasons for not being able to use it, or not wanting to use it. However, from a protocol standards point of view, it does not matter why it is used or not, the only important thing is to make sure that it will interoperate if it is used, and that the endpoints can unambiguously agree on whether to use it or not.=20 If a protocol mechanism is fully optional, it can be excluded from an implementation, and that is a feature. It is not our job as standards writers to enforce what to implement in terms of optimizations (like timer-based compression), if it is not actually needed. BR /L-E > Lars-Erik and Kristofer, >=20 > Sorry for the late reply, but here are my comments: >=20 > Sending non-zero CLOCK feedback option to turn on timer-based=20 > compression seems fine. >=20 > But I just want to clarify that timer-based compression is always=20 > required to be implemented in ROHC stack. It is an optional mechanism=20 > only in the sense that if the decompressor does not have timing=20 > information from a clock, then it can not be used. When the=20 > CLOCK_RESOLUTION on the decompressor side is non-zero, then=20 > timer-based compression can always be used if the compressor indicates > so. >=20 > In addition, if CLOCK feedback is needed to turn on timer-based=20 > compression, then we need to clarify in the implementer's guide that=20 > if the decompressor hasn't sent CLCOK feedback to the compressor, upon > receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the=20 > decompressor needs to send CLOCK feedback value to indicate the=20 > CLOCK_RESOLUTION. >=20 > Thanks, > Haipeng >=20 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] >=20 > Sent: Wednesday, April 20, 2005 12:22 AM > To: Kristofer Sandlund; Jin, Haipeng > Cc: rohc@ietf.org > Subject: RE: Clarification on timer-based compression (was: Re: [rohc] > New Draft for Support of Reordering and Constant IP-ID) >=20 > Haipeng and Kristofer, >=20 > I believe Kristofer is correct in that the enabling of timer-based=20 > compression as a two-step process involving initiatives from both=20 > decompressor and compressor also serves the purpose of making timer-=20 > based compression an optional mechanism. We have always considered=20 > timer-based as an optional mechanism, requiring CLOCK-OPTION > + enabling > from the compressor before it can be used. That was the purpose when=20 > writing it and that is what has always been the assumption, even if=20 > 3095 (as often) is not very clear on this. We see this being reflected > in the example implementation structure described in 6.5.1, where=20 > clock resolution is initially set to 0. >=20 > To summarize, I believe the requirement to have received a CLOCK=20 > feedback option before timer-based compression can be turned on, is=20 > correct. >=20 > I made a minor re-write of the text, making it more compact.=20 > The result > became as follows: >=20 > ---------------------------------------------------------------- > 4.8. Using timer-based compression > =20 > Timer-based compression of the RTP timestamp, as described in=20 > section > 4.5.4, may be used to reduce the number of transmitted timestamp=20 > bits > (bytes) needed when the timestamp can not be inferred from the SN.=20 > It > should thus be noted that timer-based compression has no influence=20 > on > decompression of packets where no timestamp bits are sent, in that > case the timestamp is just linearly inferred from the SN (see=20 > section > 4.2 of this document). >=20 > Whether to use timer-based compression or not is controlled by the > TIME_STRIDE control field, which can be set either by an IR, an IR- > DYN, or by a compressed packet with extension 3. The compressor=20 > turns > on timer-based compression by setting TIME_STRIDE to a value > 0,=20 > but > that can be done first after the decompressor has declared its clock > resolution, which is done by sending a CLOCK feedback option for any > CID on the channel.=20 > ----------------------------------------------------------------- >=20 > Rgds, > /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Apr 25 19:50:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12220 for ; Mon, 25 Apr 2005 19:50:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQDXb-0000Bs-Ct for rohc-archive@ietf.org; Mon, 25 Apr 2005 20:03:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQDIz-0003yu-Hu; Mon, 25 Apr 2005 19:47:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQDIy-0003ya-45 for rohc@megatron.ietf.org; Mon, 25 Apr 2005 19:47:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12112 for ; Mon, 25 Apr 2005 19:47:51 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQDVH-000077-P1 for rohc@ietf.org; Mon, 25 Apr 2005 20:00:41 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3PNlaqP030544; Tue, 26 Apr 2005 00:47:36 +0100 Received: from mjw-pc.roke.co.uk (mjw-pc.comm.ad.roke.co.uk [193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JF3JWX0K; Tue, 26 Apr 2005 00:48:06 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: Re: [rohc] RE: Clarification on timer-based compression Date: Tue, 26 Apr 2005 00:47:32 +0100 Message-ID: Thread-Topic: [rohc] RE: Clarification on timer-based compression Thread-Index: AcVJ8TpNMzlaXPYiSH+CJWED8KiMyQ== From: "West, Mark" To: "Jin, Haipeng" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146 Cc: rohc@ietf.org, Kristofer Sandlund , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0894941827==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b This is a multi-part message in MIME format. --===============0894941827== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C549F1.3A0FFF00" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C549F1.3A0FFF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Haipeng, But if the compressor sets TIME_STRIDE then it is scaling the timestamp before it knows (a) the decompressor clock resolution; or (b) whether = the decompressor even supports timer-based timestamp coding. Given that the compressor should not send anything that it is not confident that the decompressor can not decompress, I really don't see = how the compressor can decide to use timer-based encoding *without* some information from the decompressor. (or am I misunderstanding your argument?) So, for example, I agree with Kristofer that, on a uni-directional link, timer-based encoding (without out-of-band 'negotiation' of willingness = and parameters such as clock resolution) is a really, really bad idea. Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Mon, 25 Apr 2005, Jin, Haipeng wrote: > Date: Mon, 25 Apr 2005 15:01:12 -0700 > From: "Jin, Haipeng" > To: "Lars-Erik Jonsson (LU/EAB)" , > Kristofer Sandlund > Cc: rohc@ietf.org > Subject: [rohc] RE: Clarification on timer-based compression > > Hi, Lars-Erik and Kristofer, > > If, as your interpretation, the decompressor is required to send CLOCK > feedback first before the compressor can send non-zero TIME-STRIDE, = then > you can make timer-based compression optional. > > But this is not at all clear in RFC3095. For example, with my way of > interpretation, we can say that it is not optional but it is only = turned > on if decompressor responds with non-zero CLOCK to the non-zero > TIME-STRIDE sent by the compressor. If the clock resolution is not = high > enough or the compressor/decompressor doesnot want to use it (for > whatever reason), the compressor can simply choose not to send > TIME-STRIDE or the decompressor can choose to send zero CLOCK feedback > or not send feedback at all (on Unidirection link). I don't think = there > will be inter-op problem as long as we have one consistent way of > interpretating the RFC text (as Lars-Erik pointed out). > > With that said, I don't want to get into argument before fully > understand the problem. Could you please explain the specific reasons > for making timer-based compression optional for implementation? > > Thanks, > Haipeng > > > > > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) = [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Monday, April 25, 2005 1:20 AM > To: Jin, Haipeng; Kristofer Sandlund > Cc: rohc@ietf.org > Subject: RE: Clarification on timer-based compression > > Haipeng, > > Timer-based compression has always been seen as an optional mechanism, > i.e. optional both from a compressor and a decompressor point of view. > There are several reasons for this, as there can be many reasons for = not > being able to use it, or not wanting to use it. However, from a = protocol > standards point of view, it does not matter why it is used or not, the > only important thing is to make sure that it will interoperate if it = is > used, and that the endpoints can unambiguously agree on whether to use > it or not. > > If a protocol mechanism is fully optional, it can be excluded from an > implementation, and that is a feature. > It is not our job as standards writers to enforce what to implement in > terms of optimizations (like timer-based compression), if it is not > actually needed. > > BR > /L-E > > > > > Lars-Erik and Kristofer, > > > > Sorry for the late reply, but here are my comments: > > > > Sending non-zero CLOCK feedback option to turn on timer-based > > compression seems fine. > > > > But I just want to clarify that timer-based compression is always > > required to be implemented in ROHC stack. It is an optional = mechanism > > only in the sense that if the decompressor does not have timing > > information from a clock, then it can not be used. When the > > CLOCK_RESOLUTION on the decompressor side is non-zero, then > > timer-based compression can always be used if the compressor = indicates > > > so. > > > > In addition, if CLOCK feedback is needed to turn on timer-based > > compression, then we need to clarify in the implementer's guide that > > if the decompressor hasn't sent CLCOK feedback to the compressor, = upon > > > receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the > > decompressor needs to send CLOCK feedback value to indicate the > > CLOCK_RESOLUTION. > > > > Thanks, > > Haipeng > > > > -----Original Message----- > > From: Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > > > > Sent: Wednesday, April 20, 2005 12:22 AM > > To: Kristofer Sandlund; Jin, Haipeng > > Cc: rohc@ietf.org > > Subject: RE: Clarification on timer-based compression (was: Re: = [rohc] > > > New Draft for Support of Reordering and Constant IP-ID) > > > > Haipeng and Kristofer, > > > > I believe Kristofer is correct in that the enabling of timer-based > > compression as a two-step process involving initiatives from both > > decompressor and compressor also serves the purpose of making timer- > > based compression an optional mechanism. We have always considered > > timer-based as an optional mechanism, requiring CLOCK-OPTION > > + enabling > > from the compressor before it can be used. That was the purpose when > > writing it and that is what has always been the assumption, even if > > 3095 (as often) is not very clear on this. We see this being = reflected > > > in the example implementation structure described in 6.5.1, where > > clock resolution is initially set to 0. > > > > To summarize, I believe the requirement to have received a CLOCK > > feedback option before timer-based compression can be turned on, is > > correct. > > > > I made a minor re-write of the text, making it more compact. > > The result > > became as follows: > > > > ---------------------------------------------------------------- > > 4.8. Using timer-based compression > > > > Timer-based compression of the RTP timestamp, as described in > > section > > 4.5.4, may be used to reduce the number of transmitted timestamp > > bits > > (bytes) needed when the timestamp can not be inferred from the SN. > > It > > should thus be noted that timer-based compression has no influence > > on > > decompression of packets where no timestamp bits are sent, in that > > case the timestamp is just linearly inferred from the SN (see > > section > > 4.2 of this document). > > > > Whether to use timer-based compression or not is controlled by the > > TIME_STRIDE control field, which can be set either by an IR, an = IR- > > DYN, or by a compressed packet with extension 3. The compressor > > turns > > on timer-based compression by setting TIME_STRIDE to a value > 0, > > but > > that can be done first after the decompressor has declared its = clock > > resolution, which is done by sending a CLOCK feedback option for = any > > CID on the channel. > > ----------------------------------------------------------------- > > > > Rgds, > > /L-E > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > ------_=_NextPart_001_01C549F1.3A0FFF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rohc] RE: Clarification on timer-based compression

Hi, Haipeng,

But if the compressor sets TIME_STRIDE then it is = scaling the timestamp
before it knows (a) the decompressor clock = resolution; or (b) whether the
decompressor even supports timer-based timestamp = coding.

Given that the compressor should not send anything = that it is not
confident that the decompressor can not decompress, I = really don't see how
the compressor can decide to use timer-based encoding = *without* some
information from the decompressor.

(or am I misunderstanding your argument?)

So, for example, I agree with Kristofer that, on a = uni-directional link,
timer-based encoding (without out-of-band = 'negotiation' of willingness and
parameters such as clock resolution) is a really, = really bad idea.

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 = 0ZN
Phone +44 (0)1794 833311   Fax  +44 = (0)1794 833433



On Mon, 25 Apr 2005, Jin, Haipeng wrote:

> Date: Mon, 25 Apr 2005 15:01:12 -0700
> From: "Jin, Haipeng" = <haipengj@qualcomm.com>
> To: "Lars-Erik Jonsson (LU/EAB)" = <lars-erik.jonsson@ericsson.com>,
>      Kristofer Sandlund = <kristofer.sandlund@effnet.com>
> Cc: rohc@ietf.org
> Subject: [rohc] RE: Clarification on timer-based = compression
>
> Hi, Lars-Erik and Kristofer,
>
> If, as your interpretation, the decompressor is = required to send CLOCK
> feedback first before the compressor can send = non-zero TIME-STRIDE, then
> you can make timer-based compression = optional.
>
> But this is not at all clear in RFC3095. For = example, with my way of
> interpretation, we can say that it is not = optional but it is only turned
> on if decompressor responds with non-zero CLOCK = to the non-zero
> TIME-STRIDE sent by the compressor. If the clock = resolution is not high
> enough or the compressor/decompressor doesnot = want to use it (for
> whatever reason), the compressor can simply = choose not to send
> TIME-STRIDE or the decompressor can choose to = send zero CLOCK feedback
> or not send feedback at all (on Unidirection = link). I don't think there
> will be inter-op problem as long as we have one = consistent way of
> interpretating the RFC text (as Lars-Erik = pointed out).
>
> With that said, I don't want to get into = argument before fully
> understand the problem. Could you please explain = the specific reasons
> for making timer-based compression optional for = implementation?
>
> Thanks,
> Haipeng
>
>
>
>
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@e= ricsson.com]
>
> Sent: Monday, April 25, 2005 1:20 AM
> To: Jin, Haipeng; Kristofer Sandlund
> Cc: rohc@ietf.org
> Subject: RE: Clarification on timer-based = compression
>
> Haipeng,
>
> Timer-based compression has always been seen as = an optional mechanism,
> i.e. optional both from a compressor and a = decompressor point of view.
> There are several reasons for this, as there can = be many reasons for not
> being able to use it, or not wanting to use it. = However, from a protocol
> standards point of view, it does not matter why = it is used or not, the
> only important thing is to make sure that it = will interoperate if it is
> used, and that the endpoints can unambiguously = agree on whether to use
> it or not.
>
> If a protocol mechanism is fully optional, it = can be excluded from an
> implementation, and that is a feature.
> It is not our job as standards writers to = enforce what to implement in
> terms of optimizations (like timer-based = compression), if it is not
> actually needed.
>
> BR
> /L-E
>
>
>
> >  Lars-Erik and Kristofer,
> >
> > Sorry for the late reply, but here are my = comments:
> >
> > Sending non-zero CLOCK feedback option to = turn on timer-based
> > compression seems fine.
> >
> > But I just want to clarify that timer-based = compression is always
> > required to be implemented in ROHC stack. = It is an optional mechanism
> > only in the sense that if the decompressor = does not have timing
> > information from a clock, then it can not = be used. When the
> > CLOCK_RESOLUTION on the decompressor side = is non-zero, then
> > timer-based compression can always be used = if the compressor indicates
>
> > so.
> >
> > In addition, if CLOCK feedback is needed to = turn on timer-based
> > compression, then we need to clarify in the = implementer's guide that
> > if the decompressor hasn't sent CLCOK = feedback to the compressor, upon
>
> > receiving non-zero TIME_STRIDE from the = compressor (e.g, in IR), the
> > decompressor needs to send CLOCK feedback = value to indicate the
> > CLOCK_RESOLUTION.
> >
> > Thanks,
> > Haipeng
> >
> > -----Original Message-----
> > From: Lars-Erik Jonsson (LU/EAB)
> > [mailto:lars-erik.jonsson@e= ricsson.com]
> >
> > Sent: Wednesday, April 20, 2005 12:22 = AM
> > To: Kristofer Sandlund; Jin, Haipeng
> > Cc: rohc@ietf.org
> > Subject: RE: Clarification on timer-based = compression (was: Re: [rohc]
>
> > New Draft for Support of Reordering and = Constant IP-ID)
> >
> > Haipeng and Kristofer,
> >
> > I believe Kristofer is correct in that the = enabling of timer-based
> > compression as a two-step process involving = initiatives from both
> > decompressor and compressor also serves the = purpose of making timer-
> > based compression an optional mechanism. We = have always considered
> > timer-based as an optional mechanism, = requiring CLOCK-OPTION
> > + enabling
> > from the compressor before it can be used. = That was the purpose when
> > writing it and that is what has always been = the assumption, even if
> > 3095 (as often) is not very clear on this. = We see this being reflected
>
> > in the example implementation structure = described in 6.5.1, where
> > clock resolution is initially set to = 0.
> >
> > To summarize, I believe the requirement to = have received a CLOCK
> > feedback option before timer-based = compression can be turned on, is
> > correct.
> >
> > I made a minor re-write of the text, making = it more compact.
> > The result
> > became as follows:
> >
> > = ----------------------------------------------------------------
> > 4.8. Using timer-based compression
> >
> >   Timer-based compression of the = RTP timestamp, as described in
> > section
> >   4.5.4, may be used to reduce = the number of transmitted timestamp
> > bits
> >   (bytes) needed when the = timestamp can not be inferred from the SN.
> > It
> >   should thus be noted that = timer-based compression has no influence
> > on
> >   decompression of packets where = no timestamp bits are sent, in that
> >   case the timestamp is just = linearly inferred from the SN (see
> > section
> >   4.2 of this document).
> >
> >   Whether to use timer-based = compression or not is controlled by the
> >   TIME_STRIDE control field, = which can be set either by an IR, an IR-
> >   DYN, or by a compressed packet = with extension 3. The compressor
> > turns
> >   on timer-based compression by = setting TIME_STRIDE to a value > 0,
> > but
> >   that can be done first after = the decompressor has declared its clock
> >   resolution, which is done by = sending a CLOCK feedback option for any
> >   CID on the channel.
> > = -----------------------------------------------------------------
> >
> > Rgds,
> > /L-E
>
> = _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/rohc
>

------_=_NextPart_001_01C549F1.3A0FFF00-- --===============0894941827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0894941827==-- From rohc-bounces@ietf.org Mon Apr 25 20:22:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14792 for ; Mon, 25 Apr 2005 20:22:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQE38-0001Lg-C5 for rohc-archive@ietf.org; Mon, 25 Apr 2005 20:35:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQDpI-0000jE-FF; Mon, 25 Apr 2005 20:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQDpG-0000j6-J9 for rohc@megatron.ietf.org; Mon, 25 Apr 2005 20:21:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14706 for ; Mon, 25 Apr 2005 20:21:16 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQE1X-0001Ju-St for rohc@ietf.org; Mon, 25 Apr 2005 20:34:00 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3Q0Ktdv003568; Mon, 25 Apr 2005 17:20:56 -0700 (PDT) Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3Q0K2fr023067; Mon, 25 Apr 2005 17:20:52 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 17:21:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] RE: Clarification on timer-based compression Date: Mon, 25 Apr 2005 17:20:47 -0700 Message-ID: Thread-Topic: [rohc] RE: Clarification on timer-based compression Thread-Index: AcVJ8TpNMzlaXPYiSH+CJWED8KiMyQAAoooA From: "Jin, Haipeng" To: "West, Mark" X-OriginalArrivalTime: 26 Apr 2005 00:21:03.0577 (UTC) FILETIME=[D4CA4C90:01C549F5] X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.6 (/) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 Cc: rohc@ietf.org, Kristofer Sandlund , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2034690242==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 This is a multi-part message in MIME format. --===============2034690242== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C549F5.C97046E8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C549F5.C97046E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, =20 Please see my comments inline. ________________________________ From: West, Mark [mailto:mark.a.west@roke.co.uk]=20 Sent: Monday, April 25, 2005 4:48 PM To: Jin, Haipeng Cc: Lars-Erik Jonsson (LU/EAB); Kristofer Sandlund; rohc@ietf.org Subject: Re: [rohc] RE: Clarification on timer-based compression Hi, Haipeng,=20 But if the compressor sets TIME_STRIDE then it is scaling the timestamp=20 before it knows (a) the decompressor clock resolution; or (b) whether the=20 decompressor even supports timer-based timestamp coding.=20 Given that the compressor should not send anything that it is not=20 confident that the decompressor can not decompress, I really don't see how=20 the compressor can decide to use timer-based encoding *without* some=20 information from the decompressor.=20 (or am I misunderstanding your argument?) [Haipeng Jin] I understand your point, but you might have missed my point. What I mean is that I can interpret the RFC3095 text as saying that: (a) all compressor/decompressor must support timer-based compression (b) if decompressor tells the compressor that its clock_resolution is 0, then the compressor can not use timer based compression; (c) if the compressor wants to use timer-based compression before it has info about decompressor's clock_resolution, it needs to send non-zero TIME_STRIDE to prompt CLOCK feedback from the decompressor. If the decompressor says CLOCK=3D0 or no feedback at all = (in U mode), then the compressor can not use timer-based compression. So, for example, I agree with Kristofer that, on a uni-directional link, timer-based encoding (without out-of-band 'negotiation' of willingness and=20 parameters such as clock resolution) is a really, really bad idea.=20 [Haipeng Jin] Agree with you. But I am not proposing to do blind timer-based compression on a uni-directional link or even bi-directional links. What I really mean is both compressor and decompressor support timer-based compression but such compression can only be used when the decompressor has a clock and the compressor knows the clock's resolution. Thanks, Haipeng =20 Cheers,=20 Mark.=20 --=20 Mark A. West, Senior Consultant Engineer=20 Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN=20 Phone +44 (0)1794 833311 Fax +44 (0)1794 833433=20 On Mon, 25 Apr 2005, Jin, Haipeng wrote:=20 > Date: Mon, 25 Apr 2005 15:01:12 -0700=20 > From: "Jin, Haipeng" =20 > To: "Lars-Erik Jonsson (LU/EAB)" ,=20 > Kristofer Sandlund =20 > Cc: rohc@ietf.org=20 > Subject: [rohc] RE: Clarification on timer-based compression=20 >=20 > Hi, Lars-Erik and Kristofer,=20 >=20 > If, as your interpretation, the decompressor is required to send CLOCK > feedback first before the compressor can send non-zero TIME-STRIDE, then=20 > you can make timer-based compression optional.=20 >=20 > But this is not at all clear in RFC3095. For example, with my way of=20 > interpretation, we can say that it is not optional but it is only turned=20 > on if decompressor responds with non-zero CLOCK to the non-zero=20 > TIME-STRIDE sent by the compressor. If the clock resolution is not high=20 > enough or the compressor/decompressor doesnot want to use it (for=20 > whatever reason), the compressor can simply choose not to send=20 > TIME-STRIDE or the decompressor can choose to send zero CLOCK feedback > or not send feedback at all (on Unidirection link). I don't think there=20 > will be inter-op problem as long as we have one consistent way of=20 > interpretating the RFC text (as Lars-Erik pointed out).=20 >=20 > With that said, I don't want to get into argument before fully=20 > understand the problem. Could you please explain the specific reasons=20 > for making timer-based compression optional for implementation?=20 >=20 > Thanks,=20 > Haipeng=20 >=20 >=20 >=20 >=20 > -----Original Message-----=20 > From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com]=20 >=20 > Sent: Monday, April 25, 2005 1:20 AM=20 > To: Jin, Haipeng; Kristofer Sandlund=20 > Cc: rohc@ietf.org=20 > Subject: RE: Clarification on timer-based compression=20 >=20 > Haipeng,=20 >=20 > Timer-based compression has always been seen as an optional mechanism, > i.e. optional both from a compressor and a decompressor point of view. > There are several reasons for this, as there can be many reasons for not=20 > being able to use it, or not wanting to use it. However, from a protocol=20 > standards point of view, it does not matter why it is used or not, the > only important thing is to make sure that it will interoperate if it is=20 > used, and that the endpoints can unambiguously agree on whether to use > it or not.=20 >=20 > If a protocol mechanism is fully optional, it can be excluded from an=20 > implementation, and that is a feature.=20 > It is not our job as standards writers to enforce what to implement in > terms of optimizations (like timer-based compression), if it is not=20 > actually needed.=20 >=20 > BR=20 > /L-E=20 >=20 >=20 >=20 > > Lars-Erik and Kristofer,=20 > >=20 > > Sorry for the late reply, but here are my comments:=20 > >=20 > > Sending non-zero CLOCK feedback option to turn on timer-based=20 > > compression seems fine.=20 > >=20 > > But I just want to clarify that timer-based compression is always=20 > > required to be implemented in ROHC stack. It is an optional mechanism=20 > > only in the sense that if the decompressor does not have timing=20 > > information from a clock, then it can not be used. When the=20 > > CLOCK_RESOLUTION on the decompressor side is non-zero, then=20 > > timer-based compression can always be used if the compressor indicates=20 >=20 > > so.=20 > >=20 > > In addition, if CLOCK feedback is needed to turn on timer-based=20 > > compression, then we need to clarify in the implementer's guide that > > if the decompressor hasn't sent CLCOK feedback to the compressor, upon=20 >=20 > > receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the > > decompressor needs to send CLOCK feedback value to indicate the=20 > > CLOCK_RESOLUTION.=20 > >=20 > > Thanks,=20 > > Haipeng=20 > >=20 > > -----Original Message-----=20 > > From: Lars-Erik Jonsson (LU/EAB)=20 > > [mailto:lars-erik.jonsson@ericsson.com]=20 > >=20 > > Sent: Wednesday, April 20, 2005 12:22 AM=20 > > To: Kristofer Sandlund; Jin, Haipeng=20 > > Cc: rohc@ietf.org=20 > > Subject: RE: Clarification on timer-based compression (was: Re: [rohc]=20 >=20 > > New Draft for Support of Reordering and Constant IP-ID)=20 > >=20 > > Haipeng and Kristofer,=20 > >=20 > > I believe Kristofer is correct in that the enabling of timer-based=20 > > compression as a two-step process involving initiatives from both=20 > > decompressor and compressor also serves the purpose of making timer- > > based compression an optional mechanism. We have always considered=20 > > timer-based as an optional mechanism, requiring CLOCK-OPTION=20 > > + enabling=20 > > from the compressor before it can be used. That was the purpose when > > writing it and that is what has always been the assumption, even if=20 > > 3095 (as often) is not very clear on this. We see this being reflected=20 >=20 > > in the example implementation structure described in 6.5.1, where=20 > > clock resolution is initially set to 0.=20 > >=20 > > To summarize, I believe the requirement to have received a CLOCK=20 > > feedback option before timer-based compression can be turned on, is=20 > > correct.=20 > >=20 > > I made a minor re-write of the text, making it more compact.=20 > > The result=20 > > became as follows:=20 > >=20 > > ----------------------------------------------------------------=20 > > 4.8. Using timer-based compression=20 > >=20 > > Timer-based compression of the RTP timestamp, as described in=20 > > section=20 > > 4.5.4, may be used to reduce the number of transmitted timestamp=20 > > bits=20 > > (bytes) needed when the timestamp can not be inferred from the SN. > > It=20 > > should thus be noted that timer-based compression has no influence > > on=20 > > decompression of packets where no timestamp bits are sent, in that > > case the timestamp is just linearly inferred from the SN (see=20 > > section=20 > > 4.2 of this document).=20 > >=20 > > Whether to use timer-based compression or not is controlled by the > > TIME_STRIDE control field, which can be set either by an IR, an IR-=20 > > DYN, or by a compressed packet with extension 3. The compressor=20 > > turns=20 > > on timer-based compression by setting TIME_STRIDE to a value > 0,=20 > > but=20 > > that can be done first after the decompressor has declared its clock=20 > > resolution, which is done by sending a CLOCK feedback option for any=20 > > CID on the channel.=20 > > -----------------------------------------------------------------=20 > >=20 > > Rgds,=20 > > /L-E=20 >=20 > _______________________________________________=20 > Rohc mailing list=20 > Rohc@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/rohc=20 >=20 ------_=_NextPart_001_01C549F5.C97046E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [rohc] RE: Clarification on timer-based = compression
Mark,
 
Please see my comments = inline.

From: West, Mark = [mailto:mark.a.west@roke.co.uk]=20
Sent: Monday, April 25, 2005 4:48 PM
To: Jin,=20 Haipeng
Cc: Lars-Erik Jonsson (LU/EAB); Kristofer Sandlund;=20 rohc@ietf.org
Subject: Re: [rohc] RE: Clarification on = timer-based=20 compression


Hi, Haipeng,

But if the compressor sets TIME_STRIDE then it is = scaling the=20 timestamp
before it knows (a) the decompressor = clock=20 resolution; or (b) whether the
decompressor = even=20 supports timer-based timestamp coding.

Given that the compressor should not send anything = that it is=20 not
confident that the decompressor can not = decompress,=20 I really don't see how
the compressor can = decide to use=20 timer-based encoding *without* some
information from the=20 decompressor.

(or am I misunderstanding your argument?)
[Haipeng = Jin] I=20 understand your point, but you might have missed my point. What I mean = is=20 that I can interpret the RFC3095 text as saying that: (a)=20 all compressor/decompressor must support timer-based=20 compression (b) if decompressor tells the compressor that its=20 clock_resolution is 0, then the compressor can not use timer based=20 compression; (c) if the compressor wants to use timer-based = compression=20 before it has info about decompressor's clock_resolution, it needs to = send=20 non-zero TIME_STRIDE to prompt CLOCK feedback from the = decompressor.=20 If the decompressor says CLOCK=3D0 or no feedback at all (in U mode), = then the=20 compressor can not use timer-based compression.

So, for example, I agree with Kristofer that, on a=20 uni-directional link,
timer-based encoding = (without=20 out-of-band 'negotiation' of willingness and
parameters=20 such as clock resolution) is a really, really bad idea.
[Haipeng=20 Jin] Agree with you. But I am not proposing to do blind = timer-based=20 compression on a uni-directional link or even bi-directional links. = What I=20 really mean is both compressor and decompressor support timer-based = compression=20 but such compression can only be used when the decompressor = has a=20 clock and the compressor knows the clock's=20 resolution.

Thanks,

Haipeng  =

Cheers,

Mark.

--
Mark A. West, Senior = Consultant=20 Engineer
Roke Manor Research Ltd., Romsey, = Hants. =20 SO51 0ZN
Phone +44 (0)1794 833311   = Fax =20 +44 (0)1794 833433



On Mon, 25 Apr 2005, Jin, Haipeng wrote:

> Date: Mon, 25 Apr 2005 15:01:12 -0700 =
> From: "Jin, Haipeng" <haipengj@qualcomm.com> =
> To: "Lars-Erik Jonsson (LU/EAB)"=20 <lars-erik.jonsson@ericsson.com>,
>      Kristofer Sandlund=20 <kristofer.sandlund@effnet.com>
> Cc: = rohc@ietf.org
> Subject: [rohc] RE: = Clarification on=20 timer-based compression
>
> Hi, Lars-Erik and Kristofer,
>=20
> If, as your interpretation, the decompressor is = required=20 to send CLOCK
> feedback first before the = compressor=20 can send non-zero TIME-STRIDE, then
> you = can make=20 timer-based compression optional.
> =
> But this is not at all clear in RFC3095. For example, with = my way=20 of
> interpretation, we can say that it is = not=20 optional but it is only turned
> on if = decompressor=20 responds with non-zero CLOCK to the non-zero
>=20 TIME-STRIDE sent by the compressor. If the clock resolution is not = high=20
> enough or the compressor/decompressor doesnot = want to use=20 it (for
> whatever reason), the compressor = can simply=20 choose not to send
> TIME-STRIDE or the = decompressor=20 can choose to send zero CLOCK feedback
> or = not send=20 feedback at all (on Unidirection link). I don't think there =
> will be inter-op problem as long as we have one consistent = way=20 of
> interpretating the RFC text (as = Lars-Erik=20 pointed out).
>
> With=20 that said, I don't want to get into argument before fully =
> understand the problem. Could you please explain the = specific=20 reasons
> for making timer-based = compression optional=20 for implementation?
>
>=20 Thanks,
> Haipeng
>=20
>
>
>
> -----Original = Message-----=20
> From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@e= ricsson.com]=20
>
> Sent: Monday, = April 25, 2005=20 1:20 AM
> To: Jin, Haipeng; Kristofer = Sandlund=20
> Cc: rohc@ietf.org
> = Subject:=20 RE: Clarification on timer-based compression
>=20
> Haipeng,
> =
> Timer-based compression has always been seen as an = optional=20 mechanism,
> i.e. optional both from a = compressor and=20 a decompressor point of view.
> There are = several=20 reasons for this, as there can be many reasons for not
> being able to use it, or not wanting to use it. However, = from a=20 protocol
> standards point of view, it does = not=20 matter why it is used or not, the
> only = important=20 thing is to make sure that it will interoperate if it is =
> used, and that the endpoints can unambiguously agree on = whether to=20 use
> it or not.
>=20
> If a protocol mechanism is fully optional, it = can be=20 excluded from an
> implementation, and that = is a=20 feature.
> It is not our job as standards = writers to=20 enforce what to implement in
> terms of = optimizations=20 (like timer-based compression), if it is not
>=20 actually needed.
>
>=20 BR
> /L-E
>=20
>
>
>=20 >  Lars-Erik and Kristofer,
> = >=20
> > Sorry for the late reply, but here are my=20 comments:
> >
> >=20 Sending non-zero CLOCK feedback option to turn on timer-based =
> > compression seems fine.
>=20 >
> > But I just want to clarify that = timer-based compression is always
> > = required to=20 be implemented in ROHC stack. It is an optional mechanism =
> > only in the sense that if the decompressor does not = have=20 timing
> > information from a clock, = then it can=20 not be used. When the
> > = CLOCK_RESOLUTION on the=20 decompressor side is non-zero, then
> >=20 timer-based compression can always be used if the compressor = indicates=20
>
> > so. =
> >
> > In addition, if = CLOCK=20 feedback is needed to turn on timer-based
> = >=20 compression, then we need to clarify in the implementer's guide = that=20
> > if the decompressor hasn't sent CLCOK = feedback to the=20 compressor, upon
>
> >=20 receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), = the=20
> > decompressor needs to send CLOCK feedback = value to=20 indicate the
> > = CLOCK_RESOLUTION.=20
> >
> > = Thanks,=20
> > Haipeng
> = >=20
> > -----Original Message-----
> > From: Lars-Erik Jonsson (LU/EAB)
>=20 > [mailto:lars-erik.jonsson@e= ricsson.com]=20
> >
> > Sent: = Wednesday,=20 April 20, 2005 12:22 AM
> > To: = Kristofer=20 Sandlund; Jin, Haipeng
> > Cc:=20 rohc@ietf.org
> > Subject: RE: = Clarification on=20 timer-based compression (was: Re: [rohc]
>=20
> > New Draft for Support of Reordering and = Constant=20 IP-ID)
> >
> >=20 Haipeng and Kristofer,
> > =
> > I believe Kristofer is correct in that the enabling = of=20 timer-based
> > compression as a = two-step process=20 involving initiatives from both
> > = decompressor=20 and compressor also serves the purpose of making timer-
> > based compression an optional mechanism. We have = always=20 considered
> > timer-based as an = optional=20 mechanism, requiring CLOCK-OPTION
> > +=20 enabling
> > from the compressor before = it can be=20 used. That was the purpose when
> > = writing it and=20 that is what has always been the assumption, even if
> > 3095 (as often) is not very clear on this. We see = this being=20 reflected
>
> = > in the=20 example implementation structure described in 6.5.1, where =
> > clock resolution is initially set to 0. =
> >
> > To summarize, I = believe the=20 requirement to have received a CLOCK
> > = feedback=20 option before timer-based compression can be turned on, is =
> > correct.
> > =
> > I made a minor re-write of the text, making it more=20 compact.
> > The result
> > became as follows:
> = >=20
> >=20 ----------------------------------------------------------------=20
> > 4.8. Using timer-based compression =
> >
> >   = Timer-based=20 compression of the RTP timestamp, as described in
>=20 > section
> >   4.5.4, may = be used to=20 reduce the number of transmitted timestamp
> >=20 bits
> >   (bytes) needed when = the=20 timestamp can not be inferred from the SN.
> >=20 It
> >   should thus be noted = that=20 timer-based compression has no influence
> = >=20 on
> >   decompression of = packets where=20 no timestamp bits are sent, in that
>=20 >   case the timestamp is just linearly inferred from the = SN=20 (see
> > section
>=20 >   4.2 of this document).
> = >=20
> >   Whether to use timer-based = compression or=20 not is controlled by the
> >   = TIME_STRIDE control field, which can be set either by an IR, an = IR-=20
> >   DYN, or by a compressed packet = with=20 extension 3. The compressor
> > = turns=20
> >   on timer-based compression by = setting=20 TIME_STRIDE to a value > 0,
> > = but=20
> >   that can be done first after = the=20 decompressor has declared its clock
>=20 >   resolution, which is done by sending a CLOCK feedback = option=20 for any
> >   CID on the = channel.=20
> >=20 ----------------------------------------------------------------- =
> >
> > = Rgds,=20
> > /L-E
> =
> _______________________________________________ =
> Rohc mailing list
> = Rohc@ietf.org=20
> https://www1.ietf.or= g/mailman/listinfo/rohc=20
>

------_=_NextPart_001_01C549F5.C97046E8-- --===============2034690242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============2034690242==-- From rohc-bounces@ietf.org Tue Apr 26 02:48:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06608 for ; Tue, 26 Apr 2005 02:48:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQK4I-0003EP-Bw for rohc-archive@ietf.org; Tue, 26 Apr 2005 03:01:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQJoW-0001xC-FM; Tue, 26 Apr 2005 02:44:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQJoT-0001x7-Vv for rohc@megatron.ietf.org; Tue, 26 Apr 2005 02:44:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06259 for ; Tue, 26 Apr 2005 02:44:52 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQK0r-00039V-MJ for rohc@ietf.org; Tue, 26 Apr 2005 02:57:42 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3Q6hZj0005273; Tue, 26 Apr 2005 08:44:42 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 08:43:30 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 08:43:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] RE: Clarification on timer-based compression Date: Tue, 26 Apr 2005 08:43:29 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2828@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] RE: Clarification on timer-based compression Thread-Index: AcVJ8TpNMzlaXPYiSH+CJWED8KiMyQAAoooAAAzo2DA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Jin, Haipeng" , "West, Mark" X-OriginalArrivalTime: 26 Apr 2005 06:43:30.0531 (UTC) FILETIME=[423D9B30:01C54A2B] X-Spam-Score: 0.6 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: rohc@ietf.org, Kristofer Sandlund X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1884063033==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b This is a multi-part message in MIME format. --===============1884063033== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54A2B.41E1A4E8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C54A2B.41E1A4E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Haipeng, But if the compressor sets TIME_STRIDE then it is scaling the timestamp=20 before it knows (a) the decompressor clock resolution; or (b) whether = the=20 decompressor even supports timer-based timestamp coding.=20 Given that the compressor should not send anything that it is not=20 confident that the decompressor can not decompress, I really don't see = how=20 the compressor can decide to use timer-based encoding *without* some=20 information from the decompressor.=20 (or am I misunderstanding your argument?) [Haipeng Jin] I understand your point, but you might have missed my = point. What I mean is that I can interpret the RFC3095 text as saying = that: (a) all compressor/decompressor must support timer-based = compression (b) if decompressor tells the compressor that its = clock_resolution is 0, then the compressor can not use timer based = compression; (c) if the compressor wants to use timer-based compression = before it has info about decompressor's clock_resolution, it needs to = send non-zero TIME_STRIDE to prompt CLOCK feedback from the = decompressor. If the decompressor says CLOCK=3D0 or no feedback at all = (in U mode), then the compressor can not use timer-based compression.=20 [LEJ] a) I know 3095 is not formally explicit on this, but to me it is pretty = clear (based on technical grounds) that this is an optional mechanism, = as it can not always be used, and it require explicit actions from both = decompressor and compressor (in that order) before it can be used. In = IETF specifications, we usually do not mandate things that can't be = mandated, and if a mechanism is in any way optional, we leave it to the = implementer(s) to decide whether to use it or not, thereby we do not = restrict implementation. This is common practice, so to me it is clear = that implementers are free to decide whether to implement timer-based = compression or not. b) This would mean timer-based compression would be default, and the = decompressor would have to turn it off. That would not work, as pointed = out by Mark and others, since the compressor need to know the = clock_resolution BEFORE it can use timer-based compression, not because = we have said so, but because it would not work otherwise. c) That could mean the compressor would send packets that can not for = sure be decompressed, and that is not the intension of the = specification. Further, it is not stated anywhere that the decompressor = must respond to such behavior by sending a CLOCK option. So, for example, I agree with Kristofer that, on a uni-directional link, = timer-based encoding (without out-of-band 'negotiation' of willingness = and=20 parameters such as clock resolution) is a really, really bad idea.=20 [Haipeng Jin] Agree with you. But I am not proposing to do blind = timer-based compression on a uni-directional link or even bi-directional = links. What I really mean is both compressor and decompressor support = timer-based compression but such compression can only be used when the = decompressor has a clock and the compressor knows the clock's = resolution.=20 [LEJ] I do have a hard time seeing what you are after here. Why would = you want to allow the compressor to start using an optimization scheme = that require knowledge about decompressor capabilities before the = decompressor has made that information available? I believe that would = not work, neither would it be desirable as it would make timer-based = compression a mandatory mechanism to implement, something that would go = against both the intensions of 3095 and the opinions of the = implementer's who have participated in the ROHC interoperability events. = Timer-based is a scheme that provides a minimal compression gain for = some packets by adding extra complexity, and it should be up to = implementer's to decide whether the gain is worth the complexity.=20 /L-E ------_=_NextPart_001_01C54A2B.41E1A4E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rohc] RE: Clarification on timer-based compression
Haipeng,

But if the compressor sets TIME_STRIDE then it is = scaling the=20 timestamp
before it knows (a) the = decompressor clock=20 resolution; or (b) whether the
decompressor = even=20 supports timer-based timestamp coding.

Given that the compressor should not send anything = that it is=20 not
confident that the decompressor can not=20 decompress, I really don't see how
the = compressor can=20 decide to use timer-based encoding *without* some
information from the decompressor.

(or am I misunderstanding your argument?)
[Haipeng=20 Jin] I understand your point, but you might have missed my point. = What I=20 mean is that I can interpret the RFC3095 text as saying = that: (a)=20 all compressor/decompressor must support timer-based=20 compression (b) if decompressor tells the compressor that its=20 clock_resolution is 0, then the compressor can not use timer based=20 compression; (c) if the compressor wants to use timer-based = compression=20 before it has info about decompressor's clock_resolution, it needs to = send=20 non-zero TIME_STRIDE to prompt CLOCK feedback from the = decompressor.=20 If the decompressor says CLOCK=3D0 or no feedback at all (in U mode), = then the=20 compressor can not use timer-based compression. 

[LEJ]

a) I know 3095 is not = formally=20 explicit on this, but to me it is pretty clear (based on technical = grounds)=20 that this is an optional mechanism, as it can not always be used, and = it=20 require explicit actions from both decompressor and compressor (in = that order)=20 before it can be used. In IETF specifications, we usually do not = mandate=20 things that can't be mandated, and if a mechanism is in any way = optional, we=20 leave it to the implementer(s) to decide whether to use it or not, = thereby we=20 do not restrict implementation. This is common practice, so to me it = is clear=20 that implementers are free to decide whether to implement timer-based=20 compression or not.

b) This would mean = timer-based=20 compression would be default, and the decompressor would have to turn = it off.=20 That would not work, as pointed out by Mark and others, since the = compressor=20 need to know the clock_resolution BEFORE it can use timer-based = compression,=20 not because we have said so, but because it would not work=20 otherwise.

c) That could mean = the compressor=20 would send packets that can not for sure be decompressed, and that is = not the=20 intension of the specification. Further, it is not stated anywhere = that the=20 decompressor must respond to such behavior by sending a CLOCK=20 option.

So, for example, I agree with Kristofer that, on a=20 uni-directional link,
timer-based encoding = (without=20 out-of-band 'negotiation' of willingness and
parameters such as clock resolution) is a really, really bad=20 idea.
[Haipeng Jin] Agree with you. But = I am not=20 proposing to do blind timer-based compression on a = uni-directional=20 link or even bi-directional links. What I really mean is both = compressor and=20 decompressor support timer-based compression but such=20 compression can only be used when the decompressor has a clock = and=20 the compressor knows the clock's resolution. 

[LEJ]=20 I=20 do have a hard time seeing what you are after here. Why would you want = to=20 allow the compressor to start using an optimization scheme that = require=20 knowledge about decompressor capabilities before the decompressor has = made=20 that information available? I believe that would not work, neither = would it be=20 desirable as it would make timer-based compression a mandatory = mechanism to=20 implement, something that would go against both the intensions of 3095 = and the=20 opinions of the implementer's who have participated in the ROHC=20 interoperability events. Timer-based is a scheme that provides a = minimal=20 compression gain for some packets by adding extra complexity, and it = should be=20 up to implementer's to decide whether the gain is worth the = complexity.=20

/L-E

------_=_NextPart_001_01C54A2B.41E1A4E8-- --===============1884063033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1884063033==-- From rohc-bounces@ietf.org Thu Apr 28 03:53:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17818 for ; Thu, 28 Apr 2005 03:53:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR42p-0005gS-Ju for rohc-archive@ietf.org; Thu, 28 Apr 2005 04:06:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR3ox-0006Pn-2j; Thu, 28 Apr 2005 03:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR3ou-0006OH-Sd for rohc@megatron.ietf.org; Thu, 28 Apr 2005 03:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17775 for ; Thu, 28 Apr 2005 03:52:23 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR41g-0005bR-BT for rohc@ietf.org; Thu, 28 Apr 2005 04:05:40 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3S7pDSC030176; Thu, 28 Apr 2005 09:52:12 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 09:52:00 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 09:52:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Thu, 28 Apr 2005 09:52:00 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DAD9@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 Thread-Index: AcVGTo73pKL0jIYmQ9ClZ/gTovZ4AQDSR9bQAIudxhA= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" , X-OriginalArrivalTime: 28 Apr 2005 07:52:00.0619 (UTC) FILETIME=[28DEC3B0:01C54BC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Just some quick notes... inline. /Ghyslain > > - I know this was discussed on the list a couple of years=20 > > ago, but why do we need "5.1.5. State Machine Supporting > > Context Replication"? This state machine is already > > described in the CR draft itself.... Maybe I should extend > > this question to "why do we even need any state machines, > > they just describe a specific way of implementing things > > and not actually much normative logic", but maybe some > > people want states to be able to relate to 3095 (where > > they are equally pointless)? >=20 > Oooops, as I just said above, I have the same feeling about > the descriptive concept with states. We should learn from=20 > our mistakes with 3095 and get rid of this. I _totally_ agree! I did fiercely defend this point of view a while ago, = also pointing out that state are only a pedagogical mean of explaining = some concepts, until the wg actually decided that this had to be in. It = was mostly after R. Price and M. West having insisted a lot that these = should be in. But I'm happy if we can make this go away again. > > - Next time the tcp-pf.txt is copied into the draft, DO NOT=20 > > remove the box notation (for all the people I have made > > read the document, I've had to give them the tcp-pf document > > so that they could get easy reference to how things work), > > and DO NOT remove the initial part of the file with=20 > > the references to profile-specific encodings. >=20 > Agree, we should have the formats also in box notation, so > that also ordinary humans can read this specification and get > something out of it. I disagree, for the simple reason that this means that we've failed with = the aspect of having a formal notation that is readable and = understandable. Having both augments the risks of discrepency between = both notations and the risk of errors. When one would review, I am = afraid that only one notation would be looked at, and not the other. If = there are discrepencies, we might miss errors somewhere in the process. = So, I "vote" for not having both notations in there at the same time. If = you want to push the case for the "other" notation, then that is a = different topic. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 28 09:11:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12605 for ; Thu, 28 Apr 2005 09:11:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR90E-0001dG-JQ for rohc-archive@ietf.org; Thu, 28 Apr 2005 09:24:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR8m8-0001jB-8n; Thu, 28 Apr 2005 09:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR8m5-0001j0-QC for rohc@megatron.ietf.org; Thu, 28 Apr 2005 09:09:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12532 for ; Thu, 28 Apr 2005 09:09:48 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR8yw-0001cI-8Q for rohc@ietf.org; Thu, 28 Apr 2005 09:23:07 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3SD9jfm007121; Thu, 28 Apr 2005 15:09:45 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 15:09:44 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 15:09:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Thu, 28 Apr 2005 15:09:42 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2843@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 Thread-Index: AcVGTo73pKL0jIYmQ9ClZ/gTovZ4AQDSR9bQAIudxhAACuOOsA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" , X-OriginalArrivalTime: 28 Apr 2005 13:09:43.0341 (UTC) FILETIME=[8B234DD0:01C54BF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable > > > - Next time the tcp-pf.txt is copied into the draft, DO NOT=20 > > > remove the box notation (for all the people I have made > > > read the document, I've had to give them the tcp-pf document > > > so that they could get easy reference to how things work), > > > and DO NOT remove the initial part of the file with=20 > > > the references to profile-specific encodings. > >=20 > > Agree, we should have the formats also in box notation, so > > that also ordinary humans can read this specification and get > > something out of it. >=20 > I disagree, for the simple reason that this means that we've=20 > failed with the aspect of having a formal notation that is=20 > readable and understandable. Having both augments the risks=20 > of discrepency between both notations and the risk of errors.=20 > When one would review, I am afraid that only one notation=20 > would be looked at, and not the other. If there are=20 > discrepencies, we might miss errors somewhere in the process.=20 > So, I "vote" for not having both notations in there at the=20 > same time. If you want to push the case for the "other"=20 > notation, then that is a different topic. I just cite Kristofer: "for all the people I have made read the document, I've had to give them the tcp-pf document so that they could get easy reference to how things work" Many of us can much easier build an understanding from pictures, FN descriptions are not easy to "see how it works" from. Yes, we have failed with many of our intensions with the FN, but I do not think we will remove it, so the question is not about one or the other.=20 But of course, we should draw the box notation from the FN, then it will help with reviewing the formats rather than the opposite. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 28 09:16:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12906 for ; Thu, 28 Apr 2005 09:16:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR95M-0001qC-6Q for rohc-archive@ietf.org; Thu, 28 Apr 2005 09:29:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR8r0-0002b9-IR; Thu, 28 Apr 2005 09:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR8qy-0002b4-LZ for rohc@megatron.ietf.org; Thu, 28 Apr 2005 09:14:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12790 for ; Thu, 28 Apr 2005 09:14:51 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR93m-0001oF-8D for rohc@ietf.org; Thu, 28 Apr 2005 09:28:10 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j3SDESqP026334; Thu, 28 Apr 2005 14:14:28 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Apr 2005 14:15:05 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2945@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , "Ghyslain Pelletier (LU/EAB)" , Kristofer Sandlund , rohc@ietf.org Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Thu, 28 Apr 2005 14:14:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > > But of course, we should draw the box notation from the FN, > then it will help with reviewing the formats rather than the > opposite. > Agreed! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 28 10:48:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22842 for ; Thu, 28 Apr 2005 10:48:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAWL-0005l8-Ap for rohc-archive@ietf.org; Thu, 28 Apr 2005 11:01:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAIS-0004Ue-1v; Thu, 28 Apr 2005 10:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAIQ-0004UU-97 for rohc@megatron.ietf.org; Thu, 28 Apr 2005 10:47:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22636 for ; Thu, 28 Apr 2005 10:47:16 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAVH-0005iI-6S for rohc@ietf.org; Thu, 28 Apr 2005 11:00:37 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3SEkUiH007393; Thu, 28 Apr 2005 16:47:11 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 16:46:24 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 16:46:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Thu, 28 Apr 2005 16:46:23 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DAE2@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 Thread-Index: AcVGTo73pKL0jIYmQ9ClZ/gTovZ4AQDSR9bQAIudxhAACuOOsAADnibQ From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" , X-OriginalArrivalTime: 28 Apr 2005 14:46:24.0201 (UTC) FILETIME=[0CB84B90:01C54C01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable The point is not about now chosing to switch to box notation, the point = is that we decided to use FN for TCP. So, since what is in a draft is ultimately what should consist into the = specification in the end, I cannot understand why we would have BOTH box = notation AND FN to describe the TCP packet formats. For sure, both = CANNOT be normative (or?). The TCP profile is a specification, not an explanatory document whose = purpose is to explain FN in yet another manner than the FN draft does. = Furthermore, we then need to MAINTAIN two packet format descriptions, = which I think is insane and can lead to discrepencies. If YOU want to have the TCP profile represented using the box notation, = than submit this as an informational draft and synch it with releases of = the TCP profile, with the mention "informational". Then if the group = wants to have this document live further and be informational RFC than = that will be fine with me. Anywho, this is my opinion. /Ghyslain =20 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > Sent: den 28 april 2005 15:10 > To: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund; rohc@ietf.org > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 >=20 >=20 > > > > - Next time the tcp-pf.txt is copied into the draft, DO NOT=20 > > > > remove the box notation (for all the people I have made > > > > read the document, I've had to give them the tcp-pf document > > > > so that they could get easy reference to how things work), > > > > and DO NOT remove the initial part of the file with=20 > > > > the references to profile-specific encodings. > > >=20 > > > Agree, we should have the formats also in box notation, so > > > that also ordinary humans can read this specification and get > > > something out of it. > >=20 > > I disagree, for the simple reason that this means that we've=20 > > failed with the aspect of having a formal notation that is=20 > > readable and understandable. Having both augments the risks=20 > > of discrepency between both notations and the risk of errors.=20 > > When one would review, I am afraid that only one notation=20 > > would be looked at, and not the other. If there are=20 > > discrepencies, we might miss errors somewhere in the process.=20 > > So, I "vote" for not having both notations in there at the=20 > > same time. If you want to push the case for the "other"=20 > > notation, then that is a different topic. >=20 > I just cite Kristofer: > "for all the people I have made read the document, I've had > to give them the tcp-pf document so that they could get easy > reference to how things work" >=20 > Many of us can much easier build an understanding from > pictures, FN descriptions are not easy to "see how it > works" from. Yes, we have failed with many of our intensions > with the FN, but I do not think we will remove it, so the > question is not about one or the other.=20 >=20 > But of course, we should draw the box notation from the FN, > then it will help with reviewing the formats rather than the > opposite. >=20 > /L-E >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Apr 28 10:59:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23849 for ; Thu, 28 Apr 2005 10:59:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAhA-0006Fw-2O for rohc-archive@ietf.org; Thu, 28 Apr 2005 11:12:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRASz-0007GA-Db; Thu, 28 Apr 2005 10:58:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRASx-0007G2-94 for rohc@megatron.ietf.org; Thu, 28 Apr 2005 10:58:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23802 for ; Thu, 28 Apr 2005 10:58:09 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAfo-0006A7-Nq for rohc@ietf.org; Thu, 28 Apr 2005 11:11:30 -0400 Received: from effnet.com (c-e17c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.225]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id j3SDv7mg015613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Apr 2005 15:57:08 +0200 Message-ID: <4270F9EE.3000908@effnet.com> Date: Thu, 28 Apr 2005 16:57:50 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] Proposed changes to rohc-tcp-09 References: <026F8EEDAD2C4342A993203088C1FC0527DAE2@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0527DAE2@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit While I understand your concern about having to have two things to verify, I think that is mitigated by the fact that the box notation in this case are FN comments, and therefore not in any way normative. I think we will be helping the reader out a lot by keeping the box in the document, and it should be clear for anyone who has read the FN draft which part is normative and which is just comments, but it's not a dealbreaker for me if we don't have them there either. BR, Kristofer Ghyslain Pelletier (LU/EAB) wrote: > The point is not about now chosing to switch to box notation, the point is that we decided to use FN for TCP. > > So, since what is in a draft is ultimately what should consist into the specification in the end, I cannot understand why we would have BOTH box notation AND FN to describe the TCP packet formats. For sure, both CANNOT be normative (or?). > > The TCP profile is a specification, not an explanatory document whose purpose is to explain FN in yet another manner than the FN draft does. Furthermore, we then need to MAINTAIN two packet format descriptions, which I think is insane and can lead to discrepencies. > > If YOU want to have the TCP profile represented using the box notation, than submit this as an informational draft and synch it with releases of the TCP profile, with the mention "informational". Then if the group wants to have this document live further and be informational RFC than that will be fine with me. > > Anywho, this is my opinion. > > /Ghyslain > > >>-----Original Message----- >>From: Lars-Erik Jonsson (LU/EAB) >>Sent: den 28 april 2005 15:10 >>To: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund; rohc@ietf.org >>Subject: RE: [rohc] Proposed changes to rohc-tcp-09 >> >> >> >>>>>- Next time the tcp-pf.txt is copied into the draft, DO NOT >>>>>remove the box notation (for all the people I have made >>>>>read the document, I've had to give them the tcp-pf document >>>>>so that they could get easy reference to how things work), >>>>>and DO NOT remove the initial part of the file with >>>>>the references to profile-specific encodings. >>>> >>>>Agree, we should have the formats also in box notation, so >>>>that also ordinary humans can read this specification and get >>>>something out of it. >>> >>>I disagree, for the simple reason that this means that we've >>>failed with the aspect of having a formal notation that is >>>readable and understandable. Having both augments the risks >>>of discrepency between both notations and the risk of errors. >>>When one would review, I am afraid that only one notation >>>would be looked at, and not the other. If there are >>>discrepencies, we might miss errors somewhere in the process. >>>So, I "vote" for not having both notations in there at the >>>same time. If you want to push the case for the "other" >>>notation, then that is a different topic. >> >>I just cite Kristofer: >>"for all the people I have made read the document, I've had >>to give them the tcp-pf document so that they could get easy >>reference to how things work" >> >>Many of us can much easier build an understanding from >>pictures, FN descriptions are not easy to "see how it >>works" from. Yes, we have failed with many of our intensions >>with the FN, but I do not think we will remove it, so the >>question is not about one or the other. >> >>But of course, we should draw the box notation from the FN, >>then it will help with reviewing the formats rather than the >>opposite. >> >>/L-E >> > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 02:51:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26914 for ; Fri, 29 Apr 2005 02:51:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRPYS-0003cL-9f for rohc-archive@ietf.org; Fri, 29 Apr 2005 03:04:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPHe-0000JT-32; Fri, 29 Apr 2005 02:47:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRETg-0001Ro-UC for rohc@megatron.ietf.org; Thu, 28 Apr 2005 15:15:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15845 for ; Thu, 28 Apr 2005 15:15:11 -0400 (EDT) From: fjko04@kom.aau.dk Received: from zaz.kom.auc.dk ([130.225.51.10] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DREga-0000Wt-LW for rohc@ietf.org; Thu, 28 Apr 2005 15:28:33 -0400 Received: from husqvarna.kom.auc.dk ([130.225.51.77] ident=mail) by zaz.kom.auc.dk with esmtp (Exim 2.05 #3) id 1DRETc-0003LN-00 for rohc@ietf.org; Thu, 28 Apr 2005 21:15:08 +0200 Received: from localhost ([127.0.0.1] ident=www-data) by husqvarna.kom.auc.dk with esmtp (Exim 3.35 #1 (Debian)) id 1DRETX-0008VE-00 for ; Thu, 28 Apr 2005 21:15:03 +0200 Received: from port56.ds1-aboes.adsl.cybercity.dk (port56.ds1-aboes.adsl.cybercity.dk [212.242.226.121]) by webmail.kom.aau.dk (IMP) with HTTP for ; Thu, 28 Apr 2005 21:15:03 +0200 Message-ID: <1114715703.42713637a0094@webmail.kom.aau.dk> Date: Thu, 28 Apr 2005 21:15:03 +0200 To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.4 X-Originating-IP: 212.242.226.121 X-Spam-Score: 1.2 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 29 Apr 2005 02:47:28 -0400 Subject: [rohc] IP/UDP/RTP headers... X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 8bit Hi dear ROHC WG, I highly regard ROHC WG's dedicated work... and would like to get some assisstance of you. We are a student group working on header compression as well for which i am interested to know what is the best and optimal way of generating IP/UDP/RTP traffic (easy but real data). Your suggestions will be appreciated! Cheers! Fahad ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 02:53:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27021 for ; Fri, 29 Apr 2005 02:53:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRPa9-0003iP-7F for rohc-archive@ietf.org; Fri, 29 Apr 2005 03:06:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPN5-0001Ay-TY; Fri, 29 Apr 2005 02:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPN3-00018l-FI for rohc@megatron.ietf.org; Fri, 29 Apr 2005 02:53:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27003 for ; Fri, 29 Apr 2005 02:53:03 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRPa2-0003hy-2Q for rohc@ietf.org; Fri, 29 Apr 2005 03:06:32 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3T6qEjd024450; Fri, 29 Apr 2005 08:53:00 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 08:52:41 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 08:52:41 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 29 Apr 2005 08:52:40 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DAE6@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 thread-index: AcVMArI2XYW9MZxZT2+EeYTxeXQ4HgAhRVKg From: "Ghyslain Pelletier \(LU/EAB\)" To: "Kristofer Sandlund" X-OriginalArrivalTime: 29 Apr 2005 06:52:41.0150 (UTC) FILETIME=[09ACA5E0:01C54C88] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable I am not saying that it might not be helpful for the reader, of that it = cannot be made clear what part is normative or not, I am simply saying = that it does not belong to this document and that it should "live" = somewhere else. Also my concerns as the editor of the TCP draft. > dealbreaker for me if we=20 > don't have them there either. Then let's remind everyone where the box notation pf are (a link to the = CVS?) /Ghyslain > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 28 april 2005 16:58 > To: Ghyslain Pelletier (LU/EAB) > Cc: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > Subject: Re: [rohc] Proposed changes to rohc-tcp-09 >=20 >=20 > While I understand your concern about having to have two=20 > things to verify, I=20 > think that is mitigated by the fact that the box notation in=20 > this case are FN=20 > comments, and therefore not in any way normative. >=20 > I think we will be helping the reader out a lot by keeping=20 > the box in the=20 > document, and it should be clear for anyone who has read the=20 > FN draft which part=20 > is normative and which is just comments, but it's not a=20 > dealbreaker for me if we=20 > don't have them there either. >=20 > BR, > Kristofer >=20 > Ghyslain Pelletier (LU/EAB) wrote: > > The point is not about now chosing to switch to box=20 > notation, the point is that we decided to use FN for TCP. > >=20 > > So, since what is in a draft is ultimately what should=20 > consist into the specification in the end, I cannot=20 > understand why we would have BOTH box notation AND FN to=20 > describe the TCP packet formats. For sure, both CANNOT be=20 > normative (or?). > >=20 > > The TCP profile is a specification, not an explanatory=20 > document whose purpose is to explain FN in yet another manner=20 > than the FN draft does. Furthermore, we then need to MAINTAIN=20 > two packet format descriptions, which I think is insane and=20 > can lead to discrepencies. > >=20 > > If YOU want to have the TCP profile represented using the=20 > box notation, than submit this as an informational draft and=20 > synch it with releases of the TCP profile, with the mention=20 > "informational". Then if the group wants to have this=20 > document live further and be informational RFC than that will=20 > be fine with me. > >=20 > > Anywho, this is my opinion. > >=20 > > /Ghyslain =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Lars-Erik Jonsson (LU/EAB)=20 > >>Sent: den 28 april 2005 15:10 > >>To: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund; rohc@ietf.org > >>Subject: RE: [rohc] Proposed changes to rohc-tcp-09 > >> > >> > >> > >>>>>- Next time the tcp-pf.txt is copied into the draft, DO NOT=20 > >>>>>remove the box notation (for all the people I have made > >>>>>read the document, I've had to give them the tcp-pf document > >>>>>so that they could get easy reference to how things work), > >>>>>and DO NOT remove the initial part of the file with=20 > >>>>>the references to profile-specific encodings. > >>>> > >>>>Agree, we should have the formats also in box notation, so > >>>>that also ordinary humans can read this specification and get > >>>>something out of it. > >>> > >>>I disagree, for the simple reason that this means that we've=20 > >>>failed with the aspect of having a formal notation that is=20 > >>>readable and understandable. Having both augments the risks=20 > >>>of discrepency between both notations and the risk of errors.=20 > >>>When one would review, I am afraid that only one notation=20 > >>>would be looked at, and not the other. If there are=20 > >>>discrepencies, we might miss errors somewhere in the process.=20 > >>>So, I "vote" for not having both notations in there at the=20 > >>>same time. If you want to push the case for the "other"=20 > >>>notation, then that is a different topic. > >> > >>I just cite Kristofer: > >>"for all the people I have made read the document, I've had > >>to give them the tcp-pf document so that they could get easy > >>reference to how things work" > >> > >>Many of us can much easier build an understanding from > >>pictures, FN descriptions are not easy to "see how it > >>works" from. Yes, we have failed with many of our intensions > >>with the FN, but I do not think we will remove it, so the > >>question is not about one or the other.=20 > >> > >>But of course, we should draw the box notation from the FN, > >>then it will help with reviewing the formats rather than the > >>opposite. > >> > >>/L-E > >> > >=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 03:07:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28007 for ; Fri, 29 Apr 2005 03:07:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRPo4-0004H1-V7 for rohc-archive@ietf.org; Fri, 29 Apr 2005 03:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPYN-0003K2-PV; Fri, 29 Apr 2005 03:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPYL-0003Ja-Is for rohc@megatron.ietf.org; Fri, 29 Apr 2005 03:04:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27758 for ; Fri, 29 Apr 2005 03:04:44 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRPlL-00048E-Ho for rohc@ietf.org; Fri, 29 Apr 2005 03:18:13 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3T74XPe029774; Fri, 29 Apr 2005 09:04:42 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 09:04:06 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 09:04:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 29 Apr 2005 09:04:06 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2847@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 thread-index: AcVMArI2XYW9MZxZT2+EeYTxeXQ4HgAhRVKgAABZOxA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 29 Apr 2005 07:04:06.0576 (UTC) FILETIME=[A2385B00:01C54C89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > I am not saying that it might not be helpful for the reader,=20 > of that it cannot be made clear what part is normative or=20 > not, I am simply saying that it does not belong to this=20 > document and that it should "live" somewhere else. This is where we seem to disagree. If it is useful to the reader of the TCP profile, I believe the profile RFC is where it should be. > Then let's remind everyone where the box notation pf are (a=20 > link to the CVS?) The CVS is an unofficial non-archive, useless in the long run. I agree with Kristofers note that the box notation would be "comments", it is like a picture visualizing the normative text (which is the FN description). /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 03:58:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01900 for ; Fri, 29 Apr 2005 03:58:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQb6-0006UB-L2 for rohc-archive@ietf.org; Fri, 29 Apr 2005 04:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQLJ-0004Pc-JI; Fri, 29 Apr 2005 03:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQLH-0004Or-30 for rohc@megatron.ietf.org; Fri, 29 Apr 2005 03:55:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01748 for ; Fri, 29 Apr 2005 03:55:17 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQYH-0006NL-Ck for rohc@ietf.org; Fri, 29 Apr 2005 04:08:47 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3T7t2hh005261; Fri, 29 Apr 2005 09:55:11 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 09:52:33 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 09:52:33 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 29 Apr 2005 09:52:32 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DAE7@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 thread-index: AcVMArI2XYW9MZxZT2+EeYTxeXQ4HgAhRVKgAABZOxAAAZgkIA== From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 29 Apr 2005 07:52:33.0400 (UTC) FILETIME=[66D27F80:01C54C90] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Please comment on what is wrong with my constructive proposal of = maintaining this kind of pictoresque "dual" representation in a separate = draft that would live as informational. The reasons for this is 1) = maintainability of the TCP spec 2) scope of the TCP spec 3) the TCP spec = is (and is meant to) a complete specification without redundant = explanations using box notation. Furthermore, box notation cannot say as much as the formal notation = does, which means that in any case you'll need to look at the FN (also = since this is the mandatory part of the pf). As such, once a reader as = read and understood the FN (which is one of our objectives), I think = that the pf should be understandable and readable. So, once again, I'd like to stand firm by my opinion that any pictorials = of the packet formats as comments should live outside the TCP specs, as = they don't make up the specification itself. /Ghyslain > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > Sent: den 29 april 2005 09:04 > To: Ghyslain Pelletier (LU/EAB); 'Kristofer Sandlund' > Cc: 'rohc@ietf.org' > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 >=20 >=20 > > I am not saying that it might not be helpful for the reader,=20 > > of that it cannot be made clear what part is normative or=20 > > not, I am simply saying that it does not belong to this=20 > > document and that it should "live" somewhere else. >=20 > This is where we seem to disagree. If it is useful to the > reader of the TCP profile, I believe the profile RFC is > where it should be. >=20 >=20 > > Then let's remind everyone where the box notation pf are (a=20 > > link to the CVS?) >=20 > The CVS is an unofficial non-archive, useless in the long run. >=20 >=20 > I agree with Kristofers note that the box notation would be > "comments", it is like a picture visualizing the normative > text (which is the FN description). >=20 > /L-E >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 05:28:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07140 for ; Fri, 29 Apr 2005 05:28:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRS06-0001f1-Qm for rohc-archive@ietf.org; Fri, 29 Apr 2005 05:41:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRRlp-0003FW-9e; Fri, 29 Apr 2005 05:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRRlk-0003Eh-Ey for rohc@megatron.ietf.org; Fri, 29 Apr 2005 05:26:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07089 for ; Fri, 29 Apr 2005 05:26:42 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRRym-0001eK-KP for rohc@ietf.org; Fri, 29 Apr 2005 05:40:13 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3T9OGjE000011; Fri, 29 Apr 2005 11:26:42 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 11:26:31 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 11:26:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Proposed changes to rohc-tcp-09 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 29 Apr 2005 11:26:30 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2849@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 thread-index: AcVMArI2XYW9MZxZT2+EeYTxeXQ4HgAhRVKgAABZOxAAAZgkIAADWX8A From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 29 Apr 2005 09:26:31.0066 (UTC) FILETIME=[87220FA0:01C54C9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Box pictures would be only a visualization of the formal and complete description given by the FN description. As such, I think it serves the reader better when presented along with the FN descriptions within the TCP profile specification. It does not change the scope of the TCP profile in any way, and it does not provide any formal redundancy. I am not asking for complementary textual description of the content of the formats, like we had in e.g. 3095. The complete formal definitions are fully covered by the FN descriptions. I am NOT asking for adding formal redundancy. /L-E > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB)=20 > Sent: den 29 april 2005 09:53 > To: Lars-Erik Jonsson (LU/EAB); 'Kristofer Sandlund' > Cc: 'rohc@ietf.org' > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 >=20 >=20 > Please comment on what is wrong with my constructive proposal=20 > of maintaining this kind of pictoresque "dual" representation=20 > in a separate draft that would live as informational. The=20 > reasons for this is 1) maintainability of the TCP spec 2)=20 > scope of the TCP spec 3) the TCP spec is (and is meant to) a=20 > complete specification without redundant explanations using=20 > box notation. >=20 > Furthermore, box notation cannot say as much as the formal=20 > notation does, which means that in any case you'll need to=20 > look at the FN (also since this is the mandatory part of the=20 > pf). As such, once a reader as read and understood the FN=20 > (which is one of our objectives), I think that the pf should=20 > be understandable and readable. >=20 > So, once again, I'd like to stand firm by my opinion that any=20 > pictorials of the packet formats as comments should live=20 > outside the TCP specs, as they don't make up the specification itself. >=20 > /Ghyslain >=20 > > -----Original Message----- > > From: Lars-Erik Jonsson (LU/EAB)=20 > > Sent: den 29 april 2005 09:04 > > To: Ghyslain Pelletier (LU/EAB); 'Kristofer Sandlund' > > Cc: 'rohc@ietf.org' > > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 > >=20 > >=20 > > > I am not saying that it might not be helpful for the reader,=20 > > > of that it cannot be made clear what part is normative or=20 > > > not, I am simply saying that it does not belong to this=20 > > > document and that it should "live" somewhere else. > >=20 > > This is where we seem to disagree. If it is useful to the > > reader of the TCP profile, I believe the profile RFC is > > where it should be. > >=20 > >=20 > > > Then let's remind everyone where the box notation pf are (a=20 > > > link to the CVS?) > >=20 > > The CVS is an unofficial non-archive, useless in the long run. > >=20 > >=20 > > I agree with Kristofers note that the box notation would be > > "comments", it is like a picture visualizing the normative > > text (which is the FN description). > >=20 > > /L-E > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 07:32:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14751 for ; Fri, 29 Apr 2005 07:32:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRTwp-0006kT-Cg for rohc-archive@ietf.org; Fri, 29 Apr 2005 07:46:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRTix-0004k0-Dl; Fri, 29 Apr 2005 07:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRTiv-0004js-D3 for rohc@megatron.ietf.org; Fri, 29 Apr 2005 07:31:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14597 for ; Fri, 29 Apr 2005 07:31:56 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRTvy-0006ey-EE for rohc@ietf.org; Fri, 29 Apr 2005 07:45:27 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3TBVtO6001797; Fri, 29 Apr 2005 13:31:55 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 13:31:55 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 13:31:54 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Fri, 29 Apr 2005 13:31:54 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DAEE@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 thread-index: AcVMArI2XYW9MZxZT2+EeYTxeXQ4HgAhRVKgAABZOxAAAZgkIAADWX8AAAQzC0A= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 29 Apr 2005 11:31:54.0777 (UTC) FILETIME=[0B9D4090:01C54CAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable > > Please comment on what is wrong with my constructive proposal=20 > > of maintaining this kind of pictoresque "dual" representation=20 > > in a separate draft that would live as informational. The=20 I'd like to restate my above point, which you are not addressing. The = scope of what you're after is IMHO for another document... > Box pictures would be only a visualization of the formal and > complete description given by the FN description. As such, I I understand that. That does not make it any better. What you ask still only provides (redundant) information on the bit = arrangement, which is quite easily deduced already from the list of = fields in the format. On top of this, we already have commented = annotations in the ROHC-TCP draft to help with bit arrangements... The question is if this is necessary to be in the ROHC-TCP draft, also = once one as read and understood the FN. I don't think so. > think it serves the reader better when presented along with > the FN descriptions within the TCP profile specification. This is a matter of opinion. But then you're free to provide this as a = separate draft and drive it as an informational document. > It does not change the scope of the TCP profile in any way, > and it does not provide any formal redundancy. I am not In practice, it _does_ mean redundancy in the specification anyway. > asking for complementary textual description of the content > of the formats, like we had in e.g. 3095. The complete formal This means that this (redundant) information is incomplete, and the = reader still needs to read and understand the FN. To what point then? > definitions are fully covered by the FN descriptions. I am > NOT asking for adding formal redundancy. I understand that. Should be clear from previous mail. Anyways... Over and out for me on this one - get consensus first. /Ghyslain >=20 > > -----Original Message----- > > From: Ghyslain Pelletier (LU/EAB)=20 > > Sent: den 29 april 2005 09:53 > > To: Lars-Erik Jonsson (LU/EAB); 'Kristofer Sandlund' > > Cc: 'rohc@ietf.org' > > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 > >=20 > >=20 > > Please comment on what is wrong with my constructive proposal=20 > > of maintaining this kind of pictoresque "dual" representation=20 > > in a separate draft that would live as informational. The=20 > > reasons for this is 1) maintainability of the TCP spec 2)=20 > > scope of the TCP spec 3) the TCP spec is (and is meant to) a=20 > > complete specification without redundant explanations using=20 > > box notation. > >=20 > > Furthermore, box notation cannot say as much as the formal=20 > > notation does, which means that in any case you'll need to=20 > > look at the FN (also since this is the mandatory part of the=20 > > pf). As such, once a reader as read and understood the FN=20 > > (which is one of our objectives), I think that the pf should=20 > > be understandable and readable. > >=20 > > So, once again, I'd like to stand firm by my opinion that any=20 > > pictorials of the packet formats as comments should live=20 > > outside the TCP specs, as they don't make up the=20 > specification itself. > >=20 > > /Ghyslain > >=20 > > > -----Original Message----- > > > From: Lars-Erik Jonsson (LU/EAB)=20 > > > Sent: den 29 april 2005 09:04 > > > To: Ghyslain Pelletier (LU/EAB); 'Kristofer Sandlund' > > > Cc: 'rohc@ietf.org' > > > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 > > >=20 > > >=20 > > > > I am not saying that it might not be helpful for the reader,=20 > > > > of that it cannot be made clear what part is normative or=20 > > > > not, I am simply saying that it does not belong to this=20 > > > > document and that it should "live" somewhere else. > > >=20 > > > This is where we seem to disagree. If it is useful to the > > > reader of the TCP profile, I believe the profile RFC is > > > where it should be. > > >=20 > > >=20 > > > > Then let's remind everyone where the box notation pf are (a=20 > > > > link to the CVS?) > > >=20 > > > The CVS is an unofficial non-archive, useless in the long run. > > >=20 > > >=20 > > > I agree with Kristofers note that the box notation would be > > > "comments", it is like a picture visualizing the normative > > > text (which is the FN description). > > >=20 > > > /L-E > > >=20 > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Apr 29 08:25:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19275 for ; Fri, 29 Apr 2005 08:25:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRUlz-00010c-Cj for rohc-archive@ietf.org; Fri, 29 Apr 2005 08:39:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRUWW-0004pR-87; Fri, 29 Apr 2005 08:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRUWU-0004pM-JL for rohc@megatron.ietf.org; Fri, 29 Apr 2005 08:23:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19005 for ; Fri, 29 Apr 2005 08:23:09 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRUjV-0000qp-5W for rohc@ietf.org; Fri, 29 Apr 2005 08:36:40 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3TCMHhw009526; Fri, 29 Apr 2005 14:22:53 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 14:22:28 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 14:22:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Fri, 29 Apr 2005 14:22:26 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C284B@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Proposed changes to rohc-tcp-09 thread-index: AcVMArI2XYW9MZxZT2+EeYTxeXQ4HgAhRVKgAABZOxAAAZgkIAADWX8AAAQzC0AAAalKEA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "Kristofer Sandlund" X-OriginalArrivalTime: 29 Apr 2005 12:22:27.0936 (UTC) FILETIME=[1B849600:01C54CB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable > Anyways... Over and out for me on this one - get consensus first. This is a little bit hard to judge, I think. You are the only one opposing having the box notation in the profile along with the FN formats, while Robert has said "agreed", and me and Kristofer are the ones who want this to be there. If I was to see some kind of rough consensus in this, it would be that only one person is opposing while more than one is asking for it. However, I do not think I would like to conclude based on these few and diverse opinions. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Sat Apr 30 14:09:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21495 for ; Sat, 30 Apr 2005 14:09:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRwcA-0002Jk-6e for rohc-archive@ietf.org; Sat, 30 Apr 2005 14:22:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRwNe-0005ab-0S; Sat, 30 Apr 2005 14:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRwNd-0005aW-3t for rohc@megatron.ietf.org; Sat, 30 Apr 2005 14:07:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21403 for ; Sat, 30 Apr 2005 14:07:51 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRwav-0002Et-SS for rohc@ietf.org; Sat, 30 Apr 2005 14:21:39 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3UI7nO6028633; Sat, 30 Apr 2005 20:07:49 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 30 Apr 2005 20:07:48 +0200 Content-class: urn:content-classes:message Subject: RE: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Apr 2005 20:07:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff. Thread-Index: AcVBfvCoMRibJ1WQSP6gbUllEFhpggATW1pgAvdpnJA= From: "Lajos Zaccomer \(IJ/ETH\)" To: "Surtees, Abigail" X-OriginalArrivalTime: 30 Apr 2005 18:07:48.0466 (UTC) FILETIME=[84544D20:01C54DAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Content-Transfer-Encoding: quoted-printable Hi Abbie, I'm sorry for being late with my answer. I actually agree with you, = regarding all the items. br/Zacco > -----Original Message----- > From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] > Sent: Friday, April 15, 2005 5:59 PM > To: Lajos Zaccomer (IJ/ETH) > Cc: rohc@ietf.org > Subject: RE: [rohc] [SigComp]Shared mode and some other=20 > SigComp-state rela ted stuff. >=20 >=20 > Hi Zacco, >=20 > We've got crossed wires somewhere and I'm afraid I'm still confused. > What I was trying to say is the following: >=20 > 1) In standard rfc 3320 behaviour, if an endpoint advertises=20 > a piece of > state to the remote endpoint, it is saying that it has that piece of > state available for use for the duration of the compartment*.=20 > It is up > to the implementer whether the bytes of the advertised state are > uploaded to the remote endpoint and created as high priority=20 > state (i.e. > stored in the compressor compartment) or are stored outside the > compressor SMS in the endpoint (more likely e.g. dictionary). >=20 > *Shared mode state is an exception to this. >=20 > 2) The remote endpoint *can*, if it is sophisticated, notice that a > piece of state has been both uploaded (i.e. the bytes are in the > decompressor compartment) and advertised and, therefore, choose to use > this piece of state as reference state for its return message. >=20 > 3) There is no requirement on the remote endpoint to do this. >=20 > 4) If the remote endpoint does this, neither endpoint has=20 > done anything > other than use standard rfcs 3320 - 22 behaviour. >=20 > 5) An optional mechanism that would make it easier for the remote > endpoint to recognise that a piece of state is useful as a=20 > reference is > to include the bytes 'usd1' as the first 4 bytes. However,=20 > addition of > these bytes DOES NOT change the state processing at either endpoint. > The state is stored in exactly the same way (implementer's=20 > choice at the > compressor, in the SMS memory at the decompressor) as if the bytes are > not there. >=20 > 6) If the remote endpoint chooses to move the state from its > decompressor compartment and advertise it back to the local endpoint, > that is an implementation choice and is still perfectly compliant with > rfcs 3320 - 22. (An endpoint choosing to do this must carefully > consider the security implications.) >=20 > 7) If there is anything in the intention of what is written in the PoC > specification that is not covered here, please could you explain (e.g. > with use of diagrams similar to the ones in my previous email) what it > is that I'm missing. >=20 > 8) As it stands at the moment, this part of the PoC specification is > unclear, ambiguous and could lead to loss of synchronisation. >=20 > Best regards, >=20 > Abbie >=20 > >=20 > > >=20 > > > Hi Zacco, > > >=20 > > > Once again, apologies for the delay in responding to this. > > >=20 > > > I am somewhat confused by some of the statements in the=20 > > > discussion below and the level of indentation isn't helping. =20 > > > Consequently, I'm going to state my understanding and you can=20 > > > tell me where you disagree or I am wrong. I hope that's ok. =20 > > > I've used text here and put some ASCII diagrams in the=20 > > > attached file (they get messed up if they're in the body of=20 > > > the email). > > >=20 > > > Let's start with basic SigComp operation (to ensure we're all=20 > > > clear on the terminology and interpretation of pictures -=20 > > > using a 2 byte partial hash to identify state): > > >=20 > > > Scenario 1: > > > Endpoint A sends a message to endpoint B requesting two=20 > > > pieces of state to be created and feedback to be returned: > > >=20 > > > Bytecode with hash bcbc > > > Buffer state with hash bff1 > > >=20 > > > The state handler at B has no idea what the pieces of state=20 > > > are - they are just chunks of bytes. Endpoint B includes the=20 > > > feedback in its return message, thus endpoint A can refer to=20 > > > both pieces of state in its next message. > > >=20 > > > Scenario 2: > > >=20 > > > Endpoint A knows about a dictionary (with hash d1c7). It=20 > > > sends a message to endpoint B requesting state creation and=20 > > > feedback as in scenario 1, but also advertising d1c7. > > >=20 > > > If endpoint B doesn't know anything about d1c7, then the=20 > > > advertisement will be ignored and the return message will not=20 > > > refer to it. > > >=20 > > > If endpoint B does know about d1c7 and has the capacity to=20 > > > use it, then the return message will refer to it. > > >=20 > > > Scenario 3: > > > Endpoint A knows about dictionary (with hash d1c7) and wants=20 > > > to be able to use it for compression itself, so it uploads it=20 > > > to endpoint B as another piece of state. > > >=20 > > > Scenario 4: > > > Endpoint A knows about dictionary (with hash d1c7) and wants=20 > > > to be able to refer to it at endpoint B AND it thinks B may=20 > > > be a sophisticated implementation. Therefore endpoint A not=20 > > > only uploads the dictionary (as in scenario 3) but also=20 > > > advertises its presence at endpoint A, allowing B to refer to=20 > > > it. N.B. By advertising it, endpoint A is saying that the=20 > > > dictionary will be available for the duration of the=20 > > > compartment (this may be in memory external to the compressor=20 > > > SMS, or it may be created within the compartment e.g. at=20 > > > sufficiently high priority in the compressor A SMS that it=20 > > > will not be pushed out by other state - compressor A has full=20 > > > control of both alternatives). > >=20 > > [zacco] In PoC, state d1c7 is called a USD and is stored in=20 > > memory external to the compressor. > >=20 > > OMA-POC-2004-0655-CP-SigComp 5.X.1.2 says: > > "The USD is a locally available state, [RFC3320], at the PoC=20 > > Client and to improve the compression efficiency in the=20 > > uplink the PoC Client MAY upload the USD to its SIP/IP Core=20 > > compartment. To increase the compression efficiency in the=20 > > downlink, the PoC client MAY advertise the locally available=20 > > state to the SIP/IP core.=20 > > The first four bytes of the USD state value SHALL be the=20 > > specific identifier string; "usd1" in order to distinguish=20 > > the USD state from the possible bytecode uploaded for the=20 > > Universal Decompressor Virtual Machine (UDVM)." > >=20 > > >=20 > > > The simplest implementation of B on receipt of the advert for=20 > > > d1c7 would decide it knows nothing about d1c7 as is the case=20 > > > with any other state advert about which it knows nothing. > > >=20 > > > A more sophisticated implementation may notice that the state=20 > > > being advertised has also been created in the decompressor=20 > > > SMS. Therefore, because it has the bytes of the state, the=20 > > > compressor at B *could* make use of the state. However, the=20 > > > compressor at endpoint B does not know what sort of state it=20 > > > is - it's just a bunch of bytes. Some heuristic (e.g.=20 > > > comparison with the next message to be compressed) could be=20 > > > used to decide whether or not the piece of state is useful as=20 > > > a reference to improve the compression ratio of the next=20 > message. =20 > > >=20 > > > Endpoint B can refer to d1c7 as long as it knows what it is=20 > > > (i.e. it might get pushed out of the decompressor SMS at B,=20 > > > at which point, B no longer has it). As mentioned above,=20 > > > once the state has been advertised by endpoint A, endpoint A=20 > > > must keep it for the duration of the compartment. > >=20 > > Not quite if d1c7 is moved to external memory in B, which is=20 > > optional and up to B. If so, it must be indicated with=20 > > explicit acking this state. (The only problem with this=20 > > solution that it fails, if you advertise e.g. your bytecode=20 > > at the same time, and B explicitly acks the bytecode instead=20 > > of d1c7. In this case, A thinks d1c7 is in external memory,=20 > > and will most probably overwrite d1c7 sooner or later. > >=20 > > >=20 > > > So far, all of the above is standard rfc 3320 behaviour. =20 > >=20 > > Yes. My example is PoC. If we talk about 3320-22 only, I have=20 > > nothing to add or modify. > >=20 > > > When compressor A advertises the dictionary, where it stores=20 > > > the bytes of dictionary (inside or outside SMS) is=20 > > > implementation specific, though in scenarios 3 and 4 it must=20 > > > be accounted for in the SMS monitoring because it is=20 > > > mirroring the SMS at endpoint B. At endpoint B there is no=20 > > > requirement to do anything other than store state according=20 > > > to rfc 3320. > >=20 > > Unless you want to implement some PoC standard features, as well. > >=20 > > >=20 > > > I think that placing 'usd1' as the first 4 bytes of a=20 > > > dictionary is then a simple heuristic optimisation. If=20 > > > endpoint A puts 'usd1' at the beginning of the state then=20 > > > endpoint B has a simple way of recognising that the state=20 > > > will be useful as a reference. If, however, A doesn't do=20 > > > that, then B (if it wants to) can use some other heuristic,=20 > > > as it would without the optimisation. Equally, if endpoint A=20 > > > does put 'usd1' in the state and endpoint B doesn't look for=20 > > > it, both endpoints continue as if it were not there. > >=20 > > Right. > >=20 > > >=20 > > > The key point is that, whatever happens, the actual state=20 > > > creation and handling at both endpoints is the same,=20 > > > regardless of whether or not the state contains the bytes=20 > 'usd1'. =20 > > >=20 > > > Is my interpretation correct? If not, please explain my=20 > > > misunderstanding. Whether or not my understanding is=20 > > > correct, the text describing this mechanism needs=20 > > > clarification in the PoC specification. (I realise this is=20 > > > not the place for that discussion - I'm just trying to make=20 > > > sure I understand correctly). > > >=20 > > > Best regards, > > >=20 > > > Abbie > > >=20 > > > > >=20 > > > > > Sorry for the delay. I've got some questions about the PoC=20 > > > > > related use of > > > > > usds. > > > > >=20 > > > > > >=20 > > > > > > > 3. USD. I fully understand the usage of a USD.=20 > > However, I do=20 > > > > > > > not understand=20 > > > > > > > if a USD-state should be treated any differenty then any=20 > > > > > > > other state created=20 > > > > > > > at the remote end. Is a USD per definition a=20 > shared state?=20 > > > > > >=20 > > > > > > No, it isn't. RFC 3321 says it's a regular state.=20 > POC USD is=20 > > > > > > something different. I would say it's a regular and=20 > a shared=20 > > > > > > state at the same time. > > > > >=20 > > > > > What does that actually mean? As you say 3321 says it's a=20 > > > > > regular state, so > > > > > in SigComp terms how can it be a shared state as well? > > > >=20 > > > > [zacco] In PoC, the terminal uploads the USD after saving it=20 > > > > in the state memory. The special advertisement lets the=20 > > > > server know it received a USD that it also saves in the state=20 > > > > memory (or outside the state memory, which must be signalled=20 > > > > backwards). Thus, both endpoints will have the USD and can=20 > > > > use it for compression. That is why I say PoC USD is a=20 > > > > dynamic (or regular) and shared state at the same time. > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > > I'm guessing that=20 > > > > > > > it must be if the sending compressor is to have any=20 > > > > > > advantage of the=20 > > > > > > > USD-state at the remote end. Then, again, should the=20 > > > > > > > USD-state (local state)=20 > > > > > > > at A be considered to occupy State-memory? Should it be=20 > > > > > > > considered any=20 > > > > > > > differently then any other shared state? > > > > > >=20 > > > > > > It depends on which USD you are talking about. A regular=20 > > > > > > state is not saved in a state memory at the=20 > compressor side,=20 > > > > > > so if you go for the RFC 3321 USD, it decreases the=20 > available=20 > > > > > > memory at B in the state memory of compresssor at=20 > A. In case=20 > > > > > > POC USD is used, it must be saved as a local state,=20 > otherwise=20 > > > > > > the compressor at B would not be able to access it. > > > > >=20 > > > > > However, we believe that the POC definition of using USD as=20 > > > > > shared state is > > > > > not well defined and can lead to loss of synchronisation=20 > > > > > between the two > > > > > endpoints. > > > > >=20 > > > > > When you say it must be saved as 'local state', do you mean=20 > > > > > in the state > > > > > memory of the compressor at B or not in a compartment at all? > > > >=20 > > > > Not in a compartment at all (in A). However, in B it is up to=20 > > > > the endpoint if it saves in the state memory or not in the=20 > > > > compartment. > > > >=20 > > > > > >=20 > > > > > > > 5. (Little bit off-topic, PoC specific question):=20 > > In the PoC=20 > > > > > > > NEMS Signalling=20 > > > > > > > Spec. "Signalling flows (UNI) v2.06", a procedure for=20 > > > > > > > establishing a USD is=20 > > > > > > > described. Among others it states that the four first=20 > > > > > bytes of the=20 > > > > > > > state-value should be "usd1". Can any helpful individual=20 > > > > > > > explain to me what=20 > > > > > > > the purpose might be? Should either local or remote=20 > > > > > > endpoint take any=20 > > > > > > > specific action here? > > > > > > > The spec says: > > > > > > > "For USD identification it is important that the=20 > identifier=20 > > > > > > > string is placed=20 > > > > > > > in the beginning of the state_value of the USD, therefore=20 > > > > > > > special attention=20 > > > > > > > must be paid in the case of large USD as the UDVM has a=20 > > > > > > > circular buffer." > > > > > > > I do not understand the purpose here.. > > > > > >=20 > > > > > > Suppose Endpoint 2 supports USD (without the optional=20 > > > > > > requirement of moving it to the local state=20 > location) and the=20 > > > > > > explicit acknowledgement specified in RFC 3321, too. If=20 > > > > > > Endpoint 2 explicitlly acks the uploaded USD state ID,=20 > > > > > > Endpoint 1 will think USD is moved to the local states=20 > > > > > > location (indication is the same as if it was an explicit=20 > > > > > > ack) and will not update (decrease) its remote=20 > available SMS.=20 > > > > > > Later on it may result in decompression failure if=20 > a state is=20 > > > > > > saved deleting another one in use, due to the remote=20 > > > > > > available SMS out of synchron. > > > > > >=20 > > > > >=20 > > > > > I'm a bit confused here: > > > > >=20 > > > > > By 'moving it to the local state location' I take it that you=20 > > > > > mean that the > > > > > state created at Endpoint 2's decompressor would be moved to=20 > > > > > Endpoint 2's > > > > > compressor. Is this correct? Would it be duplicated (i.e.=20 > > > > > still exist in > > > > > the decompressor) or actually moved (and therefore the=20 > > > > > compressor at A has > > > > > no control over or knowledge of when it is deleted)? > > > > >=20 > > > > It is not duplicated. I meant it was moved to the=20 > > > > "non-compartment" state memory. It must be remembered somehow=20 > > > > (implementation stuff) that the state actually belongs to a=20 > > > > specific compartment, so when the compartment is deleted, the=20 > > > > USD must also be deleted. > > > >=20 > > > > > Are you saying that the presence of the string "usd1" is an=20 > > > > > indicator to > > > > > endpoint 2 that it should move/copy the state into the=20 > > compressor > > > > > compartment? > > > >=20 > > > > Besides the state is saved and advertised at the same time.=20 > > > > The reason why the usd tag was added is that this situation=20 > > > > might easily happen with a well-known bytecode. > > > >=20 > > > > >=20 > > > > > If so, this seems to be at odds with the SigComp conceptual=20 > > > > > model of state > > > > > that it is just 'some bytes'. =20 > > > > >=20 > > > >=20 > > > > Why do you say that? 'usd1' is not something that appears at=20 > > > > the beginning of a state, especially in a first message, and=20 > > > > especially not in a bytecode. > > > >=20 > > > > > If my understanding above is correct, then the piece of state=20 > > > > > presumably has > > > > > minimum retention priority? Care must once again be taken=20 > > > > due to the > > > > > possibility that the creation of multiple pieces of minimum=20 > > > > retention > > > > > priority state can lead to loss of synchronisation between=20 > > > > endpoints. > > > > >=20 > > > >=20 > > > > USD is just one state, which is absolutely in line with the=20 > > > > "one shared state at a time" concept. > > > >=20 > > > > > How does this mechanism interact with the use of shared mode=20 > > > > > as defined in > > > > > 3321? > > > > >=20 > > > >=20 > > > > Nothing special, as the shared state is not saved as a state=20 > > > > in B, only in A.=20 > > > >=20 > > > > > I also think there are some implications for=20 > > > > interoperability between > > > > > endpoints that do this and endpoints that don't. As you=20 > > > > > showed in your > > > > > example above, if there is disagreement between endpoints=20 > > > > > about whether or > > > > > not state is moved to 'local state location' (whatever that=20 > > > > > is) it can lead > > > > > to loss of synchronisation between endpoints. > > > > >=20 > > > > > Is this concept mandatory in PoC? If not, or if a non PoC=20 > > > > > endpoint receives > > > > > a state create request and an explicit advertisement, it will=20 > > > > > not know that > > > > > it should check the first 4 bytes for "usd1" and move=20 > > the state so > > > > > synchronisation will be lost as you explained. > > > >=20 > > > > As far as I know it is mandatory, but this I should check. > > > >=20 > > > > >=20 > > > > > Best regards, > > > > >=20 > > > > > Abbie > > > > >=20 > > > > > --=20 > > > > >=20 > > > > > Visit our website at www.roke.co.uk > > > > >=20 > > > > > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire=20 > > > SO51 0ZN, UK. > > > > >=20 > > > > > The information contained in this e-mail and any attachments=20 > > > > > is proprietary to > > > > > Roke Manor Research Ltd and must not be passed to any third=20 > > > > > party without > > > > > permission. This communication is for information only and=20 > > > > > shall not create or > > > > > change any contractual relationship. > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailman-bounces@ietf.org Mon May 2 11:24:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25966 for ; Mon, 2 May 2005 11:24:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSd0p-0005yk-JF for rohc-archive@ietf.org; Mon, 02 May 2005 11:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSWs3-0005am-2C for rohc-archive@ietf.org; Mon, 02 May 2005 05:05:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rohc-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 May 2005 05:06:12 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rohc-archive@ietf.org: List Password // URL ---- -------- rohc@ietf.org eczair https://www1.ietf.org/mailman/options/rohc/rohc-archive%40ietf.org From rohc-bounces@ietf.org Mon May 2 11:51:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27638 for ; Mon, 2 May 2005 11:51:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdQM-0006T9-0z for rohc-archive@ietf.org; Mon, 02 May 2005 12:05:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdBV-0007Yh-9y; Mon, 02 May 2005 11:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdBR-0007YZ-Mt for rohc@megatron.ietf.org; Mon, 02 May 2005 11:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27557 for ; Mon, 2 May 2005 11:50:07 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdP8-0006Rk-Ch for rohc@ietf.org; Mon, 02 May 2005 12:04:19 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j42Fo5Q07219; Mon, 2 May 2005 18:50:05 +0300 (EET DST) X-Scanned: Mon, 2 May 2005 18:49:58 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j42FnwHM023355; Mon, 2 May 2005 18:49:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00smwEGU; Mon, 02 May 2005 18:49:56 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j42FncM14777; Mon, 2 May 2005 18:49:39 +0300 (EET DST) Received: from agni.research.nokia.com ([172.21.50.36]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 2 May 2005 18:49:36 +0300 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.11/8.12.11) with ESMTP id j42Fnar1001878; Mon, 2 May 2005 18:49:36 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.11/8.12.11/Submit) id j42FnYZu001877; Mon, 2 May 2005 18:49:34 +0300 To: "Surtees, Abigail" Subject: Re: [rohc] SigComp torture tests X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5F38@rsys004a> (Abigail Surtees's message of "Fri, 22 Apr 2005 17:30:29 +0100") References: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5F38@rsys004a> Date: Mon, 02 May 2005 18:49:34 +0300 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 May 2005 15:49:36.0618 (UTC) FILETIME=[8AD434A0:01C54F2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Pekka Pessi , rohc@ietf.org, Herve Siegrist X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Hi Abbie, >Thanks for the extra corner cases on the state create test. They are >well worth testing (how long did it take you to find 2 pieces of state >that have the same first 6 bytes of hash? ;-) ). That was surpringly fast. I first hashed a million different states at 256, then started generating state2 at 266. I estimated it would take something like two days but I found first collision after 3 minutes. >I think there is also another useful test covered by the way you've >written the bytecode :-) > 7. Write the bytes of the identifier to the position specified >in the STATE-FREE instruction after the STATE-FREE instruction has been >run (and before END-MESSAGE). OK. >I have a few comments on the message listed as input (I think we might >not need quite so many) but am perfectly happy with the mnemonic and >bytecode. >> And the test messages: >> Compressed message: Number of state items: UDVM cycles: >> 0x00 0 13 >This one doesn't do anything - do we need it? Probably not. >> 0x0400 Decompression failure >Is there any reason why this is 0420 rather than 0405 which would test 1 >byte below the limit? No particular reason. Off-by-one might be more useful test. >> 0x0420 Decompression failure >Is there any reason why this is 0420 rather than 0415 which would test 1 >byte beyond the limit? Ditto. >> 0x0406 No 23 > change 'No' to '0' >> 0x09 1 34 >> 0x0a 0 25 >> 0x0b 1 35 >As with the previous version of the test, 0x0a and 0x0b *almost* but >don't quite (if you're being strict about it) cover point 3. 0x0a >recreates an existing piece of state before freeing it; 0x0b creates, >frees and recreates. However, 0x1e07 and 0x1e14 below both completely >cover point 3 so I'm not sure we need 0x0a and 0x0b. What do you think? Hm. Probably not needed. >> 0x1a 2 36 >> 0x1e06 2 46 >0x1e06 does pretty much the same as 0x1a (just with 2 attempts to free >the state). However, it does make a good comparison with 0x1e07 so >maybe we don't need 0x1a? OK. >> 0x1e07 0 47 >> 0x1e14 0 60 >> 0x1f14 1 70 >Similarly, 0x1f14 doesn't really show anything that isn't already shown >so I don't think we need it. What do you think? Nope. >None of these is a big deal, but given that the test can be covered by a >smaller number of test messages I don't see any point in over >complicating it. I usually let quantity to compensate for the quality when generating tests, but you have a point here. >> I took the UDVM cycle count from my notoriously reliable >> debugging output. Caveat emptor. >Our implementation agrees with your cycle counts :-) Excellent. At least, there are bug-compatible implementations... ;) --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 3 02:44:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04927 for ; Tue, 3 May 2005 02:44:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSrNA-00084B-5x for rohc-archive@ietf.org; Tue, 03 May 2005 02:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSr8n-0006UL-AS; Tue, 03 May 2005 02:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSr8l-0006UG-4F for rohc@megatron.ietf.org; Tue, 03 May 2005 02:44:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04903 for ; Tue, 3 May 2005 02:44:17 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSrMZ-00083k-KA for rohc@ietf.org; Tue, 03 May 2005 02:58:37 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j436i6Q0013739; Tue, 3 May 2005 08:44:15 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 08:41:31 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 08:41:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt Date: Tue, 3 May 2005 08:41:30 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2854@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt thread-index: AcVHJK1hWCNdzlNiSna1aGTGIH0uwwIhaIVw From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Aniruddha Kulkarni" , X-OriginalArrivalTime: 03 May 2005 06:41:31.0486 (UTC) FILETIME=[242D07E0:01C54FAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Aniruddha, Thanks for checking the document. Before I respond to all issues I agree with you on, I'd like to understand better what you mean with the following: > 4. section 6.1.2.1 , Will the addition of "The decompressor=20 > should not deliver the sequentially late (with respect to > the reference) non-updating packet to upper layer." handle > case for both updating and non-updating packets? Do you mean something is missing in 6.1.2.1? I do not understand the intention here. 6.1.2.1 only addresses updating packets, as it is about avoiding the "missing reference problem", which only concerns updating packets. Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 3 03:21:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07327 for ; Tue, 3 May 2005 03:21:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSrx5-0000HO-GZ for rohc-archive@ietf.org; Tue, 03 May 2005 03:36:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSrhi-0007ou-8B; Tue, 03 May 2005 03:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSrhg-0007op-Vu for rohc@megatron.ietf.org; Tue, 03 May 2005 03:20:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07247 for ; Tue, 3 May 2005 03:20:23 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSrvW-0000Fe-2k for rohc@ietf.org; Tue, 03 May 2005 03:34:43 -0400 Received: from [192.168.100.150] (internal.effnet.com [192.168.100.150] (may be forged)) by effnet.com (8.12.3/8.12.3) with ESMTP id j436JXmf001798; Tue, 3 May 2005 08:19:33 +0200 Message-ID: <42772627.1010900@effnet.com> Date: Tue, 03 May 2005 09:20:07 +0200 From: Aniruddha Kulkarni User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lars-Erik Jonsson (LU/EAB)" Subject: Re: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt References: <026F8EEDAD2C4342A993203088C1FC051C2854@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC051C2854@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Well, the section heading only says "Bi-directional Reliable Mode (R-mode)", so I suggested handling for both updating and non-updating packets to make it complete. ---Aniruddha Lars-Erik Jonsson (LU/EAB) wrote: >Aniruddha, > >Thanks for checking the document. Before I respond to all issues >I agree with you on, I'd like to understand better what you mean >with the following: > > > >>4. section 6.1.2.1 , Will the addition of "The decompressor >> should not deliver the sequentially late (with respect to >> the reference) non-updating packet to upper layer." handle >> case for both updating and non-updating packets? >> >> > >Do you mean something is missing in 6.1.2.1? I do not understand >the intention here. 6.1.2.1 only addresses updating packets, as >it is about avoiding the "missing reference problem", which only >concerns updating packets. > >Rgds, >/L-E > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 3 03:40:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08899 for ; Tue, 3 May 2005 03:40:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSsFH-0000fn-IE for rohc-archive@ietf.org; Tue, 03 May 2005 03:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSryv-0006a9-PU; Tue, 03 May 2005 03:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSryu-0006Zr-2b for rohc@megatron.ietf.org; Tue, 03 May 2005 03:38:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08635 for ; Tue, 3 May 2005 03:38:10 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSsCi-0000bQ-T9 for rohc@ietf.org; Tue, 03 May 2005 03:52:30 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j437bIhW022164; Tue, 3 May 2005 09:37:57 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 09:37:44 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 09:37:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt Date: Tue, 3 May 2005 09:37:43 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2855@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt thread-index: AcVPsIk6cq7isd4cRtKVZxz2sVw5zQAAdDgg From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Aniruddha Kulkarni" X-OriginalArrivalTime: 03 May 2005 07:37:44.0791 (UTC) FILETIME=[FED28670:01C54FB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Ok, then I see what you were aiming at. I'll look at this and see what I can come up with, along with the rest of your issues. Expect a summary of proposals for how to address both your=20 comments and Marks, I should be able to do this later on today or (not later than) tomorrow morning. Thanks! /L-E > -----Original Message----- > From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > Sent: den 3 maj 2005 09:20 > To: Lars-Erik Jonsson (LU/EAB) > Cc: rohc@ietf.org > Subject: Re: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt >=20 >=20 > Well, the section heading only says "Bi-directional Reliable Mode=20 > (R-mode)", so > I suggested handling for both updating and non-updating=20 > packets to make=20 > it complete. >=20 > ---Aniruddha >=20 > Lars-Erik Jonsson (LU/EAB) wrote: >=20 > >Aniruddha, > > > >Thanks for checking the document. Before I respond to all issues > >I agree with you on, I'd like to understand better what you mean > >with the following: > > > > =20 > > > >>4. section 6.1.2.1 , Will the addition of "The decompressor=20 > >> should not deliver the sequentially late (with respect to > >> the reference) non-updating packet to upper layer." handle > >> case for both updating and non-updating packets? > >> =20 > >> > > > >Do you mean something is missing in 6.1.2.1? I do not understand > >the intention here. 6.1.2.1 only addresses updating packets, as > >it is about avoiding the "missing reference problem", which only > >concerns updating packets. > > > >Rgds, > >/L-E > > =20 > > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 4 04:02:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02967 for ; Wed, 4 May 2005 04:02:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTF3m-0005kR-OO for rohc-archive@ietf.org; Wed, 04 May 2005 04:16:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTEnx-0005vI-1H; Wed, 04 May 2005 04:00:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTEnv-0005vA-0s for rohc@megatron.ietf.org; Wed, 04 May 2005 04:00:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02733 for ; Wed, 4 May 2005 04:00:21 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTF1x-0005g6-LT for rohc@ietf.org; Wed, 04 May 2005 04:14:54 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j44809g2003403; Wed, 4 May 2005 10:00:10 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 10:00:10 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 10:00:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt Date: Wed, 4 May 2005 10:00:09 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C285D@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt thread-index: AcVHJK1hWCNdzlNiSna1aGTGIH0uwwIqBjqQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Aniruddha Kulkarni" , X-OriginalArrivalTime: 04 May 2005 08:00:10.0553 (UTC) FILETIME=[4B5F4290:01C5507F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Aniruddha and others, Here are responses to your comments from the draft authors, expressed as suggestions for how to address them in the draft.=20 (Original comments from Aniruddha marked with %) Cheers, /L-E % 1. section 5.1.2.1 "The compressor removes values smaller than..." % this should be "...older than...". OLD:=20 The compressor always adds references in the sliding window for all < updating packets sent. The compressor removes values smaller than =20 NEW: The compressor always adds references in the sliding window for all > updating packets sent. The compressor removes values older than =20 % 2. section 5.2.1 "When using this encoding method, the decompressor=20 % discards...". This should be "..., the compressor discards..." % (refer 3095 section 4.5.4, para 4). We believe this text is actually correct, although it is not very well formulated. Anyway, see below how we intend to handle the timer- based issue. % I agree with others on the point that timer-based=20 % compression is not "functionally incompatible" with % reordering. It suffers in same way as scaled-timestamp % encoding would. Yes, we agree that as long as the expected jitter is properly estimated, timer-based compression requires no special reordering considerations. We suggest to remove timer-based from this section. OLD:=20 5.2.1. Functionality Incompatible with Reordering < There are some optional ROHC functions that cannot work in the presence of reordering between ROHC peers. The ROHC segmentation scheme (see [2], section 5.2.5) relies entirely on the in-order delivery of each segment, as there is no sequencing information in the segments. A segmented packet for which one (or more) segment is received out-of-order cannot be decompressed, and is discarded by the decompressor. Therefore segmentation should not be used if there can be reordering between the ROHC peers. < Timer-based compression of RTP TS (see [2], section 4.5.4) is built < on an assumption of timely (minimal jitter) delivery. When using this < encoding method, the decompressor discards packets arriving with an < arrival time that is outside the estimated upper bound for the < estimated jitter. Therefore it should be used with care over links < where reordering can occur, with respect to the amount of jitter that < can be introduced by reordering. < The use of these optional features is open to implementations and is local to the compressor only; it does not impact the decompressor. NEW: 5.2.1. Functionality Incompatible with Reordering > There is one optional ROHC function that cannot work in the presence of reordering between ROHC peers. The ROHC segmentation scheme (see [2], section 5.2.5) relies entirely on the in-order delivery of each segment, as there is no sequencing information in the segments. A segmented packet for which one (or more) segment is received out-of-order cannot be decompressed, and is discarded by the decompressor. Therefore segmentation should not be used if there can be reordering between the ROHC peers. > The use of this optional feature is open to implementations and is local to the compressor only; it does not impact the decompressor. We also suggest to add the following to the end of section 5.1.1. OLD: < NEW: > Timer-based compression of RTP TS (see [2], section 4.5.4) provides > means to reduce the number of timestamp bits needed in compressed > headers after longer gaps in the packet stream (typically due to > silence suppression). To use timer-based compression, an upper limit > on the inter-arrival jitter must be reliably estimated by the > compressor. It should be noted that although the risk of reordering > of course means there is a more significant jitter on the path=20 > between the compressor and the decompressor, there are no special > reordering considerations for timer-based compression. It all still > boils down to the task of estimating the jitter, requiring channel > characteristics knowledge at the compressor, and/or jitter estimation > figures received from the decompressor. % 3. section 6.1.1.2 , Avoiding the "missing reference" problem % If the decompressor implements the context updating logic of = section=20 % 6.1.2.1 and compressor is aware of that (by means of = standardization),=20 % why would it delay advance in sliding window? We agree that the current text is confusing and should be reformulated. However, after looking more carefully at your comment number 4 (see = below), we believe section 6.1.2.1 should actually be removed. This means we change 6.1.1.2 as follows: OLD: Avoiding the "missing reference" problem (section 5.1.2.1) A compressor implementation can delay the advance in the sliding window to a reference acknowledged by the decompressor, until it has confidence that no acknowledgement for any of the values that could be discarded can be received. This confidence can be based on the maximum delay that reordering can introduce over the < channel. It can also be based on the knowledge that the < decompressor implements the context updating logic of section < 6.1.2.1 (e.g. by means of standardization). NEW: Avoiding the "missing reference" problem (section 5.1.2.1) A compressor implementation can delay the advance in the sliding window to a reference acknowledged by the decompressor, until it has confidence that no acknowledgement for any of the values that could be discarded can be received. This confidence can be based on the maximum delay that reordering can introduce over the > channel.=20 % 4. section 6.1.2.1 , Will the addition of "The decompressor=20 % should not deliver the sequentially late (with respect to the % reference) non-updating packet to upper layer." handle case for % both updating and non-updating packets? The logic behind only discussing updating packets here was that when this was written we believed it should in most cases be possible to detect reordered updating packets only by using methods internally within ROHC. Reordering of non-updating packets would on the other hand for sure require external mechanisms. After looking a bit deeper into this, we tend to agree that there are no reliable ways to detect reordering, neither of updating nor non-updating packets, and therefore we suggest to remove section 6.1.2.1 altogether. OLD: < 6.1.2.1. Bi-directional Reliable Mode (R-mode) < < The "missing reference" problem described in section 5.1.2.1 can be < avoided. If the decompressor can detect when two updating packets < (packets including CRCs) are reordered with respect to each other, = it < should not update the context with the values of the sequentially < late update packet. NEW: > =20 % 5. section 6.1.2.2 "Note that if the decompressor does not make this=20 % adjustment to its feedback, packet losses or context damages will % not increase". % It is confusing, could it mean that "if decompressor does make the=20 % adjustment, packet losses/context damages will increase" or does % it mean "even if decompressor does not make the adjustment,=20 % losses/damages will not increase". Can it be made bit clear? Yes, it can, according to your latter interpretation: OLD: < Note that if the decompressor does not make this adjustment to its < feedback rate, packet losses or context damages will not increase. NEW: > Note that even if the decompressor does not make this adjustment > to its feedback rate, packet losses or context damages will not > increase. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 4 05:26:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10281 for ; Wed, 4 May 2005 05:26:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGNe-0007ly-Tx for rohc-archive@ietf.org; Wed, 04 May 2005 05:41:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTG81-00024h-E8; Wed, 04 May 2005 05:25:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTG7z-00024A-1h for rohc@megatron.ietf.org; Wed, 04 May 2005 05:25:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10088 for ; Wed, 4 May 2005 05:25:08 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGM1-0007hx-LY for rohc@ietf.org; Wed, 04 May 2005 05:39:43 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j449O7qP024873; Wed, 4 May 2005 10:24:07 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 4 May 2005 10:24:52 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A29AC@rsys004a> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , "Ghyslain Pelletier (LU/EAB)" , Kristofer Sandlund Subject: RE: [rohc] Proposed changes to rohc-tcp-09 Date: Wed, 4 May 2005 10:24:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi All, Just to clarify my opinion on this one: as far as I'm concerned, the box notation is an FN comment, and so is part of the FN description, just like any other useful comment - no problem there. I think the box notation is useful if it makes the FN easier to digest. My only concern is the maintenance/correctness issue with making sure the box notation accurately reflects what the FN says. I strongly agree with L-E that the box notation should be derived from the FN, definitely not the other way around! Regards Raffles > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: Friday, April 29, 2005 1:22 PM > To: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund > Cc: rohc@ietf.org > Subject: RE: [rohc] Proposed changes to rohc-tcp-09 > > > > Anyways... Over and out for me on this one - get consensus first. > > This is a little bit hard to judge, I think. You are the only one > opposing having the box notation in the profile along with the FN > formats, while Robert has said "agreed", and me and Kristofer are > the ones who want this to be there. > > If I was to see some kind of rough consensus in this, it would be > that only one person is opposing while more than one is asking for > it. However, I do not think I would like to conclude based on these > few and diverse opinions. > > /L-E > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 4 06:05:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13966 for ; Wed, 4 May 2005 06:05:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGz4-0000MB-E6 for rohc-archive@ietf.org; Wed, 04 May 2005 06:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGj9-00083A-FX; Wed, 04 May 2005 06:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGj8-000832-4W for rohc@megatron.ietf.org; Wed, 04 May 2005 06:03:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13831 for ; Wed, 4 May 2005 06:03:31 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGx9-0000Hn-51 for rohc@ietf.org; Wed, 04 May 2005 06:18:06 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j44A2oqP002318; Wed, 4 May 2005 11:02:50 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaled compression of fields in ROHC-FN. Date: Wed, 4 May 2005 11:03:25 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A29AD@rsys004a> Thread-Topic: [rohc] Expressing scaled compression of fields in ROHC-FN. Thread-Index: AcVGcflciw9M4iXiTu6rODNDmvC6BgKHIAEQ From: "Finking, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable Hi Kris, All, I've just thought of a really obvious solution to this that requires no change at all to the FN, and is really simple. But it must be wrong otherwise we'd have thought of it before. Why don't we just use a structure to split out the alternatives, like this: seq_num(payload_size) =3D=3D=3D { uc_format =3D seq_number; co_format_no_payload =3D { let(payload_size =3D=3D 0); let (seq_number_residue:uncomp_value =3D=3D seq_number:uncomp_value); let (seq_number_scaled:uncomp_value =3D=3D 0); }; co_format_with_payload =3D { let(payload_size !=3D 0); let(seq_number_residue:uncomp_value =3D=3D mod(seq_number:uncomp_value, payload_size)); let(seq_number:uncomp_value =3D=3D seq_number_scaled:uncomp_value * payload_size + seq_number_residue:uncomp_value); }; } Similarly for "ack", and then in the co_baseheader we have: control_fields =3D { seq_number ::=3D seq_num(payload); ack ::=3D ack_num(ack_stride); } Which requires no new syntax, and is scaleable. Please go ahead and point out the gaping hole in this suggestion, which must surely exist - it's so obvious that we'd have thought of it before otherwise! Comments please - we're almost there now! Cheers Raffles > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]=20 > Sent: Thursday, April 21, 2005 1:58 PM > To: rohc@ietf.org > Subject: [rohc] Expressing scaled compression of fields in ROHC-FN. >=20 >=20 > Hi all! >=20 > The main obstacle remaining in expressing the TCP packet=20 > formats in ROHC-FN=20 > seems to be the one related to the scaled sequence and ack=20 > numbers (previously=20 > discussed on the list a number of times regarding division by=20 > zero etc). >=20 > And for a packet with an unscaled sequence number (for=20 > example co_format_rnd_1),=20 > we would need to have some kind of if-statement so that we=20 > can say (because of=20 > the zero-division issue): > if (payload_size =3D=3D 0) > let (seq_number_residue:uncomp_value =3D=3D=20 > seq_number:uncomp_value); > let (seq_number_scaled:uncomp_value =3D=3D 0); > else > let (seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let (seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); >=20 >=20 > Currently, these expressions are placed in the control_fields=20 > of co_baseheader=20 > like this: >=20 > control_fields =3D > { > let (seq_number_scaled:uncomp_value =3D=3D > seq_number:uncomp_value / payload_size); > let (seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > }; >=20 > But, as anyone can see, the payload of zero will fail to bind=20 > for all packet=20 > formats with this. So, we thought about having two different=20 > control_field=20 > definitions like this: >=20 > control_fields_no_payload =3D > { > let(payload_size =3D=3D 0); > let (seq_number_residue:uncomp_value =3D=3D > seq_number:uncomp_value); >=20 > let (seq_number_scaled:uncomp_value =3D=3D 0); > }; >=20 > control_fields_with_payload =3D > { > let(payload_size !=3D 0); > let(seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let(seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); > }; >=20 > But, this approach does NOT scale. Since we have two fields=20 > to handle (seq/ack),=20 > then we're up to 4 control_fields definitions and one more=20 > field takes us to 8,=20 > so no, this is not going to scale in a way that makes FN usable. >=20 > Therefore, we need to be able to express if-statements in=20 > ROHC-FN. Yes, I know=20 > we've had this discussion multiple times before and gotten=20 > around it, but we=20 > can't just keep patching things when we all the time get back=20 > to the fact that=20 > if-statements will make this easier! I've discussed this with=20 > both Robert and=20 > Ghyslain offline, and we got no further than to=20 > if-statements. So, the syntax we=20 > would like to add is: >=20 > control_fields =3D > { > let(payload_size =3D=3D 0) > { > let (seq_number_residue:uncomp_value =3D=3D=20 > seq_number:uncomp_value); > let (seq_number_scaled:uncomp_value =3D=3D 0); > } > let(payload_size !=3D 0) > { > let(seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let(seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); > } >=20 > } >=20 > So that each let _can_ contain a block-statement and we can=20 > bind to one of these=20 > . If that wrecks havoc with the FN syntax, We just replace the=20 > "conditional let"=20 > with "if", which I guess would be reasonably easy to define. >=20 > Feedback, please. With this addition, I think we would be=20 > done with the FN draft=20 > and the TCP packet formats will be syntactically finished=20 > (even if the content=20 > can still be discussed). >=20 > BR, > Kristofer Sandlund, Effnet AB >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 4 10:00:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10291 for ; Wed, 4 May 2005 10:00:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKeF-0007Ow-SG for rohc-archive@ietf.org; Wed, 04 May 2005 10:14:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKNj-00066d-PA; Wed, 04 May 2005 09:57:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKNh-00066Y-QI for rohc@megatron.ietf.org; Wed, 04 May 2005 09:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10059 for ; Wed, 4 May 2005 09:57:39 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKbn-0007L9-Oy for rohc@ietf.org; Wed, 04 May 2005 10:12:16 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j44DuGn5010261; Wed, 4 May 2005 15:57:40 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 15:57:36 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 15:57:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Wed, 4 May 2005 15:57:35 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C286B@esealmw109.eemea.ericsson.se> Thread-Topic: Review of draft-ietf-rohc-over-reordering-02.txt thread-index: AcVGiVeNWc/HovWTSoyhGTfz/fJ9WgJSS4aw From: "Lars-Erik Jonsson \(LU/EAB\)" To: "West, Mark" , X-OriginalArrivalTime: 04 May 2005 13:57:35.0932 (UTC) FILETIME=[39D067C0:01C550B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Mark and others, Here are responses to your comments from the draft authors, expressed as suggestions for how to address them in the draft.=20 (Original comments from Mark marked with %) Cheers, /L-E % - External sequence numbers=20 % There is no discussion of how ROHC can be run over a re-ordering % channel when there is an external sequence number present (for % example when running over IPsec ESP). I accept that this % requires no modification at the compressor [other than the % knowledge that this is being done], but it would require % modification at the decompressor. It may be argued that=20 % this technique is 'out of scope' or merely 'trivial', but I'm % slightly surprised that it isn't even mentioned...=20 We agree that the scope could be made clearer, so we suggest to add the following paragraph to the end of the introduction. OLD: < NEW: > In some scenarios, there might be external means (such as a > sequence number) to detect and potentially correct reordering.=20 > That is for example the case when running compression over an > IPsec ESP tunnel. With such external means to detect reordering, > the decompressor can be modified to make use of the external > information provided, and reordering can then be handled. How > to make use of external means to address reordering is, however, > out of scope for this document. % - Discard or Decompress?=20 % Overall, I didn't see much discussion about whether the aim is to % (i) detect sequentially late packets and discard them; or % (ii) detect sequentially late packets and decompress them % correctly.=20 The goal in the long run is of course just to "decompress correctly", not necessarily even noticing reordering as anything special. In the short term, with only 3095 being available as compression standard, we will have to live with doing the best possible, probably a mixture of (i) and (ii). This document aims at discussing the various aspects of using ROHC over channels that can reorder packets, including=20 identifying the challenges, as well as suggesting both implementation methods and future standards improvements to better cope with reordering. However, this document is not aiming at specifying a solution, i.e. there is no single goal like your (i) or (ii). % 1. Introduction=20 % Asserts that, despite RFC 3095 stating to the contrary, ROHC's % inability to cope with re-ordering is a misconception. Section % 3.2 then points out profiles (including some defined in RFC % 3095) for which "reordered packets cannot be decompressed" % [without special considerations]. I guess it depends what your % definition of 'cope with' is, but I'm having a bit of % difficulty reconciling those two statements! The misconception is that ROHC handles reordering worse than other existing header compression schemes (just because it explicitly states it has been designed with an assumption about in-order delivery), and we believe that is what the text says. % 2. Terminology=20 % Cites RFC 2119 but, unless I've mis-grepped, conspicuously % fails to use any capitalised keywords (there are a bunch of % lower-case 'must's, 'should's, etc.; but these may just be red % herrings!) [Is this document actually intending to use % 'standards' language (should it?)]=20 Yes, it was our intention to use 2119 language if we formulated technical proposals to be incorporated in future ROHC profiles. However, we did not go that way but instead we just explained the technical concepts. The 2119 references should thus go away: OLD:=20 < However, the document discusses possible ways of modifying existing < ROHC implementations and/or specifications to address its objectives. < In those parts of the document, the key words "MUST", "MUST NOT", < "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", < "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as < described in RFC 2119 [1]. NEW: > =20 OLD: < [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. NEW: > % "Updating packet" -- IR/IR-DYN packets do not have a CRC computed % over the *uncompressed* packet? But are updating..? (almost just % a nit!)=20 OLD: < Updating packet < < A packet that updates the context of the decompressor, i.e. all < packets carrying a CRC calculated over the uncompressed header. < < Non-updating packet < < A packet that carries a CRC calculated over the uncompressed < header updates the context of the decompressor when it is < successfully decompressed. A packet without such a CRC is thus < referred to as a non-updating packet. NEW: > Updating packet > > A packet that updates the context of the decompressor, e.g. all > packets except R-0 and R-1* in RFC 3095 [2]. > > Non-updating packet > > A packet that does not update the context of the decompressor,=20 > e.g. only R-0 and R-1* in RFC 3095 [2]. % 5.2.1 Functionality Incompatible with Reordering=20 % Timer-based compression is quoted under "functionality incompatible % with reordering", but is (as stated correctly in the body of the % draft) just something that impacts the jitter (i.e. the impact is % already legislated for within RFC 3095) -- so I don't see why this % is necessarily 'incompatible'...=20 Agree, see previous mail with responses to Aniruddhas comments. % 6.1.1.1 Reordering and the Optimistic Approach=20 % Regarding increasing the number of repetitions of each context % update: Is this really necessary? What's the relationship between % loss and re-ordering? I haven't really thought this one through % fully, but I'm slightly suspicious...=20 There is no actual relationship between loss and reordering that specifically affects the optimistic approach, but reordering itself do influence the robustness of the optimistic approach, as discussed in 6.1.1.1. % 6.1.1.3 Robust Selection of Compressed Header=20 % I'm not completely convinced about the phase, "the interpretation % interval for the LSB encoded sequence number could be adjusted..." % I'd prefer something more explicit, such as, "packet formats could % be chosen with an interpretation interval for the LSB encoded % sequence number that..."=20 We agree: OLD: < The interpretation interval for the LSB encoded sequence number can < be adjusted to allow for larger negative offsets (see section 5.1.1). NEW: > Packet formats could be chosen with an interpretation interval for > the LSB encoded sequence number that allow for larger negative > offsets (see section 5.1.1). =20 % 6.1 "may however lower" -> "may, however, lower"=20 OLD: < The methods suggested here may however lower compression efficiency, and these modifications should not be used when reordering is known NEW: > The methods suggested here may, however, lower compression = efficiency, and these modifications should not be used when reordering is known =20 % 6.1.2.2 'effiency' -> 'efficiency'=20 OLD: packet types are used. This can be useful to minimize the usage of < the feedback channel, thereby improving effiency of the link. NEW: packet types are used. This can be useful to minimize the usage of > the feedback channel, thereby improving efficiency of the link. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 9 07:13:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28996 for ; Mon, 9 May 2005 07:13:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV6Ra-0003Le-I8 for rohc-archive@ietf.org; Mon, 09 May 2005 07:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV6BD-00024T-MQ; Mon, 09 May 2005 07:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV6BC-00024O-CS for rohc@megatron.ietf.org; Mon, 09 May 2005 07:12:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28910 for ; Mon, 9 May 2005 07:12:03 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV6QH-0003HF-86 for rohc@ietf.org; Mon, 09 May 2005 07:27:42 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j49BB5SS000409; Mon, 9 May 2005 13:12:03 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 13:11:24 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 13:11:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Expressing scaled compression of fields in ROHC-FN. Date: Mon, 9 May 2005 13:07:45 +0200 Message-ID: Thread-Topic: [rohc] Expressing scaled compression of fields in ROHC-FN. Thread-Index: AcVGcflciw9M4iXiTu6rODNDmvC6BgKHIAEQAP3tQyA= From: "Kristofer Sandlund \(LU/EAB\)" To: "Finking, Robert" , X-OriginalArrivalTime: 09 May 2005 11:11:24.0816 (UTC) FILETIME=[D6A19900:01C55487] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Hi Robert, it seems like your solution could work, but it looks a bit awkward to = me. The thing is that in the control_fields, we will bind "seq_number ::=3D = seq_num" structure, but in for example format co_format_rnd_1, we will bind "seq_number = ::=3D lsb".=20 For this format, both these bindings need to be performed, but will = there be any problem with FN overriding or cancelling out one of these bindings when both are = for the same field? If the FN itself is fine with this, I can accept this solution for = ROHC-TCP. /Kristofer Sandlund > -----Original Message----- > From: Finking, Robert [mailto:robert.finking@roke.co.uk] > Sent: den 4 maj 2005 12:03 > To: rohc@ietf.org > Cc: Kristofer Sandlund (LU/EAB) > Subject: RE: [rohc] Expressing scaled compression of fields=20 > in ROHC-FN. >=20 >=20 > Hi Kris, All, >=20 > I've just thought of a really obvious solution to this that=20 > requires no > change at all to the FN, and is really simple. But it must be wrong > otherwise we'd have thought of it before. >=20 > Why don't we just use a structure to split out the alternatives, like > this: >=20 > seq_num(payload_size) =3D=3D=3D > { > uc_format =3D seq_number; >=20 > co_format_no_payload =3D > { > let(payload_size =3D=3D 0); > let (seq_number_residue:uncomp_value =3D=3D > seq_number:uncomp_value); >=20 > let (seq_number_scaled:uncomp_value =3D=3D 0); > }; >=20 > co_format_with_payload =3D > { > let(payload_size !=3D 0); > let(seq_number_residue:uncomp_value =3D=3D > mod(seq_number:uncomp_value, payload_size)); > let(seq_number:uncomp_value =3D=3D > seq_number_scaled:uncomp_value * payload_size + > seq_number_residue:uncomp_value); > }; > } >=20 > Similarly for "ack", and then in the co_baseheader we have: >=20 > control_fields =3D > { > seq_number ::=3D seq_num(payload); > ack ::=3D ack_num(ack_stride); > } >=20 > Which requires no new syntax, and is scaleable. >=20 > Please go ahead and point out the gaping hole in this=20 > suggestion, which > must surely exist - it's so obvious that we'd have thought of=20 > it before > otherwise! >=20 > Comments please - we're almost there now! >=20 > Cheers >=20 > Raffles >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 9 08:56:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07779 for ; Mon, 9 May 2005 08:56:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV82v-00079c-0P for rohc-archive@ietf.org; Mon, 09 May 2005 09:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV7lp-00086t-Hu; Mon, 09 May 2005 08:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV7lj-00086f-Cx for rohc@megatron.ietf.org; Mon, 09 May 2005 08:53:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07713 for ; Mon, 9 May 2005 08:53:54 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV80p-00074n-6F for rohc@ietf.org; Mon, 09 May 2005 09:09:32 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j49CrXqP011486; Mon, 9 May 2005 13:53:33 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] Expressing scaled compression of fields in ROHC-FN. Date: Mon, 9 May 2005 13:54:24 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2A00@rsys004a> Thread-Topic: [rohc] Expressing scaled compression of fields in ROHC-FN. Thread-Index: AcVUiBEUBHPLDlA6Qra7SGOg27GaBAACI4GQ From: "Finking, Robert" To: "Kristofer Sandlund \(LU/EAB\)" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Hej Kris, Congratulations on making it through to the other side =3D) I really appreciate your response as I know you must have a lot on your plate with changing location. Answers inline Welcome back =3D) Regards Raffles > -----Original Message----- > From: Kristofer Sandlund (LU/EAB)=20 > [mailto:kristofer.sandlund@ericsson.com]=20 > Sent: Monday, May 09, 2005 12:08 PM > To: Finking, Robert; rohc@ietf.org > Subject: RE: [rohc] Expressing scaled compression of fields=20 > in ROHC-FN. >=20 >=20 > Hi Robert, >=20 > it seems like your solution could work, but it looks a bit=20 > awkward to me. >=20 > The thing is that in the control_fields, we will bind=20 > "seq_number ::=3D seq_num" structure, I guess the naming looks a bit awkward we might want to call it "seq_num_scaling" or something like that. > but in for example format co_format_rnd_1, we will bind=20 > "seq_number ::=3D lsb".=20 > For this format, both these bindings need to be performed,=20 > but will there be any problem > with FN overriding or cancelling out one of these bindings=20 > when both are for the same field? No, it will be fine. Both bindings will apply, just as they would if they were done directly in let-statements. >=20 > If the FN itself is fine with this, I can accept this=20 > solution for ROHC-TCP. Phew! I think we just resolved the last major issue!! >=20 > /Kristofer Sandlund >=20 > > -----Original Message----- > > From: Finking, Robert [mailto:robert.finking@roke.co.uk] > > Sent: den 4 maj 2005 12:03 > > To: rohc@ietf.org > > Cc: Kristofer Sandlund (LU/EAB) > > Subject: RE: [rohc] Expressing scaled compression of fields=20 > > in ROHC-FN. > >=20 > >=20 > > Hi Kris, All, > >=20 > > I've just thought of a really obvious solution to this that=20 > > requires no > > change at all to the FN, and is really simple. But it must be wrong > > otherwise we'd have thought of it before. > >=20 > > Why don't we just use a structure to split out the=20 > alternatives, like > > this: > >=20 > > seq_num(payload_size) =3D=3D=3D > > { > > uc_format =3D seq_number; > >=20 > > co_format_no_payload =3D > > { > > let(payload_size =3D=3D 0); > > let (seq_number_residue:uncomp_value =3D=3D > > seq_number:uncomp_value); > >=20 > > let (seq_number_scaled:uncomp_value =3D=3D 0); > > }; > >=20 > > co_format_with_payload =3D > > { > > let(payload_size !=3D 0); > > let(seq_number_residue:uncomp_value =3D=3D > > mod(seq_number:uncomp_value, payload_size)); > > let(seq_number:uncomp_value =3D=3D > > seq_number_scaled:uncomp_value * payload_size + > > seq_number_residue:uncomp_value); > > }; > > } > >=20 > > Similarly for "ack", and then in the co_baseheader we have: > >=20 > > control_fields =3D > > { > > seq_number ::=3D seq_num(payload); > > ack ::=3D ack_num(ack_stride); > > } > >=20 > > Which requires no new syntax, and is scaleable. > >=20 > > Please go ahead and point out the gaping hole in this=20 > > suggestion, which > > must surely exist - it's so obvious that we'd have thought of=20 > > it before > > otherwise! > >=20 > > Comments please - we're almost there now! > >=20 > > Cheers > >=20 > > Raffles > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 9 18:14:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18340 for ; Mon, 9 May 2005 18:14:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVGlv-0007Ml-8W for rohc-archive@ietf.org; Mon, 09 May 2005 18:30:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVGTp-0000Wd-En; Mon, 09 May 2005 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVGTn-0000WU-Jx for rohc@megatron.ietf.org; Mon, 09 May 2005 18:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17974 for ; Mon, 9 May 2005 18:11:57 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVGiy-0007Fu-0Z for rohc@ietf.org; Mon, 09 May 2005 18:27:41 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j49MBWqP012135; Mon, 9 May 2005 23:11:32 +0100 Received: from mjw-pc.roke.co.uk (mjw-pc.comm.ad.roke.co.uk [193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JF3JXDWD; Mon, 9 May 2005 23:12:23 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Mon, 9 May 2005 23:11:31 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8806C4187-100000@rsys004a> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVU5C0aQYGttH/qRlSKM2n+7XMYMw== From: "West, Mark" To: "Lars-Erik Jonsson \(LU/EAB\)" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1478654598==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 This is a multi-part message in MIME format. --===============1478654598== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C554E4.2CC03D80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C554E4.2CC03D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lars-Erik, Thanks for your suggested updates. I have a couple of follow-on = comments (for brevity, I've chopped out stuff where the update completely = addresses my comment)... Cheers, Mark. > > % - Discard or Decompress? > % Overall, I didn't see much discussion about whether the aim is to > % (i) detect sequentially late packets and discard them; or > % (ii) detect sequentially late packets and decompress them > % correctly. > > The goal in the long run is of course just to "decompress correctly", > not necessarily even noticing reordering as anything special. In the > short term, with only 3095 being available as compression standard, > we will have to live with doing the best possible, probably a mixture > of (i) and (ii). This document aims at discussing the various aspects > of using ROHC over channels that can reorder packets, including > identifying the challenges, as well as suggesting both implementation > methods and future standards improvements to better cope with > reordering. However, this document is not aiming at specifying a > solution, i.e. there is no single goal like your (i) or (ii). > Ok, that makes sense -- and maybe I should have been clear that my 'or' was not necessarily an 'exclusive or' :-) The fact remains, though, that if you are trying to correctly decompress re-ordered packets, there are more challenges than are described. Specifically, the full version of my comments argued that decompressing = a sequentially late packet during the update of a rarely-changing field = (for example) is problematic (for detection, in an R-mode scenario; and for correct decompression in U/O-mode). Unless I've missed something, then I do not see how the draft can be complete without some discussion of this? > > % 1. Introduction > % Asserts that, despite RFC 3095 stating to the contrary, ROHC's > % inability to cope with re-ordering is a misconception. Section > % 3.2 then points out profiles (including some defined in RFC > % 3095) for which "reordered packets cannot be decompressed" > % [without special considerations]. I guess it depends what your > % definition of 'cope with' is, but I'm having a bit of > % difficulty reconciling those two statements! > > The misconception is that ROHC handles reordering worse than > other existing header compression schemes (just because it > explicitly states it has been designed with an assumption > about in-order delivery), and we believe that is what the > text says. Fair enough. > > % 6.1.1.1 Reordering and the Optimistic Approach > % Regarding increasing the number of repetitions of each context > % update: Is this really necessary? What's the relationship between > % loss and re-ordering? I haven't really thought this one through > % fully, but I'm slightly suspicious... > > There is no actual relationship between loss and reordering that > specifically affects the optimistic approach, but reordering itself > do influence the robustness of the optimistic approach, as discussed > in 6.1.1.1. I think that I was struggling to find the rationale behind the text, = 'For example, the number of repetitions for each context update can be increased.' But I don't think that this is a big deal, as the section does, overall, make sense. I'm happy to leave it as it stands. ------_=_NextPart_001_01C554E4.2CC03D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt

Hi Lars-Erik,

Thanks for your suggested updates.  I have a = couple of follow-on comments
(for brevity, I've chopped out stuff where the update = completely addresses
my comment)...

Cheers,

Mark.


>
> % - Discard or Decompress?
> % Overall, I didn't see much discussion about = whether the aim is to
> % (i) detect sequentially late packets and = discard them; or
> % (ii) detect sequentially late packets and = decompress them
> % correctly.
>
> The goal in the long run is of course just to = "decompress correctly",
> not necessarily even noticing reordering as = anything special. In the
> short term, with only 3095 being available as = compression standard,
> we will have to live with doing the best = possible, probably a mixture
> of (i) and (ii). This document aims at = discussing the various aspects
> of using ROHC over channels that can reorder = packets, including
> identifying the challenges, as well as = suggesting both implementation
> methods and future standards improvements to = better cope with
> reordering. However, this document is not aiming = at specifying a
> solution, i.e. there is no single goal like your = (i) or (ii).
>

Ok, that makes sense -- and maybe I should have been = clear that my 'or'
was not necessarily an 'exclusive or' :-)

The fact remains, though, that if you are trying to = correctly decompress
re-ordered packets, there are more challenges than = are described.
Specifically, the full version of my comments argued = that decompressing a
sequentially late packet during the update of a = rarely-changing field (for
example) is problematic (for detection, in an R-mode = scenario; and for
correct decompression in U/O-mode).

Unless I've missed something, then I do not see how = the draft can be
complete without some discussion of this?

>
> % 1. Introduction
> % Asserts that, despite RFC 3095 stating to the = contrary, ROHC's
> % inability to cope with re-ordering is a = misconception. Section
> % 3.2 then points out profiles (including some = defined in RFC
> % 3095) for which "reordered packets cannot = be decompressed"
> % [without special considerations].  I = guess it depends what your
> % definition of 'cope with' is, but I'm having a = bit of
> % difficulty reconciling those two = statements!
>
> The misconception is that ROHC handles = reordering worse than
> other existing header compression schemes (just = because it
> explicitly states it has been designed with an = assumption
> about in-order delivery), and we believe that is = what the
> text says.

Fair enough.

>
> % 6.1.1.1 Reordering and the Optimistic = Approach
> % Regarding increasing the number of repetitions = of each context
> % update: Is this really necessary?  What's = the relationship between
> % loss and re-ordering?  I haven't really = thought this one through
> % fully, but I'm slightly suspicious...
>
> There is no actual relationship between loss and = reordering that
> specifically affects the optimistic approach, = but reordering itself
> do influence the robustness of the optimistic = approach, as discussed
> in 6.1.1.1.

I think that I was struggling to find the rationale = behind the text, 'For
example, the number of repetitions for each context = update can be
increased.'  But I don't think that this is a = big deal, as the section
does, overall, make sense.  I'm happy to leave = it as it stands.

------_=_NextPart_001_01C554E4.2CC03D80-- --===============1478654598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1478654598==-- From rohc-bounces@ietf.org Tue May 10 04:31:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27885 for ; Tue, 10 May 2005 04:31:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVQOH-0006ME-Da for rohc-archive@ietf.org; Tue, 10 May 2005 04:46:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVQ3s-0000zN-D9; Tue, 10 May 2005 04:25:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVQ3q-0000zI-Mv for rohc@megatron.ietf.org; Tue, 10 May 2005 04:25:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27542 for ; Tue, 10 May 2005 04:25:48 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVQJ4-000640-Nv for rohc@ietf.org; Tue, 10 May 2005 04:41:38 -0400 Received: from [192.168.100.150] (internal.effnet.com [192.168.100.150] (may be forged)) by effnet.com (8.12.3/8.12.3) with ESMTP id j4A7Oumf029889; Tue, 10 May 2005 09:24:56 +0200 Message-ID: <42806FFA.4080206@effnet.com> Date: Tue, 10 May 2005 10:25:30 +0200 From: Aniruddha Kulkarni User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lars-Erik Jonsson (LU/EAB)" Subject: Re: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt References: <026F8EEDAD2C4342A993203088C1FC051C285D@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC051C285D@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Hi Lars-Erik, Your suggested updates address my comments. I am wondering if there is no reliable way to detect reordering then are the last para in section 6.1.2.2 and section 6.1.2.3 still relavent? ---Aniruddha Lars-Erik Jonsson (LU/EAB) wrote: >Aniruddha and others, > >Here are responses to your comments from the draft authors, expressed >as suggestions for how to address them in the draft. > >(Original comments from Aniruddha marked with %) > >Cheers, >/L-E > > > >% 4. section 6.1.2.1 , Will the addition of "The decompressor >% should not deliver the sequentially late (with respect to the >% reference) non-updating packet to upper layer." handle case for >% both updating and non-updating packets? > >The logic behind only discussing updating packets here was that when >this was written we believed it should in most cases be possible to >detect reordered updating packets only by using methods internally >within ROHC. Reordering of non-updating packets would on the other >hand for sure require external mechanisms. After looking a bit deeper >into this, we tend to agree that there are no reliable ways to detect >reordering, neither of updating nor non-updating packets, and therefore >we suggest to remove section 6.1.2.1 altogether. > >OLD: >< 6.1.2.1. Bi-directional Reliable Mode (R-mode) >< >< The "missing reference" problem described in section 5.1.2.1 can be >< avoided. If the decompressor can detect when two updating packets >< (packets including CRCs) are reordered with respect to each other, it >< should not update the context with the values of the sequentially >< late update packet. > >NEW: > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 10 06:03:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03688 for ; Tue, 10 May 2005 06:03:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVRpp-0002Oz-Oh for rohc-archive@ietf.org; Tue, 10 May 2005 06:19:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVRZl-0006hG-Uj; Tue, 10 May 2005 06:02:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVRZl-0006hB-2l for rohc@megatron.ietf.org; Tue, 10 May 2005 06:02:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03526 for ; Tue, 10 May 2005 06:02:50 -0400 (EDT) Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=NAV2.lgdomain.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVRp0-0002HH-Pe for rohc@ietf.org; Tue, 10 May 2005 06:18:41 -0400 Received: from appolo.lgdomain.com ([192.168.1.21]) by NAV2.lgdomain.com with InterScan Messaging Security Suite; Tue, 10 May 2005 13:01:08 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] SigComp - is the bytecode representation unique? Date: Tue, 10 May 2005 13:01:27 +0530 Message-ID: Thread-Topic: [rohc] SigComp - is the bytecode representation unique? Thread-Index: AcVJiezwTuNZ9eqqTuOJrLD0hAPw8wLp2+lQ From: "Chintan Shah" To: "Cristian CONSTANTIN" , X-Spam-Score: 1.3 (+) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213107717==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 This is a multi-part message in MIME format. --===============1213107717== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55532.477BA1AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55532.477BA1AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cristian, One basic rule of compression: Try to get minimum number of bytes as part of compression. Using all the three rules, you will get the same value. It's ideal to generate Byte-code, which has minimum number of bytes. Why to go for 3 bytes, when you can retrieve the same information from 1 byte. 2nd & 3rd rule are helpful to fetch data, which does not fit under Rule 1. Sorry 4 late reply ! Cheers, Chintan --------------------------------------------------------------- Chintan Shah LG Soft India 7th Floor | Embassy Icon | Infantry Rd | Bangalore-17 M: (+91) 94487 60715 =0D "Start by doing what is necessary, then what is possible, and suddenly you are doing the impossible" -St. Francis of Assisi ---------------------------------------------------------------- Add me = to your address book... -----Original Message----- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On Behalf Of Cristian CONSTANTIN Sent: Monday, April 25, 2005 4:51 PM To: rohc@ietf.org Subject: [rohc] SigComp - is the bytecode representation unique? hi! suppose you're using the assembly language for UDVM defined in draft-ietf-rohc-sigcomp-user-guide-01.txt and write a udvm program; then you translate it into bytecode. is the result of this translation unique or are there _several possible_ (correct) representations in bytecode for _the same_ assembly program? if I refer to "Figure 10: Bytecode for a multitype (%) operand" in the SigComp RFC then, the value %0, for example, can be represented like: 0x00 on one byte, when using the first rule 0xA000 on two bytes, when using the seventh rule 0x800000 on three bytes, when using the eighth rule are all these representations correct? thanks in advance for your answer. bye now! cristian -- _ | There are many people who use UNIX or Linux=0D (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn=0D GPG public key at wwwkeys.de.pgp.net ************************************************************************ This Email Message is for the sole use of the intended recipient(s) and May= contain CONFIDENTIAL and PRIVILEGED information. LG Soft India will not be responisible for any viruses or defects or any= forwarded attachements emanating either from within LG Soft India or outside. Any unauthorised review , use, disclosure or= distribution is prohibited. If you are not intentded recipient, please contact the sender by reply email and destroy all copies= of the original message. ------_=_NextPart_001_01C55532.477BA1AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cristian,

One basic rule of= compression:=0D Try to get minimum number of bytes as part of compression. Using all the= three=0D rules, you will get the same value. It's ideal to generate Byte-code, which= has=0D minimum number of bytes. Why to go for 3 bytes, when you can retrieve the= same=0D information from 1 byte. 2nd & 3rd rule are helpful to fetch data,= which=0D does not fit under Rule 1.

Sorry 4 late reply= !

Cheers,
Chintan

---------------------------------------------------------------Chintan Shah

LG Soft India
7th Floor | Embassy Icon |= Infantry=0D Rd | Bangalore-17
M: (+91)  94487=0D 60715
 
"Start by doing what= is=0D necessary,
then what is possible,= =0D and
suddenly you are doing= the=0D impossible"
           =             &nb= sp;            =             &nb= sp;  =0D -St. Francis of Assisi
----------------------------------------------------------------
Add=0D me to your= address=0D book...

-----Original Message-----
From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On= Behalf=0D Of Cristian CONSTANTIN
Sent: Monday, April 25, 2005 4:51 PM
To:=0D rohc@ietf.org
Subject: [rohc] SigComp - is the bytecode representation=0D unique?

hi!

suppose you're using the assembly language for= UDVM=0D defined in
draft-ietf-rohc-sigcomp-user-guide-01.txt and write a udvm=0D program;
then you translate it into bytecode. is the result of this=0D translation
unique or are there _several possible_ (correct)= representations=0D in bytecode
for _the same_ assembly program?

if I refer to= "Figure 10:=0D Bytecode for a multitype (%) operand" in the
SigComp RFC then, the value= %0,=0D for example, can be represented like:

0x00    = on one=0D byte, when using the first rule
0xA000   on two bytes, when= using=0D the seventh rule
0x800000 on three bytes, when using the eighth=0D rule

are all these representations correct?
thanks in advance for= your=0D answer.
bye=0D now!
cristian
--
 _       =   =0D | There are many people who use UNIX or=0D Linux 
(_'_        | who IMHO do= not=0D understand UNIX.
  (_'rist  =0D |            &n= bsp;=0D --David Korn 
GPG public key at=0D wwwkeys.de.pgp.net

****************************************************************= ********

This Email Message is for the sole use of the intended recipient(s) and May= contain CONFIDENTIAL and PRIVILEGED information.
LG Soft India will not be responisible for any viruses or defects or any= forwarded attachements emanating either from within
LG Soft India or outside. Any unauthorised review , use, disclosure or= distribution is prohibited. If you are not intentded
recipient, please contact the sender by reply email and destroy all copies= of the original message.
------_=_NextPart_001_01C55532.477BA1AD-- --===============1213107717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1213107717==-- From rohc-bounces@ietf.org Tue May 10 07:54:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18001 for ; Tue, 10 May 2005 07:54:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVTZD-0001ym-6P for rohc-archive@ietf.org; Tue, 10 May 2005 08:10:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTBv-0006hl-CF; Tue, 10 May 2005 07:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTBt-0006hb-CZ for rohc@megatron.ietf.org; Tue, 10 May 2005 07:46:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17373 for ; Tue, 10 May 2005 07:46:20 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVTR9-0001Nm-9y for rohc@ietf.org; Tue, 10 May 2005 08:02:10 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4ABk7h5010907; Tue, 10 May 2005 13:46:07 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 13:46:06 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 13:46:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt Date: Tue, 10 May 2005 13:46:06 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2879@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVVOdiTpFjHPp/zSx60YNN5gZkAaAAF+AMw From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Aniruddha Kulkarni" X-OriginalArrivalTime: 10 May 2005 11:46:06.0555 (UTC) FILETIME=[D9DB82B0:01C55555] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable > Your suggested updates address my comments. I am=20 > wondering; if there is no reliable way to detect > reordering, then are the last para in section=20 > 6.1.2.2 and section 6.1.2.3 still relavent? Yes, I believe they are. 6.1.2.3 only says "if reordering can be the cause", i.e. I read it as "if the decompressor knows this channel may cause reordering and decompression fails, an additional local repair may be attempted". For the last paragraph of 6.1.2.2, I suggest the following minor re-write.=20 OLD: Acknowledgements and sequentially late packets Reordered feedback (or feedback for packets received out-of-order) will not cause problems (see section 5.1.4). However, the < decompressor should not send feedback for sequentially late < packets, as the current state of the context will better reflect the compressor context than the content of the reordered packet. NEW: Acknowledgements and sequentially late packets Reordered feedback (or feedback for packets received out-of-order) will not cause problems (see section 5.1.4). However, the > decompressor should not send acknowledging feedback for a packet > if it is reasonable to believe it is sequentially late (e.g. by > just looking at the sequence number of the packet), as the current state of the context will better reflect the compressor context than the content of the reordered packet. Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 10 07:58:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18342 for ; Tue, 10 May 2005 07:58:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVTcn-0002FS-1j for rohc-archive@ietf.org; Tue, 10 May 2005 08:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTDs-0006km-02; Tue, 10 May 2005 07:48:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTDq-0006kg-RQ for rohc@megatron.ietf.org; Tue, 10 May 2005 07:48:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17477 for ; Tue, 10 May 2005 07:48:21 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVTT9-0001QH-Lx for rohc@ietf.org; Tue, 10 May 2005 08:04:12 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4ABlRim020936; Tue, 10 May 2005 13:48:20 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 13:45:02 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 13:45:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Tue, 10 May 2005 13:45:01 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2878@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVU5C0aQYGttH/qRlSKM2n+7XMYMwAV5trw From: "Lars-Erik Jonsson \(LU/EAB\)" To: "West, Mark" X-OriginalArrivalTime: 10 May 2005 11:45:01.0799 (UTC) FILETIME=[B3428770:01C55555] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Mark, Thanks for being insistent, I believe you have a point here. After = reading the draft text again and discussing this with Kristofer, our conclusion = is that what we believe is missing is more text in section 5.1.3, which should discuss both "Reordering between non-change packets only" and "Reordering involving change packets". The current text in 5.1.3 actually only covers the former. So, our=20 proposal is to make the following changes to section 5.1.3: OLD: 5.1.3. Reordering of Packets in U/O-mode =20 < Sequentially late packets <=20 < The ability to decompress sequentially late packets is limited = by < the offset p of the interpretation interval (see section = 5.1.1). Decompression of a sequentially late packet with SN =3D x is possible if the value of the SN of the packet that last updated the context was less than or equal to x + p. =20 Problems occur if context(SN) has increased by more than p with respect to field(SN) carried within the packet to decompress. =20 This means that for a well-behaved stream with a constant unit increase in the RTP SN, a packet can arrive up to p packets out = of sequence and still be correctly decompressed. Otherwise, it = cannot be properly decompressed. It also means that if the compressor sends two consecutive packets with SN(packet1)=3D100 and SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed if = it arrives even one packet late due to reordering. =20 Decompression can always be verified since all U/O-mode packet = types < are context updating. Consequently, reordering of packets is not < deemed problematic when operating in U/O-mode. For channels known = to < reorder packets, the U/O-mode should therefore be the preferred = mode of operation. The additional risk of losing context = synchronization, or for erroneous packet to be delivered to upper layers, is = limited. NEW: 5.1.3. Reordering of Packets in U/O-mode =20 > Reordering between non-change packets only > > When there is reordering of non-change packets only, the = ability > to decompress sequentially late packets is simply limited by = the > offset p of the interpretation interval (see section 5.1.1). Decompression of a sequentially late packet with SN =3D x is possible if the value of the SN of the packet that last updated the context was less than or equal to x + p. =20 Problems occur if context(SN) has increased by more than p with respect to field(SN) carried within the packet to decompress. =20 This means that for a well-behaved stream with a constant unit increase in the RTP SN, a packet can arrive up to p packets out = of sequence and still be correctly decompressed. Otherwise, it = cannot be properly decompressed. It also means that if the compressor sends two consecutive packets with SN(packet1)=3D100 and SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed if = it arrives even one packet late due to reordering. > Reordering involving change packets > > When a packet is reordered and becomes sequentially late with > respect to a change packet, decompression of the late packet = may > eventually fail, as the context information required for > successful decompression may not be available anymore. Decompression can always be verified since all U/O-mode packet = types > are context updating. Consequently, even if reordering of packets > may in some cases result in unsuccessful decompression, context > invalidation due to reordering can be avoided or detected. The = risk > of forwarding incorrectly decompressed packets to upper layers is > therefore small when operating in U/O-mode. For channels known to > reorder packets, U/O-mode should therefore be the preferred mode = of operation. The additional risk of losing context synchronization, or for erroneous packet to be delivered to upper layers, is = limited. Does this capture what you were missing from the draft? /L-E -----Original Message----- From: West, Mark [mailto:mark.a.west@roke.co.uk] Sent: den 10 maj 2005 00:12 To: Lars-Erik Jonsson (LU/EAB) Cc: rohc@ietf.org Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Hi Lars-Erik,=20 Thanks for your suggested updates. I have a couple of follow-on = comments=20 (for brevity, I've chopped out stuff where the update completely = addresses=20 my comment)...=20 Cheers,=20 Mark.=20 >=20 > % - Discard or Decompress?=20 > % Overall, I didn't see much discussion about whether the aim is to=20 > % (i) detect sequentially late packets and discard them; or=20 > % (ii) detect sequentially late packets and decompress them=20 > % correctly.=20 >=20 > The goal in the long run is of course just to "decompress correctly",=20 > not necessarily even noticing reordering as anything special. In the=20 > short term, with only 3095 being available as compression standard,=20 > we will have to live with doing the best possible, probably a mixture=20 > of (i) and (ii). This document aims at discussing the various aspects=20 > of using ROHC over channels that can reorder packets, including=20 > identifying the challenges, as well as suggesting both implementation=20 > methods and future standards improvements to better cope with=20 > reordering. However, this document is not aiming at specifying a=20 > solution, i.e. there is no single goal like your (i) or (ii).=20 >=20 Ok, that makes sense -- and maybe I should have been clear that my 'or'=20 was not necessarily an 'exclusive or' :-)=20 The fact remains, though, that if you are trying to correctly decompress = re-ordered packets, there are more challenges than are described.=20 Specifically, the full version of my comments argued that decompressing = a=20 sequentially late packet during the update of a rarely-changing field = (for=20 example) is problematic (for detection, in an R-mode scenario; and for=20 correct decompression in U/O-mode).=20 Unless I've missed something, then I do not see how the draft can be=20 complete without some discussion of this?=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed May 11 09:40:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03975 for ; Wed, 11 May 2005 09:40:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVrhI-0007hS-2b for rohc-archive@ietf.org; Wed, 11 May 2005 09:56:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrOk-0003KK-37; Wed, 11 May 2005 09:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrOh-0003Jn-IP; Wed, 11 May 2005 09:37:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03839; Wed, 11 May 2005 09:37:09 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVreD-0007YT-SK; Wed, 11 May 2005 09:53:14 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4BDZVmR022657; Wed, 11 May 2005 15:37:05 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 15:37:01 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 15:37:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt Date: Wed, 11 May 2005 15:37:00 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C288B@esealmw109.eemea.ericsson.se> Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt Thread-Index: AcVGsK+ZB2HmnyVzRdmKlM478mx93gAB+qAAAAFCAXAAACNPsAAABc3AA9m5cPA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ash, Gerald R \(Jerry\), ALABS" , , X-OriginalArrivalTime: 11 May 2005 13:37:00.0813 (UTC) FILETIME=[828473D0:01C5562E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Jerry and others, First of all, I must say you've done a great job with this update. The technical solution is starting to get in shape, and so also the draft itself. I just have a few issues that I believe should be given some additional attention, and I'll start with the least technical one: * References =20 - There is one incorrect reference to RFC 3409, which I think has not much to do with this document. The correct document to refer to is RFC 3241, "Robust Header Compression (ROHC) over PPP". - There is one invalid reference [IPCP], I guess it should be [RFC1332] - As it is currently written, I believe [RFC3544] and [RFC3241] would be normative for this document. I believe some other references, e.g. some MPLS references, would also be normative. - There are many informative references, go through them and make sure they all are actually bringing any value as informative to this document (I am not sure about the MPLS references). It might also make sense to group them based on content (HD vs MPLS, etc), that would make it easier for the reader. * Separation of functionality As previously discussed, I believe it would be useful to more clearly separate negotiation/setup/signalling from encapsulation. As it now stands, I am not sure I understand what purpose the separation of chapter 2 and chapter 3 serves. Chapter 2 is about both setup and encapsulation, while chapter 3 is about setup only. * Requirements fulfilment In chapter 1, it is said that the outlined solution fulfils the requirements of [MPLS-HC-REQ]. I am not sure this listing is really needed, neither do I think it is fully correct. a) is true, that is a design decision for this document b) is also true, ok, it is the whole purpose of the document c) is not really achieved by this document, but depends on the header compression scheme used, and especially on how that scheme is implemented. This document can not guarantee anything in this regard, but it provides what it can to make this possible. What this document do indeed provide, is the mechanism to avoid multiple compression/decompression cycles, but that is b) above. d) "signal context identification", I do not know what is meant with that, neither do I know what standard protocols are referred to, is it the MPLS PW mechanisms that are meant, and/or the HC-over-PPP specifications (for the latter, see also below). e) this is implementation dependent on HC-protocol level, and it is out of control of this specification, which is dependent on the HC scheme implementation(s). Or do PW provide means for=20 in-order delivery? Overall, I do not see the point of listing these things here. I think it is sufficient to say that the solution(s) outlined in this document have been designed and chosen to address the goals and requirements of [MPLS-HC-REQ]. * "Flow Setup", end of chapter 2 introduction - Is this really only about "setup"? It does not look so to me. - I believe this can be generalized so that it is HC-scheme independent, should not be hard to do. - It is not clear whether 2) is mandatory or not, i.e. is it mandatory to have a bidirectional connection? * "Flow setup", last bullet, "Free up CID when flow terminates" - How can one ever know that a flow has terminated? For UDP-based "flows", there is no such thing. Also, why should one free CIDs, I agree CIDs should be re-usable, but if memory is allocated for a certain number of CIDs, that memory should last as long as the HC instance(s) is(are) alive. It is the compressor that may choose to re-use a CID. This has been thoroughly discussed in the ROHC WG, captured in chapter 7 of . * Link layer packet type field The requirement that link layers must provide packet type identification for HC packets does not apply to ROHC. Therefore I believe it is an improper design to require the extra multiplexing byte (Pkt Typ field) for all schemes. There is a negotiation of HC scheme done for the "channel", so why not say that for schemes that can not identify their own packet types, the extra byte is needed, as described. Or actually negotiate whether to have this byte, independent of HC scheme (although some require it). * I think it makes sense to re-use the principles of RFC 3544 and RFC 3241, but I also think this document will actually have to define more specifically how the negotiation is done (with similar principles as in 3544 and 3241). Both RFC 3544 and RFC 3241 are written as plug-ins to the PPP control protocol IPCP, so just referring to them here where there is no PPP or IPCP does not convince me about the completeness of the solution.=20 Rgds, /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Ash, Gerald R (Jerry), ALABS > Sent: den 22 april 2005 00:06 > To: rohc@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: [rohc] RE: I-D > ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt >=20 >=20 > Hi All, >=20 > Please review and comment on the (significantly) updated=20 > draft "Protocol > Extensions for Header Compression over MPLS" > (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpl > s-protocol > -00.txt). >=20 > Here is a brief background and overview/explanation of the updates: >=20 > Work on requirements for header compression over MPLS > (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-mpls-re > qs-03.txt) > is complete, and work on protocol extensions for header=20 > compression over > MPLS is underway (previous draft at > http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls- > protocol-0 > 2.txt). Chartering of the protocol work in the AVT working group has > been submitted for approval with the following milestone: >=20 > Dec 05: Submit any extensions for RTP HC on MPLS networks for Proposed > Standard >=20 > There has been considerable discussion on the previous protocol > extensions draft > (http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls > -protocol- > 02.txt) in the last couple of months. I presented the update on the > header compression over MPLS protocol extensions work at the=20 > AVT meeting > at IETF-62; slides and minutes are available at > https://datatracker.ietf.org/public/proceeding_interim.cgi?mee > ting_num=3D6 > 2 (look under AVT for minutes and slides). The recent discussion and > issues regarding the basic approach are summarized in the slides. >=20 > Header compression experts in the AVT and ROHC working groups wish to > re-use, and extend, the existing layer 2 approaches for assignment of > context identification (CID) and header compression parameter > negotiation. In a multipoint-to-point MPLS environment, one approach > would be to have the various header compressors assign CIDs as they do > now, with the possible need to resolve CID conflicts/collisions at the > header decompressor. Some comments were made that current header > compression methods do not have to resolve CID collisions, however the > synchronization source (SSRC) assigned in RTP could need > collision/conflict resolution. >=20 > A second approach, suggested by Andy Malis and Loa Andersson,=20 > is to use > pseudowires and/or targeted LDP to create 'point-to-point' sessions > between header compressor and header decompressor, thereby=20 > avoiding any > issue of CID collision. The disadvantage of this approach is that it > requires an additional 4-byte label to be carried with each packet. =20 >=20 > The updated draft based on the second approach is available at > http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls > -protocol- > 00.txt. >=20 > Once again, please review and comment on the updated draft. >=20 > Thanks, > Jerry _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu May 12 09:01:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21191 for ; Thu, 12 May 2005 09:01:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWDZp-0000sY-HM for rohc-archive@ietf.org; Thu, 12 May 2005 09:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWDGm-0007od-DR; Thu, 12 May 2005 08:58:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWDGj-0007oY-O9 for rohc@megatron.ietf.org; Thu, 12 May 2005 08:58:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21077 for ; Thu, 12 May 2005 08:58:24 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWDWS-0000oR-6l for rohc@ietf.org; Thu, 12 May 2005 09:14:41 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4CCwJh5000261; Thu, 12 May 2005 14:58:19 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 14:58:19 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 14:58:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Thu, 12 May 2005 14:58:19 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DB36@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVU5C0aQYGttH/qRlSKM2n+7XMYMwAV5trwAGzZaZA= From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , "West, Mark" X-OriginalArrivalTime: 12 May 2005 12:58:19.0525 (UTC) FILETIME=[4555C350:01C556F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Some quick picky nits on the proposed text. BR, /Ghyslain >=20 > NEW: > 5.1.3. Reordering of Packets in U/O-mode > =20 > > Reordering between non-change packets only > > > > When there is reordering of non-change packets only, the = ability > > to decompress sequentially late packets is simply limited by = the > > offset p of the interpretation interval (see section 5.1.1). Suggestion: " When only non-change packets are reordered with respect to each other, decompression of sequentially late packets is limited by the offset p of the interpretation interval (see section 5.1.1)." Because reordering of non-change packet may actually be interpreted as = with respect to any other event or packet type, despite the usage of the = word only. I actually tripped on that sentence... > Decompression of a sequentially late packet with SN =3D x is > possible if the value of the SN of the packet that last = updated > the context was less than or equal to x + p. > =20 > Problems occur if context(SN) has increased by more than p = with > respect to field(SN) carried within the packet to decompress. > =20 > This means that for a well-behaved stream with a constant = unit > increase in the RTP SN, a packet can arrive up to p packets = out of > sequence and still be correctly decompressed. Otherwise, it = cannot > be properly decompressed. It also means that if the = compressor > sends two consecutive packets with SN(packet1)=3D100 and > SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed = if it > arrives even one packet late due to reordering. >=20 > > Reordering involving change packets > > > > When a packet is reordered and becomes sequentially late with > > respect to a change packet, decompression of the late packet = may > > eventually fail, as the context information required for > > successful decompression may not be available anymore. >=20 > Decompression can always be verified since all U/O-mode packet = types > > are context updating. Consequently, even if reordering of = packets > > may in some cases result in unsuccessful decompression, context > > invalidation due to reordering can be avoided or detected. The = risk Suggestion: " Consequently, a failure to decompress a packet that is caused by reordering can be detected, and context invalidation due to reordering can thus be avoided." Because both "avoidance" and "detection" are applied to context = invalidation in the proposed text, while in fact "detection" applies to = the decompression failure and "avoidance" applies to context = invalidatation. > > of forwarding incorrectly decompressed packets to upper layers = is > > therefore small when operating in U/O-mode. For channels known = to > > reorder packets, U/O-mode should therefore be the preferred mode = of > operation. The additional risk of losing context = synchronization, > or for erroneous packet to be delivered to upper layers, is = limited. >=20 >=20 > Does this capture what you were missing from the draft? > /L-E >=20 >=20 > -----Original Message----- > From: West, Mark [mailto:mark.a.west@roke.co.uk] > Sent: den 10 maj 2005 00:12 > To: Lars-Erik Jonsson (LU/EAB) > Cc: rohc@ietf.org > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt >=20 >=20 > Hi Lars-Erik,=20 > Thanks for your suggested updates. I have a couple of=20 > follow-on comments=20 > (for brevity, I've chopped out stuff where the update=20 > completely addresses=20 > my comment)...=20 > Cheers,=20 > Mark.=20 >=20 > >=20 > > % - Discard or Decompress?=20 > > % Overall, I didn't see much discussion about whether the aim is to=20 > > % (i) detect sequentially late packets and discard them; or=20 > > % (ii) detect sequentially late packets and decompress them=20 > > % correctly.=20 > >=20 > > The goal in the long run is of course just to "decompress=20 > correctly",=20 > > not necessarily even noticing reordering as anything=20 > special. In the=20 > > short term, with only 3095 being available as compression standard,=20 > > we will have to live with doing the best possible, probably=20 > a mixture=20 > > of (i) and (ii). This document aims at discussing the=20 > various aspects=20 > > of using ROHC over channels that can reorder packets, including=20 > > identifying the challenges, as well as suggesting both=20 > implementation=20 > > methods and future standards improvements to better cope with=20 > > reordering. However, this document is not aiming at specifying a=20 > > solution, i.e. there is no single goal like your (i) or (ii).=20 > >=20 > Ok, that makes sense -- and maybe I should have been clear=20 > that my 'or'=20 > was not necessarily an 'exclusive or' :-)=20 > The fact remains, though, that if you are trying to correctly=20 > decompress=20 > re-ordered packets, there are more challenges than are described.=20 > Specifically, the full version of my comments argued that=20 > decompressing a=20 > sequentially late packet during the update of a=20 > rarely-changing field (for=20 > example) is problematic (for detection, in an R-mode=20 > scenario; and for=20 > correct decompression in U/O-mode).=20 > Unless I've missed something, then I do not see how the draft can be=20 > complete without some discussion of this?=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu May 12 09:33:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23458 for ; Thu, 12 May 2005 09:33:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWE44-0001cM-4n for rohc-archive@ietf.org; Thu, 12 May 2005 09:49:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWDmg-0004uS-Vm; Thu, 12 May 2005 09:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWDme-0004uJ-Sv for rohc@megatron.ietf.org; Thu, 12 May 2005 09:31:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23356 for ; Thu, 12 May 2005 09:31:23 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWE2O-0001b1-0q for rohc@ietf.org; Thu, 12 May 2005 09:47:40 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4CDVDg2001401; Thu, 12 May 2005 15:31:22 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 15:31:19 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 15:31:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Thu, 12 May 2005 15:31:18 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2899@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVU5C0aQYGttH/qRlSKM2n+7XMYMwAV5trwAGzZaZAAAdv58A== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , "West, Mark" X-OriginalArrivalTime: 12 May 2005 13:31:19.0173 (UTC) FILETIME=[E14C1350:01C556F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: quoted-printable I like these adjustments! I'm, however, still waiting for Mark to ack the proposed changes. /L-E > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB)=20 > Sent: den 12 maj 2005 14:58 > To: Lars-Erik Jonsson (LU/EAB); West, Mark > Cc: rohc@ietf.org > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt >=20 >=20 > Some quick picky nits on the proposed text. >=20 > BR, >=20 > /Ghyslain >=20 > >=20 > > NEW: > > 5.1.3. Reordering of Packets in U/O-mode > > =20 > > > Reordering between non-change packets only > > > > > > When there is reordering of non-change packets=20 > only, the ability > > > to decompress sequentially late packets is simply=20 > limited by the > > > offset p of the interpretation interval (see=20 > section 5.1.1). >=20 > Suggestion: >=20 > " When only non-change packets are reordered with respect to each > other, decompression of sequentially late packets is limited by > the offset p of the interpretation interval (see section 5.1.1)." >=20 > Because reordering of non-change packet may actually be=20 > interpreted as with respect to any other event or packet=20 > type, despite the usage of the word only. I actually tripped=20 > on that sentence... >=20 > > Decompression of a sequentially late packet with SN =3D x = is > > possible if the value of the SN of the packet that=20 > last updated > > the context was less than or equal to x + p. > > =20 > > Problems occur if context(SN) has increased by=20 > more than p with > > respect to field(SN) carried within the packet to=20 > decompress. > > =20 > > This means that for a well-behaved stream with a=20 > constant unit > > increase in the RTP SN, a packet can arrive up to=20 > p packets out of > > sequence and still be correctly decompressed. =20 > Otherwise, it cannot > > be properly decompressed. It also means that if=20 > the compressor > > sends two consecutive packets with SN(packet1)=3D100 and > > SN(packet2)=3D108 when p=3D7, packet1 cannot be=20 > decompressed if it > > arrives even one packet late due to reordering. > >=20 > > > Reordering involving change packets > > > > > > When a packet is reordered and becomes=20 > sequentially late with > > > respect to a change packet, decompression of the=20 > late packet may > > > eventually fail, as the context information required for > > > successful decompression may not be available anymore. > >=20 > > Decompression can always be verified since all=20 > U/O-mode packet types > > > are context updating. Consequently, even if=20 > reordering of packets > > > may in some cases result in unsuccessful=20 > decompression, context > > > invalidation due to reordering can be avoided or=20 > detected. The risk >=20 > Suggestion: >=20 > " Consequently, a failure to decompress a packet that is caused > by reordering can be detected, and context invalidation due > to reordering can thus be avoided." >=20 > Because both "avoidance" and "detection" are applied to=20 > context invalidation in the proposed text, while in fact=20 > "detection" applies to the decompression failure and=20 > "avoidance" applies to context invalidatation. >=20 > > > of forwarding incorrectly decompressed packets to=20 > upper layers is > > > therefore small when operating in U/O-mode. For=20 > channels known to > > > reorder packets, U/O-mode should therefore be the=20 > preferred mode of > > operation. The additional risk of losing context=20 > synchronization, > > or for erroneous packet to be delivered to upper=20 > layers, is limited. > >=20 > >=20 > > Does this capture what you were missing from the draft? > > /L-E > >=20 > >=20 > > -----Original Message----- > > From: West, Mark [mailto:mark.a.west@roke.co.uk] > > Sent: den 10 maj 2005 00:12 > > To: Lars-Erik Jonsson (LU/EAB) > > Cc: rohc@ietf.org > > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt > >=20 > >=20 > > Hi Lars-Erik,=20 > > Thanks for your suggested updates. I have a couple of=20 > > follow-on comments=20 > > (for brevity, I've chopped out stuff where the update=20 > > completely addresses=20 > > my comment)...=20 > > Cheers,=20 > > Mark.=20 > >=20 > > >=20 > > > % - Discard or Decompress?=20 > > > % Overall, I didn't see much discussion about whether the=20 > aim is to=20 > > > % (i) detect sequentially late packets and discard them; or=20 > > > % (ii) detect sequentially late packets and decompress them=20 > > > % correctly.=20 > > >=20 > > > The goal in the long run is of course just to "decompress=20 > > correctly",=20 > > > not necessarily even noticing reordering as anything=20 > > special. In the=20 > > > short term, with only 3095 being available as compression=20 > standard,=20 > > > we will have to live with doing the best possible, probably=20 > > a mixture=20 > > > of (i) and (ii). This document aims at discussing the=20 > > various aspects=20 > > > of using ROHC over channels that can reorder packets, including=20 > > > identifying the challenges, as well as suggesting both=20 > > implementation=20 > > > methods and future standards improvements to better cope with=20 > > > reordering. However, this document is not aiming at specifying a=20 > > > solution, i.e. there is no single goal like your (i) or (ii).=20 > > >=20 > > Ok, that makes sense -- and maybe I should have been clear=20 > > that my 'or'=20 > > was not necessarily an 'exclusive or' :-)=20 > > The fact remains, though, that if you are trying to correctly=20 > > decompress=20 > > re-ordered packets, there are more challenges than are described.=20 > > Specifically, the full version of my comments argued that=20 > > decompressing a=20 > > sequentially late packet during the update of a=20 > > rarely-changing field (for=20 > > example) is problematic (for detection, in an R-mode=20 > > scenario; and for=20 > > correct decompression in U/O-mode).=20 > > Unless I've missed something, then I do not see how the=20 > draft can be=20 > > complete without some discussion of this?=20 > >=20 > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu May 12 10:01:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25809 for ; Thu, 12 May 2005 10:01:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWEVp-0002Vy-4X for rohc-archive@ietf.org; Thu, 12 May 2005 10:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWEFu-0002FL-Vq; Thu, 12 May 2005 10:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWEFt-0002Cw-5B for rohc@megatron.ietf.org; Thu, 12 May 2005 10:01:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25733 for ; Thu, 12 May 2005 10:01:35 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWEVc-0002Uj-Kd for rohc@ietf.org; Thu, 12 May 2005 10:17:53 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4CE1WhX011193 for ; Thu, 12 May 2005 16:01:35 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 16:00:59 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 16:00:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2005 16:00:58 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC051C289B@esealmw109.eemea.ericsson.se> Thread-Topic: Document Action: 'Requirements for Header Compression over MPLS' to Informational RFC Thread-Index: AcVW+o9Y6dP4r4VET6CGzK5qx86NVQAAFWiA From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 12 May 2005 14:00:59.0005 (UTC) FILETIME=[0628E2D0:01C556FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Subject: [rohc] FW: Document Action: 'Requirements for Header Compression over MPLS' to Informational RFC X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org]On Behalf Of The IESG Sent: den 12 maj 2005 15:52 To: IETF-Announce Cc: Magnus Westerlund (KI/EAB); avt chair; Internet Architecture Board; avt mailing list; RFC Editor Subject: Document Action: 'Requirements for Header Compression over MPLS' to Informational RFC=20 The IESG has approved the following document: - 'Requirements for Header Compression over MPLS ' as an Informational RFC This document is the product of the Audio/Video Transport Working Group. It was reviewed as well by the Multiprotocol Label Switching Working = Group. The IESG contact persons are Allison Mankin and Jon Peterson. RFC Editor Note: OLD: These MPLS signaling protocol extensions need coordination with other working=20 groups (e.g., MPLS). NEW: =20 The specific MPLS signaling protocol extensions to support these approved requirements need to be developed as a well-coordinated separate document in the MPLS working group. The IETF needs to support a coordinated process for the two solution documents, though they are in separate areas. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Sat May 14 18:43:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10763 for ; Sat, 14 May 2005 18:43:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX5cS-000211-K1 for rohc-archive@ietf.org; Sat, 14 May 2005 19:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX5M8-0002iB-Ry; Sat, 14 May 2005 18:43:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX5M6-0002i6-Um for rohc@megatron.ietf.org; Sat, 14 May 2005 18:43:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10756 for ; Sat, 14 May 2005 18:43:31 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX5cJ-00020l-HR for rohc@ietf.org; Sat, 14 May 2005 19:00:20 -0400 Received: from tipau (tipau [10.147.65.84]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4EMhQa03558 for ; Sun, 15 May 2005 00:43:27 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau (8.12.7/8.8.8) with ESMTP id j4EMhLbb028012 for ; Sun, 15 May 2005 00:43:21 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j4EMhLpo028011 for rohc@ietf.org; Sun, 15 May 2005 00:43:21 +0200 From: Cristian CONSTANTIN Date: Sun, 15 May 2005 00:43:20 +0200 To: rohc@ietf.org Message-ID: <20050514224320.GA27917@terix.fokus.gmd.de> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1646555084==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --===============1646555084== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi! suppose that a STATE-CREATE tries to create a state with a state_identifier that matches (taking into account the minimum_access_length) another state which already exists in the same compartment. what should happen? 1. create a new state (even though the state_identifiers will overlap) 2. drop the old one? 3. drop the new one? bye now! cristian --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFChn8IypNgyZIZ1MERAn5eAJ9cOsrXNKYiZEcOmVZCg2/voJTSZACeLtxF iyonA6ZYNLGQujnH0mmVbWI= =ZUqt -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- --===============1646555084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1646555084==-- From rohc-bounces@ietf.org Mon May 16 07:33:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28640 for ; Mon, 16 May 2005 07:33:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXe79-0000jE-KD for rohc-archive@ietf.org; Mon, 16 May 2005 07:50:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXdpf-0006Nf-4v; Mon, 16 May 2005 07:32:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXdpe-0006F0-5N; Mon, 16 May 2005 07:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28297; Mon, 16 May 2005 07:31:30 -0400 (EDT) From: r.parthasarathi@flextronicssoftware.com Received: from [61.16.168.135] (helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXe5L-0000eZ-ES; Mon, 16 May 2005 07:48:36 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id j4GBU3d21735; Mon, 16 May 2005 17:00:05 +0530 In-Reply-To: <20050413104807.GN16335@terix.fokus.gmd.de> To: Cristian CONSTANTIN Subject: Re: [rohc] sigcomp - meaning of the F bit in the input_bit_order register MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Mon, 16 May 2005 16:57:12 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 05/16/2005 05:02:02 PM Content-Type: multipart/mixed; boundary="=_mixed 003EE95565257003_=" X-Spam-Score: 0.9 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: rohc@ietf.org, rohc-bounces@ietf.org, rashed.ahammad@flextronicssoftware.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 --=_mixed 003EE95565257003_= Content-Type: multipart/alternative; boundary="=_alternative 003EE95565257003_=" --=_alternative 003EE95565257003_= Content-Type: text/plain; charset="US-ASCII" Hi, Please read in-line Cristian CONSTANTIN Sent by: rohc-bounces@ietf.org 04/13/2005 04:18 PM To rohc@ietf.org cc Subject [rohc] sigcomp - meaning of the F bit in the input_bit_order register hi! please help me to grasp the meaning of the F/H bits :-) in the SigComp rfc, at 8.2. Requesting Additional Compressed Data there is this statement: "When an INPUT instruction requests n bits of compressed data, it interprets the received bits as an integer between 0 and 2^n - 1. The F-bit and the H-bit specify whether the bits in these integers are considered to arrive in MSB to LSB order (bit set to 0) or in LSB to MSB order (bit set to 1)." how should this be interpreted? 1. same as for the P bit; that is the bytes themselves are always in network byte order but the bits in the bytes are in LSB to MSB order when F=1 and the other way around for F=0. Yes, F-Bit is same as P-Bit for the INPUT-BITS instruction 2. the bits in the _(short) integer_ are: a. LSB to MSB for F=1. that would mean that the component bytes are also swapped which would more or less contradict another statement in 8.2: "Note that the input_bit_order register cannot change the order in which the bytes themselves are passed to the INPUT instructions (bytes are always passed in the same order as they occur in the SigComp message)." The input_bit_order register talks only about the order of flow of bits within a byte. It has nothing to do with the order of flow of bytes b. MSB to LSB for F=0. now, if 1 is the right interpretation, then wouldn't P=1 && F=1 cancel each other's effect? Yes, your understanding of the above point is correct. thank you for your attention. bye now! cristian -- _ | There are many people who use UNIX or Linux (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn GPG public key at wwwkeys.de.pgp.net _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc *********************** FSS-Unclassified *********************** --=_alternative 003EE95565257003_= Content-Type: text/html; charset="US-ASCII"
Hi,

Please read in-line



Cristian CONSTANTIN <constantin@fokus.fraunhofer.de>
Sent by: rohc-bounces@ietf.org

04/13/2005 04:18 PM

To
rohc@ietf.org
cc
Subject
[rohc] sigcomp - meaning of the F bit in the input_bit_order        register





hi!

please help me to grasp the meaning of the F/H bits :-)
in the SigComp rfc, at 8.2.  Requesting Additional Compressed Data there
is this statement:

 "When an INPUT instruction requests n bits of compressed data, it
  interprets the received bits as an integer between 0 and 2^n - 1.
  The F-bit and the H-bit specify whether the bits in these integers
  are considered to arrive in MSB to LSB order (bit set to 0) or in LSB
  to MSB order (bit set to 1)."

how should this be interpreted?

1. same as for the P bit; that is the bytes themselves are always in
network byte order but the bits in the bytes are in LSB to MSB order when
F=1 and the other way around for F=0.
<Partha> Yes, F-Bit is same as P-Bit for the INPUT-BITS instruction </Partha>

2. the bits in the _(short) integer_ are:
 
a. LSB to MSB for F=1. that would mean that the component bytes are
  also swapped which would more or less contradict another statement in
  8.2:
  "Note that the input_bit_order register cannot change the order in
  which the bytes themselves are passed to the INPUT instructions
  (bytes are always passed in the same order as they occur in the
  SigComp message)."
<Partha>  The input_bit_order register talks only about the order of flow of bits within a byte.
          It has nothing to do with the order of flow of bytes </Partha>
   
b. MSB to LSB for F=0.

now, if 1 is the right interpretation, then wouldn't P=1 && F=1 cancel
each other's effect?
<Partha>  Yes, your understanding of the above point is correct. </Partha>

thank you for your attention.
bye now!
cristian
--
_          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
 (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc


***********************  FSS-Unclassified   *********************** --=_alternative 003EE95565257003_=-- --=_mixed 003EE95565257003_= Content-Type: application/octet-stream; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoR05V L0xpbnV4KQ0KDQppRDhEQlFGQ1hQam55cE5neVpJWjFNRVJBbE5HQUo5RmZNTUdWVjRuNFprdU9v SHQwci9vc1k5ZUl3Q2duTTV4DQovNE5Vd1c0ZmR6MzVoSDM4c21BWE9Bbz0NCj14aHUrDQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 003EE95565257003_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --=_mixed 003EE95565257003_=-- From rohc-bounces@ietf.org Mon May 16 11:24:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25837 for ; Mon, 16 May 2005 11:24:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXhib-00072Y-Rj for rohc-archive@ietf.org; Mon, 16 May 2005 11:41:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhRF-0005pI-74; Mon, 16 May 2005 11:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXhRD-0005p9-DV for rohc@megatron.ietf.org; Mon, 16 May 2005 11:23:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25664 for ; Mon, 16 May 2005 11:23:20 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXhhk-00070A-MV for rohc@ietf.org; Mon, 16 May 2005 11:40:30 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4GFKiqP023634; Mon, 16 May 2005 16:20:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Date: Mon, 16 May 2005 16:21:36 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FC8@rsys004a> Thread-Topic: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Thread-Index: AcVY1tWYzRguqWpeS0SDWpkwEYXP4gBS/67g From: "Surtees, Abigail" To: "Cristian CONSTANTIN" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Hi Cristian, The behaviour of the STATE-CREATE instruction is dependent only in part on whether or not the state is in the same compartment. If the full 20 bytes of state identifier match another identifier (in any compartment) but the state itself does not match, then the state creation fails. If the full 20 bytes match and the state itself matches then the behaviour is dependent on the compartment. If they are not in the same compartment, a new piece of state is created; if they are in the same compartment, then the old state is moved so that it is as if it has just been newly created. Otherwise the state is created in the compartment in which the request has been made. So the answer to your question (assuming that not all 20 bytes match) is option 1 - create a new state. The issue for the clash when minimum_access_length bytes are checked does not arise until state is accessed (at which point the compartment is unknown). When the state is accessed, the number of pieces of state with the same first n bytes of identifier is checked. If this is greater than 1, then the STATE-ACCESS fails. Due to the fact that state is accessed from a global list (because at the time of access the compartment identifier is not known), the likelihood of this happening on a server with thousands of pieces of state is actually greater than one might imagine and is discussed in detail in section 7 of the implementer's guide . =20 I hope this clarifies the situation. Best regards, Abbie > -----Original Message----- > From: cristian CONSTANTIN [mailto:constantin@fokus.fraunhofer.de]=20 > Sent: Saturday, May 14, 2005 11:43 PM > To: rohc@ietf.org > Subject: [rohc] sigcomp - state_identifier matching an=20 > existing one at a STATE-CREATE >=20 hi! suppose that a STATE-CREATE tries to create a state with a state_identifier that matches (taking into account the minimum_access_length) another state which already exists in the same compartment. what should happen? 1. create a new state (even though the state_identifiers will overlap) 2. drop the old one? 3. drop the new one? bye now! cristian --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 16 19:10:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12884 for ; Mon, 16 May 2005 19:10:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXozY-00028o-C3 for rohc-archive@ietf.org; Mon, 16 May 2005 19:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXogv-00044O-FK; Mon, 16 May 2005 19:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXogt-00044J-9g for rohc@megatron.ietf.org; Mon, 16 May 2005 19:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12540 for ; Mon, 16 May 2005 19:08:00 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXoxV-0001xK-AT for rohc@ietf.org; Mon, 16 May 2005 19:25:14 -0400 Received: from tipau (tipau [10.147.65.84]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4GN7ua22216; Tue, 17 May 2005 01:07:56 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau (8.12.7/8.8.8) with ESMTP id j4GN7mbb026177; Tue, 17 May 2005 01:07:48 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j4GN7maJ026176; Tue, 17 May 2005 01:07:48 +0200 From: Cristian CONSTANTIN Date: Tue, 17 May 2005 01:07:48 +0200 To: "Surtees, Abigail" Subject: Re: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Message-ID: <20050516230748.GA25257@terix.fokus.gmd.de> References: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FC8@rsys004a> Mime-Version: 1.0 In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FC8@rsys004a> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0980324939==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 --===============0980324939== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 16, 2005 at 04:21:36PM +0100, Surtees, Abigail wrote: > Hi Cristian, >=20 > The behaviour of the STATE-CREATE instruction is dependent only in part > on whether or not the state is in the same compartment. >=20 > If the full 20 bytes of state identifier match another identifier (in > any compartment) but the state itself does not match, then the state > creation fails. >=20 > If the full 20 bytes match and the state itself matches then the > behaviour is dependent on the compartment. If they are not in the same > compartment, a new piece of state is created; if they are in the same > compartment, then the old state is moved so that it is as if it has just > been newly created. cristian: thank you for the explanation. just to make sure I've got it right; this movement has to do with the following paragraph from the sigcomp rfc: 5. The order in which the existing state items are freed is determined by the state_retention_priority, which is set when the state items are created. The state_retention_priority of 65535 is reserved for locally available states; these states must always be freed first. Apart from this special case, states with the lowest state_retention_priority are always freed first. In the event of a tie, then the state item created first in the compartment is also the first to be freed. >=20 > Otherwise the state is created in the compartment in which the request > has been made. >=20 > So the answer to your question (assuming that not all 20 bytes match) is > option 1 - create a new state. >=20 > The issue for the clash when minimum_access_length bytes are checked > does not arise until state is accessed (at which point the compartment > is unknown). >=20 > When the state is accessed, the number of pieces of state with the same > first n bytes of identifier is checked. If this is greater than 1, then > the STATE-ACCESS fails. Due to the fact that state is accessed from a > global list (because at the time of access the compartment identifier is > not known), the likelihood of this happening on a server with thousands > of pieces of state is actually greater than one might imagine and is > discussed in detail in section 7 of the implementer's guide > 04.txt>. =20 cristian: as far as I understand it (I am just a novice in cryptography), this discussion does not take into account an attack which "tries" to produ= ce=20 collisions, does it? just curios, in the light of the new weaknesses discovered in SHA-1 (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), how "vulnerable" (to faking/changing states) is now sigcomp? >=20 > I hope this clarifies the situation. >=20 > Best regards, >=20 > Abbie >=20 > > -----Original Message----- > > From: cristian CONSTANTIN [mailto:constantin@fokus.fraunhofer.de]=20 > > Sent: Saturday, May 14, 2005 11:43 PM > > To: rohc@ietf.org > > Subject: [rohc] sigcomp - state_identifier matching an=20 > > existing one at a STATE-CREATE > >=20 > hi! >=20 > suppose that a STATE-CREATE tries to create a state with a > state_identifier that matches (taking into account the > minimum_access_length) another state which already exists in the same > compartment. >=20 > what should happen? >=20 > 1. create a new state (even though the state_identifiers will overlap) > 2. drop the old one? > 3. drop the new one? >=20 > bye now! > cristian > --=20 > _ | There are many people who use UNIX or Linux =20 > (_'_ | who IMHO do not understand UNIX. > (_'rist | --David Korn =20 > GPG public key at wwwkeys.de.pgp.net > =20 --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCiSfDypNgyZIZ1MERAs6zAKDHqWNMog7eVuAZpc5qhx0gcw/K/gCgpT7k 6VtzMoA1QjLmVwxLeoP/58I= =fn6v -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- --===============0980324939== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0980324939==-- From rohc-bounces@ietf.org Tue May 17 05:37:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28304 for ; Tue, 17 May 2005 05:37:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXyn4-0001xC-KT for rohc-archive@ietf.org; Tue, 17 May 2005 05:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXyUn-0005Ua-JA; Tue, 17 May 2005 05:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXyUm-0005UV-78 for rohc@megatron.ietf.org; Tue, 17 May 2005 05:36:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28089 for ; Tue, 17 May 2005 05:36:09 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXylR-0001si-Qa for rohc@ietf.org; Tue, 17 May 2005 05:53:29 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4H9YeqP020745; Tue, 17 May 2005 10:34:40 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 10:35:42 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8807D5824@rsys004a> From: "Ollis, Paul" To: "'r.parthasarathi@flextronicssoftware.com'" , Cristian CONSTANTIN Date: Tue, 17 May 2005 10:35:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: paul.ollis@roke.co.uk Subject: RE: [rohc] sigcomp - meaning of the F bit in the input_bit_order X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Hi Christian, Partha, Actually the F/H and P bits do not quite work as suggested. (From this point on I will just talk about the F-but rather than the F/H bit.) The effects of the F-bit are different to the effects of the P-bit. The P-bit only affects how bits within each byte are read. The F-bit affects how the bits are assembled into the input value; and the value can be up to 16 bits long. The difference is not immediately obvious but I think a concrete example helps show how this works. (The rest of this will be easier to read using fixed width font.) Suppose your input buffer contains the bytes hex: F0 A3 bin: 1111 0000 1010 0011 If the P-bit is zero (0) then the order the bits are read in the following order (starting with a). 1111 0000 1010 0011 abcd efgh ijkl mnop So if, for example 11 bits are input, the bits read are: 1 1 1 1 0 0 0 0 1 0 1 a b c d e f g h i j k and the input buffer is then as shown ('x' marks bits that have been used). xxxx xxxx xxx0 0011 l mnop and the next INPUT-BITS starts with bit 'l'. If the P-bit is one (1) then the order the bits input order is. 1111 0000 1010 0011 hgfe dcba ponm lkji Giving the results, for 11 bits input. 0 0 0 0 1 1 1 1 1 1 0 a b c d e f g h i j k xxxx xxxx 1010 0xxx ponm l The F-bit affects how the bits 'a' to 'k' are interpreted to give the result. If the F-bit is zero (0) then bit 'a' is the MSB and 'k' is the LSB. So for F=0, P=0 the value is 1 1 1 1 0 0 0 0 1 0 1 or 111 1000 0101 or (as hex) 785 a b c d e f g h i j k and for F=0, P=1 the value is 0 0 0 0 1 1 1 1 1 1 0 or 000 0111 1110 or (as hex) 07E a b c d e f g h i j k When F is one(1), bit 'k' is the MSB and 'a' is the LSB. So for F=1, P=0 1 0 1 0 0 0 0 1 1 1 1 or 101 0000 1111 or (as hex) 50F k j i h g f e d c b a and F=1, P=1 0 1 1 1 1 1 1 0 0 0 0 or 011 1111 0000 or (as hex) 3F0 k j i h g f e d c b a Notice that F=1, P=1 does *not* give the same result as F=0, P=0. Also, F=0, P=1 gives a different result to F=1, P=0. I hope this helps make things clearer. Cheers, Paul -----Original Message----- From: r.parthasarathi@flextronicssoftware.com [mailto:r.parthasarathi@flextronicssoftware.com] Sent: 16 May 2005 12:27 To: Cristian CONSTANTIN Cc: rohc@ietf.org; rohc-bounces@ietf.org; rashed.ahammad@flextronicssoftware.com Subject: Re: [rohc] sigcomp - meaning of the F bit in the input_bit_order register Hi, Please read in-line Cristian CONSTANTIN Sent by: rohc-bounces@ietf.org 04/13/2005 04:18 PM Torohc@ietf.org cc Subject[rohc] sigcomp - meaning of the F bit in the input_bit_order register hi! please help me to grasp the meaning of the F/H bits :-) in the SigComp rfc, at 8.2. Requesting Additional Compressed Data there is this statement: "When an INPUT instruction requests n bits of compressed data, it interprets the received bits as an integer between 0 and 2^n - 1. The F-bit and the H-bit specify whether the bits in these integers are considered to arrive in MSB to LSB order (bit set to 0) or in LSB to MSB order (bit set to 1)." how should this be interpreted? 1. same as for the P bit; that is the bytes themselves are always in network byte order but the bits in the bytes are in LSB to MSB order when F=1 and the other way around for F=0. Yes, F-Bit is same as P-Bit for the INPUT-BITS instruction 2. the bits in the _(short) integer_ are: a. LSB to MSB for F=1. that would mean that the component bytes are also swapped which would more or less contradict another statement in 8.2: "Note that the input_bit_order register cannot change the order in which the bytes themselves are passed to the INPUT instructions (bytes are always passed in the same order as they occur in the SigComp message)." The input_bit_order register talks only about the order of flow of bits within a byte. It has nothing to do with the order of flow of bytes b. MSB to LSB for F=0. now, if 1 is the right interpretation, then wouldn't P=1 && F=1 cancel each other's effect? Yes, your understanding of the above point is correct. thank you for your attention. bye now! cristian -- _ | There are many people who use UNIX or Linux (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn GPG public key at wwwkeys.de.pgp.net _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc *********************** FSS-Unclassified *********************** _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 17 06:59:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07694 for ; Tue, 17 May 2005 06:59:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY04F-0006dC-01 for rohc-archive@ietf.org; Tue, 17 May 2005 07:16:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzma-0007Q7-8l; Tue, 17 May 2005 06:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzmY-0007Q2-LJ for rohc@megatron.ietf.org; Tue, 17 May 2005 06:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07636 for ; Tue, 17 May 2005 06:58:35 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY03G-0006W3-Oi for rohc@ietf.org; Tue, 17 May 2005 07:15:56 -0400 Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4HAwDqP011660; Tue, 17 May 2005 11:58:13 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 17 May 2005 11:59:15 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FD1@rsys004a> From: "Surtees, Abigail" To: "'Cristian CONSTANTIN'" Subject: RE: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Date: Tue, 17 May 2005 11:57:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi Cristian, > cristian: thank you for the explanation. > just to make sure I've got it right; this movement has to do with > the following paragraph from the sigcomp rfc: > > 5. The order in which the existing state items are freed is > determined by the state_retention_priority, which is > set when the > state items are created. The state_retention_priority > of 65535 is > reserved for locally available states; these states > must always be > freed first. Apart from this special case, states with > the lowest > state_retention_priority are always freed first. In > the event of > a tie, then the state item created first in the compartment is > also the first to be freed. Yes, it does. > > cristian: as far as I understand it (I am just a novice in > cryptography), > this discussion does not take into account an attack which > "tries" to produce > collisions, does it? just curios, in the light of the new weaknesses > discovered in SHA-1 > (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), how > "vulnerable" (to faking/changing states) is now sigcomp? > I'm no cryptographer either. From an attacker's perspective, creating two pieces of state with the same 20 byte hash doesn't gain anything because the second piece of state will not be created. Creating a second piece of state with the same first n bytes of hash means that in order for state to be accessed more than n bytes of hash need to be sent. If this could be done, then it is possible to restrict how state is accessed, so there is potential for an attack here. However, according to Paul Hoffman and Bruce Schneier's draft on the subject (), it is not the 'collision free' property of the SHA-1 that has been attacked rather than the 'one way' property. The above attack would require the 'one way' property to be broken, so the weaknesses discovered do not affect the vulnerability of SigComp. Best regards, Abbie Abbie Surtees Senior Engineer Roke Manor Research Ltd Old Salisbury Lane Romsey, SO51 0ZN Tel: +44 (0) 1794 833131 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 17 07:07:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08480 for ; Tue, 17 May 2005 07:07:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0Be-000729-9u for rohc-archive@ietf.org; Tue, 17 May 2005 07:24:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzuY-00011x-BB; Tue, 17 May 2005 07:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzuX-00011n-IK for rohc@megatron.ietf.org; Tue, 17 May 2005 07:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08456 for ; Tue, 17 May 2005 07:06:50 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0BG-00071T-3F for rohc@ietf.org; Tue, 17 May 2005 07:24:11 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 4305869B72; Tue, 17 May 2005 12:06:25 +0100 (BST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FD1@rsys004a> References: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FD1@rsys004a> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7fb0cda84d5ba0f771c8a10a974b62d6@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Date: Tue, 17 May 2005 12:06:23 +0100 To: "Surtees, Abigail" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi ROHCers, On 17 May 2005, at 11:57, Surtees, Abigail wrote: > it is not the 'collision free' property of the SHA-1 that has been > attacked rather than the 'one way' property. ...by which I assume Abbie meant: "it IS the 'collision free' property of the SHA-1 that has been attacked rather than the 'one way' property" ? atb, Lawrence --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 17 07:09:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08686 for ; Tue, 17 May 2005 07:09:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0EI-0007Ct-6S for rohc-archive@ietf.org; Tue, 17 May 2005 07:27:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzwL-0001rs-B7; Tue, 17 May 2005 07:08:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzwK-0001qz-KC for rohc@megatron.ietf.org; Tue, 17 May 2005 07:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08580 for ; Tue, 17 May 2005 07:08:41 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0D2-00079g-9V for rohc@ietf.org; Tue, 17 May 2005 07:26:02 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4HB8RqP014555; Tue, 17 May 2005 12:08:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Date: Tue, 17 May 2005 12:09:15 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FD3@rsys004a> Thread-Topic: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Thread-Index: AcVaz5NfCwqGxzxfQQyya9NiAEKdUAAAFhfA From: "Surtees, Abigail" To: "Cristian CONSTANTIN" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Hi Cristian, =20 Apologies, I seem to be confusing things rather than clarifying. There's an extra 'not' in what I wrote. >=20 > However, according to Paul Hoffman and Bruce Schneier's draft=20 > on the subject=20 ( ), it is not the >'collision free' property of the SHA-1 that has been attacked rather than the 'one way'=20 >property. The above attack would require the 'one way' property to be broken, so the=20 >weaknesses discovered do not affect the vulnerability of SigComp. It should say: It *is* the collision free property that has been attacked and not the 'one way' property. =20 The conclusion remains the same - SigComp is no more vulnerable than it was before this weaknesses were found. Best regards, Abbie Abbie Surtees Senior Engineer Roke Manor Research Ltd Old Salisbury Lane Romsey, SO51 0ZN Tel: +44 (0) 1794 833131 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 17 09:07:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20048 for ; Tue, 17 May 2005 09:07:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY247-0005Yt-AC for rohc-archive@ietf.org; Tue, 17 May 2005 09:24:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1jw-0003aL-SX; Tue, 17 May 2005 09:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY1jv-0003a8-B1 for rohc@megatron.ietf.org; Tue, 17 May 2005 09:04:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19721 for ; Tue, 17 May 2005 09:04:01 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY20d-0005My-Ll for rohc@ietf.org; Tue, 17 May 2005 09:21:22 -0400 Received: from tipau (tipau [10.147.65.84]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4HD3va01098; Tue, 17 May 2005 15:03:57 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau (8.12.7/8.8.8) with ESMTP id j4HD3pbb002452; Tue, 17 May 2005 15:03:52 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j4HD3p4E002451; Tue, 17 May 2005 15:03:51 +0200 From: Cristian CONSTANTIN Date: Tue, 17 May 2005 15:03:51 +0200 To: "Surtees, Abigail" Subject: Re: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE Message-ID: <20050517130351.GR1276@terix.fokus.gmd.de> References: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FC8@rsys004a> Mime-Version: 1.0 In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FC8@rsys004a> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0950156858==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 --===============0950156858== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FT/vNgDLxVq4t/AU" Content-Disposition: inline --FT/vNgDLxVq4t/AU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 16, 2005 at 04:21:36PM +0100, Surtees, Abigail wrote: > Hi Cristian, >=20 > The behaviour of the STATE-CREATE instruction is dependent only in part > on whether or not the state is in the same compartment. >=20 > If the full 20 bytes of state identifier match another identifier (in > any compartment) but the state itself does not match, then the state > creation fails. >=20 > If the full 20 bytes match and the state itself matches then the > behaviour is dependent on the compartment. If they are not in the same > compartment, a new piece of state is created; if they are in the same > compartment, then the old state is moved so that it is as if it has just > been newly created. cristian: sorry to bother you again, but... what exactly do you mean by "a new piece of state is created" ? 1. a new state item is created and it will be pointed to from this compartment. wouldn't this contradict the statement from 9.4.5. STATE-ACCESS (sigcomp rfc) that says: "Decompression failure also occurs [...] if more than one state item matches the partial identifier [...]" ? that is the first STATE-ACCESS trying to access this state will give a decompression failure (if we suppose that none of 2 identic states has=20 been freed already) 2. same state item is going to be pointed to by this compartment whose state_retention_priority data structure and state_memory_size is=20 updated to reflect the changes. >=20 > Otherwise the state is created in the compartment in which the request > has been made. >=20 > So the answer to your question (assuming that not all 20 bytes match) is > option 1 - create a new state. >=20 > The issue for the clash when minimum_access_length bytes are checked > does not arise until state is accessed (at which point the compartment > is unknown). >=20 > When the state is accessed, the number of pieces of state with the same > first n bytes of identifier is checked. If this is greater than 1, then > the STATE-ACCESS fails. Due to the fact that state is accessed from a > global list (because at the time of access the compartment identifier is > not known), the likelihood of this happening on a server with thousands > of pieces of state is actually greater than one might imagine and is > discussed in detail in section 7 of the implementer's guide > 04.txt>. =20 >=20 > I hope this clarifies the situation. >=20 > Best regards, >=20 > Abbie >=20 > > -----Original Message----- > > From: cristian CONSTANTIN [mailto:constantin@fokus.fraunhofer.de]=20 > > Sent: Saturday, May 14, 2005 11:43 PM > > To: rohc@ietf.org > > Subject: [rohc] sigcomp - state_identifier matching an=20 > > existing one at a STATE-CREATE > >=20 > hi! >=20 > suppose that a STATE-CREATE tries to create a state with a > state_identifier that matches (taking into account the > minimum_access_length) another state which already exists in the same > compartment. >=20 > what should happen? >=20 > 1. create a new state (even though the state_identifiers will overlap) > 2. drop the old one? > 3. drop the new one? >=20 > bye now! > cristian > --=20 > _ | There are many people who use UNIX or Linux =20 > (_'_ | who IMHO do not understand UNIX. > (_'rist | --David Korn =20 > GPG public key at wwwkeys.de.pgp.net > =20 --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --FT/vNgDLxVq4t/AU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCieu3ypNgyZIZ1MERAt6nAKDOb4tXvby2m+anQ9dahCDycFbyCgCfX/nT TC718wYvKMM+WWs6hfnlQlg= =lQBk -----END PGP SIGNATURE----- --FT/vNgDLxVq4t/AU-- --===============0950156858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0950156858==-- From rohc-bounces@ietf.org Tue May 17 16:07:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07844 for ; Tue, 17 May 2005 16:07:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8c5-0005XX-Dd for rohc-archive@ietf.org; Tue, 17 May 2005 16:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY84e-0007uz-T6; Tue, 17 May 2005 15:49:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY84b-0007s7-5X; Tue, 17 May 2005 15:49:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02262; Tue, 17 May 2005 15:49:46 -0400 (EDT) Message-Id: <200505171949.PAA02262@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 17 May 2005 15:49:46 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-over-reordering-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets Author(s) : G. Pelletier, et al. Filename : draft-ietf-rohc-over-reordering-03.txt Pages : 20 Date : 2005-5-17 RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-over-reordering-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-over-reordering-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-17154203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-over-reordering-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-over-reordering-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-17154203.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Tue May 17 17:03:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19937 for ; Tue, 17 May 2005 17:03:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY9Uq-0002eZ-Ub for rohc-archive@ietf.org; Tue, 17 May 2005 17:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9Be-0004M9-Sq; Tue, 17 May 2005 17:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9BY-0004Kf-3X; Tue, 17 May 2005 17:01:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19608; Tue, 17 May 2005 17:01:00 -0400 (EDT) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DY9SJ-0002SR-N6; Tue, 17 May 2005 17:18:26 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-124.messagelabs.com!1116363649!1956266!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.166.71] Received: (qmail 23167 invoked from network); 17 May 2005 21:00:50 -0000 Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71) by server-6.tower-124.messagelabs.com with SMTP; 17 May 2005 21:00:50 -0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j4HKvcMl021366; Tue, 17 May 2005 17:00:49 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 4287737400069A8A; Tue, 17 May 2005 17:00:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 May 2005 16:00:49 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA8DC5@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt Thread-Index: AcVGsK+ZB2HmnyVzRdmKlM478mx93gAB+qAAAAFCAXAAACNPsAAABc3AA9m5cPABOE/twA== From: "Ash, Gerald R \(Jerry\), ALABS" To: "Lars-Erik Jonsson \(LU/EAB\)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [rohc] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: quoted-printable Hi Lars-Erik, We really appreciate your thorough reviews and helpful suggestions. > First of all, I must say you've done a great job with this update. The > technical solution is starting to get in shape, and so also the draft > itself. I just have a few issues that I believe should be given some > additional attention, and I'll start with the least technical one: >=20 > * References > =20 > - There is one incorrect reference to RFC 3409, which I think has > not much to do with this document. The correct document to refer > to is RFC 3241, "Robust Header Compression (ROHC) over PPP". >=20 > - There is one invalid reference [IPCP], I guess it should be > [RFC1332] >=20 > - As it is currently written, I believe [RFC3544] and [RFC3241] > would be normative for this document. I believe some other > references, e.g. some MPLS references, would also be normative. >=20 > - There are many informative references, go through them and make > sure they all are actually bringing any value as informative to > this document (I am not sure about the MPLS references). It might > also make sense to group them based on content (HD vs MPLS, etc), > that would make it easier for the reader. Agree to all the above suggestions. =20 > * Separation of functionality >=20 > As previously discussed, I believe it would be useful to more > clearly separate negotiation/setup/signaling from encapsulation. As > it now stands, I am not sure I understand what purpose the=20 > separation of chapter 2 and chapter 3 serves. Chapter 2 is about > both setup and encapsulation, while chapter 3 is about setup only. OK, perhaps we could map current Sections 2 and 3 into the following sub-sections: Section 2.1: link layer encapsulation type field (current Section 2.2) Section 2.2: PW and HC scheme negotiation/setup/signaling (current Sections 2.1 and 3) Section 3: procedures summary (from "In Figure 1 ..." in current Section 2) If you have another suggested organization, please let us know. > * Requirements fulfillment >=20 > In chapter 1, it is said that the outlined solution fulfils the > requirements of [MPLS-HC-REQ]. I am not sure this listing is really > needed, neither do I think it is fully correct. >=20 > a) is true, that is a design decision for this document > b) is also true, ok, it is the whole purpose of the document > c) is not really achieved by this document, but depends on the > header compression scheme used, and especially on how that > scheme is implemented. This document can not guarantee anything > in this regard, but it provides what it can to make this=20 > possible. What this document do indeed provide, is the > mechanism to avoid multiple compression/decompression cycles, > but that is b) above. > d) "signal context identification", I do not know what is meant > with that, neither do I know what standard protocols are referred > to, is it the MPLS PW mechanisms that are meant, and/or the > HC-over-PPP specifications (for the latter, see also below). We can make it more clear that we meant to use existing CRTP, ECRTP or ROHC procedures to signal these natively. The nice thing about the approach is that it achieves functional separation from the PW signaling. > e) this is implementation dependent on HC-protocol level, and it > is out of control of this specification, which is dependent on > the HC scheme implementation(s). Or do PW provide means for=20 > in-order delivery? Agreed that it is HC scheme dependent, however, PW does provide a means for in-order delivery. > Overall, I do not see the point of listing these things here. I > think it is sufficient to say that the solution(s) outlined in > this document have been designed and chosen to address the > goals and requirements of [MPLS-HC-REQ]. We agree with your suggestion to replace the material with a statement like the one above. =20 > * "Flow Setup", end of chapter 2 introduction >=20 > - Is this really only about "setup"? It does not look so to me. >=20 > - I believe this can be generalized so that it is HC-scheme > independent, should not be hard to do. Agreed, we'll re-word to make it HC-scheme independent. =20 > - It is not clear whether 2) is mandatory or not, i.e. is it > mandatory to have a bidirectional connection? We think it is mandatory to have a bidirectional connection for CRTP/ECRTP/ROHC with feedback channel, and also for voice signaling and flow control (RTCP). =20 > * "Flow setup", last bullet, "Free up CID when flow terminates" >=20 > - How can one ever know that a flow has terminated? For UDP-based > "flows", there is no such thing. Also, why should one free > CIDs, I agree CIDs should be re-usable, but if memory is > allocated for a certain number of CIDs, that memory should > last as long as the HC instance(s) is(are) alive. It is the > compressor that may choose to re-use a CID. This has been > thoroughly discussed in the ROHC WG, captured in chapter 7 > of . Agreed. has a nice discussion on CID re-use, which we'll reference. > * Link layer packet type field >=20 > The requirement that link layers must provide packet type > identification for HC packets does not apply to ROHC. Therefore > I believe it is an improper design to require the extra > multiplexing byte (Pkt Typ field) for all schemes. There is > a negotiation of HC scheme done for the "channel", so why not > say that for schemes that can not identify their own packet > types, the extra byte is needed, as described. Or actually > negotiate whether to have this byte, independent of HC scheme > (although some require it). Dynamic negotiation of the multiplexing byte may require a bit more work and complexity than is desirable. Since the gateways need to be configured for each HC type anyway, we could follow this suggestion by saying that the extra byte will be needed for those HC schemes that can not identify their own packet type. That is, an extra byte will be added by default once a certain HC type is configured. =20 > * I think it makes sense to re-use the principles of RFC 3544 and > RFC 3241, but I also think this document will actually have to > define more specifically how the negotiation is done (with > similar principles as in 3544 and 3241). Both RFC 3544 and RFC > 3241 are written as plug-ins to the PPP control protocol IPCP, > so just referring to them here where there is no PPP or IPCP > does not convince me about the completeness of the solution. Are you suggesting that we provide a more detailed specification to extend the use of IPCP or similar scheme for HC parameter negotiation over MPLS? > Rgds, > /L-E Thanks again, Regards, Jerry _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 17 18:53:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00160 for ; Tue, 17 May 2005 18:53:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYBD3-0000M8-5r for rohc-archive@ietf.org; Tue, 17 May 2005 19:10:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYAtT-0004Oi-Eh; Tue, 17 May 2005 18:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYAtR-0004OV-TY for rohc@megatron.ietf.org; Tue, 17 May 2005 18:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29868 for ; Tue, 17 May 2005 18:50:26 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYBAE-0000Cg-Cm for rohc@ietf.org; Tue, 17 May 2005 19:07:53 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4HMoBqP001996; Tue, 17 May 2005 23:50:11 +0100 Received: from mjw-pc.roke.co.uk (mjw-pc.comm.ad.roke.co.uk [193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JF3JXJ6W; Tue, 17 May 2005 23:51:11 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Tue, 17 May 2005 23:50:08 +0100 Message-ID: Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVbMuwl0ZT+l/90RXyfiLmAOh3VIw== From: "West, Mark" To: "Lars-Erik Jonsson \(LU/EAB\)" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0184517433==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e05124dbe0e171b371ff9d88326a1ab7 This is a multi-part message in MIME format. --===============0184517433== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55B32.EBA6D980" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C55B32.EBA6D980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lars-Erik, Given the scope of the draft, as discussed with regard to previous comments, yes -- I'm much happier that the text now explicitly discusses the implication of re-ordering of "change packets". I believe that you have now addressed all of my comments. Thanks, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Tue, 10 May 2005, Lars-Erik Jonsson (LU/EAB) wrote: > Date: Tue, 10 May 2005 13:45:01 +0200 > From: "Lars-Erik Jonsson (LU/EAB)" > To: "West, Mark" > Cc: rohc@ietf.org > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt > > Mark, > > Thanks for being insistent, I believe you have a point here. After = reading > the draft text again and discussing this with Kristofer, our = conclusion is > that what we believe is missing is more text in section 5.1.3, which > should discuss both "Reordering between non-change packets only" > and "Reordering involving change packets". > The current text in 5.1.3 actually only covers the former. So, our > proposal is to make the following changes to section 5.1.3: > > OLD: > 5.1.3. Reordering of Packets in U/O-mode > > < Sequentially late packets > < > < The ability to decompress sequentially late packets is = limited by > < the offset p of the interpretation interval (see section = 5.1.1). > Decompression of a sequentially late packet with SN =3D x is > possible if the value of the SN of the packet that last = updated > the context was less than or equal to x + p. > > Problems occur if context(SN) has increased by more than p = with > respect to field(SN) carried within the packet to decompress. > > This means that for a well-behaved stream with a constant = unit > increase in the RTP SN, a packet can arrive up to p packets = out of > sequence and still be correctly decompressed. Otherwise, it = cannot > be properly decompressed. It also means that if the = compressor > sends two consecutive packets with SN(packet1)=3D100 and > SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed = if it > arrives even one packet late due to reordering. > > Decompression can always be verified since all U/O-mode packet = types > < are context updating. Consequently, reordering of packets is not > < deemed problematic when operating in U/O-mode. For channels = known to > < reorder packets, the U/O-mode should therefore be the preferred = mode > of operation. The additional risk of losing context = synchronization, > or for erroneous packet to be delivered to upper layers, is = limited. > > NEW: > 5.1.3. Reordering of Packets in U/O-mode > > > Reordering between non-change packets only > > > > When there is reordering of non-change packets only, the = ability > > to decompress sequentially late packets is simply limited by = the > > offset p of the interpretation interval (see section 5.1.1). > Decompression of a sequentially late packet with SN =3D x is > possible if the value of the SN of the packet that last = updated > the context was less than or equal to x + p. > > Problems occur if context(SN) has increased by more than p = with > respect to field(SN) carried within the packet to decompress. > > This means that for a well-behaved stream with a constant = unit > increase in the RTP SN, a packet can arrive up to p packets = out of > sequence and still be correctly decompressed. Otherwise, it = cannot > be properly decompressed. It also means that if the = compressor > sends two consecutive packets with SN(packet1)=3D100 and > SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed = if it > arrives even one packet late due to reordering. > > > Reordering involving change packets > > > > When a packet is reordered and becomes sequentially late with > > respect to a change packet, decompression of the late packet = may > > eventually fail, as the context information required for > > successful decompression may not be available anymore. > > Decompression can always be verified since all U/O-mode packet = types > > are context updating. Consequently, even if reordering of = packets > > may in some cases result in unsuccessful decompression, context > > invalidation due to reordering can be avoided or detected. The = risk > > of forwarding incorrectly decompressed packets to upper layers = is > > therefore small when operating in U/O-mode. For channels known = to > > reorder packets, U/O-mode should therefore be the preferred mode = of > operation. The additional risk of losing context = synchronization, > or for erroneous packet to be delivered to upper layers, is = limited. > > > Does this capture what you were missing from the draft? > /L-E > > > -----Original Message----- > From: West, Mark [mailto:mark.a.west@roke.co.uk] > Sent: den 10 maj 2005 00:12 > To: Lars-Erik Jonsson (LU/EAB) > Cc: rohc@ietf.org > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt > > > Hi Lars-Erik, > Thanks for your suggested updates. I have a couple of follow-on = comments > (for brevity, I've chopped out stuff where the update completely = addresses > my comment)... > Cheers, > Mark. > > > > > % - Discard or Decompress? > > % Overall, I didn't see much discussion about whether the aim is to > > % (i) detect sequentially late packets and discard them; or > > % (ii) detect sequentially late packets and decompress them > > % correctly. > > > > The goal in the long run is of course just to "decompress = correctly", > > not necessarily even noticing reordering as anything special. In the > > short term, with only 3095 being available as compression standard, > > we will have to live with doing the best possible, probably a = mixture > > of (i) and (ii). This document aims at discussing the various = aspects > > of using ROHC over channels that can reorder packets, including > > identifying the challenges, as well as suggesting both = implementation > > methods and future standards improvements to better cope with > > reordering. However, this document is not aiming at specifying a > > solution, i.e. there is no single goal like your (i) or (ii). > > > Ok, that makes sense -- and maybe I should have been clear that my = 'or' > was not necessarily an 'exclusive or' :-) > The fact remains, though, that if you are trying to correctly = decompress > re-ordered packets, there are more challenges than are described. > Specifically, the full version of my comments argued that = decompressing a > sequentially late packet during the update of a rarely-changing field = (for > example) is problematic (for detection, in an R-mode scenario; and for > correct decompression in U/O-mode). > Unless I've missed something, then I do not see how the draft can be > complete without some discussion of this? > ------_=_NextPart_001_01C55B32.EBA6D980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt

Hi Lars-Erik,

Given the scope of the draft, as discussed with regard = to previous
comments, yes -- I'm much happier that the text now = explicitly discusses
the implication of re-ordering of "change = packets".

I believe that you have now addressed all of my = comments.

Thanks,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 = 0ZN
Phone +44 (0)1794 833311   Fax  +44 = (0)1794 833433

On Tue, 10 May 2005, Lars-Erik Jonsson (LU/EAB) = wrote:

> Date: Tue, 10 May 2005 13:45:01 +0200
> From: "Lars-Erik Jonsson (LU/EAB)" = <lars-erik.jonsson@ericsson.com>
> To: "West, Mark" = <mark.a.west@roke.co.uk>
> Cc: rohc@ietf.org
> Subject: RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt
>
> Mark,
>
> Thanks for being insistent, I believe you have a = point here. After reading
> the draft text again and discussing this with = Kristofer, our conclusion is
> that what we believe is missing is more text in = section 5.1.3, which
> should discuss both "Reordering between = non-change packets only"
> and "Reordering involving change = packets".
> The current text in 5.1.3 actually only covers = the former. So, our
> proposal is to make the following changes to = section 5.1.3:
>
> OLD:
>    5.1.3. Reordering of Packets = in U/O-mode
>
> <     Sequentially late = packets
> <
> <        = The ability to decompress sequentially late packets is limited by
> <        = the offset p of the interpretation interval (see section 5.1.1).
>          = Decompression of a sequentially late packet with SN =3D x is
>          = possible if the value of the SN of the packet that last updated
>          the = context was less than or equal to x + p.
>
>          = Problems occur if context(SN) has increased by more than p with
>          = respect to field(SN) carried within the packet to decompress.
>
>          This = means that for a well-behaved stream with a constant unit
>          = increase in the RTP SN, a packet can arrive up to p packets out = of
>          = sequence and still be correctly decompressed. Otherwise, it = cannot
>          be = properly decompressed. It also means that if the compressor
>          = sends two consecutive packets with SN(packet1)=3D100 and
>          = SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed if = it
>          = arrives even one packet late due to reordering.
>
>       = Decompression can always be verified since all U/O-mode packet = types
> <     are context = updating. Consequently, reordering of packets is not
> <     deemed problematic = when operating in U/O-mode. For channels known to
> <     reorder packets, = the U/O-mode should therefore be the preferred mode
>       of = operation. The additional risk of losing context synchronization,
>       or for = erroneous packet to be delivered to upper layers, is limited.
>
> NEW:
>    5.1.3. Reordering of Packets = in U/O-mode
>
> >     Reordering between = non-change packets only
> >
> >        = When there is reordering of non-change packets only, the ability
> >        = to decompress sequentially late packets is simply limited by the
> >        = offset p of the interpretation interval (see section 5.1.1).
>          = Decompression of a sequentially late packet with SN =3D x is
>          = possible if the value of the SN of the packet that last updated
>          the = context was less than or equal to x + p.
>
>          = Problems occur if context(SN) has increased by more than p with
>          = respect to field(SN) carried within the packet to decompress.
>
>          This = means that for a well-behaved stream with a constant unit
>          = increase in the RTP SN, a packet can arrive up to p packets out = of
>          = sequence and still be correctly decompressed. Otherwise, it = cannot
>          be = properly decompressed. It also means that if the compressor
>          = sends two consecutive packets with SN(packet1)=3D100 and
>          = SN(packet2)=3D108 when p=3D7, packet1 cannot be decompressed if = it
>          = arrives even one packet late due to reordering.
>
> >     Reordering = involving change packets
> >
> >        = When a packet is reordered and becomes sequentially late with
> >        = respect to a change packet, decompression of the late packet may
> >        = eventually fail, as the context information required for
> >        = successful decompression may not be available anymore.
>
>       = Decompression can always be verified since all U/O-mode packet = types
> >     are context = updating. Consequently, even if reordering of packets
> >     may in some cases = result in unsuccessful decompression, context
> >     invalidation due to = reordering can be avoided or detected. The risk
> >     of forwarding = incorrectly decompressed packets to upper layers is
> >     therefore small = when operating in U/O-mode. For channels known to
> >     reorder packets, = U/O-mode should therefore be the preferred mode of
>       operation. = The additional risk of losing context synchronization,
>       or for = erroneous packet to be delivered to upper layers, is limited.
>
>
> Does this capture what you were missing from the = draft?
> /L-E
>
>
> -----Original Message-----
> From: West, Mark [mailto:mark.a.west@roke.co.uk]=
> Sent: den 10 maj 2005 00:12
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: rohc@ietf.org
> Subject: RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt
>
>
> Hi Lars-Erik,
> Thanks for your suggested updates.  I have = a couple of follow-on comments
> (for brevity, I've chopped out stuff where the = update completely addresses
> my comment)...
> Cheers,
> Mark.
>
> >
> > % - Discard or Decompress?
> > % Overall, I didn't see much discussion = about whether the aim is to
> > % (i) detect sequentially late packets and = discard them; or
> > % (ii) detect sequentially late packets and = decompress them
> > % correctly.
> >
> > The goal in the long run is of course just = to "decompress correctly",
> > not necessarily even noticing reordering as = anything special. In the
> > short term, with only 3095 being available = as compression standard,
> > we will have to live with doing the best = possible, probably a mixture
> > of (i) and (ii). This document aims at = discussing the various aspects
> > of using ROHC over channels that can = reorder packets, including
> > identifying the challenges, as well as = suggesting both implementation
> > methods and future standards improvements = to better cope with
> > reordering. However, this document is not = aiming at specifying a
> > solution, i.e. there is no single goal like = your (i) or (ii).
> >
> Ok, that makes sense -- and maybe I should have = been clear that my 'or'
> was not necessarily an 'exclusive or' :-)
> The fact remains, though, that if you are trying = to correctly decompress
> re-ordered packets, there are more challenges = than are described.
> Specifically, the full version of my comments = argued that decompressing a
> sequentially late packet during the update of a = rarely-changing field (for
> example) is problematic (for detection, in an = R-mode scenario; and for
> correct decompression in U/O-mode).
> Unless I've missed something, then I do not see = how the draft can be
> complete without some discussion of this?
>

------_=_NextPart_001_01C55B32.EBA6D980-- --===============0184517433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0184517433==-- From rohc-bounces@ietf.org Tue May 17 18:55:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00353 for ; Tue, 17 May 2005 18:55:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYBF5-0000P9-CG for rohc-archive@ietf.org; Tue, 17 May 2005 19:12:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYAuW-0004d0-71; Tue, 17 May 2005 18:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYAuT-0004cv-No for rohc@megatron.ietf.org; Tue, 17 May 2005 18:51:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29984 for ; Tue, 17 May 2005 18:51:30 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYBBI-0000Dy-DR for rohc@ietf.org; Tue, 17 May 2005 19:08:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4HMpFqP002166; Tue, 17 May 2005 23:51:15 +0100 Received: from mjw-pc.roke.co.uk (mjw-pc.comm.ad.roke.co.uk [193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JF3JXJ6X; Tue, 17 May 2005 23:52:15 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Date: Tue, 17 May 2005 23:51:12 +0100 Message-ID: Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVbMxI+/spuYSSsSRW3d6RcWX7euQ== From: "West, Mark" To: "Lars-Erik Jonsson \(LU/EAB\)" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: b8a1197ccd66a793eeb911fe8a37f5bd Cc: rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0869445961==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 This is a multi-part message in MIME format. --===============0869445961== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55B33.11CC7980" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C55B33.11CC7980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Late, as ever! But having acked the proposed changes, I too like these adjustments :-) Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Thu, 12 May 2005, Lars-Erik Jonsson (LU/EAB) wrote: > Date: Thu, 12 May 2005 15:31:18 +0200 > From: "Lars-Erik Jonsson (LU/EAB)" > To: "Ghyslain Pelletier (LU/EAB)" , > "West, Mark" > Cc: rohc@ietf.org > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt > > I like these adjustments! > > I'm, however, still waiting for Mark to ack the proposed changes. > > /L-E > > > > -----Original Message----- > > From: Ghyslain Pelletier (LU/EAB) > > Sent: den 12 maj 2005 14:58 > > To: Lars-Erik Jonsson (LU/EAB); West, Mark > > Cc: rohc@ietf.org > > Subject: RE: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt > > > > > > Some quick picky nits on the proposed text. > > > > BR, > > > > /Ghyslain > > > > > > > > NEW: > > > 5.1.3. Reordering of Packets in U/O-mode > > > > > > > Reordering between non-change packets only > > > > > > > > When there is reordering of non-change packets > > only, the ability > > > > to decompress sequentially late packets is simply > > limited by the > > > > offset p of the interpretation interval (see > > section 5.1.1). > > > > Suggestion: > > > > " When only non-change packets are reordered with respect to each > > other, decompression of sequentially late packets is limited by > > the offset p of the interpretation interval (see section 5.1.1)." > > > > Because reordering of non-change packet may actually be > > interpreted as with respect to any other event or packet > > type, despite the usage of the word only. I actually tripped > > on that sentence... > > > > > Decompression of a sequentially late packet with SN =3D x = is > > > possible if the value of the SN of the packet that > > last updated > > > the context was less than or equal to x + p. > > > > > > Problems occur if context(SN) has increased by > > more than p with > > > respect to field(SN) carried within the packet to > > decompress. > > > > > > This means that for a well-behaved stream with a > > constant unit > > > increase in the RTP SN, a packet can arrive up to > > p packets out of > > > sequence and still be correctly decompressed. > > Otherwise, it cannot > > > be properly decompressed. It also means that if > > the compressor > > > sends two consecutive packets with SN(packet1)=3D100 and > > > SN(packet2)=3D108 when p=3D7, packet1 cannot be > > decompressed if it > > > arrives even one packet late due to reordering. > > > > > > > Reordering involving change packets > > > > > > > > When a packet is reordered and becomes > > sequentially late with > > > > respect to a change packet, decompression of the > > late packet may > > > > eventually fail, as the context information required for > > > > successful decompression may not be available anymore. > > > > > > Decompression can always be verified since all > > U/O-mode packet types > > > > are context updating. Consequently, even if > > reordering of packets > > > > may in some cases result in unsuccessful > > decompression, context > > > > invalidation due to reordering can be avoided or > > detected. The risk > > > > Suggestion: > > > > " Consequently, a failure to decompress a packet that is caused > > by reordering can be detected, and context invalidation due > > to reordering can thus be avoided." > > > > Because both "avoidance" and "detection" are applied to > > context invalidation in the proposed text, while in fact > > "detection" applies to the decompression failure and > > "avoidance" applies to context invalidatation. > > > > > > of forwarding incorrectly decompressed packets to > > upper layers is > > > > therefore small when operating in U/O-mode. For > > channels known to > > > > reorder packets, U/O-mode should therefore be the > > preferred mode of > > > operation. The additional risk of losing context > > synchronization, > > > or for erroneous packet to be delivered to upper > > layers, is limited. > > > > > > > > > Does this capture what you were missing from the draft? > > > /L-E > > > > > > > > > -----Original Message----- > > > From: West, Mark [mailto:mark.a.west@roke.co.uk] > > > Sent: den 10 maj 2005 00:12 > > > To: Lars-Erik Jonsson (LU/EAB) > > > Cc: rohc@ietf.org > > > Subject: RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt > > > > > > > > > Hi Lars-Erik, > > > Thanks for your suggested updates. I have a couple of > > > follow-on comments > > > (for brevity, I've chopped out stuff where the update > > > completely addresses > > > my comment)... > > > Cheers, > > > Mark. > > > > > > > > > > > % - Discard or Decompress? > > > > % Overall, I didn't see much discussion about whether the > > aim is to > > > > % (i) detect sequentially late packets and discard them; or > > > > % (ii) detect sequentially late packets and decompress them > > > > % correctly. > > > > > > > > The goal in the long run is of course just to "decompress > > > correctly", > > > > not necessarily even noticing reordering as anything > > > special. In the > > > > short term, with only 3095 being available as compression > > standard, > > > > we will have to live with doing the best possible, probably > > > a mixture > > > > of (i) and (ii). This document aims at discussing the > > > various aspects > > > > of using ROHC over channels that can reorder packets, including > > > > identifying the challenges, as well as suggesting both > > > implementation > > > > methods and future standards improvements to better cope with > > > > reordering. However, this document is not aiming at specifying a > > > > solution, i.e. there is no single goal like your (i) or (ii). > > > > > > > Ok, that makes sense -- and maybe I should have been clear > > > that my 'or' > > > was not necessarily an 'exclusive or' :-) > > > The fact remains, though, that if you are trying to correctly > > > decompress > > > re-ordered packets, there are more challenges than are described. > > > Specifically, the full version of my comments argued that > > > decompressing a > > > sequentially late packet during the update of a > > > rarely-changing field (for > > > example) is problematic (for detection, in an R-mode > > > scenario; and for > > > correct decompression in U/O-mode). > > > Unless I've missed something, then I do not see how the > > draft can be > > > complete without some discussion of this? > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > ------_=_NextPart_001_01C55B33.11CC7980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt

Late, as ever!  But having acked the proposed = changes, I too like these
adjustments :-)

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 = 0ZN
Phone +44 (0)1794 833311   Fax  +44 = (0)1794 833433

On Thu, 12 May 2005, Lars-Erik Jonsson (LU/EAB) = wrote:

> Date: Thu, 12 May 2005 15:31:18 +0200
> From: "Lars-Erik Jonsson (LU/EAB)" = <lars-erik.jonsson@ericsson.com>
> To: "Ghyslain Pelletier (LU/EAB)" = <ghyslain.pelletier@ericsson.com>,
>      "West, = Mark" <mark.a.west@roke.co.uk>
> Cc: rohc@ietf.org
> Subject: RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt
>
> I like these adjustments!
>
> I'm, however, still waiting for Mark to ack the = proposed changes.
>
> /L-E
>
>
> > -----Original Message-----
> > From: Ghyslain Pelletier (LU/EAB)
> > Sent: den 12 maj 2005 14:58
> > To: Lars-Erik Jonsson (LU/EAB); West, = Mark
> > Cc: rohc@ietf.org
> > Subject: RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt
> >
> >
> > Some quick picky nits on the proposed = text.
> >
> > BR,
> >
> > /Ghyslain
> >
> > >
> > > NEW:
> > >    5.1.3. Reordering of = Packets in U/O-mode
> > >
> > > >     = Reordering between non-change packets only
> > > >
> > > = >        When there is reordering = of non-change packets
> > only, the ability
> > > = >        to decompress = sequentially late packets is simply
> > limited by the
> > > = >        offset p of the = interpretation interval (see
> > section 5.1.1).
> >
> > Suggestion:
> >
> > " When only non-change packets are = reordered with respect to each
> >   other, decompression of = sequentially late packets is limited by
> >   the offset p of the = interpretation interval (see section 5.1.1)."
> >
> > Because reordering of non-change packet may = actually be
> > interpreted as with respect to any other = event or packet
> > type, despite the usage of the word only. I = actually tripped
> > on that sentence...
> >
> > = >          Decompression = of a sequentially late packet with SN =3D x is
> > = >          possible if = the value of the SN of the packet that
> > last updated
> > = >          the context = was less than or equal to x + p.
> > >
> > = >          Problems = occur if context(SN) has increased by
> > more than p with
> > = >          respect to = field(SN) carried within the packet to
> > decompress.
> > >
> > = >          This means = that for a well-behaved stream with a
> > constant unit
> > = >          increase in = the RTP SN, a packet can arrive up to
> > p packets out of
> > = >          sequence and = still be correctly decompressed.
> > Otherwise, it cannot
> > = >          be properly = decompressed. It also means that if
> > the compressor
> > = >          sends two = consecutive packets with SN(packet1)=3D100 and
> > = >          = SN(packet2)=3D108 when p=3D7, packet1 cannot be
> > decompressed if it
> > = >          arrives even = one packet late due to reordering.
> > >
> > > >     = Reordering involving change packets
> > > >
> > > = >        When a packet is = reordered and becomes
> > sequentially late with
> > > = >        respect to a change = packet, decompression of the
> > late packet may
> > > = >        eventually fail, as the = context information required for
> > > = >        successful decompression = may not be available anymore.
> > >
> > >       = Decompression can always be verified since all
> > U/O-mode packet types
> > > >     are = context updating. Consequently, even if
> > reordering of packets
> > > >     may in = some cases result in unsuccessful
> > decompression, context
> > > >     = invalidation due to reordering can be avoided or
> > detected. The risk
> >
> > Suggestion:
> >
> > " Consequently, a failure to = decompress a packet that is caused
> >   by reordering can be detected, = and context invalidation due
> >   to reordering can thus be = avoided."
> >
> > Because both "avoidance" and = "detection" are applied to
> > context invalidation in the proposed text, = while in fact
> > "detection" applies to the = decompression failure and
> > "avoidance" applies to context = invalidatation.
> >
> > > >     of = forwarding incorrectly decompressed packets to
> > upper layers is
> > > >     therefore = small when operating in U/O-mode. For
> > channels known to
> > > >     reorder = packets, U/O-mode should therefore be the
> > preferred mode of
> > >       = operation. The additional risk of losing context
> > synchronization,
> > >       or = for erroneous packet to be delivered to upper
> > layers, is limited.
> > >
> > >
> > > Does this capture what you were = missing from the draft?
> > > /L-E
> > >
> > >
> > > -----Original Message-----
> > > From: West, Mark [mailto:mark.a.west@roke.co.uk]=
> > > Sent: den 10 maj 2005 00:12
> > > To: Lars-Erik Jonsson (LU/EAB)
> > > Cc: rohc@ietf.org
> > > Subject: RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt
> > >
> > >
> > > Hi Lars-Erik,
> > > Thanks for your suggested = updates.  I have a couple of
> > > follow-on comments
> > > (for brevity, I've chopped out stuff = where the update
> > > completely addresses
> > > my comment)...
> > > Cheers,
> > > Mark.
> > >
> > > >
> > > > % - Discard or Decompress?
> > > > % Overall, I didn't see much = discussion about whether the
> > aim is to
> > > > % (i) detect sequentially late = packets and discard them; or
> > > > % (ii) detect sequentially late = packets and decompress them
> > > > % correctly.
> > > >
> > > > The goal in the long run is of = course just to "decompress
> > > correctly",
> > > > not necessarily even noticing = reordering as anything
> > > special. In the
> > > > short term, with only 3095 being = available as compression
> > standard,
> > > > we will have to live with doing = the best possible, probably
> > > a mixture
> > > > of (i) and (ii). This document = aims at discussing the
> > > various aspects
> > > > of using ROHC over channels that = can reorder packets, including
> > > > identifying the challenges, as = well as suggesting both
> > > implementation
> > > > methods and future standards = improvements to better cope with
> > > > reordering. However, this = document is not aiming at specifying a
> > > > solution, i.e. there is no single = goal like your (i) or (ii).
> > > >
> > > Ok, that makes sense -- and maybe I = should have been clear
> > > that my 'or'
> > > was not necessarily an 'exclusive or' = :-)
> > > The fact remains, though, that if you = are trying to correctly
> > > decompress
> > > re-ordered packets, there are more = challenges than are described.
> > > Specifically, the full version of my = comments argued that
> > > decompressing a
> > > sequentially late packet during the = update of a
> > > rarely-changing field (for
> > > example) is problematic (for = detection, in an R-mode
> > > scenario; and for
> > > correct decompression in = U/O-mode).
> > > Unless I've missed something, then I = do not see how the
> > draft can be
> > > complete without some discussion of = this?
> > >
> > > = _______________________________________________
> > > Rohc mailing list
> > > Rohc@ietf.org
> > > https://www1.ietf.or= g/mailman/listinfo/rohc
> > >
> >
>

------_=_NextPart_001_01C55B33.11CC7980-- --===============0869445961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0869445961==-- From rohc-bounces@ietf.org Fri May 20 10:30:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22349 for ; Fri, 20 May 2005 10:30:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8nf-0003RN-Rx for rohc-archive@ietf.org; Fri, 20 May 2005 10:48:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8Vv-0007Fl-3A; Fri, 20 May 2005 10:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8Vs-0007FX-V8 for rohc@megatron.ietf.org; Fri, 20 May 2005 10:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22274 for ; Fri, 20 May 2005 10:30:06 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8nD-0003QI-NG for rohc@ietf.org; Fri, 20 May 2005 10:48:06 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4KETdhI023498 for ; Fri, 20 May 2005 16:30:04 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 16:30:01 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 16:30:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 May 2005 16:30:00 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DB69@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVbMuwl0ZT+l/90RXyfiLmAOh3VIwCFIQuw From: "Ghyslain Pelletier \(LU/EAB\)" To: X-OriginalArrivalTime: 20 May 2005 14:30:01.0097 (UTC) FILETIME=[67D50790:01C55D48] X-Spam-Score: 0.8 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [rohc] Small comment on draft-ietf-rohc-rtp-lla-impl-guide-01.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2085430082==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. --===============2085430082== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D48.67A33FD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D48.67A33FD4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One small comment to section 3 "CSP Packet Format" regarding the = proposed new format - the new proposed format means that any RHP packet = carried within the CSP must carry the additional 2 octets RTP Payload = Length Field. =20 However, this is not necessary for IR and IR-DYN packets - it could then = be possible to specify that this field is present only for RHP packet = types that are of a type other than IR and IR-DYN, so that when these = larger headers are carried within the CSP the additional overhead of the = new field could be avoided. Doing so, I might be useful for parsing to = move the RTP Payload Length Field at the end of the CSP instead, so that = the RHP packet type is always at the same position no matter if the RTP = Payload Length Field is present or not. =20 I understand that for the IR packet there exist another alternative than = the CSP in order to do frame stealing, which is more efficient than = using the CSP, but yet it seems a better choice to make any alternative = as efficient as possible. =20 /Ghyslain =20 ------_=_NextPart_001_01C55D48.67A33FD4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] Review of = draft-ietf-rohc-over-reordering-02.txt
One small comment to section 3 "CSP Packet Format" = regarding=20 the proposed new format - the new proposed format means that any RHP = packet=20 carried within the CSP must carry the additional 2 octets RTP Payload = Length=20 Field.
 
However, this is not necessary for IR and IR-DYN = packets - it=20 could then be possible to specify that this field is present only for = RHP packet=20 types that are of a type other than IR and IR-DYN, so that when = these=20 larger headers are carried within the CSP the additional overhead of the = new=20 field could be avoided. Doing so, I might be useful for parsing to = move=20 the RTP Payload Length Field at the end of the CSP instead, so that = the RHP=20 packet type is always at the same position no matter if the RTP Payload = Length=20 Field is present or not.
 
I=20 understand that for the IR packet there exist another alternative than = the CSP=20 in order to do frame stealing, which is more efficient than using the = CSP, but=20 yet it seems a better choice to make any alternative = as efficient as=20 possible.
 
/Ghyslain
 
------_=_NextPart_001_01C55D48.67A33FD4-- --===============2085430082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============2085430082==-- From rohc-bounces@ietf.org Fri May 20 15:49:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04889 for ; Fri, 20 May 2005 15:49:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDmW-0006Q9-TR for rohc-archive@ietf.org; Fri, 20 May 2005 16:07:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDLY-0000qN-7I; Fri, 20 May 2005 15:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDLT-0000lR-Jo; Fri, 20 May 2005 15:39:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01400; Fri, 20 May 2005 15:39:41 -0400 (EDT) Message-Id: <200505201939.PAA01400@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 20 May 2005 15:39:41 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rfc3242bis-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP Author(s) : L. Jonsson, et al. Filename : draft-ietf-rohc-rfc3242bis-00.txt Pages : 21 Date : 2005-5-20 This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. This document is a replacement for RFC 3242, which it obsoletes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3242bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rfc3242bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rfc3242bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-20154629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rfc3242bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rfc3242bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-20154629.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Mon May 23 02:54:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24281 for ; Mon, 23 May 2005 02:54:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da77d-00050o-HT for rohc-archive@ietf.org; Mon, 23 May 2005 03:13:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da6pK-00058w-PV; Mon, 23 May 2005 02:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da6pJ-00058r-Ea for rohc@megatron.ietf.org; Mon, 23 May 2005 02:54:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24268 for ; Mon, 23 May 2005 02:54:12 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da77D-00050S-Ry for rohc@ietf.org; Mon, 23 May 2005 03:12:45 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4N6rmhb005908 for ; Mon, 23 May 2005 08:54:09 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 08:53:38 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 08:53:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Small comment on draft-ietf-rohc-rtp-lla-impl-guide-01.txt Date: Mon, 23 May 2005 08:53:38 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05B743D4@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVbMuwl0ZT+l/90RXyfiLmAOh3VIwCFIQuwAIa1D8A= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , X-OriginalArrivalTime: 23 May 2005 06:53:38.0744 (UTC) FILETIME=[25EACB80:01C55F64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Ghyslain, I can see your point, and I agree that the RTP length is not needed for = IR or IR-DYN CSP's. In general, I also agree we should not waste unnecessary = bits, if not justified by simplicity or other good reasons. However, I do not see the big deal with this, as the relative extra = overhead is still small. Further, and more important, I think the solution we = have is more straightforward and simple. Finally, and most important, this is = the solution we came up with as our official solution when the problem was=20 observed a year ago. Before we change that today, I think we should have really good arguments. So, I think you have a good point, but without more convincing arguments for the value of changing the current solution, I believe we should = stick to status quo. By the way, what has been in draft-ietf-rohc-rtp-lla-impl-guide-01.txt since last year is now, as suggested by Allison, incorporated in=20 draft-ietf-rohc-rfc3242bis-00.txt, which is intended to generate a replacement for rfc3242. BR /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Ghyslain Pelletier(LU/EAB) > Sent: den 20 maj 2005 16:30 > To: rohc@ietf.org > Subject: [rohc] Small comment on = draft-ietf-rohc-rtp-lla-impl-guide-01.txt > > > One small comment to section 3 "CSP Packet Format" regarding the = proposed > new format - the new proposed format means that any RHP packet carried > within the CSP must carry the additional 2 octets RTP Payload Length = Field. > > However, this is not necessary for IR and IR-DYN packets - it could = then > be possible to specify that this field is present only for RHP packet = types > that are of a type other than IR and IR-DYN, so that when these larger > headers are carried within the CSP the additional overhead of the new = field > could be avoided. Doing so, I might be useful for parsing to move the = RTP > Payload Length Field at the end of the CSP instead, so that the RHP = packet > type is always at the same position no matter if the RTP Payload = Length > Field is present or not. > > I understand that for the IR packet there exist another alternative = than > the CSP in order to do frame stealing, which is more efficient than = using > the CSP, but yet it seems a better choice to make any alternative as > efficient as possible. > > /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 23 04:35:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02096 for ; Mon, 23 May 2005 04:35:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da8hk-0003ka-OV for rohc-archive@ietf.org; Mon, 23 May 2005 04:54:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da8PR-0007qO-AN; Mon, 23 May 2005 04:35:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da8PQ-0007qJ-13 for rohc@megatron.ietf.org; Mon, 23 May 2005 04:35:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02076 for ; Mon, 23 May 2005 04:35:34 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da8hJ-0003jy-AB for rohc@ietf.org; Mon, 23 May 2005 04:54:05 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4N8Xsig016455 for ; Mon, 23 May 2005 10:35:28 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 10:35:16 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 10:35:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Small comment on draft-ietf-rohc-rtp-lla-impl-guide-01.txt Date: Mon, 23 May 2005 10:35:16 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0527DB6C@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVbMuwl0ZT+l/90RXyfiLmAOh3VIwCFIQuwAIa1D8AAAqvzkA== From: "Ghyslain Pelletier \(LU/EAB\)" To: "Lars-Erik Jonsson \(LU/EAB\)" , X-OriginalArrivalTime: 23 May 2005 08:35:16.0743 (UTC) FILETIME=[589B9970:01C55F72] X-Spam-Score: 1.1 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable > However, I do not see the big deal with this, as the relative=20 > extra overhead is still small. Further, and more important, I think = the=20 > solution we have is more straightforward and simple. Clearly, simplicity is not something that was the priority when making = this profile - it was rather efficiency, and I don't see what it is that = is not straightforward in my proposal. The reason why IR and IR-DYN = packets don't need to carry this information are quite straightforward = as well... Anyway, I think that the arguments in favor of saving these two octets = for IR and IR-DYN packets, even if one could use 3095 frame stealing = instead, are rather compelling. Consider: 1) LLA was made to adapt an application payload rate that is exactly the same rate as the synchronized link. As twisted a requirement this = might be, the reason to do this was the priority to make sure that _every_ = single octet that could be removed would be removed.=20 2) On the links targeted by LLA (IS-95), most likely the IR and IR-DYN will have to be segmented using RoHC segmentation (already some additional overhead there). Would the addition of these redundant two octets for the RTP payload length cause an additional segment to be sent, then this is yet another 20 ms of application payload that needs to be dropped or delayed (multiply this by the OAA approach, i.e. normally 3 such packets must be sent). This can certainly happen depending on how the LL frame sizes vary when sending these packets (on SO61, the full rate can not be guaranteed for each physical frame), there is no way to guarantee that this extra two octets will _never_ waste an additional 20 ms frame (times OAA). Of course, the alternative way to use the (poorly described) frame = stealing of 3095 could (should?) also be clarified in the draft as well = as an alternative, but yet I'd rather have this one right as well in any = case.=20 > Finally, and most important, this is the solution we came up > with as our official solution when the problem was observed > a year ago. Before we change that today, I think we should have > really good arguments. See above. Furthermore, my understanding of the document that you are = referring to (LLA implementer's guide) is that this is an informational = draft, nothing normative. Now that we've submitted a new draft to make = the corrections normative, this is where we define the "official = solution" from my perspective.=20 =20 > So, I think you have a good point, but without more convincing > arguments for the value of changing the current solution, I believe we = > should stick to status quo. See above. The proposal I made in the previous mail is straightforward = and simple. Please provide arguments _against_ instead. I really don't see your point with "let's keep things as they are because this is how = the've been" for such a trivial proposal. =20 > By the way, what has been in draft-ietf-rohc-rtp-lla-impl-guide-01.txt > since last year is now, as suggested by Allison, incorporated in=20 > draft-ietf-rohc-rfc3242bis-00.txt, which is intended to generate a > replacement for rfc3242. I know, my name's on it ; ) - I guess you meant to notify others of this = new submission. =20 > BR > /L-E >=20 >=20 > > -----Original Message----- > > From: rohc-bounces@ietf.org=20 > [mailto:rohc-bounces@ietf.org]On Behalf Of > > Ghyslain Pelletier(LU/EAB) > > Sent: den 20 maj 2005 16:30 > > To: rohc@ietf.org > > Subject: [rohc] Small comment on=20 > draft-ietf-rohc-rtp-lla-impl-guide-01.txt > > > > > > One small comment to section 3 "CSP Packet Format"=20 > regarding the proposed > > new format - the new proposed format means that any RHP=20 > packet carried > > within the CSP must carry the additional 2 octets RTP=20 > Payload Length Field. > > > > However, this is not necessary for IR and IR-DYN packets -=20 > it could then > > be possible to specify that this field is present only for=20 > RHP packet types > > that are of a type other than IR and IR-DYN, so that when=20 > these larger > > headers are carried within the CSP the additional overhead=20 > of the new field > > could be avoided. Doing so, I might be useful for parsing=20 > to move the RTP > > Payload Length Field at the end of the CSP instead, so that=20 > the RHP packet > > type is always at the same position no matter if the RTP=20 > Payload Length > > Field is present or not. > > > > I understand that for the IR packet there exist another=20 > alternative than > > the CSP in order to do frame stealing, which is more=20 > efficient than using > > the CSP, but yet it seems a better choice to make any alternative as > > efficient as possible. > > > > /Ghyslain >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 23 06:12:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10515 for ; Mon, 23 May 2005 06:12:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaADY-00043Q-Sm for rohc-archive@ietf.org; Mon, 23 May 2005 06:31:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9uZ-000141-Js; Mon, 23 May 2005 06:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9uY-00013p-1J for rohc@megatron.ietf.org; Mon, 23 May 2005 06:11:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10475 for ; Mon, 23 May 2005 06:11:47 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaACV-00042T-6k for rohc@ietf.org; Mon, 23 May 2005 06:30:23 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4NABJgu006764 for ; Mon, 23 May 2005 12:11:48 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 12:11:46 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 12:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Small comment on draft-ietf-rohc-rtp-lla-impl-guide-01.txt Date: Mon, 23 May 2005 12:11:46 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05B743D8@esealmw109.eemea.ericsson.se> Thread-Topic: [rohc] Review of draft-ietf-rohc-over-reordering-02.txt Thread-Index: AcVbMuwl0ZT+l/90RXyfiLmAOh3VIwCFIQuwAIa1D8AAAqvzkAAEO82A From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ghyslain Pelletier \(LU/EAB\)" , X-OriginalArrivalTime: 23 May 2005 10:11:46.0600 (UTC) FILETIME=[D3A1AA80:01C55F7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Ghyslain, I agree with your technical point, and if this had been suggested a year ago, I had probably bought it without any concerns.=20 > > Finally, and most important, this is the solution we came up > > with as our official solution when the problem was observed > > a year ago. Before we change that today, I think we should have > > really good arguments. >=20 > See above. Furthermore, my understanding of the document that=20 > you are referring to (LLA implementer's guide) is that this=20 > is an informational draft, nothing normative. Now that we've=20 > submitted a new draft to make the corrections normative, this=20 > is where we define the "official solution" from my perspective.=20 3242 is non-interoperable with CSP, so we had to come up with a solution. The agreed and official WG solution has been captured in the LLA implementer's guide, in the same way as we have done for RFC3095 with the ROHC implementer's guide. The LLA implementer's guide is a draft, correct (a draft has no category), but it is the most normative source that has been available. The solution has been stable, and we have not identified more flaws, therefore it is time to replace 3242 with a corrected RFC that incorporates this fix. So, the main argument I see for keeping the current solution is that it has been there for a year, and the actual performance argument against it is rather small. The argument for doing a change is technical, we would not "waste" two bytes in certain corner-cases. Also, if deployment of the existing solution is insignificantly limited, it might be a good idea to do this change. I do not see an obvious way out here, one may question the actual problem with doing this change, but one may also question the efficiency argument in favour of the change. However, right now I would say we should do this change, if we do not get more input from others, preferably from those who have implemented the RFC with the existing fix. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 23 16:17:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15971 for ; Mon, 23 May 2005 16:17:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaJeM-00073m-N2 for rohc-archive@ietf.org; Mon, 23 May 2005 16:35:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIsk-0003MZ-AG; Mon, 23 May 2005 15:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIsh-0003Lx-KG; Mon, 23 May 2005 15:46:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03576; Mon, 23 May 2005 15:46:30 -0400 (EDT) Message-Id: <200505231946.PAA03576@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 23 May 2005 15:46:30 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-12.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : ROHC Implementer's Guide Author(s) : L. Jonsson, P. Kremer Filename : draft-ietf-rohc-rtp-impl-guide-12.txt Pages : 27 Date : 2005-5-23 This document clarifies common misinterpretations and some ambiguous points of RFC 3095, which defines the framework and four profiles of the robust and efficient header compression scheme (ROHC). It also addresses minor interpretation details of RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles). These issues have been identified by members of the ROHC working group, during implementation and at interoperability test events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rtp-impl-guide-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23145032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23145032.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Wed May 25 20:29:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12233 for ; Wed, 25 May 2005 20:29:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6YD-0007Xm-Ap for rohc-archive@ietf.org; Wed, 25 May 2005 20:48:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6Cz-00048c-1p; Wed, 25 May 2005 20:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6Cx-00048R-UA; Wed, 25 May 2005 20:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11516; Wed, 25 May 2005 20:26:42 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6VS-0007HA-7G; Wed, 25 May 2005 20:45:50 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4Q0PcL23786; Wed, 25 May 2005 17:25:38 -0700 (PDT) Message-Id: <200505260025.j4Q0PcL23786@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 25 May 2005 17:25:38 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: rohc@ietf.org, rfc-editor@rfc-editor.org Subject: [rohc] RFC 4077 on A Negative Acknowledgement Mechanism for Signaling Compression X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4077 Title: A Negative Acknowledgement Mechanism for Signaling Compression Author(s): A.B. Roach Status: Standards Track Date: May 2005 Mailbox: adam@estacado.net Pages: 16 Characters: 34250 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-sigcomp-nack-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4077.txt This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. This document is a product of the Robust Header Compression Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050525172432.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4077 --OtherAccess Content-Type: Message/External-body; name="rfc4077.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050525172432.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu May 26 11:39:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06981 for ; Thu, 26 May 2005 11:39:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKkk-0003pB-19 for rohc-archive@ietf.org; Thu, 26 May 2005 11:58:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKQs-0000W8-Lh; Thu, 26 May 2005 11:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKQq-0000W3-HT for rohc@megatron.ietf.org; Thu, 26 May 2005 11:38:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06894 for ; Thu, 26 May 2005 11:37:57 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKjR-0003n5-MX for rohc@ietf.org; Thu, 26 May 2005 11:57:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QFYttT003884 for ; Thu, 26 May 2005 18:35:01 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 18:37:54 +0300 Received: from agni.research.nokia.com ([172.21.35.82]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 26 May 2005 18:37:54 +0300 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.11/8.12.11) with ESMTP id j4QFAr5H015129; Thu, 26 May 2005 18:10:53 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.11/8.12.11/Submit) id j4QElepZ014415; Thu, 26 May 2005 17:47:40 +0300 To: Cristian CONSTANTIN Subject: Re: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <20050517130351.GR1276@terix.fokus.gmd.de> (Cristian CONSTANTIN's message of "Tue, 17 May 2005 15:03:51 +0200") References: <3F2E01E1D7B04F4EBEC92D3FA324D8803D5FC8@rsys004a> <20050517130351.GR1276@terix.fokus.gmd.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) Date: Thu, 26 May 2005 17:47:40 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 26 May 2005 15:37:54.0059 (UTC) FILETIME=[E1FC35B0:01C56208] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cristian CONSTANTIN writes: >1. a new state item is created and it will be pointed to from this >compartment. wouldn't this contradict the statement from 9.4.5. >STATE-ACCESS (sigcomp rfc) that says: >"Decompression failure also occurs [...] if more than one state item >matches the partial identifier [...]" ? >that is the first STATE-ACCESS trying to access this state will give a >decompression failure (if we suppose that none of 2 identic states has >been freed already) Yes. That is the problem of compressor, I'm afraid. It should detect this thing in first place and use longer minimum_access_length for the new state (which will also incidentally change the state-ID). --Pekka >> > -----Original Message----- >> > From: cristian CONSTANTIN [mailto:constantin@fokus.fraunhofer.de] >> > Sent: Saturday, May 14, 2005 11:43 PM >> > To: rohc@ietf.org >> > Subject: [rohc] sigcomp - state_identifier matching an >> > existing one at a STATE-CREATE >> hi! >> suppose that a STATE-CREATE tries to create a state with a >> state_identifier that matches (taking into account the >> minimum_access_length) another state which already exists in the same >> compartment. >> what should happen? >> 1. create a new state (even though the state_identifiers will overlap) >> 2. drop the old one? >> 3. drop the new one? >> bye now! >> cristian >> -- >> _ | There are many people who use UNIX or Linux >> (_'_ | who IMHO do not understand UNIX. >> (_'rist | --David Korn >> GPG public key at wwwkeys.de.pgp.net _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu May 26 11:39:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07007 for ; Thu, 26 May 2005 11:39:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKks-0003qF-7V for rohc-archive@ietf.org; Thu, 26 May 2005 11:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKR4-0000Xg-3e; Thu, 26 May 2005 11:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKR3-0000XS-7E for rohc@megatron.ietf.org; Thu, 26 May 2005 11:38:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06897 for ; Thu, 26 May 2005 11:38:10 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKje-0003nC-Ea for rohc@ietf.org; Thu, 26 May 2005 11:57:27 -0400 Received: from esebh105.NOE.Nokia.com ([172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4QFc6E2026497 for ; Thu, 26 May 2005 18:38:07 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 18:38:07 +0300 Received: from agni.research.nokia.com ([172.21.35.82]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 26 May 2005 18:38:06 +0300 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.11/8.12.11) with ESMTP id j4QFAr5F015129 for ; Thu, 26 May 2005 18:10:53 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.11/8.12.11/Submit) id j4QF5XbH014501; Thu, 26 May 2005 18:05:33 +0300 To: rohc@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Thu, 26 May 2005 18:05:33 +0300 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 26 May 2005 15:38:06.0422 (UTC) FILETIME=[E95AA760:01C56208] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [rohc] MULTILOAD operands X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hello all, There is language about decoding and executing the MULTILOAD instruction: Decompression failure occurs if the set of 2-byte words set by the instruction would overlap the memory locations held by the instruction (including its operands) itself, i.e., if the instruction would be self-modifying. Now, if we have a MULTILOAD instruction like this: at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) set (f_bit, 4) set (h_bit, 2) set (p_bit, 1) :decompressed_pointer pad (2) align (64) :initialize_memory MULTILOAD (byte_copy_left, , circular_buffer, udvm_memory_size, (f_bit|p_bit), $byte_copy_left) Is it supposed to fail, or not? If not, what is the expected value of $decompressed_pointer, circular_buffer or 0? --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon May 30 07:01:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05331 for ; Mon, 30 May 2005 07:01:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DciKW-00061p-R9 for rohc-archive@ietf.org; Mon, 30 May 2005 07:21:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DchxL-0005lG-El; Mon, 30 May 2005 06:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DchxK-0005lB-9V for rohc@megatron.ietf.org; Mon, 30 May 2005 06:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05074 for ; Mon, 30 May 2005 06:57:11 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DciGh-0005wo-VB for rohc@ietf.org; Mon, 30 May 2005 07:17:17 -0400 Received: from tipau.fokus.fraunhofer.de (tipau [10.147.65.84]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4UAuum17560; Mon, 30 May 2005 12:56:57 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau.fokus.fraunhofer.de (8.12.7/8.8.8) with ESMTP id j4UAupKu012342; Mon, 30 May 2005 12:56:51 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j4UAupjt012341; Mon, 30 May 2005 12:56:51 +0200 From: Cristian CONSTANTIN Date: Mon, 30 May 2005 12:56:51 +0200 To: Pekka Pessi Subject: Re: [rohc] MULTILOAD operands Message-ID: <20050530105651.GO5117@terix.fokus.gmd.de> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0006844087==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0006844087== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wfe1KbQWcwuymTys" Content-Disposition: inline --Wfe1KbQWcwuymTys Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 26, 2005 at 06:05:33PM +0300, Pekka Pessi wrote: > Hello all, >=20 > There is language about decoding and executing the MULTILOAD > instruction: >=20 > Decompression failure occurs if the set of 2-byte words set by the > instruction would overlap the memory locations held by the > instruction (including its operands) itself, i.e., if the instruction > would be self-modifying. =20 >=20 > Now, if we have a MULTILOAD instruction like this:=20 >=20 > at (64)=20 > =20 > :byte_copy_left pad (2)=20 > :byte_copy_right pad (2)=20 > :input_bit_order pad (2) > set (f_bit, 4) > set (h_bit, 2) > set (p_bit, 1) > :decompressed_pointer pad (2)=20 > =20 > align (64) > =20 > :initialize_memory=20 > =20 > MULTILOAD (byte_copy_left, ,=20 > circular_buffer, udvm_memory_size, (f_bit|p_bit), $byte_copy_left) > =20 > Is it supposed to fail, or not? If not, what is the expected value > of $decompressed_pointer, circular_buffer or 0? cristian: now, your MULTILOAD instruction is located at byte 0x80=20 and it's writing 4 shorts (8 bytes) starting at 0x40 up to 0x48; there is a "gap" of 56 bytes btw. the last address MULTILOAD is writing to and the location where MULTILOAD is loaded; so MULTILOAD is not overwriting itself. (it is NOT self-modifying) since the sigcomp rfc also specifies about MULTILOAD (9.2.2 MULTILOAD): "[...] whilst the operands value_0 through to value_n-1 specify the values to load into these words (in the same order as they appear in the instruction)." I suppose that the value is must to be circular_buffer. (this is at least how I understand/interpret the whole stuff). hope it helps. cristian --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --Wfe1KbQWcwuymTys Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCmvFzypNgyZIZ1MERAuKxAJ9TAgzmKUKVnFqL6vgLRnlK1oCuagCfVSu+ 1u9I7D+OvI71DwriN+mkBbU= =bVmv -----END PGP SIGNATURE----- --Wfe1KbQWcwuymTys-- --===============0006844087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0006844087==-- From rohc-bounces@ietf.org Mon May 30 07:28:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07075 for ; Mon, 30 May 2005 07:28:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcil7-0006Yb-PW for rohc-archive@ietf.org; Mon, 30 May 2005 07:48:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DciQh-0000TD-GA; Mon, 30 May 2005 07:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DciQf-0000T8-O5 for rohc@megatron.ietf.org; Mon, 30 May 2005 07:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07017 for ; Mon, 30 May 2005 07:27:32 -0400 (EDT) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcik3-0006XI-MO for rohc@ietf.org; Mon, 30 May 2005 07:47:37 -0400 Received: from tipau.fokus.fraunhofer.de (tipau [10.147.65.84]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4UBRUm27612 for ; Mon, 30 May 2005 13:27:31 +0200 (MEST) Received: from tipau.fokus.fraunhofer.de (localhost [127.0.0.1]) by tipau.fokus.fraunhofer.de (8.12.7/8.8.8) with ESMTP id j4UBRPKu012631 for ; Mon, 30 May 2005 13:27:25 +0200 Received: (from cco@localhost) by tipau.fokus.fraunhofer.de (8.12.7/8.12.1/Debian -1) id j4UBRPh5012630 for rohc@ietf.org; Mon, 30 May 2005 13:27:25 +0200 From: Cristian CONSTANTIN Date: Mon, 30 May 2005 13:27:25 +0200 To: rohc@ietf.org Message-ID: <20050530112725.GP5117@terix.fokus.gmd.de> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [rohc] operator "!" in the udvm assembly (draft-ietf-rohc-sigcomp-user-guide-01.txt) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1372079593==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 --===============1372079593== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Vr2UxLU0KdcKBaxP" Content-Disposition: inline --Vr2UxLU0KdcKBaxP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi! the operator "!" for the udvm assembly language is defined like follows (excerpt from draft-ietf-rohc-sigcomp-user-guide-01.txt): "When the symbol "!" is encountered it is replaced by the location in the bytecode of the closest DECOMPRESSION-FAILURE instruction (i.e. the closest zero byte)." is there any technique for an udvm assembler to detect (at "assemble time") the closest zero byte=20 to a given address so that this byte is really going to be a DECOMPRESSION-FAILURE instruction at run time and NOT some data that=20 is supposed to be loaded with some other value or some self-modifying=20 instruction? (I'm taking into account here the peculiarities of the udvm code: mixed data and code, self-modifying code) bye now! cristian --=20 _ | There are many people who use UNIX or Linux =20 (_'_ | who IMHO do not understand UNIX. (_'rist | --David Korn =20 GPG public key at wwwkeys.de.pgp.net --Vr2UxLU0KdcKBaxP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCmvidypNgyZIZ1MERAgiNAJsGhXofM59ftROW7ftXCg7TkkyvaACgwy4c fw7dIvAuEgbg6ahJXxQ+9PA= =9NVg -----END PGP SIGNATURE----- --Vr2UxLU0KdcKBaxP-- --===============1372079593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1372079593==-- From rohc-bounces@ietf.org Mon May 30 07:36:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07401 for ; Mon, 30 May 2005 07:36:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcisw-0006gi-Pf for rohc-archive@ietf.org; Mon, 30 May 2005 07:56:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DciYi-00018n-4G; Mon, 30 May 2005 07:35:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DciYg-00018i-GE for rohc@megatron.ietf.org; Mon, 30 May 2005 07:35:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07358 for ; Mon, 30 May 2005 07:35:49 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcis4-0006fF-Cz for rohc@ietf.org; Mon, 30 May 2005 07:55:53 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j4UBZYcp010261; Mon, 30 May 2005 13:35:36 +0200 (MEST) In-Reply-To: <20050530112725.GP5117@terix.fokus.gmd.de> References: <20050530112725.GP5117@terix.fokus.gmd.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] operator "!" in the udvm assembly (draft-ietf-rohc-sigcomp-user-guide-01.txt) Date: Mon, 30 May 2005 13:35:46 +0200 To: Cristian CONSTANTIN X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi Cristian, On May 30 2005, at 13:27 Uhr, Cristian CONSTANTIN wrote: > is there any technique for an udvm assembler > to detect (at "assemble time") the closest zero byte > to a given address so that this byte is really going to be a > DECOMPRESSION-FAILURE instruction at run time and NOT some data that > is supposed to be loaded with some other value or some self-modifying > instruction? > > (I'm taking into account here the peculiarities of the udvm code: mixed > data and code, self-modifying code) Good point. No, we did not consider self-modifying code when we defined "!". Maybe a real-world assembler needs some additional hints here. Strawman: How about a new set of directives to identify read-only and read-write sections? Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue May 31 08:33:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05036 for ; Tue, 31 May 2005 08:33:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd6FH-0001Wc-E1 for rohc-archive@ietf.org; Tue, 31 May 2005 08:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd5v1-0002N4-Jj; Tue, 31 May 2005 08:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd5v0-0002Mx-JM for rohc@megatron.ietf.org; Tue, 31 May 2005 08:32:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05017 for ; Tue, 31 May 2005 08:32:25 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd6Eb-0001WB-M6 for rohc@ietf.org; Tue, 31 May 2005 08:52:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by delivery_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C9E10390441 for ; Tue, 31 May 2005 14:32:18 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by outbound_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B5B734F0003 for ; Tue, 31 May 2005 14:32:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 14:32:18 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 14:32:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2005 14:32:18 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05B74416@esealmw109.eemea.ericsson.se> Thread-Topic: I-D ACTION:draft-ertekin-rqts-hcoipsec-01.txt Thread-Index: AcVi9gRrCAfbkToaTIqa8ruY2B2RFwC5qXfQ From: "Lars-Erik Jonsson (LU/EAB)" To: X-OriginalArrivalTime: 31 May 2005 12:32:18.0357 (UTC) FILETIME=[C8A7AE50:01C565DC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [rohc] FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-01.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Integration of Header Compression over IPsec=20 Security Associations Author(s) : E. Ertekin, et al. Filename : draft-ertekin-rqts-hcoipsec-01.txt Pages : 15 Date : 2005-5-27 =09 Internet Protocol security mechanisms, such as IP Security (IPsec) [IPSEC], provides various security services for IP traffic. However, the benefits offered by IPsec may come at the cost of increased overhead. This document identifies a methodology for integrating header compression (HC) over IPsec (HCoIPsec). HCoIPsec proposes to reduce the amount of packet overhead associated with the transmission of traffic over tunnel mode security associations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ertekin-rqts-hcoipsec-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc