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"