From mailnull@www1.ietf.org Mon Mar 3 03:56:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12172 for ; Mon, 3 Mar 2003 03:56:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2396Xd25205 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 04:06:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2396Xp25202 for ; Mon, 3 Mar 2003 04:06:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12163 for ; Mon, 3 Mar 2003 03:56:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2396Ip25192; Mon, 3 Mar 2003 04:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2395Mp25149 for ; Mon, 3 Mar 2003 04:05:22 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12154 for ; Mon, 3 Mar 2003 03:54:56 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h238uwnT002785 for ; Mon, 3 Mar 2003 09:56:58 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Mar 2003 09:56:57 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the ROHC impl. guide Date: Mon, 3 Mar 2003 09:56:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, In the updated draft, your comment has been addressed. All packets are "totally updating", except for UO-1-ID. Of course, packets such as R-0 or UO-0 can not update fields like TTL, as they do not carry a TTL field. However, I think it is still ok to say "update all header fields", and make UO-1-ID the exception. /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 28 februari 2003 17:32 > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] Updating the ROHC impl. guide > > > Lars-Erik, > > Any thoughts on my proposed text for section 4.7? In particular, > if you have think it is correct? Note that I added UO-0 in the > last sentence. Also, what about UO-1 and UO-1-TS? Do they update > all the header fields or just a subset? > > ------------------ > "In UO-mode, all packets are updating packets, while in R-mode > all packets with a CRC are updating packets. An updating packet > in R-mode updates the reference values of all header fields, either > explicitly or implicitly. Same is true for updating packets in > UO-mode, except for UO-1-ID and UO-0, which only update TS, SN > and IP-ID (see 5.7.3)." > ------------------ > > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 03:57:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12191 for ; Mon, 3 Mar 2003 03:57:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2397DY25578 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 04:07:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2397Dp25569 for ; Mon, 3 Mar 2003 04:07:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12187 for ; Mon, 3 Mar 2003 03:56:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23972p25264; Mon, 3 Mar 2003 04:07:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2396wp25229 for ; Mon, 3 Mar 2003 04:06:58 -0500 Received: from condor.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12168 for ; Mon, 3 Mar 2003 03:56:32 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by condor.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h238wYA2016571 for ; Mon, 3 Mar 2003 09:58:34 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Mar 2003 09:58:33 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the ROHC impl. guide Date: Mon, 3 Mar 2003 09:58:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > Anyway, there is no single criteria, we have to look at each case. > > Since this is a WG document, it would help to have some kind of > criteria/rules for what should be included and what should not. That would be impossible with this kind of document, as we can not know what kind of things will have to be further explained or clarified. When someone identifies an issue, we discuss it and find out whether it should be added, and then what should be added. The purpose of the document is to provide additional guidelines for implementer's of ROHC. It should be short enough so that people bother to read it and easily find answers to their questions, but it should also contain enough material to really answer the most common questions and clarify identified ambiguities. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 05:49:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16401 for ; Mon, 3 Mar 2003 05:49:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23AxLh03800 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 05:59:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23AxLp03797 for ; Mon, 3 Mar 2003 05:59:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16398 for ; Mon, 3 Mar 2003 05:48:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Ax7p03771; Mon, 3 Mar 2003 05:59:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Awhp03746 for ; Mon, 3 Mar 2003 05:58:43 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16385 for ; Mon, 3 Mar 2003 05:48:13 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 10:50:13 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1DE@rsys002a.roke.co.uk> From: "Price, Richard" To: "'rohc@ietf.org'" Subject: FW: [rohc] Updating the Formal Notation draft Date: Mon, 3 Mar 2003 10:50:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I'd also like to propose some terminology changes to make the > notation draft more readable, and to hopefully fix the > inconsistencies between the notation draft and other TCP-related > drafts. A list of these terminology changes is available from > http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt Hi, For completeness, here is the list of proposed terminology changes in non-linked form. Terminology changes: 1. We should give the notation a better name, e.g. ROHC-FN (Formal Notation for Robust Header Compression). 2. The "rules" should be called "encoding methods" to bring the terminology in line with RFC 3095. 3. The "labels" should be renamed "temporary variables" to make it clearer what they actually do! 4. The names of encoding methods and variables should be cleanly separated, e.g. by using lowercase for the names of encoding methods and uppercase for variable names. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 06:54:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19004 for ; Mon, 3 Mar 2003 06:54:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23C4Tl09148 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 07:04:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23C4Tp09145 for ; Mon, 3 Mar 2003 07:04:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18985 for ; Mon, 3 Mar 2003 06:54:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23C4Hp09131; Mon, 3 Mar 2003 07:04:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23C3Kp09083 for ; Mon, 3 Mar 2003 07:03:20 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18953 for ; Mon, 3 Mar 2003 06:52:52 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by alaska.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h23BsqpY021759 for ; Mon, 3 Mar 2003 12:54:52 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Mar 2003 12:54:52 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Mon, 3 Mar 2003 12:54:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > 1. We should give the notation a better name, e.g. ROHC-FN > (Formal Notation for Robust Header Compression). Yes! > 2. The "rules" should be called "encoding methods" to bring the > terminology in line with RFC 3095. OK! > 3. The "labels" should be renamed "temporary variables" to > make it clearer what they actually do! I am not sure, to me "variables" does not make much sense in a formal notation. I have to think more about this... > 4. The names of encoding methods and variables should be > cleanly separated, e.g. by using lowercase for the names > of encoding methods and uppercase for variable names. I would leave that for now. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 07:07:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19265 for ; Mon, 3 Mar 2003 07:07:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23CHIu10590 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 07:17:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23CHHp10587 for ; Mon, 3 Mar 2003 07:17:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19262 for ; Mon, 3 Mar 2003 07:06:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23CH7p10575; Mon, 3 Mar 2003 07:17:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23CG0p10517 for ; Mon, 3 Mar 2003 07:16:00 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19243 for ; Mon, 3 Mar 2003 07:05:32 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h23C7WnT006162 for ; Mon, 3 Mar 2003 13:07:33 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Mar 2003 13:07:32 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Mon, 3 Mar 2003 13:07:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > The main piece currently missing from the drafts is a description > > > of how to encode each field in the TCP/IP header, so we've added a > > > very simple proposal for this based on the current behavior draft. > > > > How to encode the original fields are rather well "suggested" in the > > behavior draft > > This certainly seems to be the case based on our initial test > TCP flows. One interesting open issue, however, is the level of > complexity needed in the final TCP encoding. Our current > implementation only uses a very basic set of packet formats, > designed specifically to be human-readable. Are these documented anywhere? > If we choose the former approach then the notation defines > which encoding methods are applied to which fields (including > the "control" fields not present in the original TCP/IP header). > To get from this to "bits on the wire", we just need to > define a library of 4 or 5 basic encoding methods for the > notation to use. I do not follow this. Can you maybe clarify better how this would be done? In principle? How do you capture all functional design decisions? Interaction with the context, feedback handling, trade-offs between optimizing for the most common cases, the average header size, etc? BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 07:54:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22124 for ; Mon, 3 Mar 2003 07:54:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23D4VR13875 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 08:04:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23D4Vp13872 for ; Mon, 3 Mar 2003 08:04:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22109 for ; Mon, 3 Mar 2003 07:54:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23D4Ip13852; Mon, 3 Mar 2003 08:04:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23D3Zp13812 for ; Mon, 3 Mar 2003 08:03:35 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22020 for ; Mon, 3 Mar 2003 07:53:05 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 12:55:05 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1E1@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Mon, 3 Mar 2003 12:55:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Thanks for your comments! I've added a couple of replies inline. Regards, Richard > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Monday, March 03, 2003 11:55 AM > To: 'rohc@ietf.org' > Subject: RE: [rohc] Updating the Formal Notation draft > > > > 1. We should give the notation a better name, e.g. ROHC-FN > > (Formal Notation for Robust Header Compression). > > Yes! > > > > 2. The "rules" should be called "encoding methods" to bring the > > terminology in line with RFC 3095. > > OK! > > > > 3. The "labels" should be renamed "temporary variables" to > > make it clearer what they actually do! > > I am not sure, to me "variables" does not make much sense in > a formal notation. I have to think more about this... For this reason, I suspect that using the name "variables" would be an excellent idea! From a technical perspective we definitely have this functionality in the notation - whether it's a good idea or not is open for debate, but we should at least clarify that the functionality is there so that folks can argue for or against it. The term "labels" is misleading, because it implies that they take the same constant value for each header. In fact, the value of a label can change as the header is being parsed - hence the term "variable" is more appropriate. > > 4. The names of encoding methods and variables should be > > cleanly separated, e.g. by using lowercase for the names > > of encoding methods and uppercase for variable names. > > I would leave that for now. Ok, I'll stick with what we've got at the moment (lowercase for encoding methods, mixture of uppercase and lowercase for variables). This is fine for now. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 08:27:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24338 for ; Mon, 3 Mar 2003 08:27:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23DbeV17343 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 08:37:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Dbep17340 for ; Mon, 3 Mar 2003 08:37:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24312 for ; Mon, 3 Mar 2003 08:27:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DbDp16897; Mon, 3 Mar 2003 08:37:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DaUp16444 for ; Mon, 3 Mar 2003 08:36:30 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24246 for ; Mon, 3 Mar 2003 08:25:59 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 13:28:00 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1E2@rsys002a.roke.co.uk> From: "Price, Richard" To: "'cabo@Informatik.Uni-Bremen.DE'" , rohc@ietf.org Subject: RE: [rohc] Updating the Formal Notation draft Date: Mon, 3 Mar 2003 13:27:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Carsten, Many thanks for these comments. I've added some further comments on the proposed changes that I'd like to make in the next version of the notation draft. The remaining issues just relate to the syntax of the notation - we can finalise these later on (e.g. after we've chosen between Haskell/Prolog etc.). Regards, Richard > -----Original Message----- > From: cabo@Informatik.Uni-Bremen.DE > [mailto:cabo@Informatik.Uni-Bremen.DE] > Sent: Thursday, February 27, 2003 7:51 PM > To: rohc@ietf.org > Subject: [rohc] Updating the Formal Notation draft > > > ROHCers, > > some comments (WG chair hat off) on > http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt below. > > Gruesse, Carsten > > Based on our implementation experience we'd like to propose a > few changes to the current formal notation draft (see > ): > > Terminology changes: > > The following changes have no technical effect on the notation, > but will hopefully make the draft easier to understand: > > 1. We should give the notation a better name, e.g. ROHC-FN > (Formal Notation for Robust Header Compression). > > If, as you explain in a later message, it is just about packet > formats, it probably should be named ROHC-FNPF or some such? It might be better to keep the name of the notation more generic, at least for the time being. As Lars-Erik pointed out the final scope of the notation may change... > 2. The "rules" should be called "encoding methods" to bring the > terminology in line with RFC 3095. > > d/c (don't care). Ok, I'll use the term "encoding methods" - should make the draft a bit clearer. > 3. The "labels" should be renamed "temporary variables" to > make it clearer what they actually do! > > Hmm, this creates the impression the notation has imperative > semantics. I thought we were trying to avoid this. Bindings? The term "labels" (or "bindings") implies that each label name refers to a fixed value for each header. This isn't currently the case - labels can change their value as the header is parsed, so the term "variable" is more appropriate. Obviously it would be nicer to avoid having variables in a notational language - it's an open issue whether we can do this or not. > 4. The names of encoding methods and variables should be > cleanly separated, e.g. by using lowercase for the names > of encoding methods and uppercase for variable names. > > This might conflict with the choice of Haskell (uppercase is reserved > for specific things in that language). (It also would conflict with > Prolog.) That's ok - it doesn't matter which is uppercase and which is lowercase, so long as they are cleanly separated. I'll stick with what we've currently got (we can always change it later if it conflicts with our choice of well-known language). > Miscellaneous changes: > > The following changes aren't required to make the notation > Haskell-compatible, but we think that they're a good idea anyway: > > 1. We should add "Self-describing variable-length values" from > Section 4.5.6 of RFC 3095 to the library of encoding methods. > > Sure. The Library will grow with our use of the notation. > > 2. A function for calculating an n-bit CRC should be added to > the maths library. > > Sure. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 08:42:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25026 for ; Mon, 3 Mar 2003 08:42:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23DqNu18070 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 08:52:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DqNp18067 for ; Mon, 3 Mar 2003 08:52:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25013 for ; Mon, 3 Mar 2003 08:41:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23DqAp18058; Mon, 3 Mar 2003 08:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Dpop18026 for ; Mon, 3 Mar 2003 08:51:50 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24979 for ; Mon, 3 Mar 2003 08:41:19 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h23DhKnT005697 for ; Mon, 3 Mar 2003 14:43:20 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Mar 2003 14:43:20 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the Formal Notation draft Date: Mon, 3 Mar 2003 14:43:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, > > 3. The "labels" should be renamed "temporary variables" to > > make it clearer what they actually do! > > > > Hmm, this creates the impression the notation has imperative > > semantics. I thought we were trying to avoid this. Bindings? > > The term "labels" (or "bindings") implies that each label name refers > to a fixed value for each header. This isn't currently the case - > labels can change their value as the header is parsed, so the term > "variable" is more appropriate. > > Obviously it would be nicer to avoid having variables in a notational > language - it's an open issue whether we can do this or not. What do you mean with "header is parsed"? We are talking about a "language" to describe how header fields are to be compressed (not field data from a specific packet header), and to me "parsing" sounds like something you do with an actual packet header. I have to re-read the draft, but I will wait for the updated version. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 09:53:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27568 for ; Mon, 3 Mar 2003 09:53:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23F3Mg23383 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 10:03:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23F3Lp23380 for ; Mon, 3 Mar 2003 10:03:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27565 for ; Mon, 3 Mar 2003 09:52:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23F36p23363; Mon, 3 Mar 2003 10:03:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23F2Xp23332 for ; Mon, 3 Mar 2003 10:02:33 -0500 Received: from condor.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27513 for ; Mon, 3 Mar 2003 09:52:00 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by condor.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h23Es2A1027241 for ; Mon, 3 Mar 2003 15:54:02 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Mar 2003 15:54:01 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Date: Mon, 3 Mar 2003 15:53:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] ROHC@IETF56 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ROHCers, The San Francisco meeting is approaching and we are about to prepare an agenda for the ROHC session. On the tentative agenda, ROHC is scheduled for a Monday evening slot on the 17th. We are now soliciting input on how to spend our session time. Before proposing an agenda item, consider the following: - Is it a proper agenda item at this point in time? * Is there useful material available (as Internet Drafts) for people to read? * Has there been mail list discussions indicating that face2face discussions are needed to get progress? * Is it reasonable to expect that a face2face discussion will be able to bring the work forward? - For new proposals: * Is the proposal within scope for the WG charter ** If yes, is there already work ongoing to address that part of the charter? Has it already been addressed? ** If no, be aware that focus must be on motivating a charter update to include the new work item. Exploring the problem space would thus be the first step. Is it really proper IETF work, ROHC work? If you have proposals for what to discuss at the meeting, please contact the WG chairs not later than Friday, March 7. Rgds, /Lars-Erik -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 10:20:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29200 for ; Mon, 3 Mar 2003 10:20:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23FUCD25879 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 10:30:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FUBp25876 for ; Mon, 3 Mar 2003 10:30:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29183 for ; Mon, 3 Mar 2003 10:19:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FTwp25848; Mon, 3 Mar 2003 10:29:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FSnp25753 for ; Mon, 3 Mar 2003 10:28:49 -0500 Received: from exchsvr.octasic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29167 for ; Mon, 3 Mar 2003 10:18:16 -0500 (EST) Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 10:00:54 -0500 Message-ID: From: Remi Pelland To: "'rohc@ietf.org'" Date: Mon, 3 Mar 2003 10:00:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23FSnp25754 Subject: [rohc] GRE and RFC 3095. Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The general compressed RTP header format provided in section 5.7 shows two occurences of "GRE checksum". I understand that the one following the "AH data for outer list" is associated with the outer GRE header, which leaves the one just before the "UDP checksum" associated with the inner header. I'm far from being a GRE expert, so there may be something I didn't quite understand. However, when looking at RFC 2784 it seems to me like the GRE header is always followed by an IPv4 header (the one from the payload packet). It thus seems impossible to find a GRE header somewhere between the inner IP header and the UDP header. With this in mind, I'm wondering about the purpose of the second "GRE checksum" entry in the general packet format. Any input on this would be appreciated. Thanks, Rémi. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 10:39:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29927 for ; Mon, 3 Mar 2003 10:39:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23FnN228059 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 10:49:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FnNp28056 for ; Mon, 3 Mar 2003 10:49:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29913 for ; Mon, 3 Mar 2003 10:38:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Fn9p28042; Mon, 3 Mar 2003 10:49:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FmOp28005 for ; Mon, 3 Mar 2003 10:48:24 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29878 for ; Mon, 3 Mar 2003 10:37:50 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 15:39:52 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1E5@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Updating the Formal Notation draft Date: Mon, 3 Mar 2003 15:39:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Richard, > > > > 3. The "labels" should be renamed "temporary variables" to > > > make it clearer what they actually do! > > > > > > Hmm, this creates the impression the notation has imperative > > > semantics. I thought we were trying to avoid this. Bindings? > > > > The term "labels" (or "bindings") implies that each label name refers > > to a fixed value for each header. This isn't currently the case - > > labels can change their value as the header is parsed, so the term > > "variable" is more appropriate. > > > > Obviously it would be nicer to avoid having variables in a notational > > language - it's an open issue whether we can do this or not. > > What do you mean with "header is parsed"? We are talking about a > "language" to describe how header fields are to be compressed (not > field data from a specific packet header), and to me "parsing" sounds > like something you do with an actual packet header. Hi, Yes, I meant "parsing" as in compressing actual packet headers. The temporary variables are used by the notation to store certain fields from a header - I've had a go at explaining why this is useful below: It's often the case that two fields in a header have related behaviour (e.g. RTP Sequence Number and Timestamp). Obviously these dependencies need to be taken into account when encoding the fields - this means that the encoding method for the RTP Timestamp must have the RTP Sequence Number available before it can work out the compressed version of the Timestamp. ROHC-FN captures these field dependencies using "temporary variables". In a description of RTP, the encoding method for the RTP Sequence Number would create a new temporary variable called, say, "RTP_Seq" for storing the RTP Sequence Number. The encoding method for the RTP Timestamp would retrieve the Sequence Number from the variable "RTP_Seq" and use it when compressing the Timestamp. When parsing a specific RTP header, the temporary variable "RTP_Seq" would contain the specific value of the RTP Sequence Number for that particular header. If we want to parse two different RTP headers then the temporary variable will generally take a different value in each case - hence the term "variable" is appropriate. > I have to re-read the draft, but I will wait for the updated version. I've just submitted the updated version of the draft. It might be worth checking out the worked example for IPv6, which makes use of two temporary variables called "Next_Header" and "Remaining_Data". Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 3 11:59:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03012 for ; Mon, 3 Mar 2003 11:59:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23H9ZE04349 for rohc-archive@odin.ietf.org; Mon, 3 Mar 2003 12:09:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H9Zp04346 for ; Mon, 3 Mar 2003 12:09:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02979 for ; Mon, 3 Mar 2003 11:59:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H9Jp04323; Mon, 3 Mar 2003 12:09:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23H8Yp04225 for ; Mon, 3 Mar 2003 12:08:34 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02914 for ; Mon, 3 Mar 2003 11:57:59 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h23H02q13149 for ; Mon, 3 Mar 2003 11:00:02 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Mar 2003 10:59:59 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Mar 2003 10:59:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Mon, 3 Mar 2003 10:59:58 -0600 Message-ID: Thread-Topic: [rohc] Updating the ROHC impl. guide Thread-Index: AcLhYwTOduSa4++TTa6OtIVqHgkaxgAPbfIQ To: , X-OriginalArrivalTime: 03 Mar 2003 16:59:58.0983 (UTC) FILETIME=[52CDB970:01C2E1A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23H8Yp04226 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, Could you send out the new text about this in the updated draft, so I can take a look? I want to check if my comments has been addressed correctly, since it looks you don't want to use my proposed text and I haven't seen you explaining the reasons. As a technical discussion, it would be helpful if you simply point out what you disagree with my text, like what I did with the text of current draft. BTW, your reply below is confusing. For example, R-0 is NOT an updating packet. It does not update *anything*. I don't know why it is mentioned at all in the context of updating TTL field. But again, I'd like to read the new text and see if it indeed addresses my comments. Zhigang > -----Original Message----- > From: ext Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: March 03, 2003 2:57 AM > To: rohc@ietf.org > Subject: RE: [rohc] Updating the ROHC impl. guide > > > Zhigang, > > In the updated draft, your comment has been addressed. > > All packets are "totally updating", except for UO-1-ID. > Of course, packets such as R-0 or UO-0 can not update > fields like TTL, as they do not carry a TTL field. > However, I think it is still ok to say "update all > header fields", and make UO-1-ID the exception. > > /L-E > > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: den 28 februari 2003 17:32 > > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > > Subject: RE: [rohc] Updating the ROHC impl. guide > > > > > > Lars-Erik, > > > > Any thoughts on my proposed text for section 4.7? In particular, > > if you have think it is correct? Note that I added UO-0 in the > > last sentence. Also, what about UO-1 and UO-1-TS? Do they update > > all the header fields or just a subset? > > > > ------------------ > > "In UO-mode, all packets are updating packets, while in R-mode > > all packets with a CRC are updating packets. An updating packet > > in R-mode updates the reference values of all header fields, either > > explicitly or implicitly. Same is true for updating packets in > > UO-mode, except for UO-1-ID and UO-0, which only update TS, SN > > and IP-ID (see 5.7.3)." > > ------------------ > > > > Zhigang > > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Mar 4 03:38:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09197 for ; Tue, 4 Mar 2003 03:38:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h248mRA15781 for rohc-archive@odin.ietf.org; Tue, 4 Mar 2003 03:48:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h248mRp15778 for ; Tue, 4 Mar 2003 03:48:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09192 for ; Tue, 4 Mar 2003 03:37:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h248mEp15742; Tue, 4 Mar 2003 03:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h248jCp15652 for ; Tue, 4 Mar 2003 03:45:12 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09092 for ; Tue, 4 Mar 2003 03:34:18 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by alaska.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h248aJpX008951 for ; Tue, 4 Mar 2003 09:36:19 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 4 Mar 2003 09:36:14 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the ROHC impl. guide Date: Tue, 4 Mar 2003 09:24:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, The text of the updated draft became as follows: "An updating packet thus updates the reference values of all header fields, either explicitly or implicitly, with an exception for the UO-1-ID packet, which only updates TS, SN and IP-ID (see 5.7.3). In UO-mode, all packets are updating packets, while in R-mode all packets with a CRC are updating packets." This is the same text as before, but adjusted based on your comment. If you still think there are contradictions, we can fix that in the next update. The reason I did not just take your alternative text was that it changed the order of the sentences, and that made it fit less well within the section as a whole. Regarding your BTW, you are right that R-0 is a non-updating packet as it does not have a CRC, but replace R-0 in my note with R-0-CRC and you should get the point. All packets that are updating (i.e. all but R-0) update *all* fields (i.e. fields for which data is sent in the compressed header plus TS & IP-ID implicitly), with the single exception of UO-1-ID, which ONLY updates SN, TS & IP-ID. /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 3 mars 2003 18:00 > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] Updating the ROHC impl. guide > > > Lars-Erik, > > Could you send out the new text about this in the updated > draft, so I can take a look? I want to check if my comments > has been addressed correctly, since it looks you don't want to > use my proposed text and I haven't seen you explaining the > reasons. As a technical discussion, it would be helpful if > you simply point out what you disagree with my text, like what > I did with the text of current draft. > > BTW, your reply below is confusing. For example, R-0 is NOT an > updating packet. It does not update *anything*. I don't know > why it is mentioned at all in the context of updating TTL field. > But again, I'd like to read the new text and see if it indeed > addresses my comments. > > Zhigang > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (EAB) > > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > > Sent: March 03, 2003 2:57 AM > > To: rohc@ietf.org > > Subject: RE: [rohc] Updating the ROHC impl. guide > > > > > > Zhigang, > > > > In the updated draft, your comment has been addressed. > > > > All packets are "totally updating", except for UO-1-ID. > > Of course, packets such as R-0 or UO-0 can not update > > fields like TTL, as they do not carry a TTL field. > > However, I think it is still ok to say "update all > > header fields", and make UO-1-ID the exception. > > > > /L-E > > > > > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: den 28 februari 2003 17:32 > > > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > > > Subject: RE: [rohc] Updating the ROHC impl. guide > > > > > > > > > Lars-Erik, > > > > > > Any thoughts on my proposed text for section 4.7? In particular, > > > if you have think it is correct? Note that I added UO-0 in the > > > last sentence. Also, what about UO-1 and UO-1-TS? Do they update > > > all the header fields or just a subset? > > > > > > ------------------ > > > "In UO-mode, all packets are updating packets, while in R-mode > > > all packets with a CRC are updating packets. An updating packet > > > in R-mode updates the reference values of all header fields, > > > either explicitly or implicitly. Same is true for updating > > > packets in UO-mode, except for UO-1-ID and UO-0, which only > > > update TS, SN and IP-ID (see 5.7.3)." > > > ------------------ > > > > > > Zhigang > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 4 07:40:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15838 for ; Tue, 4 Mar 2003 07:40:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CoWW00339 for rohc-archive@odin.ietf.org; Tue, 4 Mar 2003 07:50:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24CoWp00336 for ; Tue, 4 Mar 2003 07:50:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15789 for ; Tue, 4 Mar 2003 07:39:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24CoHp00305; Tue, 4 Mar 2003 07:50:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cfip32061 for ; Tue, 4 Mar 2003 07:41:44 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15110 for ; Tue, 4 Mar 2003 07:30:46 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h24CWlnS012903 for ; Tue, 4 Mar 2003 13:32:47 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 4 Mar 2003 13:32:47 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'rohc@ietf.org'" Date: Tue, 4 Mar 2003 13:30:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-2" Subject: [rohc] input bytes beyond message Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, At SIPit, an interesting interpretation problem was found regarding the INPUT-BYTES instruction. Namely: what to do with the bytes read if there aren't as many in the message as was requested? The RFC says: "If the instruction requests data that lies beyond the end of the SigComp message, no data is returned. Instead the UDVM moves program execution to the address specified by the address operand." In my interpretation this sentence means that ONLY data that lies beyond the end of the message should be discarded. Others interpreted this to discard even those bytes that were part of the message. Why is this important? Because it may be a very nice feature to eliminate implementing a loop or passing the length of the data block, resulting in shorter bytecodes: INPUT-BYTES maximum_length, destination, continue_address This instructions reads a maximum of maximum_length bytes from the message without knowing how many bytes there are. I don't think this may impose security risk compared to the other solution, when all the bytes are discarded, if the available cpb is increased with the number of the actually read bytes, instead of the value of the length parameter (the same way as it is done in the INPUT-HUFFMAN instruction). As I need some statement regarding this question in one or two weeks, I call all interested parties, standardizers and implementors, to start a discussion on this question. BR/Zacco _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 4 09:11:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22546 for ; Tue, 4 Mar 2003 09:11:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24EMSM07446 for rohc-archive@odin.ietf.org; Tue, 4 Mar 2003 09:22:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EMSp07443 for ; Tue, 4 Mar 2003 09:22:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22508 for ; Tue, 4 Mar 2003 09:11:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EMBp07427; Tue, 4 Mar 2003 09:22:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EJJp07274 for ; Tue, 4 Mar 2003 09:19:19 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22324 for ; Tue, 4 Mar 2003 09:08:18 -0500 (EST) Received: from tzi.org (nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id h24EAFl05960; Tue, 4 Mar 2003 15:10:16 +0100 (MET) Date: Tue, 4 Mar 2003 15:09:54 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Carsten Bormann To: rohc@ietf.org From: Carsten Bormann Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [rohc] Role and approach of the ROHC formal notation Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ROHCers, Lars-Erik (who plays chair on this issue) and I have had a little discussion on the side on the formal notation. Actually, it seems to us that we need to have this discussion on the list. We need to get a much better grasp of the role and basic approach of the ROHC formal notation before we meet in San Francisco, in order to be able to use the precious face time there for wrapping up the more sticky points. So, I would like to invite comments on the views discussed below. Please do comment even if you haven't been involved in the notation work so far, e.g., if you see an issue that is not currently explained very well in the document and/or seems to need further discussion. Gruesse, Carsten PS.: Looking at the message again, I'd like to point out that one thing we *don't* need to converge on at this point is what the basis of the formal notation should be, e.g. Haskell vs. Prolog. I'm just citing these two "implementations" of the ROHC-FN approach to underscore the points I was trying to make. Begin forwarded message: > From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann) > Date: Tue Mar 4, 2003 07:07:59 Europe/Berlin > To: "Lars-Erik Jonsson (EAB)" > Subject: Re: Notation questions > > From Lars-Erik.Jonsson@epl.ericsson.se Mon Mar 3 17:25:37 2003 > Date: Mon, 3 Mar 2003 17:18:38 +0100 > From: "Lars-Erik Jonsson (EAB)" > To: "Carsten Bormann (E-mail)" > Subject: Notation questions > > Intro: > > For me, notation is about having a well defined way of > describing what to send in compressed headers. That > description would be a result of the characteristics of > the original headers, and the "compression principles" > used for the profile. > > I think what we came up with is a little different -- it describes the > meaning of compressed headers in terms of the uncompressed headers. > Of course, you can leave the latter part out, it just becomes hard to > have any kind of formal semantics then. (I.e., you can still decide > whether a compressed header is syntactically correct -- but for a good > compression scheme this is true for almost any bit combination. But > it becomes hard to assign formal semantics to a parse tree if you > don't have a formal notation for the uncompressed headers.) > > The notated information could then be used to draw > compressed header formats by hand, or one could > potentially use some automated means to generate compressed > header formats in a more structured way. Whether such formats > would be humanly readable or not would depend on the > mechanism used, but must in either case be documented in > some way in profile specifications. > > This drawing mechanism might be a third operational mode of the > compiled notation programs (the other ones are compression and > decompression, but see below). > > With EPIC, they had a notation, and two different automated > means to generate formats, called EPIC and EPIC-Lite, where > both generated a very large set of formats that could not > easily be documented. The header generation algorithms do > put limitations on how the formats are done, and imply a > number of specific ways of operating. An algorithm, such as > EPIC, thus constitutes a number of technical compression > decisions, things that are far from obvious how to do. > > Which format to use when compressing a packet is further a > separate issue. I believe that header formats that are > generated by automatic means might provide simpler means > to create compressed headers, but these two issues (defining > compressed formats and actually compressing headers) are > still different parts of what we are discussing. > > In an implementation, yes. In a formal notation, formally defining > the structure of the compressed packets without defining their > relationship to the uncompressed packets is not very useful (I'm > repeating myself). Once you describe this relationship formally, and > find a way to compile the formal notation, you can build a compressor > and a decompressor this way (modulo oracles, see below). > > 1) In Richards last e-mails, he seems to say that the notation > itself gives the compressed formats (bits on the wire), and > I do not buy that. How could that be possible? > > I believe Richard's/Mark's idea is that the notation defines all the > bits in the compressed packet (its "body"), apart from an initial > discriminator. This discriminator is what differs between EPIC and > EPIC-lite. The discriminator carries all the information that is > needed to parse the body. The body carries information that is too > big to carry in the discriminator; essentially orthogonally encodable > information. The discriminator can use interesting tricks like EPIC > (Huffman on complete discriminators) or, if we want, arithmetic coding > (I don't know when those patents run out, though). The notation > supplies everything that is needed to go into the discriminator > computation (values, probabilities). > > 2) Richard is confusing compressing headers with defining the > candidate compressed header formats. Do you understand this? > > Well, the compressed header formats are in some way related to the > uncompressed packet. The notation captures this relationship. The > notation can use an oracle function to be able to derive more than one > packet format based on the same uncompressed packet. > > 3) By using a functional language, exactly what do you mean > you would get by compiling the notated information? > > That was one question that Richard raised. Right now, in his proposal > you get a program that can either compress or decompress, depending on > a switch thrown initially. I don't know yet how his oracles work; I > still have to read it up. > > In my proposal, the Prolog program defines a relation (in the > mathematical sense) between uncompressed and compressed packets. > Since the relation can have multiple compressed packets for one > uncompressed packet, the oracle functionality is already built into > the model. (Obviously, it also can have multiple uncompressed packets > for one compressed packet, so you can write incorrect instances of the > notation. One useful property of a notation would be to allow > automatically catching this error -- this may be easier in Richard's > variant than in mine.) > > In both cases, state (context) enters the picture. Even with that, it > is not always clear which packet format to use. The fun part is > leaving the hard decisions (and, preferably, the implementation > dependent decisions) to oracles. > > 4) Do you really believe that all the kind of stuff we had > in 3095 could be captured this way? Note that Roke Manor > themselves had problems to make the EPIC stuff operating in > anything but unidirectional mode. There is much to consider > when using feedback, and operating towards contexts. > > Most definitely, the basic approach can. Whether you would *want* to, > I don't know. In other words, the notation we define (i.e., the > library of encoding rules) may favor packet formats that are different > from the ones we finally decided to use in 3095. This is of course > particularly true if we stick with a single discriminator for the > whole packet (I believe that is a mistake and you need some form of > cross-product generation of packet formats, which calls for separate > discriminators -- something my proposal does not even start to > address yet). _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 4 09:37:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23780 for ; Tue, 4 Mar 2003 09:37:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24ElVj09382 for rohc-archive@odin.ietf.org; Tue, 4 Mar 2003 09:47:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24ElVp09378 for ; Tue, 4 Mar 2003 09:47:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23775 for ; Tue, 4 Mar 2003 09:36:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24El9p09351; Tue, 4 Mar 2003 09:47:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EiNp09261 for ; Tue, 4 Mar 2003 09:44:23 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23736 for ; Tue, 4 Mar 2003 09:33:21 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 14:35:21 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1E8@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Tue, 4 Mar 2003 14:35:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Thanks for all of these comments - hopefully I managed to take them into account in the updated version of the notation draft. I've added a few clarifications inline, particularly regarding the scope of ROHC-FN (where more discussion is clearly required). Regards, Richard > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Friday, February 28, 2003 3:14 PM > To: 'rohc@ietf.org' > Subject: RE: [rohc] Updating the Formal Notation draft > > > Richard, > > In general, I think we should not make any changes to the > actual notation at this point (although the draft might be > updated for other reasons), as we do not have a common view > either of how to proceed with this, or for example if we > should do this "Haskell"-step, or something similar using > another functional language. We need to discuss this more, > then we can get a stable ground for the content before we > do the changes. Absolutely - there's no need to update the syntax of the notation at this stage. It's more important to clarify the scope of the notation draft, and to make sure that we understand how it fits into the overall ROHC solution. > However, we might want to update it just to change the title, > and maybe some of the "environmental texts". I've provided > some comments on this below. > > BR > /L-E > > > > Section 4.6 on "control fields" is redundant given the > > information contained in . > > Well, it might be worth mentioning that information that > can be noted is either original header fields, or additional > control fields introduced by the compression scheme. Ok, I mentioned this briefly in the updated draft. > > I propose to leave the ROHC-TCP draft as it is and delete > > Section 4.6 from the formal notation. > > Of course, the TCP control field can not be discussed as > part of the general notation. Good point - Section 4.6 talks about specific control fields such as the "Master Sequence Number", which is used exclusively by ROHC-TCP. So it's definitely out of scope of the formal notation draft. > > Conversely, one issue that the current draft doesn't explain > > very well is the scope of the formal notation - what it does, > > what it doesn't do, how it relates to the ROHC framework and > > to ROHC profiles etc. > > This is indeed very important, and should be done before we > go much further. However, I do not think we do have a common > understanding about that, as it has never been settled. I think that the first step is to explain the scope of the current notation draft. Once we've clarified this, we can decide whether the scope is correct, or whether it's too broad, too narrow etc. > > I'd like to add a new section to clarify this issue: > > > > 3.X. Scope of ROHC-FN > > > > The following section describes the scope of ROHC-FN, and > > explains how it relates to the overall ROHC framework and to > > specific ROHC profiles. > > > > The ROHC framework is common to all profiles, and provides > > generic features such as padding and segmentation of the > > compressed packets (useful if the link layer can only handle > > a limited range of packet sizes). > > Well, the framework provides the base for all ROHC compression. > It defines the profile concept, which makes ROHC a general platform > for compression schemes. It sets link layer requirements, and > especially negotiation requirements for all ROHC profiles. It > defines a set of common functions, as segmentation, CID's, and > padding. It also defines common packet formats (IR, IR-DYN, Feedback, > Short-CID expander, etc), and it defines a generic, profile > independent, handling of feedback. One can also say that it defines > the general principles for doing ROHC compression. > > > A ROHC profile is a description of how to compress a certain > > protocol stack over a certain type of link. For example, ROHC > > profiles are available for RTP/UDP/IP and many other protocol > > stacks. > > > > Each ROHC profile can be further subdivided into the following > > two components: > > > > a) Packet formats for compressing and decompressing headers > > I would say "compressed packet formats" As I'm not 100% sure what exactly is meant by a "packet format" (compressed or otherwise), it might be useful to capture in more detail what information needs to be defined to get interoperable ROHC profiles: What we're really trying to define is a *function*, whose inputs are the uncompressed header and the context, and whose outputs are the compressed header and a (possibly updated) version of the context: function uncompressed header <--------------> compressed header context updated context So, as well as specifying which fields are in the compressed header, we also need to define how to map between the uncompressed version and the compressed version of each field. For example, if a particular field is compressed using LSB encoding, then we need to to define the interpretation interval, whether the field is compressed as an offset from a different field etc. We also have to define whether each field updates the context or not. Does the term "compressed packet formats" cover all of the above information? If so, then great! If not, then a different term might be more appropriate. > > b) State machine > > I am not sure "state machine" captures all the rest that is there, > but I'll think more about this. Again, it would be useful to capture exactly what needs to be defined, so that we can see whether the term "state machine" is appropriate or whether another term would be better. I think that the following features are needed in conjunction with the ROHC framework and the above "compressed packet formats": 1. Deciding when to delete context entries from the sliding window (e.g. optimistic approach, ACKs etc.) 2. Deciding when the context needs to be refreshed (e.g. timeouts, NACKs etc.) 3. How to recover from decompression failure 4. Context replication I'm not sure whether context replication is within the scope of the state machine - perhaps a more general term that captures all of the above would be "context management" issues? > > ROHC-FN is designed to help provide the packet formats for use > > in new ROHC profiles. > > It is a notation form for the information to compress, it is not clear > to me at this point how far you really get with the notation. A description of, say, TCP/IP in the formal notation will give you exactly what is defined in a) above. You get a function whose inputs are the uncompressed header and the context, and whose outputs are the compressed header and a (possibly updated) version of the context. I suspect that more explanation of how exactly the notation defines this function would be useful - I'll have a go at providing this in a separate post. > > Comments on the above text would be much appreciated! > > This is a good start, as I think it is essential that we try to define > what the notation is, what it will be used for, and how it fits in > the "big ROHC picture". > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Mar 4 11:40:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29830 for ; Tue, 4 Mar 2003 11:40:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GpUM19330 for rohc-archive@odin.ietf.org; Tue, 4 Mar 2003 11:51:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GpUp19327 for ; Tue, 4 Mar 2003 11:51:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29792 for ; Tue, 4 Mar 2003 11:40:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GpFp19313; Tue, 4 Mar 2003 11:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Ggup18947 for ; Tue, 4 Mar 2003 11:42:56 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29468 for ; Tue, 4 Mar 2003 11:31:52 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 16:33:54 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1E9@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Carsten Bormann'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Tue, 4 Mar 2003 16:33:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > 1) In Richards last e-mails, he seems to say that the notation > > itself gives the compressed formats (bits on the wire), and > > I do not buy that. How could that be possible? > > > > I believe Richard's/Mark's idea is that the notation defines all the > > bits in the compressed packet (its "body"), apart from an initial > > discriminator. This discriminator is what differs between EPIC and > > EPIC-lite. The discriminator carries all the information that is > > needed to parse the body. The body carries information that is too > > big to carry in the discriminator; essentially orthogonally encodable > > information. The discriminator can use interesting tricks like EPIC > > (Huffman on complete discriminators) or, if we want, arithmetic coding > > (I don't know when those patents run out, though). The notation > > supplies everything that is needed to go into the discriminator > > computation (values, probabilities). Hi, It might be simpler to avoid mentioning EPIC and EPIC-lite at this stage, because the notation can generate a decent set of compressed packet formats without needing to use either. In RFC 3095 terminology, both EPIC and EPIC-lite are just encoding methods, which we may or may not want to use when compressing fields in a header. For simplicity let's avoid them for now, and just stick with the encoding methods that are available in RFC 3095. In particular, let's try creating a set of compressed packet formats using the following three encoding methods from RFC 3095: Static - Encodes a field that takes the same value as in the previous header. No "bits on the wire" need to be sent in this case. Irregular n - Encodes an n-bit field with no discernable pattern (by sending all n bits in the compressed header). Self-describing values - Allows a field to be encoded in two different ways, and sends a 1-bit flag to indicate which way has been chosen. In the notation, we denote this encoding method using the symbol "/". Using these three encoding methods, we can apply ROHC-FN to create a more complex encoding method designed (say) to handle the TCP Source Port: tcp_source_port ::= static / irregular (16) This new encoding method can encode the field either using a single "0" (if it happens to be the same as in the previous header), or by sending a "1" followed by the 16-bit Source Port in full. The new encoding method certainly defines "bits on the wire" - we can write these out using packet formats as follows: +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1| TCP Source Port | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The next field in the TCP header can be encoded in the same way: tcp_destination_port ::= static / irregular (16) Finally, let's join the two fields together to get a set of packet formats capable of handling both fields: mini_tcp_header ::= tcp_source_port tcp_destination_port The corresponding packet formats for these two fields are as follows: +-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| or |1| TCP Source Port |0| or +-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| TCP Destination Port | or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| TCP Source Port |1| TCP Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hopefully it should be clear that we can define how to compress all of the other fields in a TCP/IP header in a similar manner - then we just join them up to get our complete "compressed packet formats". Comments welcome! Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 4 12:15:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02134 for ; Tue, 4 Mar 2003 12:15:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24HQHh23716 for rohc-archive@odin.ietf.org; Tue, 4 Mar 2003 12:26:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HQHp23713 for ; Tue, 4 Mar 2003 12:26:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02126 for ; Tue, 4 Mar 2003 12:15:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HQ5p23694; Tue, 4 Mar 2003 12:26:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HNkp23533 for ; Tue, 4 Mar 2003 12:23:46 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01941 for ; Tue, 4 Mar 2003 12:12:41 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 17:14:44 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1EA@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" Cc: "'Carsten Bormann'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Tue, 4 Mar 2003 17:14:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > 4) Do you really believe that all the kind of stuff we had > > in 3095 could be captured this way? Note that Roke Manor > > themselves had problems to make the EPIC stuff operating in > > anything but unidirectional mode. There is much to consider > > when using feedback, and operating towards contexts. Hi, This is news to us! Our implementation of EPIC has a full state machine including feedback, context management, error recovery and all of the other functionality of RFC 3095. Perhaps you're thinking of the state machine in the old EPIC-lite draft, which only supported unidirectional mode? The reason it didn't include the more complex features from RFC 3095 was because we wanted to minimise the risk of IPR claims against the draft - not because of any technical limitations of a notation-based approach. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 03:28:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21613 for ; Wed, 5 Mar 2003 03:28:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h258dm204596 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 03:39:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h258dm504593 for ; Wed, 5 Mar 2003 03:39:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21610 for ; Wed, 5 Mar 2003 03:28:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h258dR504580; Wed, 5 Mar 2003 03:39:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h258cf504405 for ; Wed, 5 Mar 2003 03:38:41 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21598 for ; Wed, 5 Mar 2003 03:27:18 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by alaska.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h258TJ0i006932 for ; Wed, 5 Mar 2003 09:29:20 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Mar 2003 09:29:19 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Wed, 5 Mar 2003 09:29:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Perhaps you're thinking of the state machine in the old EPIC-lite > draft, which only supported unidirectional mode? Yes, that was what I was thinking of. It was rather difficult to keep up with the changes in the EPIC documents during that period. Hopefully, this should not be a problem then. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 04:27:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22630 for ; Wed, 5 Mar 2003 04:27:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h259cIe08710 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 04:38:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259cI508707 for ; Wed, 5 Mar 2003 04:38:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22611 for ; Wed, 5 Mar 2003 04:26:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259c6508698; Wed, 5 Mar 2003 04:38:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259bw508678 for ; Wed, 5 Mar 2003 04:37:58 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22603 for ; Wed, 5 Mar 2003 04:26:33 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h259SaB4009798 for ; Wed, 5 Mar 2003 10:28:36 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Mar 2003 10:28:35 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Wed, 5 Mar 2003 10:28:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, Comments inline... > It might be simpler to avoid mentioning EPIC and EPIC-Lite at > this stage, because the notation can generate a decent set of > compressed packet formats without needing to use either. I think referring to EPIC and EPIC-Lite was rather useful here, because the core of those was actually the glue that, at least to me, seems to be missing from the current notation->compression discussion. Last year, we agreed that it is one thing to define how to encode each field, and putting all fields together in compressed headers is another this. The notation obviously covers the former. The latter includes e.g. how to create the "discriminator", as Carsten called it. I agree with you that we do not have to discuss the actual EPIC and EPIC-Lite algorithms for doing this, but referring to them as Carsten did was still useful for getting an understanding of the various pieces. > In RFC 3095 terminology, both EPIC and EPIC-Lite are just encoding > methods, which we may or may not want to use when compressing > fields in a header. I do not agree with that. An encoding method, in 3095 terminology, is a way to compress a field, while the core of EPIC and EPIC-Lite were the algorithms for combining all fields together into "distinguishable bits on the wire". > In particular, let's try creating a set of compressed packet formats > using the following three encoding methods from RFC 3095: > > Static - Encodes a field that takes the same value as in the previous > header. No "bits on the wire" need to be sent in this case. > > Irregular n - Encodes an n-bit field with no discernable pattern (by > sending all n bits in the compressed header). > > Self-describing values - Allows a field to be encoded in two different > ways, and sends a 1-bit flag to indicate which way has been > chosen. In > the notation, we denote this encoding method using the symbol "/". > > Using these three encoding methods, we can apply ROHC-FN to create a > more complex encoding method designed (say) to handle the TCP Source > Port: > > tcp_source_port ::= static / irregular (16) > > This new encoding method can encode the field either using a single > "0" (if it happens to be the same as in the previous header), or by > sending a "1" followed by the 16-bit Source Port in full. > > The new encoding method certainly defines "bits on the wire" - we can > write these out using packet formats as follows: > > +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| or |1| TCP Source Port | > +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The next field in the TCP header can be encoded in the same way: > > tcp_destination_port ::= static / irregular (16) > > Finally, let's join the two fields together to get a set of packet > formats capable of handling both fields: > > mini_tcp_header ::= tcp_source_port > tcp_destination_port > > The corresponding packet formats for these two fields are as follows: > > +-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0| or |1| TCP Source Port |0| or > +-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| TCP Destination Port | or > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| TCP Source Port |1| TCP Destination Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Hopefully it should be clear that we can define how to compress all > of the other fields in a TCP/IP header in a similar manner - then we > just join them up to get our complete "compressed packet formats". This is a very generic approach, but you do not get very efficient formats. With these formats, you have one extra bit for each field, and if you want to have variable length fields, you get even more control bits. The format "discriminator" gets large. If we want to define automatic means to create the compressed formats, we need to have means to affect this and reduce the number of possible combinations to make the discriminator overhead smaller. Anyway, this was still a very good example, but things get much more complicated when we start addressing fields that are compressed together, and when we add context interaction. Static fields are just present in IR/IR-DYN headers, and those are easily defined without automatic means. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 04:32:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22787 for ; Wed, 5 Mar 2003 04:32:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h259hM308959 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 04:43:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259hM508956 for ; Wed, 5 Mar 2003 04:43:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22776 for ; Wed, 5 Mar 2003 04:31:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259hA508948; Wed, 5 Mar 2003 04:43:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259gV508910 for ; Wed, 5 Mar 2003 04:42:31 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22759 for ; Wed, 5 Mar 2003 04:31:06 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h259X4EH000403 for ; Wed, 5 Mar 2003 02:33:05 -0700 (MST) Received: [from zil05exm01.sps.mot.com (zil05exm01.sps.mot.com [216.3.95.200]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id CAA16343 for ; Wed, 5 Mar 2003 02:33:07 -0700 (MST)] Received: from motorola.com (castle.msil.sps.mot.com [223.41.95.7]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 1R9BG12G; Wed, 5 Mar 2003 11:33:05 +0200 Message-ID: <3E65C451.7000804@motorola.com> Date: Wed, 05 Mar 2003 11:33:05 +0200 From: Haim Ben-lulu Organization: MSIL User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 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 Content-Transfer-Encoding: 7bit Subject: [rohc] Unsubscribe me from mail list Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit unsubscribe me from mail list -- Regards, Haim ----------------------------------- Haim B.L System & Design engineer - NETCOMM Motorola semi-conductor Israel LTD. ----------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 05:23:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23994 for ; Wed, 5 Mar 2003 05:23:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25AYcm11638 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 05:34:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25AYc511635 for ; Wed, 5 Mar 2003 05:34:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23973 for ; Wed, 5 Mar 2003 05:23:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25AYG511626; Wed, 5 Mar 2003 05:34:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25AXq511591 for ; Wed, 5 Mar 2003 05:33:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23934 for ; Wed, 5 Mar 2003 05:22:25 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25AORpC007074; Wed, 5 Mar 2003 11:24:27 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Mar 2003 11:24:27 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Carsten Bormann'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Wed, 5 Mar 2003 11:24:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Carsten, > I think what we came up with is a little different -- it > describes the meaning of compressed headers in terms of > the uncompressed headers. Ok, how does the context(s) come into the picture? > > Which format to use when compressing a packet is > > further a separate issue. I believe that header > > formats that are generated by automatic means might > > provide simpler means to create compressed headers, > > but these two issues defining compressed formats and > > actually compressing headers) are still different > > parts of what we are discussing. > > In an implementation, yes. In a formal notation, formally > defining the structure of the compressed packets without > defining their relationship to the uncompressed packets is > not very useful (I'm repeating myself). Once you describe > this relationship formally, > ******** and find a way to compile the formal notation ********, > you can build a compressor and a decompressor this way (modulo > oracles, see below). Yes, but "the way to compile" is not a "one single obvious way". > > > > 1) In Richards last e-mails, he seems to say that the > > notation itself gives the compressed formats (bits on > > the wire), and I do not buy that. How could that be > > possible? > > > I believe Richard's/Mark's idea is that the notation defines > all the bits in the compressed packet (its "body"), apart from > an initial discriminator. This discriminator is what differs > between EPIC and EPIC-Lite. The discriminator carries all the > information that is needed to parse the body. The body carries > information that is too big to carry in the discriminator; > essentially orthogonally encodable information. The notation > supplies everything that is needed to go into the discriminator > computation (values, probabilities). Ok, maybe (someone still has to convince me about this) the notation includes all that is needed to create discriminators, but as you also indicate, there is not one single way to do this. The notation does not dictate how to do it, it inly provides the means to do it. It could be done by hand (as we did in 3095), or it could be automated using some kind of algorithm, but this is a decision that must be taken. > > 2) Richard is confusing compressing headers with > > defining the candidate compressed header formats. > > > Well, the compressed header formats are in some way related > to the uncompressed packet. Sure, I would not expect otherwise...=) > The notation captures this relationship. The notation can > use an oracle function to be able to derive more than one > packet format based on the same uncompressed packet. Ok, now we are getting somewhere. Can you elaborate a little bit on the "oracle" issue? Actually, can you define exactly what you mean with "oracle", maybe draw some parallel with well known things, like 3095? > In other words, the notation we define (i.e., the library > of encoding rules) may favor packet formats that are > different from the ones we finally decided to use in 3095. > This is of course particularly true if we stick with a > single discriminator for the whole packet (I believe that > is a mistake and you need some form of cross-product > generation of packet formats, which calls for separate > discriminators -- something my proposal does not even start > to address yet). I followed you up to "single discriminator", but there you lost me. Can you elaborate on this? Thnx, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 06:40:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27238 for ; Wed, 5 Mar 2003 06:40:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BpU318196 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 06:51:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BpU518193 for ; Wed, 5 Mar 2003 06:51:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27193 for ; Wed, 5 Mar 2003 06:40:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BpJ518170; Wed, 5 Mar 2003 06:51:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bi7517482 for ; Wed, 5 Mar 2003 06:44:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26662; Wed, 5 Mar 2003 06:32:39 -0500 (EST) Message-Id: <200303051132.GAA26662@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Mar 2003 06:32:39 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-03.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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-03.txt Pages : 15 Date : 2003-3-4 This document describes common misinterpretations and some ambiguous points of ROHC [RFC 3095], which defines the framework and four profiles of a robust and efficient header compression scheme. These points have been identified by the members of the ROHC working group during different interoperability test events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4174525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174525.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 06:43:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27439 for ; Wed, 5 Mar 2003 06:43:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BsMH18577 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 06:54:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BsM518574 for ; Wed, 5 Mar 2003 06:54:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27404 for ; Wed, 5 Mar 2003 06:42:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bs5518551; Wed, 5 Mar 2003 06:54:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BrU518496 for ; Wed, 5 Mar 2003 06:53:30 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27353 for ; Wed, 5 Mar 2003 06:42:02 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25Bi5pC028355 for ; Wed, 5 Mar 2003 12:44:05 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Mar 2003 12:44:00 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the Formal Notation draft Date: Wed, 5 Mar 2003 12:43:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, I'm still not sure "Variable" is the right word for this at the notation level, and as you say we should investigate if we can avoid having this at all. The examples you have shown seem to be about compressing fields together, i.e. using another field as a reference for compressing a field. Would "Reference" be a potential word if we have to keep this? BR /L-E > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: den 3 mars 2003 16:40 > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] Updating the Formal Notation draft > > > > > 3. The "labels" should be renamed "temporary variables" to > > > > make it clearer what they actually do! > > > > > > > > Hmm, this creates the impression the notation has imperative > > > > semantics. I thought we were trying to avoid this. Bindings? > > > > > > The term "labels" (or "bindings") implies that each label > name refers > > > to a fixed value for each header. This isn't currently the case - > > > labels can change their value as the header is parsed, so the term > > > "variable" is more appropriate. > > > > > > Obviously it would be nicer to avoid having variables in > a notational > > > language - it's an open issue whether we can do this or not. > > > > What do you mean with "header is parsed"? We are talking about a > > "language" to describe how header fields are to be compressed (not > > field data from a specific packet header), and to me > "parsing" sounds > > like something you do with an actual packet header. > > Hi, > > Yes, I meant "parsing" as in compressing actual packet headers. The > temporary variables are used by the notation to store certain fields > from a header - I've had a go at explaining why this is useful below: > > It's often the case that two fields in a header have related behaviour > (e.g. RTP Sequence Number and Timestamp). Obviously these > dependencies > need to be taken into account when encoding the fields - this > means that > the encoding method for the RTP Timestamp must have the RTP Sequence > Number available before it can work out the compressed version of the > Timestamp. > > ROHC-FN captures these field dependencies using "temporary variables". > In a description of RTP, the encoding method for the RTP Sequence > Number would create a new temporary variable called, say, "RTP_Seq" > for storing the RTP Sequence Number. The encoding method for the RTP > Timestamp would retrieve the Sequence Number from the > variable "RTP_Seq" > and use it when compressing the Timestamp. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 08:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00221 for ; Wed, 5 Mar 2003 08:55:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25E6dp27390 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 09:06:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25E6d527387 for ; Wed, 5 Mar 2003 09:06:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00215 for ; Wed, 5 Mar 2003 08:55:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25E6M527374; Wed, 5 Mar 2003 09:06:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25E5v527359 for ; Wed, 5 Mar 2003 09:05:57 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00195 for ; Wed, 5 Mar 2003 08:54:26 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 13:56:28 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1ED@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Wed, 5 Mar 2003 13:56:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Comments inline... > > > It might be simpler to avoid mentioning EPIC and EPIC-Lite at > > this stage, because the notation can generate a decent set of > > compressed packet formats without needing to use either. > > I think referring to EPIC and EPIC-Lite was rather useful here, > because the core of those was actually the glue that, at least > to me, seems to be missing from the current notation->compression > discussion. Last year, we agreed that it is one thing to define > how to encode each field, and putting all fields together in > compressed headers is another this. The notation obviously covers > the former. The latter includes e.g. how to create the > "discriminator", as Carsten called it. I agree with you that we > do not have to discuss the actual EPIC and EPIC-Lite algorithms > for doing this, but referring to them as Carsten did was still > useful for getting an understanding of the various pieces. Hi, If EPIC and EPIC-lite are useful to get an understanding of a complete notation-based solution, then it's good that Carsten mentioned them ;-) However, one point I'd like to clarify is that algorithms like EPIC and EPIC-lite are for -generating- packet formats, whereas the notation is for -describing- packet formats. Another way of generating packet formats is of course to design them by hand! But even if we choose to do this, the notation can still be used to capture the exact hand-crafted packet formats that we want to use. I've had a go at explaining this distinction in a bit more detail using some examples (see below). > > In RFC 3095 terminology, both EPIC and EPIC-Lite are just encoding > > methods, which we may or may not want to use when compressing > > fields in a header. > > I do not agree with that. An encoding method, in 3095 terminology, > is a way to compress a field, while the core of EPIC and EPIC-Lite > were the algorithms for combining all fields together into > "distinguishable bits on the wire". Is it always the case that an encoding method compresses exactly one field? What about list encoding from RFC 3095? > > Hopefully it should be clear that we can define how to compress all > > of the other fields in a TCP/IP header in a similar manner - then we > > just join them up to get our complete "compressed packet formats". > > This is a very generic approach, but you do not get very efficient formats. Absolutely - all the original example tries to do is to demonstrate how the notation gives "bits on the wire". > With these formats, you have one extra bit for each field, and if you want > to have variable length fields, you get even more control bits. The format > "discriminator" gets large. Ok, let's try something more complicated ;-) Using the same three encoding methods, we can put in a little more effort and create the following encoding for the TCP ports: mini_tcp_header ::= format_1 / (format_2 / (format_3 / format_4)) format_1 ::= static ; TCP Source Port static ; TCP Destination Port format_2 ::= irregular (16) static format_3 ::= static irregular (16) format_4 ::= irregular (16) irregular (16) This corresponds to the following packet formats: +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1|0| TCP Source Port | or +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0| TCP Destination Port | or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1| TCP Source Port | TCP Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These packet formats are more efficient than the ones I gave previously, because a single 1-bit discriminator can be used to indicate that both the Source and Destination ports are static. The point I'm trying to make with all of this is that the notation is just a way of describing how to compress and decompress headers. If you use the encoding methods from RFC 3095 then you can create packet formats just like the ones in 3095, and capture your design decisions via the formal notation. Using the notation without EPIC or EPIC-lite can still be quite useful - the packet formats are "formally" defined, meaning that the notation can be compiled into executable code. This saves a lot of implementation effort! However, on its own the notation won't reduce the amount of effort needed to devise efficient new packet formats - for this we need EPIC or EPIC-lite... > If we want to define automatic means to create the compressed formats, we > need to have means to affect this and reduce the number of possible > combinations to make the discriminator overhead smaller. This is where EPIC and EPIC-lite come in. They both offer more efficient ways of adding discriminators to the compressed header, without having to go to the trouble of designing the packet formats by hand. Let's try the above example using EPIC-lite. We can replace the old "self-describing values" discriminator (denoted by "/") with a new discriminator generated by EPIC-lite (which we'll denote using the symbol "|"). The description of the TCP ports in the formal notation then becomes: mini_tcp_header ::= tcp_source_port tcp_destination_port tcp_source_port ::= static 90% | irregular (16) 10% tcp_destination_port ::= static 90% | irregular (16) 10% Note that EPIC-lite needs an additional parameter whenever we offer a choice of encoding methods - namely the probability that each encoding method will be used. EPIC-lite uses this extra information to work out the best discriminator for each packet format. In the above example (ignoring byte-alignment and reserving the ROHC framework indicator bits), EPIC-lite calculates the overall probability that each packet format will be needed, and assigns shorter discriminators to the more common formats: Format: Source Port: Destination Port: Probability: Discriminator: 1 static static 81% "0" 2 irregular static 9% "10" 3 static irregular 9% "110" 4 irregular irregular 1% "111" EPIC-lite then sticks the correct discriminator onto the front of each packet format. So, we get exactly the same set of packet formats as the ones we designed by hand above, but generated automatically by the EPIC-lite algorithm: +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1|0| TCP Source Port | or +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0| TCP Destination Port | or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1| TCP Source Port | TCP Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Anyway, this was still a very good example, but things get much more > complicated when we start addressing fields that are compressed together, > and when we add context interaction. Static fields are just present in > IR/IR-DYN headers, and those are easily defined without automatic means. Fields that are compressed together are easy to handle using the appropriate encoding method. For example, suppose that we want to compress the IP-ID as an offset from the Master Sequence Number. We can write this in the notation as follows: ip_id ::= inferred_offset (16, MSN) lsb (4, 0) / lsb (8, 0) / irregular (16) The first line subtracts the Master Sequence Number from the IP-ID. The second line compresses the resulting offset by sending a choice of 4 LSBs, 8 LSBs or the 16-bit field in full. Context interactions are also easy to describe using the notation. By default every encoding method automatically updates the context - if we don't want this to be the case for whatever reason then we can write the following: tcp_source_port ::= no_update (static / irregular (16)) This allows us, e.g. to prevent the context from being updated if the packet format doesn't include enough bits of CRC. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 09:15:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00912 for ; Wed, 5 Mar 2003 09:15:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25EQHB29064 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 09:26:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25EQH529061 for ; Wed, 5 Mar 2003 09:26:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00899 for ; Wed, 5 Mar 2003 09:14:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25EQ6529034; Wed, 5 Mar 2003 09:26:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25EPh529009 for ; Wed, 5 Mar 2003 09:25:43 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00880 for ; Wed, 5 Mar 2003 09:14:13 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25EGEB7008324 for ; Wed, 5 Mar 2003 15:16:14 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Mar 2003 15:16:13 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Wed, 5 Mar 2003 15:16:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Some more comments (next cycle, we should try to reduce the number of parallel threads)... > I think that the first step is to explain the scope of the > current notation draft. Once we've clarified this, we can > decide whether the scope is correct, or whether it's too broad, > too narrow etc. Yes, and this would hopefully mean that we all could start using the same terminology and get a common view. We are not there yet, but these discussions are helping a lot to move forward on that path. > > > The ROHC framework is common to all profiles, and > > > provides generic features such as padding and > > > segmentation of the compressed packets (useful if > > > the link layer can only handle a limited range of > > > packet sizes). I noticed that you did not manage to get this paragraph enhanced in the submitted draft. That is fine for now, just make sure to do it in the next revision, using e.g. material from below... > > Well, the framework provides the base for all ROHC > > compression. It defines the profile concept, which makes > > ROHC a general platform for compression schemes. It sets > > link layer requirements, and especially negotiation > > requirements for all ROHC profiles. It defines a set of > > common functions, as segmentation, CID's, and padding. > > It also defines common packet formats (IR, IR-DYN, > > Feedback, Short-CID expander, etc), and it defines a > > generic, profile independent, handling of feedback. > > One can also say that it defines the general principles > > for doing ROHC compression. > > > a) Packet formats for compressing and decompressing > > > headers > > > > I would say "compressed packet formats" > > As I'm not 100% sure what exactly is meant by a "packet > format" (compressed or otherwise), it might be useful to > capture in more detail what information needs to be defined > to get interoperable ROHC profiles: I think all existing header compression schemes should serve as rather good references for what a compressed header format is. Regarding capturing all that is needed to get interoperable ROHC profiles, that is the role of the profile specification and not within scope for the notation. > What we're really trying to define is a *function*, whose > inputs are the uncompressed header and the context, and > whose outputs are the compressed header and a (possibly > updated) version of the context: > > function > uncompressed header <--------------> compressed header > context updated context There is an inconsistency here. We have already agreed that generating packet formats are not within scope for the notation. The notation defines the content of the compressed header "body" (using Carsten's terminology), but to compress the header and get a compressed output, one have to generate the compressed header format, and that is another step. > I'm not sure whether context replication is within the scope > of the state machine - perhaps a more general term that > captures all of the above would be "context management" issues? Might be ok! > A description of, say, TCP/IP in the formal notation will > give you exactly what is defined in a) above. You get a > function whose inputs are the uncompressed header and the > context, and whose outputs are the compressed header and a > (possibly updated) version of the context. Once again, this does not make sense. The notation itself only defines the content of compressed header, not the actual formats. You would have to take additional steps before you can actually get a compressed header to send. (see Carsten's mail). /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 10:02:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02696 for ; Wed, 5 Mar 2003 10:02:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25FDeM01064 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 10:13:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FDe501061 for ; Wed, 5 Mar 2003 10:13:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02640 for ; Wed, 5 Mar 2003 10:02:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FDO501032; Wed, 5 Mar 2003 10:13:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FCX500834 for ; Wed, 5 Mar 2003 10:12:33 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02546 for ; Wed, 5 Mar 2003 10:01:01 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25F32B4022750 for ; Wed, 5 Mar 2003 16:03:03 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Mar 2003 16:03:02 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Wed, 5 Mar 2003 16:03:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, > However, one point I'd like to clarify is that algorithms like > EPIC and EPIC-lite are for -generating- packet formats, whereas > the notation is for -describing- packet formats. Another way of > generating packet formats is of course to design them by hand! Exactly, this is what I have been trying to say all the time. The notation itself is only for describing the content of compressed headers, it only provides a structured input to the process of generating compressed packet formats (by hand or by "automated" means). > But even if we choose to do this, the notation can still be > used to capture the exact hand-crafted packet formats that we > want to use. Yes, the notation should be useful in any case, to get a structured way of documenting the compressed header content. > Is it always the case that an encoding method compresses > exactly one field? What about list encoding from RFC 3095? I would not call list compression itself an encoding method in the sense of 3095, but others might have a different opinion in that regard. List compression is a rather separate part of 3095, while the encoding methods I would refer to are those that are listed as encoding methods in section 4.5. > > This is a very generic approach, but you do not get very > > efficient formats. > > Absolutely - all the original example tries to do is to > demonstrate how the notation gives "bits on the wire". This is where the inconsistency appears. The notation, as you wrote above, does not generate the actual compressed formats. One use the notated information when generating the formats, but this is an additional process. Thus, by just notating the compressed header content, one will not get "bits on the wire". > Let's try the above example using EPIC-lite. We can replace > the old "self-describing values" discriminator (denoted by "/") > with a new discriminator generated by EPIC-lite (which we'll > denote using the symbol "|"). > > mini_tcp_header ::= tcp_source_port > tcp_destination_port > > tcp_source_port ::= static 90% | irregular (16) 10% Do you mean that the current notation language is not providing enough information to use more sophisticated means to generate packet formats? The notation above, i.e. with probabilities, seems to me to be a very generic approach that should be used in the ROHC FN. Even if we did not have a notation then, of course we did have such probability expectations in the back of our heads when we wrote 3095. > In the above example (ignoring byte-alignment and reserving > the ROHC framework indicator bits), EPIC-lite calculates the > overall probability that each packet format will be needed, > and assigns shorter discriminators to the more common formats: In principle, as we did in 3095 (but not by automatic means). > So, we get exactly the same set of packet formats as the ones > we designed by hand above, but generated automatically by the > EPIC-lite algorithm: Yes, and therefore I also agree that we could potentially gain from using such automated means. If we still document the output in a human readible form, it would still be possible to make minor adjustments by hand, and the formats would be independently defined by the profile specification. > > Anyway, this was still a very good example, but things get > > much more complicated when we start addressing fields that > > are compressed together, and when we add context interaction. > > Fields that are compressed together are easy to handle using > the appropriate encoding method. For example, suppose that we > want to compress the IP-ID as an offset from the Master > Sequence Number. We can write this in the notation as follows: > > ip_id ::= inferred_offset (16, MSN) > lsb (4, 0) / lsb (8, 0) / irregular (16) > > Context interactions are also easy to describe using the > notation. By default every encoding method automatically > updates the context - if we don't want this to be the case > for whatever reason then we can write the following: > > tcp_source_port ::= no_update (static / irregular (16)) Looks ok! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 10:05:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02943 for ; Wed, 5 Mar 2003 10:05:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25FGEg01334 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 10:16:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FGE501331 for ; Wed, 5 Mar 2003 10:16:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02900 for ; Wed, 5 Mar 2003 10:04:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FG3501306; Wed, 5 Mar 2003 10:16:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FFb501222 for ; Wed, 5 Mar 2003 10:15:38 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02826 for ; Wed, 5 Mar 2003 10:04:06 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 15:06:08 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B886AA@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'Lajos Zaccomer (ETH)'" , "'rohc@ietf.org'" Subject: RE: [rohc] input bytes beyond message Date: Wed, 5 Mar 2003 15:06:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zacco, Thanks for raising this on the list. I'll add some thoughts into the melting pot. This text appears in the INPUT-BITS instruction as well. I assume that those of us with implementations are internally consistent - that is if we return no bytes we also return no bits, if we return the bytes that are there we also return the bits that are there? This discussion has raised another question: In the case of not returning the bits or bytes, what happens to them? e.g. there are 6 bytes of message left and the next instruction is INPUT-BYTES with length 12. There aren't enough bytes so we jump to the appropriate instruction. I think that in a lot of the bytecodes people are using, there would then be no further INPUT instructions so whether the msg pointer still points to the beginning of the 6 bytes or the end of the message is irrelevant. However, I believe it is undefined which it should be. If there were to be another INPUT instruction e.g. INPUT-BYTES length 6, should it successfully read those bytes or have they effectively been thrown away? Best regards, Abbie >At SIPit, an interesting interpretation problem was found >regarding the INPUT-BYTES instruction. Namely: what to do with >the bytes read if there aren't as many in the message as was requested? > >The RFC says: "If the instruction requests data that lies >beyond the end of the SigComp message, no data is returned. >Instead the UDVM moves program execution to the address >specified by the address operand." > >In my interpretation this sentence means that ONLY data that >lies beyond the end of the message should be discarded. Others >interpreted this to discard even those bytes that were part of >the message. > >Why is this important? Because it may be a very nice feature >to eliminate implementing a loop or passing the length of the >data block, resulting in shorter bytecodes: > INPUT-BYTES maximum_length, destination, continue_address >This instructions reads a maximum of maximum_length bytes from >the message without knowing how many bytes there are. > >I don't think this may impose security risk compared to the >other solution, when all the bytes are discarded, if the >available cpb is increased with the number of the actually >read bytes, instead of the value of the length parameter (the >same way as it is done in the INPUT-HUFFMAN instruction). > >As I need some statement regarding this question in one or two >weeks, I call all interested parties, standardizers and >implementors, to start a discussion on this question. > >BR/Zacco >_______________________________________________ >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 mailnull@www1.ietf.org Wed Mar 5 11:53:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12363 for ; Wed, 5 Mar 2003 11:53:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25H4bo13948 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 12:04:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H4b513945 for ; Wed, 5 Mar 2003 12:04:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12316 for ; Wed, 5 Mar 2003 11:53:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H4K513905; Wed, 5 Mar 2003 12:04:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Gx0513220 for ; Wed, 5 Mar 2003 11:59:00 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11739 for ; Wed, 5 Mar 2003 11:47:26 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 16:49:29 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1EE@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Wed, 5 Mar 2003 16:49:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > > The ROHC framework is common to all profiles, and > > > > provides generic features such as padding and > > > > segmentation of the compressed packets (useful if > > > > the link layer can only handle a limited range of > > > > packet sizes). > > I noticed that you did not manage to get this paragraph enhanced > in the submitted draft. That is fine for now, just make sure to > do it in the next revision, using e.g. material from below... Oops! Thanks for reminding me - I've added your text to the source file so that it will be in the next revision of the draft. > > > Well, the framework provides the base for all ROHC > > > compression. It defines the profile concept, which makes > > > ROHC a general platform for compression schemes. It sets > > > link layer requirements, and especially negotiation > > > requirements for all ROHC profiles. It defines a set of > > > common functions, as segmentation, CID's, and padding. > > > It also defines common packet formats (IR, IR-DYN, > > > Feedback, Short-CID expander, etc), and it defines a > > > generic, profile independent, handling of feedback. > > > One can also say that it defines the general principles > > > for doing ROHC compression. > > > > > > a) Packet formats for compressing and decompressing > > > > headers > > > > > > I would say "compressed packet formats" > > > > As I'm not 100% sure what exactly is meant by a "packet > > format" (compressed or otherwise), it might be useful to > > capture in more detail what information needs to be defined > > to get interoperable ROHC profiles: > > I think all existing header compression schemes should serve > as rather good references for what a compressed header format > is. I'm still not 100% clear about this - e.g. does a compressed header format include a description of which fields update the context? > Regarding capturing all that is needed to get interoperable > ROHC profiles, that is the role of the profile specification > and not within scope for the notation. However, the notation could itself be part of a normative profile specification. In this case it's important to understand exactly what it does and does not define (so we know how much else needs to be done before we have a complete ROHC profile). > > What we're really trying to define is a *function*, whose > > inputs are the uncompressed header and the context, and > > whose outputs are the compressed header and a (possibly > > updated) version of the context: > > > > function > > uncompressed header <--------------> compressed header > > context updated context > > There is an inconsistency here. We have already agreed that > generating packet formats are not within scope for the notation. Yes, the notation itself doesn't help us to generate packet formats (only to capture what's been generated afterwards). > The notation defines the content of the compressed header "body" > (using Carsten's terminology) Unfortunately, I think that there might be a mistake in Carsten's email which is causing some confusion: > > I believe Richard's/Mark's idea is that the notation defines > > all the bits in the compressed packet (its "body"), apart from > > an initial discriminator. This discriminator is what differs > > between EPIC and EPIC-Lite. This isn't the case - in fact the compressed headers generated by EPIC and EPIC-lite have completely different bodies as well. > but to compress the header and get a compressed output, one have > to generate the compressed header format, and that is another step. From the notation's point of view, there's no difference at all between the "discriminator" bits and the "compressed body". In each case, the notation just runs the relevant encoding method to convert the uncompressed data into compressed data. I'll try to explain this using an example. Suppose we define how to compress the TCP Source Port using the formal notation: tcp_source_port ::= static / irregular (16) On its own this description means nothing. However, once we've defined how the three encoding methods (static, irregular and "/") actually work, then the notation specifies the exact bits on the wire that need to be sent to compress the TCP Source Port. Note that the "irregular" encoding method outputs bits that can be considered to be part of the compressed body, whereas the "self-describing values" encoding method (denoted by "/") outputs a 1-bit indicator flag that can be considered to be part of the discriminator. However, the notation doesn't care which is which, because all it does is invoke the encoding method and then stick whatever bits it generates onto the compressed header. EPIC and EPIC-lite work in the same manner. If we want to use EPIC-lite to compress the TCP Source Port instead, then we can write the following: tcp_source_port ::= static 90% | irregular (16) 10% When the notation encounters the symbol "|", it invokes EPIC-lite to generate a suitable discriminator for the compressed header. > > I'm not sure whether context replication is within the scope > > of the state machine - perhaps a more general term that > > captures all of the above would be "context management" issues? > > Might be ok! > > > > A description of, say, TCP/IP in the formal notation will > > give you exactly what is defined in a) above. You get a > > function whose inputs are the uncompressed header and the > > context, and whose outputs are the compressed header and a > > (possibly updated) version of the context. > > Once again, this does not make sense. The notation itself only > defines the content of compressed header, not the actual > formats. You would have to take additional steps before you > can actually get a compressed header to send. (see Carsten's > mail). The only additional step needed to get "bits on the wire" is to define all of the basic encoding methods that the notation draft invokes. However, from the notation's perspective there's no difference between the "discriminator" and the "compressed body". If we use LSB encoding, say, to generate the compressed body then a definition of LSB encoding must of course be provided before we get the compressed headers. Equally, if we use EPIC-lite to generate the discriminator then we have to define how EPIC-lite encoding works. Once this is done, the notation defines the exact bits on the wire for each compressed header. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 5 13:21:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19267 for ; Wed, 5 Mar 2003 13:21:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25IVwE05418 for rohc-archive@odin.ietf.org; Wed, 5 Mar 2003 13:31:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IVwO05415 for ; Wed, 5 Mar 2003 13:31:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19223 for ; Wed, 5 Mar 2003 13:20:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IViO05393; Wed, 5 Mar 2003 13:31:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IOvO04625 for ; Wed, 5 Mar 2003 13:24:57 -0500 Received: from marjan.fesb.hr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14762 for ; Wed, 5 Mar 2003 12:25:29 -0500 (EST) Received: from fesb.hr (demorgan.bit.fesb.hr [161.53.169.245]) (authenticated bits=0) by marjan.fesb.hr (8.12.3/8.12.3/Debian-5) with ESMTP id h25HRRaX018734; Wed, 5 Mar 2003 18:27:27 +0100 Message-ID: <3E663488.1070202@fesb.hr> Date: Wed, 05 Mar 2003 18:31:52 +0100 From: Julije Ozegovic Organization: FESB Split User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en, hr MIME-Version: 1.0 To: "Lars-Erik Jonsson (EAB)" , Carsten Bormann , rohc@ietf.org Subject: Re: [rohc] ROHC@IETF56 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at marjan Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Carsten, Lars, regarding submitted draft draft-ozegovic-mornar-dccp-epic-00.txt I propose a 5 minute slot at IETF 56 to present the following topics: - mechanisms found in DCCP and impact to formal notation - effectiveness of formal notation approach Best regards, Julije Ozegovic Lars-Erik Jonsson (EAB) wrote: > ROHCers, > > The San Francisco meeting is approaching and we are about to > prepare an agenda for the ROHC session. On the tentative agenda, > ROHC is scheduled for a Monday evening slot on the 17th. > > We are now soliciting input on how to spend our session time. > Before proposing an agenda item, consider the following: > - Is it a proper agenda item at this point in time? > * Is there useful material available (as Internet Drafts) > for people to read? > * Has there been mail list discussions indicating that > face2face discussions are needed to get progress? > * Is it reasonable to expect that a face2face discussion > will be able to bring the work forward? > - For new proposals: > * Is the proposal within scope for the WG charter > ** If yes, is there already work ongoing to address > that part of the charter? Has it already been addressed? > ** If no, be aware that focus must be on motivating a > charter update to include the new work item. Exploring > the problem space would thus be the first step. Is it > really proper IETF work, ROHC work? > > If you have proposals for what to discuss at the meeting, please > contact the WG chairs not later than Friday, March 7. > > Rgds, > /Lars-Erik > > -------------------------------------- > Lars-Erik Jonsson > IETF ROHC WG Chair > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 920 20 21 07 > Home: +46 920 999 57 > > My opinions are my personal opinions and should not be considered > as the opinions of my employer, if not explicitly stated. > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 01:53:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14978 for ; Thu, 6 Mar 2003 01:53:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2674R028519 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 02:04:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2674RO28516 for ; Thu, 6 Mar 2003 02:04:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14972 for ; Thu, 6 Mar 2003 01:53:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2674FO28490; Thu, 6 Mar 2003 02:04:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2673lO28473 for ; Thu, 6 Mar 2003 02:03:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14963 for ; Thu, 6 Mar 2003 01:52:21 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h266sPB3011821; Thu, 6 Mar 2003 07:54:25 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 07:54:22 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Surtees, Abigail'" , "'rohc@ietf.org'" Subject: RE: [rohc] input bytes beyond message Date: Thu, 6 Mar 2003 07:51:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-2" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Abbie, I agree with you, the input instructions should have a consistent behaviour, which means if it applies to INPUT-BYTES, it should also apply to INPUT-BITS. The only exception is INPUT-HUFFMAN, as its result is not valid in such a case; however, the problem you raised, in case of discarded data, should be handled in INPUT-HUFFMAN, too. BR/Zacco -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Wednesday, March 05, 2003 4:06 PM To: Lajos Zaccomer (ETH); 'rohc@ietf.org' Subject: RE: [rohc] input bytes beyond message Hi Zacco, Thanks for raising this on the list. I'll add some thoughts into the melting pot. This text appears in the INPUT-BITS instruction as well. I assume that those of us with implementations are internally consistent - that is if we return no bytes we also return no bits, if we return the bytes that are there we also return the bits that are there? This discussion has raised another question: In the case of not returning the bits or bytes, what happens to them? e.g. there are 6 bytes of message left and the next instruction is INPUT-BYTES with length 12. There aren't enough bytes so we jump to the appropriate instruction. I think that in a lot of the bytecodes people are using, there would then be no further INPUT instructions so whether the msg pointer still points to the beginning of the 6 bytes or the end of the message is irrelevant. However, I believe it is undefined which it should be. If there were to be another INPUT instruction e.g. INPUT-BYTES length 6, should it successfully read those bytes or have they effectively been thrown away? Best regards, Abbie >At SIPit, an interesting interpretation problem was found >regarding the INPUT-BYTES instruction. Namely: what to do with >the bytes read if there aren't as many in the message as was requested? > >The RFC says: "If the instruction requests data that lies >beyond the end of the SigComp message, no data is returned. >Instead the UDVM moves program execution to the address >specified by the address operand." > >In my interpretation this sentence means that ONLY data that >lies beyond the end of the message should be discarded. Others >interpreted this to discard even those bytes that were part of >the message. > >Why is this important? Because it may be a very nice feature >to eliminate implementing a loop or passing the length of the >data block, resulting in shorter bytecodes: > INPUT-BYTES maximum_length, destination, continue_address >This instructions reads a maximum of maximum_length bytes from >the message without knowing how many bytes there are. > >I don't think this may impose security risk compared to the >other solution, when all the bytes are discarded, if the >available cpb is increased with the number of the actually >read bytes, instead of the value of the length parameter (the >same way as it is done in the INPUT-HUFFMAN instruction). > >As I need some statement regarding this question in one or two >weeks, I call all interested parties, standardizers and >implementors, to start a discussion on this question. > >BR/Zacco >_______________________________________________ >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 mailnull@www1.ietf.org Thu Mar 6 05:06:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00343 for ; Thu, 6 Mar 2003 05:06:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26AHe520929 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 05:17:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AHeO20926 for ; Thu, 6 Mar 2003 05:17:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00336 for ; Thu, 6 Mar 2003 05:06:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AHSO20889; Thu, 6 Mar 2003 05:17:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AGkO20841 for ; Thu, 6 Mar 2003 05:16:46 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00308 for ; Thu, 6 Mar 2003 05:05:17 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 10:07:20 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F0@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Updating the Formal Notation draft Date: Thu, 6 Mar 2003 10:07:14 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I'm still not sure "Variable" is the right word for this at > the notation level, and as you say we should investigate if > we can avoid having this at all. The examples you have shown > seem to be about compressing fields together, i.e. using > another field as a reference for compressing a field. Would > "Reference" be a potential word if we have to keep this? Hi, Referencing fields is certainly the main use of "temporary variables", but there are some others that might be worth taking into account. In general, we use the variables to store any miscellaneous information that an encoding method needs to compress a field, but which isn't available in the uncompressed packet or in the context. I've had a go at listing all of the places where temporary variables come in handy below: 1. Using another field as a reference to compress a field This is the example mentioned above. Currently we store the actual value of the field in a temporary variable, but it would be ok to instead store a pointer to where the field can be found in the uncompressed packet. So the term "reference" would be fine in this case. 2. Using a "control" field to compress a field In some cases the field that we want to use might be a control field, i.e. one created by the compressor and not found in the uncompressed packet. An example for TCP/IP compression would be the "Master Sequence Number". I'm not sure how we could do this as a reference, since the control fields aren't stored anywhere in the uncompressed packet. 3. Other values that might be needed for compression. We also use temporary variables to store other values, which can't really be considered to be "fields" at all (since they're not part of the compressed or uncompressed packets). Here are some examples: a. Remaining_Data : The number of bits remaining in the uncompressed packet. b. Index : A pointer to the current context entry. c. No_Update : Set to 1 if the encoding method is not supposed to update the context. I'm not sure that "references" captures all of the above, but there are probably better terms than "variables" which we could use. Comments welcome! Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 05:56:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01510 for ; Thu, 6 Mar 2003 05:56:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26B7SJ24426 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 06:07:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26B7SO24423 for ; Thu, 6 Mar 2003 06:07:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01503 for ; Thu, 6 Mar 2003 05:55:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26B7EO24084; Thu, 6 Mar 2003 06:07:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26B6nO23728 for ; Thu, 6 Mar 2003 06:06:49 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01496 for ; Thu, 6 Mar 2003 05:55:18 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26AvMB4021719 for ; Thu, 6 Mar 2003 11:57:22 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 11:57:17 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Date: Thu, 6 Mar 2003 11:55:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Formal notation - Variables (was: Updating the Formal Notation dr aft) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, This was a good summary, and I think we will have to look at each case and see how it can be best expressed. References could be expressed as references. Control fields could be defined as control fields, and then handles exactly as all uncompressed fields. Regarding the other values, these are details that we should discuss further what they really are, and come up with ways to handle. I think it is worth a lot not to group all these together but consider each of them separately, that should make the notation both clearer and more correct. BR /L-E > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: den 6 mars 2003 11:07 > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] Updating the Formal Notation draft > > > > I'm still not sure "Variable" is the right word for this at > > the notation level, and as you say we should investigate if > > we can avoid having this at all. The examples you have shown > > seem to be about compressing fields together, i.e. using > > another field as a reference for compressing a field. Would > > "Reference" be a potential word if we have to keep this? > > Hi, > > Referencing fields is certainly the main use of "temporary > variables", but there are some others that might be worth > taking into account. > > In general, we use the variables to store any miscellaneous > information that an encoding method needs to compress a field, > but which isn't available in the uncompressed packet or in > the context. I've had a go at listing all of the places where > temporary variables come in handy below: > > 1. Using another field as a reference to compress a field > > This is the example mentioned above. Currently we store the > actual value of the field in a temporary variable, but it > would be ok to instead store a pointer to where the field can > be found in the uncompressed packet. So the term "reference" > would be fine in this case. > > 2. Using a "control" field to compress a field > > In some cases the field that we want to use might be a > control field, i.e. one created by the compressor and not > found in the uncompressed packet. An example for TCP/IP > compression would be the "Master Sequence Number". I'm not > sure how we could do this as a reference, since the control > fields aren't stored anywhere in the uncompressed packet. > > 3. Other values that might be needed for compression. > > We also use temporary variables to store other values, which > can't really be considered to be "fields" at all (since they're > not part of the compressed or uncompressed packets). Here are > some examples: > > a. Remaining_Data : The number of bits remaining in the > uncompressed packet. > > b. Index : A pointer to the current context entry. > > c. No_Update : Set to 1 if the encoding method is not > supposed to update the context. > > I'm not sure that "references" captures all of the above, but > there are probably better terms than "variables" which we could > use. Comments welcome! > > Regards, > > Richard > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 08:37:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13424 for ; Thu, 6 Mar 2003 08:37:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26DmXV04774 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 08:48:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DmXO04771 for ; Thu, 6 Mar 2003 08:48:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13330 for ; Thu, 6 Mar 2003 08:36:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DmIO04754; Thu, 6 Mar 2003 08:48:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DkUO04583 for ; Thu, 6 Mar 2003 08:46:30 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13155 for ; Thu, 6 Mar 2003 08:34:56 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 13:36:56 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F2@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'Carsten Bormann'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Thu, 6 Mar 2003 13:36:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > I think what we came up with is a little different -- it > > describes the meaning of compressed headers in terms of > > the uncompressed headers. > > Ok, how does the context(s) come into the picture? Hi, More specifically, the notation defines a function whose inputs are the uncompressed header and the context, and whose outputs are the compressed header and an updated version of the context. What might be confusing about this function is that it's defined in terms of "oracles" - perhaps this is the source of the confusion between defining the candidate compressed header formats, and actually compressing the headers? Oracle functions aren't too complicated - I've explained a bit more about them below. > > > 2) Richard is confusing compressing headers with > > > defining the candidate compressed header formats. > > > > > Well, the compressed header formats are in some way related > > to the uncompressed packet. > > Sure, I would not expect otherwise...=) > > > The notation captures this relationship. The notation can > > use an oracle function to be able to derive more than one > > packet format based on the same uncompressed packet. > > Ok, now we are getting somewhere. Can you elaborate a little > bit on the "oracle" issue? Actually, can you define exactly > what you mean with "oracle", maybe draw some parallel with > well known things, like 3095? An "oracle" function is just a function which returns an implementation-specific value. Whenever the compressed header formats offer a choice for implementers, the notation calls an oracle function to find out what choice the implementer wants to make. A good example from 3095 is the implementation-specific choice we make when selecting which packet format to use. The three steps that need to be taken are as follows: 1. Pick which packet format to use. 2. Output some indicator bits to tell the decompressor which choice you made. 3. Compress the header using the chosen packet format. Step 1 is an implementation-specific choice, so when we're defining a set of packet formats using the formal notation, we call an oracle function to tell us which choice to make. We then convert the output of the oracle function into bits and stick it onto the front of the compressed header. From the notation's perspective the oracle function can be called just like any other function (e.g. the CRC). When the notation is compiled, an implementation of each of these basic functions must of course be provided. For the CRC function you (naturally) implement a CRC. For the oracle function you can write any code you like, since the output of the oracle doesn't affect interoperability. > > In other words, the notation we define (i.e., the library > > of encoding rules) may favor packet formats that are > > different from the ones we finally decided to use in 3095. > > This is of course particularly true if we stick with a > > single discriminator for the whole packet (I believe that > > is a mistake and you need some form of cross-product > > generation of packet formats, which calls for separate > > discriminators -- something my proposal does not even start > > to address yet). > > I followed you up to "single discriminator", but there you lost > me. Can you elaborate on this? This last point is just talking about a specific feature of EPIC-lite, which is that it always generates a single discriminator for the *entire* packet (as opposed to RFC 3095, where there is usually a discriminator to indicate the overall packet format, as well as separate discriminators on the front of each individual compressed protocol header). The EPIC-lite approach is more efficient than the 3095 approach, so I don't know why Carsten thinks we need separate discriminators. However, this is an issue with the EPIC-lite algorithm itself, and we can always change it to generate separate discriminators for each protocol if there's a good reason to do so. The notation will happily support either approach. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 09:16:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15625 for ; Thu, 6 Mar 2003 09:16:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26ERLm07628 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 09:27:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ERLO07623 for ; Thu, 6 Mar 2003 09:27:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15604 for ; Thu, 6 Mar 2003 09:15:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ER7O07612; Thu, 6 Mar 2003 09:27:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EQOO07579 for ; Thu, 6 Mar 2003 09:26:24 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15561 for ; Thu, 6 Mar 2003 09:14:51 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 14:16:54 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F3@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Thu, 6 Mar 2003 14:16:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > Is it always the case that an encoding method compresses > > exactly one field? What about list encoding from RFC 3095? > > I would not call list compression itself an encoding method in > the sense of 3095, but others might have a different opinion in > that regard. List compression is a rather separate part of 3095, > while the encoding methods I would refer to are those that are > listed as encoding methods in section 4.5. In this case we may need to pick a more general term to avoid confusion with 3095. What we're looking for is a term to describe a general "compression function", which converts uncompressed data into compressed data (relative to a context). It shouldn't matter whether the function compresses a single field, a whole protocol header, or even the entire packet. Also, it shouldn't matter whether the function outputs compressed bits that are considered to lie in the "discriminator" or in the "compressed body" part of the header. In particular, the term must be equally suitable for describing all of the following: * LSB encoding * Self-describing variable-length values * List encoding * EPIC-lite Any ideas for a good term to use? Once we have one, I suspect that the scope of the formal notation will be *much* easier to define. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 09:36:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17073 for ; Thu, 6 Mar 2003 09:36:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26ElRO09640 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 09:47:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ElRO09637 for ; Thu, 6 Mar 2003 09:47:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17054 for ; Thu, 6 Mar 2003 09:35:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26El5O09614; Thu, 6 Mar 2003 09:47:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EkVO09574 for ; Thu, 6 Mar 2003 09:46:31 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17005 for ; Thu, 6 Mar 2003 09:34:57 -0500 (EST) Received: from localhost (IDENT:EwEiwE1GvfJ2TqEKZx+38NzarDluutyf@roman.informatik.uni-bremen.de [134.102.218.120]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h26Eas9D005213; Thu, 6 Mar 2003 15:36:58 +0100 (MET) Date: Thu, 6 Mar 2003 15:36:56 +0100 (CET) From: Carsten Bormann X-X-Sender: cabo@ringo.local To: "Price, Richard" cc: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0F1F3@rsys002a.roke.co.uk> Message-ID: References: <76C92FBBFB58D411AE760090271ED41804A0F1F3@rsys002a.roke.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , I liked "rule". Short, sweet, but does not mean to much (i.e., does not get in the way of understanding). (For the same reason, I prefer "label" or maybe "binding" over "variable".) It is completely OK to define a *small* number of "new" terms for *core* concepts of the FN. Some typical mistakes when choosing terminology: 1) trying to be super-precise and inventing a whole new alphabet soup of abbreviations which you *have* to memorize before you can understand anything (unfair example: MPLS). 2) adopting terms from a different domain and using them in an ever-so-slightly different sense so casual readers knowing the original domain are misled to no end (unfair example: SIP). Applied to the question how to call the component statements of the FN: Example for error number one: FDER. Example for error number two: production. Gruesse, Carsten On Thu, 6 Mar 2003, Price, Richard wrote: > In this case we may need to pick a more general term to avoid > confusion with 3095. What we're looking for is a term to describe > a general "compression function", which converts uncompressed > data into compressed data (relative to a context). It shouldn't > matter whether the function compresses a single field, a whole > protocol header, or even the entire packet. Also, it shouldn't > matter whether the function outputs compressed bits that are > considered to lie in the "discriminator" or in the "compressed > body" part of the header. > > In particular, the term must be equally suitable for describing > all of the following: > > * LSB encoding > * Self-describing variable-length values > * List encoding > * EPIC-lite > > Any ideas for a good term to use? Once we have one, I suspect > that the scope of the formal notation will be *much* easier to > define. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 09:38:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17171 for ; Thu, 6 Mar 2003 09:38:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26EnQB09774 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 09:49:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EnQO09771 for ; Thu, 6 Mar 2003 09:49:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17148 for ; Thu, 6 Mar 2003 09:37:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EnAO09756; Thu, 6 Mar 2003 09:49:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EmEO09715 for ; Thu, 6 Mar 2003 09:48:14 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17093 for ; Thu, 6 Mar 2003 09:36:40 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26Echwv026515 for ; Thu, 6 Mar 2003 15:38:43 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 15:38:39 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Date: Thu, 6 Mar 2003 15:37:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Formal notation - "Encoding methods" (Was: Role and approach of t he ROHC formal notation) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > In this case we may need to pick a more general term to avoid > confusion with 3095. What we're looking for is a term to describe > a general "compression function", which converts uncompressed > data into compressed data (relative to a context). It shouldn't > matter whether the function compresses a single field, a whole > protocol header, or even the entire packet. Also, it shouldn't > matter whether the function outputs compressed bits that are > considered to lie in the "discriminator" or in the "compressed > body" part of the header. Here I would strongly disagree. I rather think we should have a few different terms for the different kind of "encoding methods", since I think that would heavily simplify understanding, and make it easier to separate the various pieces. > In particular, the term must be equally suitable for describing > all of the following: > > * LSB encoding > * Self-describing variable-length values I agree that these two should fall into the same category. > * List encoding List compression, as defined in 3095, is a rather different compression method, so I am not sure this falls into the same group. But this is absolutely an open question. > * EPIC-lite Methods to use for generating the actual compressed header formats, e.g. EPIC-lite, are rather different. Which one to use is a profile specification issue, and I am rather skeptical to have such methods defined in the general formal notation, and a question would be which to document there. I rather think we should include THE method used for the profile in the profile specification, and the method might be NULL, for cases where we do the compressed formats "by hand". In any case, these methods should fall into a separate category. > Any ideas for a good term to use? Once we have one, I suspect > that the scope of the formal notation will be *much* easier to > define. "Encoding method" is ok for the formal notation, I think. But that assumes the formal notation would not include everything. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 10:07:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18653 for ; Thu, 6 Mar 2003 10:07:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FIOS12414 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 10:18:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FINO12411 for ; Thu, 6 Mar 2003 10:18:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18593 for ; Thu, 6 Mar 2003 10:06:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FI8O12381; Thu, 6 Mar 2003 10:18:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FHMO12312 for ; Thu, 6 Mar 2003 10:17:22 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18409 for ; Thu, 6 Mar 2003 10:05:48 -0500 (EST) Received: from localhost (IDENT:EfvqVlIm83NbGKwSO9mneVnwPxMJKgKG@roman.informatik.uni-bremen.de [134.102.218.120]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h26F7k9D014067; Thu, 6 Mar 2003 16:07:50 +0100 (MET) Date: Thu, 6 Mar 2003 16:07:49 +0100 (CET) From: Carsten Bormann X-X-Sender: cabo@ringo.local To: "Price, Richard" cc: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0F1F2@rsys002a.roke.co.uk> Message-ID: References: <76C92FBBFB58D411AE760090271ED41804A0F1F2@rsys002a.roke.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > The EPIC-lite approach is more efficient than the 3095 approach, > so I don't know why Carsten thinks we need separate discriminators. I'm not so interested in the separation, just in a way to control the combinatorial explosion. It would then become a matter of design to control which indicators combine to form one discriminator (which is then optimized based on the known probabilities of the possible values) and which ones stay separate to reduce combinatorial explosion. The latter may be desirable when the designer knows that the case in which the indicators are used is unlikely enough, and also when it is somehow clear the values being separated from each other are sufficiently orthogonal that there is little gain in the optimization. All this is, of course, just a set of second-order considerations. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 10:12:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19344 for ; Thu, 6 Mar 2003 10:12:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FNHf12868 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 10:23:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FNHO12865 for ; Thu, 6 Mar 2003 10:23:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19307 for ; Thu, 6 Mar 2003 10:11:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FN2O12827; Thu, 6 Mar 2003 10:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FMQO12775 for ; Thu, 6 Mar 2003 10:22:26 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19240 for ; Thu, 6 Mar 2003 10:10:50 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26FCqwv007185 for ; Thu, 6 Mar 2003 16:12:52 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 16:12:52 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Thu, 6 Mar 2003 16:11:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26FMQO12780 Subject: [rohc] Formal notation, what is it? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, During the last week, we have had an extensive discussion about the formal notation, trying to get a common understanding. After reading both the draft and some recent posts, I have started to wonder whether we all mean that it is just a notation, i.e. a system of symbols, characters, etc, to describe something in a formal way. One could maybe call that a kind of language. This is how I have seen the formal notation, as a language, a tool, for describing how header fields are to be compressed. When defining a new compression profile, the notation (language) would then be used to describe how to compress e.g. TCP fields. What is described in a profile specification, using (at least to some part) the formal notation would then constitute an implementable profile. Note that the notation itself would not be something that would be implementable. Of course, the various mechanisms described by the notation could be implemented, but not the notation itself. The notation is not a machine, it is a language. To me it therefore makes no sense to say that "the notation executes", or "the notation calls". The point is that, I believe the notation should be about.... .....notating, nothing else. /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Luleĺ, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 10:31:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20518 for ; Thu, 6 Mar 2003 10:31:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FgOO14907 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 10:42:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FgOO14904 for ; Thu, 6 Mar 2003 10:42:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20483 for ; Thu, 6 Mar 2003 10:30:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fg7O14883; Thu, 6 Mar 2003 10:42:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FfoO14847 for ; Thu, 6 Mar 2003 10:41:50 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20456 for ; Thu, 6 Mar 2003 10:30:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 15:32:18 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F4@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Carsten Bormann'" Cc: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Thu, 6 Mar 2003 15:32:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, A minor point - I think that this conflicts with the definition of a "rule" as used in Prolog. Our "encoding methods" are a subset of "Prolog rules" - every encoding method can be represented as a Prolog rule, but there are plenty of Prolog rules that don't define encoding methods. Regards, Richard > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, March 06, 2003 2:37 PM > To: Price, Richard > Cc: 'Lars-Erik Jonsson (EAB)'; rohc@ietf.org > Subject: RE: [rohc] Role and approach of the ROHC formal notation > > > I liked "rule". Short, sweet, but does not mean to much (i.e., does not > get in the way of understanding). (For the same reason, I prefer "label" or > maybe "binding" over "variable".) It is completely OK to define a *small* > number of "new" terms for *core* concepts of the FN. > > Some typical mistakes when choosing terminology: > 1) trying to be super-precise and inventing a whole new alphabet soup of > abbreviations which you *have* to memorize before you can understand > anything (unfair example: MPLS). > 2) adopting terms from a different domain and using them in an > ever-so-slightly different sense so casual readers knowing the original > domain are misled to no end (unfair example: SIP). > > Applied to the question how to call the component statements of the FN: > Example for error number one: FDER. > Example for error number two: production. > > Gruesse, Carsten > > On Thu, 6 Mar 2003, Price, Richard wrote: > > > In this case we may need to pick a more general term to avoid > > confusion with 3095. What we're looking for is a term to describe > > a general "compression function", which converts uncompressed > > data into compressed data (relative to a context). It shouldn't > > matter whether the function compresses a single field, a whole > > protocol header, or even the entire packet. Also, it shouldn't > > matter whether the function outputs compressed bits that are > > considered to lie in the "discriminator" or in the "compressed > > body" part of the header. > > > > In particular, the term must be equally suitable for describing > > all of the following: > > > > * LSB encoding > > * Self-describing variable-length values > > * List encoding > > * EPIC-lite > > > > Any ideas for a good term to use? Once we have one, I suspect > > that the scope of the formal notation will be *much* easier to > > define. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 10:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20811 for ; Thu, 6 Mar 2003 10:37:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FmJp15263 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 10:48:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FmJO15260 for ; Thu, 6 Mar 2003 10:48:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20796 for ; Thu, 6 Mar 2003 10:36:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fm7O15246; Thu, 6 Mar 2003 10:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FlwO15224 for ; Thu, 6 Mar 2003 10:47:58 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20788 for ; Thu, 6 Mar 2003 10:36:23 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26FcQwv018311 for ; Thu, 6 Mar 2003 16:38:26 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 16:38:25 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Thu, 6 Mar 2003 16:37:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At this point, I think it is important not to consider such "solution details", but first figure out what we are really trying to achieve here. /L-E > Hi, > > A minor point - I think that this conflicts with the definition of a > "rule" as used in Prolog. Our "encoding methods" are a subset of > "Prolog rules" - every encoding method can be represented as a Prolog > rule, but there are plenty of Prolog rules that don't define encoding > methods. > > Regards, > > Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 10:38:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20895 for ; Thu, 6 Mar 2003 10:38:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FnEi15357 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 10:49:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FnEO15354 for ; Thu, 6 Mar 2003 10:49:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20858 for ; Thu, 6 Mar 2003 10:37:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fn1O15324; Thu, 6 Mar 2003 10:49:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FmMO15279 for ; Thu, 6 Mar 2003 10:48:22 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20800 for ; Thu, 6 Mar 2003 10:36:47 -0500 (EST) Received: from localhost (IDENT:vZ4a2vpFV8JX82B46l8RCvgEj5BHss3i@roman.informatik.uni-bremen.de [134.102.218.120]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h26Fcn9D022759; Thu, 6 Mar 2003 16:38:49 +0100 (MET) Date: Thu, 6 Mar 2003 16:38:51 +0100 (CET) From: Carsten Bormann X-X-Sender: cabo@ringo.local To: "Lars-Erik Jonsson (EAB)" cc: "Rohc (E-mail)" Subject: Re: [rohc] Formal notation, what is it? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > The point is that, I believe the notation should be about.... > .....notating, nothing else. Correct. Now, I did make the proposal that the notation should best be founded on an executable language ("programming language"). The reason for this was that previous attempts at defining a notation all had semantic problems. We needed to map it to *some* CS concepts in a semantically unambiguous way. A programming language has the nice property that it allows you to provide the mapping together with the concepts that you map to. Not any programming language will do here -- you need one that allows defining what amounts to new syntax as well as reasoning about its own programs -- that's why we came up with Prolog and Haskell as two examples (Lisp would be fine, too, but probably too verbose). > Note that the notation itself would not be something that would be > implementable. Of course, the various mechanisms described by the > notation could be implemented, but not the notation itself. The notation > is not a machine, it is a language. To me it therefore makes no sense > to say that "the notation executes", or "the notation calls". This is, of course, a fine line. Using a notation language that is rooted in a programming language and supplying the glue means that the notation would actually be executable. As Richard has explained, the resulting program would not necessarily be very useful without some additional functionality (e.g., oracles). It will have a defined execution semantics, though, and this is the whole point -- it saves us from having to rigorously define the notation semantics in English, which is a much worse language for this purpose. (We do have to give *some* English language definition, because the notation should be reasonably useful to those that did not study its foundation in the chosen language.) Also, we actually can run test cases against the notation and see what they do. A really great tool during development of a profile. All this would be futile if we needed multi-year development efforts to develop the notation and its programming language mapping. It seems, though, that something useful can be built in a much shorter time. I did a useful Prolog prototype (some 50 lines!) in a few hours in Atlanta. Roke Manor did a much more complete Haskell prototype which is still quite manageable. These prototypes have enormously helped in communicating about the properties of the notation that we consider desirable or undesirable. Even if we go back to English-language-only standardization of the notation, the current work will have been tremendously useful. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 10:44:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21294 for ; Thu, 6 Mar 2003 10:44:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FtH915733 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 10:55:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FtHO15730 for ; Thu, 6 Mar 2003 10:55:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21266 for ; Thu, 6 Mar 2003 10:43:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ft4O15705; Thu, 6 Mar 2003 10:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fq6O15549 for ; Thu, 6 Mar 2003 10:52:06 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21044 for ; Thu, 6 Mar 2003 10:40:31 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26FgWx5019808 for ; Thu, 6 Mar 2003 16:42:34 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Mar 2003 16:42:32 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Thu, 6 Mar 2003 16:41:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > I think all existing header compression schemes should serve > > as rather good references for what a compressed header format > > is. > > I'm still not 100% clear about this - e.g. does a compressed > header format include a description of which fields update the > context? Both yes and no. The format is the "bits on the wire", but how to interpret these might of course depend on the state of the context(s). As an example, in the RTP profile, some formats are interpreted different depending on the current mode of operation. > > Regarding capturing all that is needed to get interoperable > > ROHC profiles, that is the role of the profile specification > > and not within scope for the notation. > > However, the notation could itself be part of a normative > profile specification. Well, the notation is just a notation, right? A profile specification might define new "encoding rules" in addition to more general ones, but the notation document we are now working with should be generally applicable. > > There is an inconsistency here. We have already agreed that > > generating packet formats are not within scope for the notation. > > Yes, the notation itself doesn't help us to generate packet > formats (only to capture what's been generated afterwards). Afterwards? Rather what should be used as input to the actual format generation, I think. > I'll try to explain this using an example. Suppose we define how > to compress the TCP Source Port using the formal notation: > > tcp_source_port ::= static / irregular (16) > > On its own this description means nothing. However, once we've > defined how the three encoding methods (static, irregular and "/") > actually work, then the notation specifies the exact bits on the > wire that need to be sent to compress the TCP Source Port. Yes, but the "/" encoding method is rather different from the other two. static and irregular are only about the content to be compressed, while "/" would also define how to combine things together, i.e. create discriminators. > The only additional step needed to get "bits on the wire" is > to define all of the basic encoding methods that the notation > draft invokes. Let me know if you have a different view, but the notation draft defines a notation "language", used to notate things. An implementation of a notated profile might invoke encoding methods described by the notation draft, but not the opposite. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 11:14:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24002 for ; Thu, 6 Mar 2003 11:14:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26GP5119093 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 11:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GP5O19090 for ; Thu, 6 Mar 2003 11:25:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23940 for ; Thu, 6 Mar 2003 11:13:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GOmO19039; Thu, 6 Mar 2003 11:24:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GJqO18537 for ; Thu, 6 Mar 2003 11:19:52 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23306 for ; Thu, 6 Mar 2003 11:08:14 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 16:10:17 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F5@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: RE: [rohc] Formal notation, what is it? Date: Thu, 6 Mar 2003 16:10:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Hi all, > > During the last week, we have had an extensive discussion about the > formal notation, trying to get a common understanding. After reading > both the draft and some recent posts, I have started to wonder whether > we all mean that it is just a notation, i.e. a system of symbols, > characters, etc, to describe something in a formal way. One could > maybe call that a kind of language. > > This is how I have seen the formal notation, as a language, a tool, > for describing how header fields are to be compressed. When defining > a new compression profile, the notation (language) would then be used > to describe how to compress e.g. TCP fields. What is described in a > profile specification, using (at least to some part) the > formal notation would then constitute an implementable profile. This is exactly my understanding of how the notation should be used ;-) > Note that the notation itself would not be something that would be > implementable. I don't understand the above statement. The notation is a language, so it's possible to implement a compiler which converts (say) a description of TCP/IP written in the notation into executable code. > Of course, the various mechanisms described by the notation could be > implemented, but not the notation itself. The notation is not a machine, > it is a language. Yes, which is why it's possible to implement a compiler for the notation. > To me it therefore makes no sense to say that "the notation executes", > or "the notation calls". The above might be misleading - for clarity we should say "a description written using the formal notation calls...". > The point is that, I believe the notation should be about.... > .....notating, nothing else. Absolutely. Would it be possible to point out any specific statements which seem to contradict the above (particularly if they're in the notation draft itself)? Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 12:04:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28774 for ; Thu, 6 Mar 2003 12:04:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HFIb24300 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 12:15:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HFIO24297 for ; Thu, 6 Mar 2003 12:15:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28734 for ; Thu, 6 Mar 2003 12:03:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HF5O24266; Thu, 6 Mar 2003 12:15:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GwYO22219 for ; Thu, 6 Mar 2003 11:58:34 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27018 for ; Thu, 6 Mar 2003 11:46:56 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 16:48:59 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F6@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Formal notation - "Encoding methods" Date: Thu, 6 Mar 2003 16:48:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > In this case we may need to pick a more general term to avoid > > confusion with 3095. What we're looking for is a term to describe > > a general "compression function", which converts uncompressed > > data into compressed data (relative to a context). It shouldn't > > matter whether the function compresses a single field, a whole > > protocol header, or even the entire packet. Also, it shouldn't > > matter whether the function outputs compressed bits that are > > considered to lie in the "discriminator" or in the "compressed > > body" part of the header. > > Here I would strongly disagree. I rather think we should have a few > different terms for the different kind of "encoding methods", since > I think that would heavily simplify understanding, and make it easier > to separate the various pieces. However, a single term is still needed for the concept of an "encoding method" as a whole. Once this term is defined, nothing prevents us from having more specific terms for different kinds of encoding methods. In fact we already do this - e.g. in the notation draft we have the "list encoding methods", the "control field encoding methods" etc. > > In particular, the term must be equally suitable for describing > > all of the following: > > > > * LSB encoding > > * Self-describing variable-length values > > I agree that these two should fall into the same category. > > > * List encoding > > List compression, as defined in 3095, is a rather different compression > method, so I am not sure this falls into the same group. But this is > absolutely an open question. In the notation draft we have a specific section devoted to "list encoding methods" which handle lists of items. However, the notation language itself doesn't treat these encoding methods differently from any others. > > * EPIC-lite > > Methods to use for generating the actual compressed header formats, > e.g. EPIC-lite, are rather different. However, from the point of view of the notation language, is there any reason to treat EPIC-lite differently from the other encoding methods? > Which one to use is a profile specification issue, and I am rather > skeptical to have such methods defined in the general formal notation, > and a question would be which to document there. I rather think we > should include THE method used for the profile in the profile > specification, and the method might be NULL, for cases where we do > the compressed formats "by hand". I disagree with the above. The notation language itself shouldn't make a distinction between EPIC-lite and any other encoding method. If we want to use EPIC-lite to design our compressed header formats then it should be invoked within a ROHC-FN description, in the same way as LSB encoding, list encoding and so on are invoked when we want to use these. This approach is much simpler and more flexible than treating EPIC- lite separately from the other encoding methods. For example, as Carsten mentioned it might be useful to apply EPIC-lite several times to get different discriminator bits for individual protocols in the protocol stack. Or perhaps we might want to encode part of the header using EPIC-lite and the remainder by hand. Both of these are possible if EPIC-lite can be invoked in the same way as the other encoding methods. > In any case, these methods should fall into a separate category. From the perspective of the notation I can't see any reason to treat EPIC-lite differently from, say, LSB encoding or list compression. What would this buy us? > > Any ideas for a good term to use? Once we have one, I suspect > > that the scope of the formal notation will be *much* easier to > > define. > > "Encoding method" is ok for the formal notation, I think. But that > assumes the formal notation would not include everything. Before we decide on the correct terminology, I think that we'll need to resolve the above technical issue. Should the notation language treat EPIC and EPIC-lite differently from the other encoding methods (and if so, what benefits does this give us)? Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 12:33:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01717 for ; Thu, 6 Mar 2003 12:33:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Hj3S28674 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 12:45:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Hj3O28671 for ; Thu, 6 Mar 2003 12:45:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01692 for ; Thu, 6 Mar 2003 12:33:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HinO28628; Thu, 6 Mar 2003 12:44:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HgvO28531 for ; Thu, 6 Mar 2003 12:42:57 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01424 for ; Thu, 6 Mar 2003 12:31:18 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 17:33:22 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1F7@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Role and approach of the ROHC formal notation Date: Thu, 6 Mar 2003 17:33:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > However, one point I'd like to clarify is that algorithms like > > EPIC and EPIC-lite are for -generating- packet formats, whereas > > the notation is for -describing- packet formats. Another way of > > generating packet formats is of course to design them by hand! > > Exactly, this is what I have been trying to say all the time. > The notation itself is only for describing the content of compressed > headers, it only provides a structured input to the process of > generating compressed packet formats (by hand or by "automated" > means). Hi, Based on our recent discussions, I think that I now understand the difference between our views on how the notation should be used. In my view, a ROHC-FN description is a complete specification of "bits on the wire" (assuming of course that all of the basic encoding methods have been defined). In particular, if the compressed header formats are generated by EPIC-lite then the ROHC-FN description invokes EPIC-lite, and provides all of the input needed by EPIC-lite to generate the bits on the wire (which happens to be the content of the compressed headers, plus a set of probability values). If the compressed header formats are created manually then the ROHC-FN description captures the exact hand-crafted packet formats - not just the content of the compressed headers, but the hand-crafted "discriminator" bits as well. > > But even if we choose to do this, the notation can still be > > used to capture the exact hand-crafted packet formats that we > > want to use. > > Yes, the notation should be useful in any case, to get a structured > way of documenting the compressed header content. The notation describes more than just the compressed header content - it describes the exact packet formats (i.e. bits on the wire). Even if we design the packet formats by hand, they can still be described formally using the notation. > > > This is a very generic approach, but you do not get very > > > efficient formats. > > > > Absolutely - all the original example tries to do is to > > demonstrate how the notation gives "bits on the wire". > > This is where the inconsistency appears. The notation, as you > wrote above, does not generate the actual compressed formats. > One use the notated information when generating the formats, > but this is an additional process. Thus, by just notating the > compressed header content, one will not get "bits on the wire". As above, in my view the notation should describe the exact bits on the wire (not just the compressed header content). > > Let's try the above example using EPIC-lite. We can replace > > the old "self-describing values" discriminator (denoted by "/") > > with a new discriminator generated by EPIC-lite (which we'll > > denote using the symbol "|"). > > > > mini_tcp_header ::= tcp_source_port > > tcp_destination_port > > > > tcp_source_port ::= static 90% | irregular (16) 10% > > Do you mean that the current notation language is not providing > enough information to use more sophisticated means to generate > packet formats? The probability values aren't part of the notation itself - they're inputs that are needed by the EPIC-lite encoding method. This might be clearer if we avoid using the rather confusing symbol "|" to denote EPIC-lite, and instead write it out explicitly as follows: tcp_source_port ::= epic_lite (static, irregular (16), 90%, 10%) This means that the TCP Source Port is compressed using EPIC-lite, which in turn offers us a choice of two encoding methods (static or irregular) for compressing the field. After picking one of these two encoding methods, EPIC-lite outputs a suitable discriminator to tell the decompressor which choice has been made. The probability values are just parameters that are needed by EPIC- lite in order to work out which bits on the wire to send. > The notation above, i.e. with probabilities, seems to me to be a > very generic approach that should be used in the ROHC FN. The probabilities aren't part of the notation - they're just the parameters which EPIC-lite needs in order to calculate the bits on the wire. If the notation is describing hand-crafted packet formats, then the probabilities aren't included (because they're not needed to describe the packet formats). > Even if we did not have a notation then, of course we did have > such probability expectations in the back of our heads when we > wrote 3095. However, if we generate the packet formats by hand then the probability values would not be captured in the ROHC-FN description of the compressed packet formats. The description would capture our hand-crafted packet formats instead. > > In the above example (ignoring byte-alignment and reserving > > the ROHC framework indicator bits), EPIC-lite calculates the > > overall probability that each packet format will be needed, > > and assigns shorter discriminators to the more common formats: > > In principle, as we did in 3095 (but not by automatic means). > > > > So, we get exactly the same set of packet formats as the ones > > we designed by hand above, but generated automatically by the > > EPIC-lite algorithm: > > Yes, and therefore I also agree that we could potentially gain > from using such automated means. If we still document the output > in a human readible form, it would still be possible to make > minor adjustments by hand, and the formats would be > independently defined by the profile specification. In my view of how the formal notation works, minor adjustments to the packet formats would be made within the ROHC-FN description itself. We would invoke EPIC-lite to generate the packet formats, and then we would modify the output of EPIC-lite by applying one or more additional encoding methods to tweak the "bits on the wire". The big advantage of making the adjustments within ROHC-FN is that the description of the compressed packet formats remain machine- readable, and can still be compiled into executable code without needing any hand-made adjustments. > > > Anyway, this was still a very good example, but things get > > > much more complicated when we start addressing fields that > > > are compressed together, and when we add context interaction. > > > > Fields that are compressed together are easy to handle using > > the appropriate encoding method. For example, suppose that we > > want to compress the IP-ID as an offset from the Master > > Sequence Number. We can write this in the notation as follows: > > > > ip_id ::= inferred_offset (16, MSN) > > lsb (4, 0) / lsb (8, 0) / irregular (16) > > > > Context interactions are also easy to describe using the > > notation. By default every encoding method automatically > > updates the context - if we don't want this to be the case > > for whatever reason then we can write the following: > > > > tcp_source_port ::= no_update (static / irregular (16)) > > Looks ok! > > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 14:46:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08592 for ; Thu, 6 Mar 2003 14:46:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JvJx08143 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 14:57:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JvJO08140 for ; Thu, 6 Mar 2003 14:57:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08581 for ; Thu, 6 Mar 2003 14:45:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Jv3O08032; Thu, 6 Mar 2003 14:57:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JaWO06144 for ; Thu, 6 Mar 2003 14:36:32 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07686 for ; Thu, 6 Mar 2003 14:24:51 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26JUEF13434 for ; Thu, 6 Mar 2003 21:30:15 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Mar 2003 21:26:54 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 21:26:54 +0200 Received: from localhost.localdomain (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA15720 for ; Thu, 6 Mar 2003 21:26:54 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h26JQima025806 for ; Thu, 6 Mar 2003 21:26:44 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h26JQiTe025805; Thu, 6 Mar 2003 21:26:44 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Thu, 06 Mar 2003 21:26:44 +0200 In-Reply-To: <76C92FBBFB58D411AE760090271ED41804B885BB@rsys002a.roke.co.uk> (Surtees, Abigail's message of "Mon, 20 Jan 2003 13:50:08 -0000") Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) References: <76C92FBBFB58D411AE760090271ED41804B885BB@rsys002a.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 06 Mar 2003 19:26:54.0852 (UTC) FILETIME=[58B5D440:01C2E416] Subject: [rohc] Stack manipulation torture test in -01 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hello, The precompiled bytecode in A.1.13 for stack manipulation test seems to be missing the LOAD (stack_location, 32) instruction at address_a. Here is the correct(?) bytecode. Pekka 0xf814 110e a046 8610 0210 6010 a042 2286 0811 8611 6311 a046 2286 0x0816 2800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 000e a046 200e a048 a140 0724 0x8818 3400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0018 6400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 000e a046 a17f 0ea1 7f1a 0fa1 b003 0x0180 c001 8f19 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0x0000 0000 0000 0000 0000 0023 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 15:41:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11722 for ; Thu, 6 Mar 2003 15:41:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26KqIw12858 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 15:52:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KqIO12855 for ; Thu, 6 Mar 2003 15:52:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11707 for ; Thu, 6 Mar 2003 15:40:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Kq5O12834; Thu, 6 Mar 2003 15:52:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KUkO11082 for ; Thu, 6 Mar 2003 15:30:46 -0500 Received: from marjan.fesb.hr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11096 for ; Thu, 6 Mar 2003 15:19:03 -0500 (EST) Received: from fesb.hr (demorgan.bit.fesb.hr [161.53.169.245]) (authenticated bits=0) by marjan.fesb.hr (8.12.3/8.12.3/Debian-5) with ESMTP id h26KKraX014066 for ; Thu, 6 Mar 2003 21:20:53 +0100 Message-ID: <3E67AEC5.7080705@fesb.hr> Date: Thu, 06 Mar 2003 21:25:41 +0100 From: Julije Ozegovic Organization: FESB Split User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en, hr MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at marjan Content-Transfer-Encoding: 7bit Subject: [rohc] EPIC-Lite software released version 1.10 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ROHCers, EPIC-Lite implementation release V1.10 is available on http://www.epic-lite.org In version V1.10: - Huffman preprocessing is supported - SCTP is supported - full SCTP interoperability with Roke Manor is achieved - some bugs were discovered and removed - SCTP test archive is added Please use V1.10 for future reference. V1.00 is removed. We are sorry that program is based on already expired draft, but currently we have nothing better: draft-ietf-rohc-epic-lite-01.txt (already expired). Test files are included for reference, this time archives for TCP, RTP and SCTP are separated. We are working on DCCP profile (just for fun :) and have serious plans to implement multiple profile multiple flow functionality. As soon as new formal notation is stable, we hope to upgrade our program accordingly. Best regards, Julije Ozegovic _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 6 15:58:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12234 for ; Thu, 6 Mar 2003 15:58:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26L9Sr14429 for rohc-archive@odin.ietf.org; Thu, 6 Mar 2003 16:09:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26L9SO14426 for ; Thu, 6 Mar 2003 16:09:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12206 for ; Thu, 6 Mar 2003 15:57:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26L9CO14389; Thu, 6 Mar 2003 16:09:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KbdO12031 for ; Thu, 6 Mar 2003 15:37:39 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11277 for ; Thu, 6 Mar 2003 15:25:58 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h26KS0v68420; Thu, 6 Mar 2003 21:28:00 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.27] (dial03.office [10.1.1.27]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2A58D920E0; Thu, 6 Mar 2003 21:30:16 +0100 (CET) Date: Thu, 06 Mar 2003 21:28:13 +0100 From: Juergen Quittek To: "West, Mark (ITN)" , "Rohc (E-mail)" Subject: Re: [rohc] MIB Message-ID: <78556568.1046986093@[10.1.1.27]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, Sorry for the late reply. Thank you very much for all the comments. Please find detailed replies inline. Juergen -- West, Mark (ITN) wrote on 04 February 2003 09:04 +0000: > > Hi all, > > Having been asked to have a read the MIB for ROHC, I finally got around to it. Here are my comments. Mostly these are just a few typos. Anyway... > > 4.1.2. 'notIn&Use' -> 'notInUse'? Fixed. > 4.1.4. the state of the CID seems to be missing an entry... > 'conrtext' -> 'context' Fixed. > 'mean packets size' -> 'mean packet size' Fixed. > Since a row in the rohcContextTable is created when a context is initialised, I was wondering whether it makes sense to create a contxt in the 'unused' state? I suppose if you view creating a pool of unassigned contexts to use, they would be 'unused'. Yes, you are right. This was one of the thoughts behind introducing state 'unused'. For example, if you do not use LARGE_CIDS, you might want to report on all 16 CIDs. But I agree, that state 'unused' is not really necessary. However, it does not harm also and may give a little bit more expressiveness in some situations. > I don't think anything needs to change -- I'm just thinking out loud! > > 4.3. This is just a random thought, but... I noticed that the LLA profiles are bundled in with the ROHC-RTP profiles. On one level this clearly makes sense, since they compressing the same thing. On the other hand, there a quite a lot of things that > are LLA specific and have no relevance to the 'regular' RTP profiles. If it's not possible/too much of a change, I wouldn't bother, but... is it possible to have the LLA bits as an extension of the original RTP profiles, rather than included. We discussed this several times with Ghyslain and others. The conclusion was that the LLA profile has a lot in common with the RTP profile, but it is not possible - with given SMI limitations - to define the LLA profile as an extension of the RTP profile without re-wiriting almost everything. > 5. > > Definition of rohcChannelEntry seems suspicious -- referring to 'scripts in non-volatile memory'... Yep, This was a copy-and-paste-error. It's fixed. > rohcChannelType: 'ight' -> 'might' Fixed. > rohcInstanceVersion: I assume that this a 'vendor specific' version? (i.e. I'm not aware of any 'version' of rohc, per se, but only of the profiles... Yes. The text says "version number of the implementation", not "version number of the specification". > rohcInstanceLargeCIDs: 'retireved' -> 'retrieved' Fixed. > rohcInstanceMRRU: 'according to .' According to what?! Removed "according to". > rohcInstanceContextStorageTime: 'rohcInstanceContextExpireTime' doesn't appear anywhere in the MIB..! Fixed. > rohcInstancePackets: 'Counter of passing' -> 'Counter of packets passing' Fixed. > rohcInstanceCompressionRatio: would it be useful to have the compression ratio for just the headers as well as the overall compression ratio? We discussed this some time ago. Ghyslain or Lars-Erik, or both of them said no. > rohcProfileTable: I can understand this storing a list of the profiles supported by the decompressor (and, I assume, this would cover the compressor for that instance?) but I'm not sure about the injunction that the compressor MUST NOT use a profile > not in the list. A compressor can only use a profile that has been negotiated (in some way) with the peer decompressor. I guess you could use the MIB to do that, but... I replaced the text according to Lars-Erik's suggestion. > rohcProfileVersion: I assume that this some 'vendor specific' version, since rohc profiles have a version encoded into the profile identifier... Yes. The text says "version number of the implementation", not "version number of the specification". > rohcContextCIDState: can a CID change state from 'active' to 'active'..? No. The state machine per CID is +--> 'terminated' -+ | | 'unused' ---> 'active' -+ | ^ | v | +--> 'expired' --->+ | | +-------------------------+ > rohcContextStorageTime: 'rochContextCIDState' -> 'rohcContextCIDState' Fixed. > rohcContextFeedbacks: 'feddbacks' -> 'feedbacks' Fixed. > rohcContextAllPacjetsMeanSize: 'in byte rounded' -> 'in bytes rounded' Fixed. > rohcContextAllHeadersMeanSize: 'in byte rounded' -> 'in bytes rounded' Fixed. > rohcContextLastHeadersMeanSize: 'in byte rounded' -> 'in bytes rounded' Fixed. > rohcRtpContextState 'noContex' -> 'noContext' Fixed. > 6. Well, ok, not directly related to the text in the security considerations but... Is there no way of using the MIB to control the mode in which a decompressor operates? There aren't many changes that you might like to be able to make to a rohc > instance, but that struck me as a possibility. We discussed configuring a context by means of the MIB two times at ROHC sessions. Both times, the conclusion was: We don't need it. > Cheers, Thanks. > > Mark. > > -- > Mark A. West, Consultant Engineer > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Mar 7 04:45:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16496 for ; Fri, 7 Mar 2003 04:45:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h279vA103972 for rohc-archive@odin.ietf.org; Fri, 7 Mar 2003 04:57:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279vAO03969 for ; Fri, 7 Mar 2003 04:57:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16487 for ; Fri, 7 Mar 2003 04:45:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279v0O03943; Fri, 7 Mar 2003 04:57:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279s7O03825 for ; Fri, 7 Mar 2003 04:54:07 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16418 for ; Fri, 7 Mar 2003 04:42:10 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 09:44:13 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B886C1@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'Pekka Pessi'" , rohc@ietf.org Subject: RE: [rohc] Stack manipulation torture test in -01 Date: Fri, 7 Mar 2003 09:44:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Pekka, Thanks for pointing it out and providing the correct bytecode. We'll change it in the next version of the draft. Best regards, Abbie >-----Original Message----- >From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] >Sent: 06 March 2003 19:27 >To: rohc@ietf.org >Subject: [rohc] Stack manipulation torture test in -01 > > > Hello, > > The precompiled bytecode in A.1.13 for stack manipulation test > seems to be missing the LOAD (stack_location, 32) instruction at > address_a. Here is the correct(?) bytecode. > > Pekka > > 0xf814 110e a046 8610 0210 6010 a042 2286 0811 8611 6311 a046 2286 > 0x0816 2800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 0000 000e a046 200e a048 a140 0724 > 0x8818 3400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0018 6400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 000e a046 a17f 0ea1 7f1a 0fa1 b003 > 0x0180 c001 8f19 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0000 0000 0000 0000 0000 0023 > >_______________________________________________ >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 mailnull@www1.ietf.org Fri Mar 7 07:06:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23452 for ; Fri, 7 Mar 2003 07:06:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CHcb17610 for rohc-archive@odin.ietf.org; Fri, 7 Mar 2003 07:17:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CHcO17607 for ; Fri, 7 Mar 2003 07:17:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23403 for ; Fri, 7 Mar 2003 07:05:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CHPO17591; Fri, 7 Mar 2003 07:17:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C6GO15788 for ; Fri, 7 Mar 2003 07:06:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21498; Fri, 7 Mar 2003 06:54:16 -0500 (EST) Message-Id: <200303071154.GAA21498@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:54:16 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-mib-rtp-06.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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 : Definitions of Managed Objects for Robus Header Compression Author(s) : J. Quittek et al. Filename : draft-ietf-rohc-mib-rtp-06.txt Pages : 44 Date : 2003-3-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of robust header compression. The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP profile, the ROHC UDP profile, and the ROHC ESP profile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-mib-rtp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mib-rtp-06.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-mib-rtp-06.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: <2003-3-6125412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-mib-rtp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-mib-rtp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125412.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 7 10:07:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08827 for ; Fri, 7 Mar 2003 10:07:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FJGk02698 for rohc-archive@odin.ietf.org; Fri, 7 Mar 2003 10:19:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FJGO02695 for ; Fri, 7 Mar 2003 10:19:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08728 for ; Fri, 7 Mar 2003 10:07:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FEZO02012; Fri, 7 Mar 2003 10:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F6QO00457 for ; Fri, 7 Mar 2003 10:06:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07267; Fri, 7 Mar 2003 09:54:22 -0500 (EST) Message-Id: <200303071454.JAA07267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 09:54:22 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-field-behavior-02.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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 : TCP/IP Field Behavior Author(s) : M. West, S. McCanne Filename : draft-ietf-rohc-tcp-field-behavior-02.txt Pages : 42 Date : 2003-3-6 This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible thanks to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095 [31]. This memo performs a similar role for the compression of TCP/IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-field-behavior-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tcp-field-behavior-02.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-tcp-field-behavior-02.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: <2003-3-6175723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-tcp-field-behavior-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-tcp-field-behavior-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6175723.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 7 15:57:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02387 for ; Fri, 7 Mar 2003 15:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27L9eN08809 for rohc-archive@odin.ietf.org; Fri, 7 Mar 2003 16:09:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L9dO08806 for ; Fri, 7 Mar 2003 16:09:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02282 for ; Fri, 7 Mar 2003 15:57:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L9KO08791; Fri, 7 Mar 2003 16:09:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KnkO05977 for ; Fri, 7 Mar 2003 15:49:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29754; Fri, 7 Mar 2003 15:37:34 -0500 (EST) Message-Id: <200303072037.PAA29754@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:37:34 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-formal-notation-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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 : Formal Notation for Robust Header Compression (ROHC-FN) Author(s) : R. Price et. al. Filename : draft-ietf-rohc-formal-notation-01.txt Pages : 28 Date : 2003-3-7 This document defines ROHC-FN: a formal notation for specifying how to compress and decompress fields from an arbitrary protocol stack. ROHC-FN is intended to simplify the creation of new compression profiles to fit within the ROHC [RFC-3095] framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-formal-notation-01.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-formal-notation-01.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: <2003-3-7151748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-formal-notation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-formal-notation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151748.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 10 21:18:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24393 for ; Mon, 10 Mar 2003 21:18:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B2VWi08292 for rohc-archive@odin.ietf.org; Mon, 10 Mar 2003 21:31:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B2VWO08289 for ; Mon, 10 Mar 2003 21:31:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24376 for ; Mon, 10 Mar 2003 21:17:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B2VJO08241; Mon, 10 Mar 2003 21:31:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B2U0O08207 for ; Mon, 10 Mar 2003 21:30:00 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24353 for ; Mon, 10 Mar 2003 21:16:15 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 10 Mar 2003 18:18:22 -0800 Received: from 192.169.41.41 by lw8fd.law8.hotmail.msn.com with HTTP; Tue, 11 Mar 2003 02:18:22 GMT X-Originating-IP: [192.169.41.41] From: "william zheng" To: rohc@ietf.org Date: Tue, 11 Mar 2003 02:18:22 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 11 Mar 2003 02:18:22.0441 (UTC) FILETIME=[7D4FF590:01C2E774] Subject: [rohc] ROHC-FN Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: ,

Hi All,

We have seen the new release of ROHC-FN. May I know the reason for the change that "updated_context" has removed? In the new release, the encoding method FIELD updates the context with the new field value as it does compression but there is no rollback action of updating the context when the compression/decompression may fail. How to understand it?

In addition to the description on the compression procedures of the pre-defined, basic and extended library of all the encoding methods in the draft,  should we need its counterpart the decompression  procedures to complete the understanding of the encoding methods that is useful to those who try to write the encoding algorithm of the profile such as ROHC-TCP?

Any help is greatly appreciated.

Regards,

William


MSN 8 helps ELIMINATE E-MAIL VIRUSES. Get 2 months FREE*. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 11 11:13:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25189 for ; Tue, 11 Mar 2003 11:13:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BGQhl09799 for rohc-archive@odin.ietf.org; Tue, 11 Mar 2003 11:26:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGQhO09796 for ; Tue, 11 Mar 2003 11:26:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25163 for ; Tue, 11 Mar 2003 11:12:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGQSO09747; Tue, 11 Mar 2003 11:26:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGP7O09672 for ; Tue, 11 Mar 2003 11:25:07 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25104 for ; Tue, 11 Mar 2003 11:11:04 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BGDBwv028034; Tue, 11 Mar 2003 17:13:11 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 17:13:10 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Richard Price (E-mail)" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Tue, 11 Mar 2003 17:13:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, > > One interesting open issue, however, is the level of > > complexity needed in the final TCP encoding. Our current > > implementation only uses a very basic set of packet formats, > > designed specifically to be human-readable. > > Are these documented anywhere? Can you send the TCP packet formats you used to the mailing list? Thanks, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 11 11:51:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27195 for ; Tue, 11 Mar 2003 11:51:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BH5IL13145 for rohc-archive@odin.ietf.org; Tue, 11 Mar 2003 12:05:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH5IO13142 for ; Tue, 11 Mar 2003 12:05:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27157 for ; Tue, 11 Mar 2003 11:51:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH54O13117; Tue, 11 Mar 2003 12:05:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH2GO12610 for ; Tue, 11 Mar 2003 12:02:16 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27023 for ; Tue, 11 Mar 2003 11:48:13 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 16:50:20 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F200@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Tue, 11 Mar 2003 16:50:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > One interesting open issue, however, is the level of > > > complexity needed in the final TCP encoding. Our current > > > implementation only uses a very basic set of packet formats, > > > designed specifically to be human-readable. > > > > Are these documented anywhere? > > Can you send the TCP packet formats you used to the mailing list? No problem. Would you like them in notated or pictorial form (or both, for comparison)? If you'd like the packet formats in pictorial form, are the pictures themselves sufficient or should all of the ancillary information needed to get "bits on the wire" also be included (e.g. field dependencies, interpretation intervals for LSB encoding, context updating properties etc.)? Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 11 17:15:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15089 for ; Tue, 11 Mar 2003 17:15:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BMTRD06153 for rohc-archive@odin.ietf.org; Tue, 11 Mar 2003 17:29:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMTRO06150 for ; Tue, 11 Mar 2003 17:29:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15063 for ; Tue, 11 Mar 2003 17:15:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMTGO06140; Tue, 11 Mar 2003 17:29:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMSSO06105 for ; Tue, 11 Mar 2003 17:28:28 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15011 for ; Tue, 11 Mar 2003 17:14:19 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BMGPwv011250; Tue, 11 Mar 2003 23:16:26 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 23:16:25 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Price, Richard'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Tue, 11 Mar 2003 23:16:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > Can you send the TCP packet formats you used to the mailing list? > > No problem. Would you like them in notated or pictorial form (or > both, for comparison)? > > If you'd like the packet formats in pictorial form, are the pictures > themselves sufficient or should all of the ancillary information > needed to get "bits on the wire" also be included (e.g. field > dependencies, interpretation intervals for LSB encoding, context > updating properties etc.)? I think the pictorial form would be ok also without the "rules" for how to interpret the bits. Together with the notation form, it would be a good example. Thanks! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 11 17:52:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16173 for ; Tue, 11 Mar 2003 17:52:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BN6Fm08794 for rohc-archive@odin.ietf.org; Tue, 11 Mar 2003 18:06:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN6FO08791 for ; Tue, 11 Mar 2003 18:06:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16160 for ; Tue, 11 Mar 2003 17:52:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN64O08783; Tue, 11 Mar 2003 18:06:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN5WO08755 for ; Tue, 11 Mar 2003 18:05:32 -0500 Received: from exchsvr.octasic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16138 for ; Tue, 11 Mar 2003 17:51:22 -0500 (EST) Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 17:33:53 -0500 Message-ID: From: Remi Pelland To: "'rohc@ietf.org'" Date: Tue, 11 Mar 2003 17:33:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BN5WO08756 Subject: [rohc] FW: GRE and RFC 3095. Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I haven't received any response to my question below. Anyone know about the two "GRE checksum" fields appearing in the general packet format shown at the beginning of section 5.7? Thanks. Remi. > -----Original Message----- > From: Remi Pelland > Sent: Monday, March 03, 2003 10:01 AM > To: 'rohc@ietf.org' > Subject: GRE and RFC 3095. > > > The general compressed RTP header format provided in section 5.7 shows two > occurences of "GRE checksum". I understand that the one following the "AH > data for outer list" is associated with the outer GRE header, which leaves > the one just before the "UDP checksum" associated with the inner header. > > I'm far from being a GRE expert, so there may be something I didn't quite > understand. However, when looking at RFC 2784 it seems to me like the GRE > header is always followed by an IPv4 header (the one from the payload > packet). It thus seems impossible to find a GRE header somewhere between > the inner IP header and the UDP header. > > With this in mind, I'm wondering about the purpose of the second "GRE > checksum" entry in the general packet format. > > Any input on this would be appreciated. > > Thanks, > Rémi. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 12 03:49:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26365 for ; Wed, 12 Mar 2003 03:49:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C93mC25426 for rohc-archive@odin.ietf.org; Wed, 12 Mar 2003 04:03:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C93lO25423 for ; Wed, 12 Mar 2003 04:03:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26358 for ; Wed, 12 Mar 2003 03:49:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C93ZO25414; Wed, 12 Mar 2003 04:03:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C91xO25087 for ; Wed, 12 Mar 2003 04:01:59 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26315 for ; Wed, 12 Mar 2003 03:47:37 -0500 (EST) Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h2C8naHU009967; Wed, 12 Mar 2003 09:49:43 +0100 (MET) Date: Wed, 12 Mar 2003 09:49:31 +0100 Subject: Re: [rohc] FW: GRE and RFC 3095. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Carsten Bormann , "'rohc@ietf.org'" To: Remi Pelland From: Carsten Bormann In-Reply-To: Message-Id: <8A881AF3-5467-11D7-9CBB-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Remi, while GRE may be used to encapsulate protocols other than IPv4 (cf. "Note that this implies that only GRE headers with Ether types that correspond to an IP protocol number can be compressed." in 5.8.4.4), your basic point is correct. With the current set of profiles and ethertype assignments, it seems you only ever can have one GRE header in a ROHC compressed packet. I seem to remember that we noticed your point late in the development of RFC 3095, but at that point the formats were fixed. If we later define a profile that does provide for a nesting of more than one GRE header (e.g., the IP profile currently under discussion), the currently defined formats will come in handy. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 12 08:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03566 for ; Wed, 12 Mar 2003 08:55:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CE9cW14193 for rohc-archive@odin.ietf.org; Wed, 12 Mar 2003 09:09:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CE9cO14190 for ; Wed, 12 Mar 2003 09:09:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03535 for ; Wed, 12 Mar 2003 08:55:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CE9KO14180; Wed, 12 Mar 2003 09:09:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CE8rO14163 for ; Wed, 12 Mar 2003 09:08:53 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03528 for ; Wed, 12 Mar 2003 08:54:21 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 13:56:30 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F201@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile (described pictorially) Date: Wed, 12 Mar 2003 13:56:30 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Here is the current set of TCP/IP packet formats that we use in our implementation. At present we only have limited support for TCP options (and no support for IPv6 or extension headers), but it should be easy enough to add these later on. The pictures themselves only describe the compressed versions of each field, so the rules for how to interpret these compressed bits must be provided separately. If you need these rules, you can find them in the ROHC-FN version of the packet formats. The indicator flags are currently designed by hand in a very simplistic manner, so there's plenty of scope for making them more efficient in future (e.g. by using EPIC-lite to generate them automatically). Comments welcome! Regards, Richard ---------------------------------------------------------------------------------------- 1. Overall Compressed TCP/IP Header +-------------------------------+ denotes a variable number of bits +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ denotes an exact number of bits (in this case 16) The overall compressed TCP/IP packet format is divided into the following headers: +-------------------------------+ | Control Fields | (see 2) +-------------------------------+ | TCP Header | (see 3) +-------------------------------+ | IP Header | (see 4) +-------------------------------+ | Padding | +-------------------------------+ N.B. The "Padding" field adds enough zero bits onto the compressed header to ensure byte-alignment. To Do: Pad with something more sensible, e.g. sequence number. 2. Control Fields +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| MSN | or |1| MSN | +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N.B. "MSN" is the Master Sequence Number, used for inferring the IP-ID. The MSN will also be needed for feedback packets. To Do: At some stage we should add support for a CRC. 3. TCP Header +-------------------------------+ | TCP Data Offset | (3.1) +-------------------------------+ | TCP Options | (3.2) +-------------------------------+ | TCP Urgent Fields | (3.3) +-------------------------------+ | TCP Checksum | (3.4) +-------------------------------+ | TCP Window | (3.5) +-------------------------------+ | TCP Flags | (3.6) +-------------------------------+ | TCP Sequence and Ack Numbers | (3.7) +-------------------------------+ | TCP Destination Port | (3.8) +-------------------------------+ | TCP Source Port | (3.9) +-------------------------------+ 3.1. TCP Data Offset +-+ +-+-+-+-+-+ |0| or |1| D.O. | +-+ +-+-+-+-+-+ N.B. "D.O." is the TCP Data Offset. 3.2. TCP Options +-+ +-+-------------------------------+ |0| or |1| TCP Options | variable length +-+ +-+-------------------------------+ N.B. If the TCP Options change then we currently just send them in full. The length of the TCP Options can be derived from the TCP Data Offset. To Do: Add better support for options, including specific compressed header formats for well-known options such as SACK and Timestamp. 3.3. TCP Urgent Fields +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1| TCP Urgent Pointer |U| +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N.B. "U" is the URG flag. 3.4. TCP Checksum +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N.B. Always send this in full to avoid breaking end-to-end error protection. 3.5. TCP Window +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1|0| TCP Window | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1| TCP Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.6. TCP Flags +-------------------------------+ | RST, SYN and FIN Flags | (3.6.1) +-------------------------------+ | PSH and ACK Flags | (3.6.2) +-------------------------------+ | ECN Flags | (3.6.3) +-------------------------------+ | Reserved Bits | (3.6.4) +-------------------------------+ N.B. The URG flag is compressed together with the Urgent Pointer. 3.6.1. RST, SYN and FIN Flags +-+ +-+-+ +-+-+-+ +-+-+-+-+-+-+ |0| or |1|0| or |1|1|0| or |1|1|1|R|S|F| +-+ +-+-+ +-+-+-+ +-+-+-+-+-+-+ N.B. "R" is the RST flag, "S" is the SYN flag and "F" is the FIN flag. 3.6.2. PSH and ACK Flags +-+-+ +-+-+-+ |P|0| or |P|1|A| +-+-+ +-+-+-+ N.B. "P" is the PSH flag and "A" is the ACK flag. 3.6.3. ECN Flags +-+ +-+-+-+-+-+ |0| or |1|ECN|C|E| +-+ +-+-+-+-+-+ N.B. "C" is the CWR flag and "E" is the ECE flag. The ECN bits are from the IP header. 3.6.4. Reserved Bits +-+ +-+-+-+-+-+ |0| or |1| Res | +-+ +-+-+-+-+-+ N.B. We allow the TCP reserved bits to be sent in full for future-proofing. 3.7. TCP Sequence and Ack Numbers +-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1|0| Ack Number | or |1|1|0| Sequence Number | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1|1|0| Ack Number | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1|1|1|0| Ack Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1|1|1|1|0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1|1|1|1|1|0| Ack Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1|1|1|1|1|1|0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1|1|1|1|1|1|1|0| Ack Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ack Number (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.8. TCP Destination Port +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1| TCP Destination Port | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.9. TCP Source Port +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1| TCP Source Port | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IP Header +-------------------------------+ | IP Destination Address | (4.1) +-------------------------------+ | IP Source Address | (4.2) +-------------------------------+ | IP Time To Live | (4.3) +-------------------------------+ | IP Don't Fragment | (4.4) +-------------------------------+ | IP-ID | (4.5) +-------------------------------+ | IP TOS | (4.6) +-------------------------------+ 4.1. IP Destination Address +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1| IP Destination Address | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2. IP Source Address +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| or |1| IP Source Address | +-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3. IP Time To Live +-+ +-+-+-+-+-+-+-+-+-+ |0| or |1| Time To Live | +-+ +-+-+-+-+-+-+-+-+-+ 4.4. IP Don't Fragment +-+ +-+-+ |0| or |1|D| +-+ +-+-+ N.B. "D" is the Don't Fragment flag. 4.5. IP-ID +-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ |0| IP-ID | or |1|0| IP-ID | +-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or |1|1| IP-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N.B. The IP-ID is compressed as an offset from the MSN. 4.6. IP TOS +-+ +-+-+-+-+-+-+-+ |0| or |1| IP TOS | +-+ +-+-+-+-+-+-+-+ N.B. The ECN flags are compressed separately. > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Tuesday, March 11, 2003 10:16 PM > To: Price, Richard; 'rohc@ietf.org' > Subject: RE: [rohc] TCP compression profile > > > > > Can you send the TCP packet formats you used to the mailing list? > > > > No problem. Would you like them in notated or pictorial form (or > > both, for comparison)? > > > > If you'd like the packet formats in pictorial form, are the pictures > > themselves sufficient or should all of the ancillary information > > needed to get "bits on the wire" also be included (e.g. field > > dependencies, interpretation intervals for LSB encoding, context > > updating properties etc.)? > > I think the pictorial form would be ok also without the "rules" for how > to interpret the bits. Together with the notation form, it would be a > good example. > > Thanks! > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 12 08:59:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03687 for ; Wed, 12 Mar 2003 08:59:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CEDT514399 for rohc-archive@odin.ietf.org; Wed, 12 Mar 2003 09:13:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CEDTO14396 for ; Wed, 12 Mar 2003 09:13:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03679 for ; Wed, 12 Mar 2003 08:58:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CED2O14376; Wed, 12 Mar 2003 09:13:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CECYO14351 for ; Wed, 12 Mar 2003 09:12:34 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03650 for ; Wed, 12 Mar 2003 08:58:04 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 14:00:13 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F202@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile (described using ROHC-FN) Date: Wed, 12 Mar 2003 14:00:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ... and for comparison, the TCP/IP packet formats described using ROHC-FN are as follows: tcp_ip_encoding ::= create_msn inferred_ip_checksum ip_header tcp_header other_fields ip_header ::= ip_version ip_header_length ip_tos ip_length ip_id ip_reserved ip_dont_fragment ip_more_fragments ip_offset ip_time_to_live ip_protocol ip_checksum ip_source_address ip_dest_address tcp_header ::= tcp_source_port tcp_dest_port tcp_seq_ack tcp_data_offset tcp_reserved tcp_ecn tcp_urg tcp_ack tcp_psh tcp_rsf tcp_window tcp_checksum tcp_urg_pointer tcp_options other_fields ::= next_field (MSN) lsb (3, 0) / irregular (16) ip_version ::= value (4, 4) ip_header_length ::= value (4, 5) ip_tos ::= static / irregular (6) label (2, ECN) ip_length ::= inferred_size (16, -48) ip_id ::= inferred_offset (16, MSN) lsb (4, 0) / lsb (8, 0) / irregular (16) ip_reserved ::= value (1, 0) ip_dont_fragment ::= static / irregular (1) ip_more_fragments ::= value (1, 0) ip_offset ::= value (13, 0) ip_time_to_live ::= static / irregular (8) ip_protocol ::= value (8, 6) ip_checksum ::= skip (16) ip_source_address ::= static / irregular (32) ip_dest_address ::= static / irregular (32) tcp_source_port ::= static / irregular (16) tcp_dest_port ::= static / irregular (16) tcp_seq_ack ::= tcp_sack_a / tcp_sack_b / tcp_sack_c / tcp_sack_d / tcp_sack_e / tcp_sack_f / tcp_sack_g / tcp_sack_h / tcp_sack_i tcp_sack_a ::= static static tcp_sack_b ::= static lsb (10, 256) tcp_sack_c ::= lsb (10, 256) static tcp_sack_d ::= lsb (10, 256) lsb (10, 256) tcp_sack_e ::= static lsb (14, 4096) tcp_sack_f ::= lsb (14, 4096) static tcp_sack_g ::= static lsb (18, 65536) tcp_sack_h ::= lsb (18, 65536) static tcp_sack_i ::= irregular (32) irregular (32) tcp_data_offset ::= label (4, TCP_Header_Length) tcp_reserved ::= static / irregular (4) tcp_ecn ::= ecn_unused / ecn_used ecn_unused ::= next_field (ECN) value (2, 0) value (2, 0) ecn_used ::= next_field (ECN) irregular (2) irregular (2) tcp_urg ::= label (1, URG_Flag) tcp_ack ::= static / irregular (1) tcp_psh ::= irregular (1) tcp_rsf ::= value (3, 0) / value (3, 4) / value (3, 1) / irregular (3) tcp_window ::= static / lsb (12, 2048) / irregular (16) tcp_checksum ::= irregular (16) tcp_urg_pointer ::= next_field (URG_Flag) urgf_zero / urgf_one urgf_zero ::= value (1, 0) static urgf_one ::= irregular (1) irregular (16) tcp_options ::= value (options_length, context_value (Index)) / irregular (options_length) next_field (TCP_Header_Length) static / irregular (4) where options_length is (TCP_Header_Length * 32) - 160 > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Tuesday, March 11, 2003 10:16 PM > To: Price, Richard; 'rohc@ietf.org' > Subject: RE: [rohc] TCP compression profile > > > > > Can you send the TCP packet formats you used to the mailing list? > > > > No problem. Would you like them in notated or pictorial form (or > > both, for comparison)? > > > > If you'd like the packet formats in pictorial form, are the pictures > > themselves sufficient or should all of the ancillary information > > needed to get "bits on the wire" also be included (e.g. field > > dependencies, interpretation intervals for LSB encoding, context > > updating properties etc.)? > > I think the pictorial form would be ok also without the "rules" for how > to interpret the bits. Together with the notation form, it would be a > good example. > > Thanks! > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 12 10:48:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08788 for ; Wed, 12 Mar 2003 10:48:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CG2c222043 for rohc-archive@odin.ietf.org; Wed, 12 Mar 2003 11:02:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG2cO22040 for ; Wed, 12 Mar 2003 11:02:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08776 for ; Wed, 12 Mar 2003 10:48:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG2PO22028; Wed, 12 Mar 2003 11:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFxWO21782 for ; Wed, 12 Mar 2003 10:59:32 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08643 for ; Wed, 12 Mar 2003 10:45:01 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 15:47:08 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F203@rsys002a.roke.co.uk> From: "Price, Richard" To: "'william zheng'" , rohc@ietf.org Subject: RE: [rohc] ROHC-FN Date: Wed, 12 Mar 2003 15:47:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Hi All, > We have seen the new release of ROHC-FN. May I know the > reason for the change that "updated_context" has removed? Hi William, The term "updated_context" has been removed because it implied (misleadingly) that the compressor must store exactly two copies of the context: the "old" context containing the fields from the previous header in the flow, and the "updated" context, which is created using fields from the header currently being compressed. In fact, for robustness, the compressor context will typically store a history of field values from several previous headers in the flow. When a new header is successfully compressed, its field values will be added to the ones already contained in the context (the number of values stored for each field depends on how much robustness you need). However, the above is only important if you're worried about robustness in the first place. For a non-robust implementation, it's fine to store just the "old" and the "updated" context at the compressor. > In the new release, the encoding method FIELD updates the > context with the new field value as it does compression but > there is no rollback action of updating the context when the > compression/decompression may fail. How to understand it? Rollback is handled as before - if compression or decompression fails for whatever reason, then the context is not updated to contain the field values from the current header. > In addition to the description on the compression procedures > of the pre-defined, basic and extended library of all the > encoding methods in the draft, should we need its > counterpart the decompression procedures to complete the > understanding of the encoding methods that is useful to those > who try to write the encoding algorithm of the profile such > as ROHC-TCP? For the basic encoding method library of Chapter 5, it might be useful to provide the decompression procedures as well as the compression procedures. Obviously it's possible to decompress headers just by "reversing" the compression process, but writing out how to do this explicitly would probably be helpful in making the encoding methods easier to implement. For the extended encoding method library of Chapter 6, there's no need to provide separate procedures for compression and decompression. This is because all of the encoding methods in Chapter 6 are defined using ROHC-FN itself, by applying one or more of the basic encoding methods from Chapter 5. For example: label (#n,$name) ::= field (n) map (name, Null, Field_Value) map (Field_Value, name, Null) This means that the "label" encoding method is defined by a single application of the "field" encoding method, plus two applications of the "map" encoding method. This definition works for both compression and decompression. If you want to use "label" to compress a field, you simply invoke the compression versions of the "field" and "map" encoding methods. If you want to use it for decompression, you invoke the decompression versions of the two encoding methods. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 12 12:57:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13742 for ; Wed, 12 Mar 2003 12:57:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIB5832740 for rohc-archive@odin.ietf.org; Wed, 12 Mar 2003 13:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIB5O32737 for ; Wed, 12 Mar 2003 13:11:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13718 for ; Wed, 12 Mar 2003 12:56:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIAqO32706; Wed, 12 Mar 2003 13:10:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CI7bO32451 for ; Wed, 12 Mar 2003 13:07:37 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13562 for ; Wed, 12 Mar 2003 12:53:03 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CHtBwv006220 for ; Wed, 12 Mar 2003 18:55:11 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 12 Mar 2003 18:55:11 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Wed, 12 Mar 2003 18:55:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] FW: [Sipping] SIGCOMP and large binary content SIP messages Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Forwarded from the SIPPING list.... -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: den 12 mars 2003 17:26 To: adam@dynamicsoft.com; Markus.Isomaki@nokia.com; mwatson@nortelnetworks.com; sipping@ietf.org Subject: RE: [Sipping] SIGCOMP and large binary content SIP messages Yes, that is also what I had in mind for SIP. But my point is that a SigComp receiver now needs to have some knowledge about application message format and do parsing to determine the end of an uncompressed message. This is something new (or at least unspecified) in RFC 3320 and needs to be spelled out in a new (standard track) RFC. The document will be short, but I think it's needed for interoperability. I'll write up an I-D and submit it after IETF 56. But I'd like to know if folks in SIPPING think it should be done here or in ROHC. Zhigang > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: March 11, 2003 9:03 PM > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > Subject: RE: [Sipping] SIGCOMP and large binary content SIP messages > > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > Having binary content in SIP messages may have two impacts on > > SigComp: > > > > a) multiplexing of uncompressed messages with SigComp > messages on the > > same port. > ... > > For a), it is only an issue for SigComp/TCP, not > SigComp/UDP (where one > > SigComp message maps to one UDP packet). Adam's point 1 and > 2 are related > > to this. As to point 1, I think the SigComp receiver still > needs to know > > (somehow) the end of an uncompressed message, or at least > the end of the > > binary part of each SIP messages. Otherwise, a bit pattern 11111 in > > the binary part will be mistaken by SigComp as the > beginning of a SigComp > > message. As to point 2, I would add that the delimiter > 0xFFFF can appear > > at the both the beginning and the end of a SigComp message. So, the > > receiver needs to have the same parsing logic just mentioned for bit > pattern > > 11111. > > This isn't any more of an issue than it is without SigComp. SIP > messages provide their own framing, and SigComp messages do the > same. They can be trivially mixed on the same stream: > > 1. Peek at the first byte waiting in the stream. > > 2. If it is 0xf8 or higher, the next message in the stream is > a SigComp message. The message continues until a 0xFFFF is > encountered in the stream. > > 3. Otherwise, the next message in the stream is a SIP message. > Read the stream until a CR/LF/CR/LF is encountered. Parse > the headers, and then read the number of bytes specified > in the "Content-Length" header. > > 4. Return to step 1. > > /a > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 13 09:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01801 for ; Thu, 13 Mar 2003 09:31:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DEjd532363 for rohc-archive@odin.ietf.org; Thu, 13 Mar 2003 09:45:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEjcO32360 for ; Thu, 13 Mar 2003 09:45:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01760 for ; Thu, 13 Mar 2003 09:30:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEjJO32321; Thu, 13 Mar 2003 09:45:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEiOO32253 for ; Thu, 13 Mar 2003 09:44:24 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01680 for ; Thu, 13 Mar 2003 09:29:23 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2DEVXB3005130 for ; Thu, 13 Mar 2003 15:31:33 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 13 Mar 2003 15:31:32 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Thu, 13 Mar 2003 15:31:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Formal notation, combined thread Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, After last weeks discussions, I found it useful to let all new insights come to rest before answering again. Below, I have tried to group the issues, although they are of course all closely related to each other. BR /L-E 1. Specification vs. implementation We have to separate specification from implementation. Even if implementation is in the back of our heads when we specify our protocols, the specification is not about how to implement it. What we define for header compression are data structures (compressed headers), as well as compression rules for what to put in compressed headers and how to interpret what is sent. Even if you would implement a ROHC profile using a "notation compiler", what we do is to define the notation language, and in the profile specification we will use it as a reference (we do not have to redefine these for each case). > RP: An "oracle" function is just a function which returns an > implementation-specific value. Whenever the compressed header > formats offer a choice for implementers, the notation calls > an oracle function to find out what choice the implementer > wants to make. The oracle functions is thus an implementation issue about choosing proper compressed formats, so we do not even have to mention these anywhere, right? We define the means to communicate and how to interpret what is communicated, but not what to say. > RP: From the notation's perspective the oracle function can be > called just like any other function (e.g. the CRC). When the > notation is compiled, an implementation of each of these basic > functions must of course be provided. I guess you mean "when a profile specified using the notation language is compiled...". The oracle functions is just an implementation issue, as it is part of "compress" (i.e. not specified). We must be careful and separate implementation from specification. > > LEJ: Note that the notation itself would not be something that > > would be implementable. > > RP: I don't understand the above statement. The notation is a > language, so it's possible to implement a compiler which converts > (say) a description of TCP/IP written in the notation into > executable code. Yes, you might do a compiler FOR specifications based on the notation. > > LEJ: Of course, the various mechanisms described by the notation > > could be implemented, but not the notation itself. The notation > > is not a machine, it is a language. > > RP: Yes, which is why it's possible to implement a compiler for > the notation. Yes, and such a compiler could of course be a useful tool when implementing profiles defined using that notation. But that is only about implementation. > > LEJ: The point is that, I believe the notation should be > > about.........notating, nothing else. > > RP: Absolutely. Would it be possible to point out any specific > statements which seem to contradict the above (particularly if > they're in the notation draft itself)? Yes, for example section 4.2 in the notation draft, which talks about "implementing the notation". 2. Field encoding vs. discriminator encoding > > > RP: It shouldn't matter whether the function compresses a > > > single field, a whole protocol header, or even the entire > > > packet. Also, it shouldn't matter whether the function outputs > > > compressed bits that are considered to lie in the > > > "discriminator" or in the "compressed body" part of the > > > header. > > > > LEJ: Here I would strongly disagree. I rather think we should > > have a few different terms for the different kind of "encoding > > methods", since I think that would heavily simplify > > understanding, and make it easier to separate the various > > pieces. > > RP: However, a single term is still needed for the concept of an > "encoding method" as a whole. Actually, I do not think we really need that. Encoding of fields is a rather different thing than "discriminator encoding" (or maybe "branch encoding"?), and we should make that clear in the notation. A good name for these would be really useful, as "self-describing values" as just another method does not say much about what it is or how different the method really is. > > LEJ: Methods to use for generating the actual compressed header > > formats, e.g. EPIC-lite, are rather different. > > RP: However, from the point of view of the notation language, is > there any reason to treat EPIC-lite differently from the other > encoding methods? Yes, because there is a significant difference between these. Normal encoding methods are chosen based on how fields behave, while it is a subjective profile specification decision to pick a "discriminator encoding method" for the profile. > RP: The notation language itself shouldn't make a distinction > between EPIC-lite and any other encoding method. As I have said above, I think it is important to make a clear distinction between these, as they are so different. That is also what we said last year, when we talked about field encoding vs. compressed header encoding. 3. Notating the content or the compressed formats > RP: In my view, a ROHC-FN description is a complete specification > of "bits on the wire" (assuming of course that all of the basic > encoding methods have been defined). This is not what we discussed last year when we started the notation discussion and talked about field encoding versus encoding the complete compressed headers. The notation was said to capture only the first. I had not heard anything else so I assumed this was still the case. That absolutely caused some confusion on my side. > RP: If the compressed header formats are created manually then the > ROHC-FN description captures the exact hand-crafted packet > formats - not just the content of the compressed headers, but the > hand-crafted "discriminator" bits as well. OK, but then we would not even need the notation as a tool, if the actual formats (in written form) would just mean the same. I think the notation should capture the field compression part and provide all details useful for arbitrary "discriminator encodings", as that would provide flexibility for profile specifications to use the same general notation independent of which discriminator method is then defined to be used for the profile. > RP: The notation describes more than just the compressed header > content - it describes the exact packet formats (i.e. bits on the > wire). Now I get this, from the definition of "/". However, I do think the "/" method should not be totally defined, only have defined parameters, then the notated fields would look the same independent of which discriminator method is used for the profile. A profile might choose to use the current definition of "/", define it as "EPIC-Lite", any other method, or define the actual formats by hand. The generic "/" should have probability values as parameters, as that is essential information independent of how the discriminators/formats are defined (not for the simple per-branch bit mask as the current "/" uses, but for any sophisticated method). > RP: The probabilities aren't part of the notation - they're just > the parameters which EPIC-lite needs in order to calculate the > bits on the wire. If the notation is describing hand-crafted > packet formats, then the probabilities aren't included (because > they're not needed to describe the packet formats). As explained above, I would like to make the notation a formal way of defining what information to put in compressed headers, but not include defining the actual headers (although a profile might choose to define "/" formally to be used as you suggest). The difference is basically that the "/" should just be an unspecified "branch" or "discriminator" method, which a profile specification defines the meaning of (might be current "/" definition, "EPIC-L", or something else). 4. Discriminators > > LEJ: I followed you up to "single discriminator", but there you > > lost me. Can you elaborate on this? > RP: This last point is just talking about a specific feature of > EPIC-lite, which is that it always generates a single > discriminator for the *entire* packet (as opposed to RFC 3095, > where there is usually a discriminator to indicate the overall > packet format, as well as separate discriminators on the front > of each individual compressed protocol header). Do you mean like the bit mask we have in Ext3, which is an additional discriminator for compressed header, on top of the "packet type"? 5. Notation "completeness" I think we agree that we can not know that the notation will be "complete" for all future needs, but it might have to be extended in the future to capture new things we might want to do. However, this is actually not a problem, but might even be a good thing, as after accepting this we do not have to worry about the future at all. You can of course do a compiler for the notation (if that is a preferred choice when implementing a profile), but that compiler might have to be modified if new methods are defined and used by future profile specifications. The point is that since a "notation compiler" is just an implementation tool (in the same way as the notation itself is a specification tool), having to modify it when implementing new profiles should not be a concern. 6. Human-readable vs machine-readable > RP: In the notation draft we have a specific section devoted to > "list encoding methods" which handle lists of items. However, > the notation language itself doesn't treat these encoding methods > differently from any others. This is actually one of my main concerns. Everything is forced to become "just another encoding method", and that does not make the whole thing clearer. Just because it is possible to do, you do not necessary have to do it that way. > RP: The big advantage of making the adjustments within ROHC-FN > is that the description of the compressed packet formats remain > machine-readable We are defining standards, which should be human-readable. There are probably disagreements in this regard, but personally I think human-readability is more important than machine-readability. 7. EPIC-Lite The EPIC and EPIC-Lite terms have been overloaded several times by now, and they actually do not say much about what they really do. If we want to use the "EPIC-Lite" method for "discriminator encoding" and potentially define it in the general notation document, we should come up with a name that tells us what it does. Any ideas? _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 13 10:53:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06396 for ; Thu, 13 Mar 2003 10:53:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DG8Uu07391 for rohc-archive@odin.ietf.org; Thu, 13 Mar 2003 11:08:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG8UO07388 for ; Thu, 13 Mar 2003 11:08:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06384 for ; Thu, 13 Mar 2003 10:53:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG8GO07366; Thu, 13 Mar 2003 11:08:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG7bO07199 for ; Thu, 13 Mar 2003 11:07:37 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06356; Thu, 13 Mar 2003 10:52:35 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DFsla11330; Thu, 13 Mar 2003 09:54:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 09:54:33 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 09:54:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Mar 2003 09:54:31 -0600 Message-ID: Thread-Topic: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcLpVL875wZKKes8SNWZDhb0yP7KAQAIsPiA To: Cc: , , , , X-OriginalArrivalTime: 13 Mar 2003 15:54:33.0304 (UTC) FILETIME=[D70C2580:01C2E978] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DG7cO07201 Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree. How to handling binary content is a generic issue for any application messages. What I have in mind is to give generic descriptions/requirements (mainly on the SigComp receiver parsing part), then touch on SIP (perhaps RTSP too) as a particular example. Unless someone objects, I'll submit it in ROHC. Zhigang > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: March 13, 2003 5:36 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > mwatson@nortelnetworks.com; sipping@ietf.org > Subject: Re: [Sipping] SIGCOMP and large binary content SIP messages > > > Zhigang, > > you can submit that draft to ROHC. SIPPING can review it afterwards. > IMO, the competence needed to generate this draft can be found more > easily in ROHC than in SIPPING. > > Besides, you could use SigComp to compress RTSP messages, for instance > And RTSP is not handle by SIPPING either. > > Gonzalo > > zhigang.c.liu@nokia.com wrote: > > > > Yes, that is also what I had in mind for SIP. But my point is that > > a SigComp receiver now needs to have some knowledge about > application > > message format and do parsing to determine the end of an > uncompressed > > message. This is something new (or at least unspecified) in RFC 3320 > > and needs to be spelled out in a new (standard track) RFC. > The document > > will be short, but I think it's needed for interoperability. > > > > I'll write up an I-D and submit it after IETF 56. But I'd > like to know > > if folks in SIPPING think it should be done here or in ROHC. > > > > Zhigang > > > > > -----Original Message----- > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: March 11, 2003 9:03 PM > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > Subject: RE: [Sipping] SIGCOMP and large binary content > SIP messages > > > > > > > > > > -----Original Message----- > > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > > > > > Having binary content in SIP messages may have two impacts on > > > > SigComp: > > > > > > > > a) multiplexing of uncompressed messages with SigComp > > > messages on the > > > > same port. > > > ... > > > > For a), it is only an issue for SigComp/TCP, not > > > SigComp/UDP (where one > > > > SigComp message maps to one UDP packet). Adam's point 1 and > > > 2 are related > > > > to this. As to point 1, I think the SigComp receiver still > > > needs to know > > > > (somehow) the end of an uncompressed message, or at least > > > the end of the > > > > binary part of each SIP messages. Otherwise, a bit > pattern 11111 in > > > > the binary part will be mistaken by SigComp as the > > > beginning of a SigComp > > > > message. As to point 2, I would add that the delimiter > > > 0xFFFF can appear > > > > at the both the beginning and the end of a SigComp > message. So, the > > > > receiver needs to have the same parsing logic just > mentioned for bit > > > pattern > > > > 11111. > > > > > > This isn't any more of an issue than it is without SigComp. SIP > > > messages provide their own framing, and SigComp messages do the > > > same. They can be trivially mixed on the same stream: > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > 2. If it is 0xf8 or higher, the next message in the stream is > > > a SigComp message. The message continues until a 0xFFFF is > > > encountered in the stream. > > > > > > 3. Otherwise, the next message in the stream is a SIP message. > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > the headers, and then read the number of bytes specified > > > in the "Content-Length" header. > > > > > > 4. Return to step 1. > > > > > > /a > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 14 06:12:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22219 for ; Fri, 14 Mar 2003 06:12:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EBRhv02206 for rohc-archive@odin.ietf.org; Fri, 14 Mar 2003 06:27:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EBRhO02203 for ; Fri, 14 Mar 2003 06:27:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22214 for ; Fri, 14 Mar 2003 06:12:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EBRQO02192; Fri, 14 Mar 2003 06:27:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EBQJO02134 for ; Fri, 14 Mar 2003 06:26:19 -0500 Received: from mail-jpn.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22179 for ; Fri, 14 Mar 2003 06:10:52 -0500 (EST) Received: from jpn-imc-01.fareast.corp.microsoft.com ([157.60.4.29]) by mail-jpn.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Mar 2003 20:13:02 +0900 Received: from 157.60.4.29 by jpn-imc-01.fareast.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Mar 2003 20:13:02 +0900 Received: from BJS-MSG-01.fareast.corp.microsoft.com ([157.60.72.120]) by jpn-imc-01.fareast.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Mar 2003 20:13:02 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rohc] TCP compression profile (described using ROHC-FN) Date: Fri, 14 Mar 2003 19:13:01 +0800 Message-ID: Thread-Topic: [rohc] TCP compression profile (described using ROHC-FN) thread-index: AcLooGb+hCThyaWdQFqU2S8rFcU1ygBdgcDA From: "Qian Zhang \(MSR\)" To: "Price, Richard" , "Lars-Erik Jonsson \(EAB\)" , X-OriginalArrivalTime: 14 Mar 2003 11:13:02.0400 (UTC) FILETIME=[ADB27C00:01C2EA1A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EBQJO02135 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Richard, We noticed that there are quite a lot changes for the notation. 1. The probability that original used had been deleted. 2. The global indicator had been replaced by individual field indicator. Based on this notation and the sample TCP/IP packet format given in the last email, we have several concerns. 1. This scheme is quite in-efficient. Since each field needs a bit to indicate whether it exists or not, the smallest packet size is 5 bytes (just to represent a header without sequence number or acknowledgement number change). Moreover, we need another byte for the packet type. 2. The presentation ability is quite weak. For example, it is hard to encode the TCP option part. Moreover, for ROHC-RTP case, how to encode list type of things? Any comments for that? Thanks, Qian & Hongbin -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Wednesday, March 12, 2003 10:00 PM To: 'Lars-Erik Jonsson (EAB)'; 'rohc@ietf.org' Subject: RE: [rohc] TCP compression profile (described using ROHC-FN) ... and for comparison, the TCP/IP packet formats described using ROHC-FN are as follows: tcp_ip_encoding ::= create_msn inferred_ip_checksum ip_header tcp_header other_fields ip_header ::= ip_version ip_header_length ip_tos ip_length ip_id ip_reserved ip_dont_fragment ip_more_fragments ip_offset ip_time_to_live ip_protocol ip_checksum ip_source_address ip_dest_address tcp_header ::= tcp_source_port tcp_dest_port tcp_seq_ack tcp_data_offset tcp_reserved tcp_ecn tcp_urg tcp_ack tcp_psh tcp_rsf tcp_window tcp_checksum tcp_urg_pointer tcp_options other_fields ::= next_field (MSN) lsb (3, 0) / irregular (16) ip_version ::= value (4, 4) ip_header_length ::= value (4, 5) ip_tos ::= static / irregular (6) label (2, ECN) ip_length ::= inferred_size (16, -48) ip_id ::= inferred_offset (16, MSN) lsb (4, 0) / lsb (8, 0) / irregular (16) ip_reserved ::= value (1, 0) ip_dont_fragment ::= static / irregular (1) ip_more_fragments ::= value (1, 0) ip_offset ::= value (13, 0) ip_time_to_live ::= static / irregular (8) ip_protocol ::= value (8, 6) ip_checksum ::= skip (16) ip_source_address ::= static / irregular (32) ip_dest_address ::= static / irregular (32) tcp_source_port ::= static / irregular (16) tcp_dest_port ::= static / irregular (16) tcp_seq_ack ::= tcp_sack_a / tcp_sack_b / tcp_sack_c / tcp_sack_d / tcp_sack_e / tcp_sack_f / tcp_sack_g / tcp_sack_h / tcp_sack_i tcp_sack_a ::= static static tcp_sack_b ::= static lsb (10, 256) tcp_sack_c ::= lsb (10, 256) static tcp_sack_d ::= lsb (10, 256) lsb (10, 256) tcp_sack_e ::= static lsb (14, 4096) tcp_sack_f ::= lsb (14, 4096) static tcp_sack_g ::= static lsb (18, 65536) tcp_sack_h ::= lsb (18, 65536) static tcp_sack_i ::= irregular (32) irregular (32) tcp_data_offset ::= label (4, TCP_Header_Length) tcp_reserved ::= static / irregular (4) tcp_ecn ::= ecn_unused / ecn_used ecn_unused ::= next_field (ECN) value (2, 0) value (2, 0) ecn_used ::= next_field (ECN) irregular (2) irregular (2) tcp_urg ::= label (1, URG_Flag) tcp_ack ::= static / irregular (1) tcp_psh ::= irregular (1) tcp_rsf ::= value (3, 0) / value (3, 4) / value (3, 1) / irregular (3) tcp_window ::= static / lsb (12, 2048) / irregular (16) tcp_checksum ::= irregular (16) tcp_urg_pointer ::= next_field (URG_Flag) urgf_zero / urgf_one urgf_zero ::= value (1, 0) static urgf_one ::= irregular (1) irregular (16) tcp_options ::= value (options_length, context_value (Index)) / irregular (options_length) next_field (TCP_Header_Length) static / irregular (4) where options_length is (TCP_Header_Length * 32) - 160 > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Tuesday, March 11, 2003 10:16 PM > To: Price, Richard; 'rohc@ietf.org' > Subject: RE: [rohc] TCP compression profile > > > > > Can you send the TCP packet formats you used to the mailing list? > > > > No problem. Would you like them in notated or pictorial form (or > > both, for comparison)? > > > > If you'd like the packet formats in pictorial form, are the pictures > > themselves sufficient or should all of the ancillary information > > needed to get "bits on the wire" also be included (e.g. field > > dependencies, interpretation intervals for LSB encoding, context > > updating properties etc.)? > > I think the pictorial form would be ok also without the "rules" for how > to interpret the bits. Together with the notation form, it would be a > good example. > > Thanks! > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sat Mar 15 23:44:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05312 for ; Sat, 15 Mar 2003 23:44:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G4xjk24613 for rohc-archive@odin.ietf.org; Sat, 15 Mar 2003 23:59:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G4xjO24610 for ; Sat, 15 Mar 2003 23:59:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05308 for ; Sat, 15 Mar 2003 23:43:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G4xLO24600; Sat, 15 Mar 2003 23:59:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G4uMO24561 for ; Sat, 15 Mar 2003 23:56:22 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05263 for ; Sat, 15 Mar 2003 23:40:05 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2G4gDwv004430; Sun, 16 Mar 2003 05:42:13 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sun, 16 Mar 2003 05:42:13 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Qian Zhang (MSR)" , "Price, Richard" , rohc@ietf.org Subject: RE: [rohc] TCP compression profile (described using ROHC-FN) Date: Sun, 16 Mar 2003 05:40:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Qian, The updated notation draft has indeed taken a step backwards in scope and optimization, but it has also taken a few steps forward in clarity. This is a process we have to go through, and the last weeks discussions is an important component in that process. My interpretation of the TCP example from Richard is thus that it is just a simple example to show how the notation can be applied. We will of course have to continue with both the notation work and the TCP profile specifics, as the TCP profile document does not even have any packet formats defined yet. The WG has not come that far yet. BR /L-E > -----Original Message----- > From: Qian Zhang (MSR) [mailto:qianz@microsoft.com] > Sent: den 14 mars 2003 12:13 > To: Price, Richard; Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] TCP compression profile (described using ROHC-FN) > > > Richard, > > We noticed that there are quite a lot changes for the notation. > 1. The probability that original used had been deleted. > 2. The global indicator had been replaced by individual field > indicator. > > Based on this notation and the sample TCP/IP packet format > given in the > last email, we have several concerns. > 1. This scheme is quite in-efficient. Since each field needs a bit to > indicate whether it exists or not, the smallest packet size is 5 bytes > (just to represent a header without sequence number or acknowledgement > number change). Moreover, we need another byte for the packet type. > > 2. The presentation ability is quite weak. For example, it is hard to > encode the TCP option part. Moreover, for ROHC-RTP case, how to encode > list type of things? > > Any comments for that? > > Thanks, > Qian & Hongbin > > > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, March 12, 2003 10:00 PM > To: 'Lars-Erik Jonsson (EAB)'; 'rohc@ietf.org' > Subject: RE: [rohc] TCP compression profile (described using ROHC-FN) > > ... and for comparison, the TCP/IP packet formats described using > ROHC-FN are as follows: > > tcp_ip_encoding ::= create_msn > inferred_ip_checksum > ip_header > tcp_header > other_fields > > ip_header ::= ip_version > ip_header_length > ip_tos > ip_length > ip_id > ip_reserved > ip_dont_fragment > ip_more_fragments > ip_offset > ip_time_to_live > ip_protocol > ip_checksum > ip_source_address > ip_dest_address > > tcp_header ::= tcp_source_port > tcp_dest_port > tcp_seq_ack > tcp_data_offset > tcp_reserved > tcp_ecn > tcp_urg > tcp_ack > tcp_psh > tcp_rsf > tcp_window > tcp_checksum > tcp_urg_pointer > tcp_options > > other_fields ::= next_field (MSN) > lsb (3, 0) / irregular (16) > > ip_version ::= value (4, 4) > > ip_header_length ::= value (4, 5) > > ip_tos ::= static / irregular (6) > label (2, ECN) > > ip_length ::= inferred_size (16, -48) > > ip_id ::= inferred_offset (16, MSN) > lsb (4, 0) / lsb (8, 0) / irregular (16) > > ip_reserved ::= value (1, 0) > > ip_dont_fragment ::= static / irregular (1) > > ip_more_fragments ::= value (1, 0) > > ip_offset ::= value (13, 0) > > ip_time_to_live ::= static / irregular (8) > > ip_protocol ::= value (8, 6) > > ip_checksum ::= skip (16) > > ip_source_address ::= static / irregular (32) > > ip_dest_address ::= static / irregular (32) > > tcp_source_port ::= static / irregular (16) > > tcp_dest_port ::= static / irregular (16) > > tcp_seq_ack ::= tcp_sack_a / tcp_sack_b / > tcp_sack_c / tcp_sack_d / > tcp_sack_e / tcp_sack_f / > tcp_sack_g / tcp_sack_h / > tcp_sack_i > > tcp_sack_a ::= static > static > > tcp_sack_b ::= static > lsb (10, 256) > > tcp_sack_c ::= lsb (10, 256) > static > > tcp_sack_d ::= lsb (10, 256) > lsb (10, 256) > > tcp_sack_e ::= static > lsb (14, 4096) > > tcp_sack_f ::= lsb (14, 4096) > static > > tcp_sack_g ::= static > lsb (18, 65536) > > tcp_sack_h ::= lsb (18, 65536) > static > > tcp_sack_i ::= irregular (32) > irregular (32) > > tcp_data_offset ::= label (4, TCP_Header_Length) > > tcp_reserved ::= static / irregular (4) > > tcp_ecn ::= ecn_unused / ecn_used > > ecn_unused ::= next_field (ECN) > value (2, 0) > value (2, 0) > > ecn_used ::= next_field (ECN) > irregular (2) > irregular (2) > > tcp_urg ::= label (1, URG_Flag) > > tcp_ack ::= static / irregular (1) > > tcp_psh ::= irregular (1) > > tcp_rsf ::= value (3, 0) / value (3, 4) / > value (3, 1) / > irregular (3) > > tcp_window ::= static / lsb (12, 2048) / irregular (16) > > tcp_checksum ::= irregular (16) > > tcp_urg_pointer ::= next_field (URG_Flag) > urgf_zero / urgf_one > > urgf_zero ::= value (1, 0) > static > > urgf_one ::= irregular (1) > irregular (16) > > tcp_options ::= value (options_length, context_value > (Index)) / > irregular (options_length) > next_field (TCP_Header_Length) > static / irregular (4) > > where options_length is (TCP_Header_Length * 32) - 160 > > > -----Original Message----- > > From: Lars-Erik Jonsson (EAB) > > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > > Sent: Tuesday, March 11, 2003 10:16 PM > > To: Price, Richard; 'rohc@ietf.org' > > Subject: RE: [rohc] TCP compression profile > > > > > > > > Can you send the TCP packet formats you used to the > mailing list? > > > > > > No problem. Would you like them in notated or pictorial form (or > > > both, for comparison)? > > > > > > If you'd like the packet formats in pictorial form, are > the pictures > > > themselves sufficient or should all of the ancillary information > > > needed to get "bits on the wire" also be included (e.g. field > > > dependencies, interpretation intervals for LSB encoding, context > > > updating properties etc.)? > > > > I think the pictorial form would be ok also without the "rules" for > how > > to interpret the bits. Together with the notation form, it > would be a > > good example. > > > > Thanks! > > /L-E > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Mar 16 13:01:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00891 for ; Sun, 16 Mar 2003 13:01:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GIH5P13841 for rohc-archive@odin.ietf.org; Sun, 16 Mar 2003 13:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GIH5O13838 for ; Sun, 16 Mar 2003 13:17:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00864 for ; Sun, 16 Mar 2003 13:00:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GIGXO13824; Sun, 16 Mar 2003 13:16:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GH4rO09344 for ; Sun, 16 Mar 2003 12:04:53 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29357 for ; Sun, 16 Mar 2003 11:48:22 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 16 Mar 2003 08:50:33 -0800 X-Originating-IP: [130.129.131.214] From: "Richard Price" To: , , References: Subject: Re: [rohc] TCP compression profile (described using ROHC-FN) Date: Sun, 16 Mar 2003 08:50:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 16 Mar 2003 16:50:33.0724 (UTC) FILETIME=[2940CBC0:01C2EBDC] Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The updated notation draft has indeed taken a step backwards in > scope and optimization, but it has also taken a few steps forward > in clarity. Hi, There seems to be some confusion between the notation draft itself, and the implementation that we just published! The updated notation draft contains no technical changes from the old draft, so its scope and optimization remain exactly the same. However, the implementation that we made available to the WG only includes a subset of the features documented in the notation draft - enough to demonstrate the notation in action, but not enough for an "optimally" efficient set of compressed TCP packet formats. > My interpretation of the TCP example from Richard is thus that it > is just a simple example to show how the notation can be applied. > We will of course have to continue with both the notation work > and the TCP profile specifics, as the TCP profile document does > not even have any packet formats defined yet. The WG has not > come that far yet. Exactly. The example TCP packet formats only use encoding methods supported by our published implementation, so there's plenty of room for improvement. > > 1. This scheme is quite in-efficient. Since each field needs a bit to > > indicate whether it exists or not, the smallest packet size is 5 bytes > > (just to represent a header without sequence number or acknowledgement > > number change). Moreover, we need another byte for the packet type. We can generate more efficient indicator bits by taking into account the probability that each field encoding will be used. This feature is available in the current notation draft (Section 6.4.3), but we haven't used it in the TCP packet formats just yet because it's not supported in the implementation. > > 2. The presentation ability is quite weak. For example, it is hard to > > encode the TCP option part. Moreover, for ROHC-RTP case, how to encode > > list type of things? Both of the above can be compressed using the "list" encoding method (Section 6.5.1 of the notation draft). We'll use this to compress the TCP options as soon as we've added it to the published implementation. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 17 16:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02942 for ; Mon, 17 Mar 2003 16:37:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HLrvs05510 for rohc-archive@odin.ietf.org; Mon, 17 Mar 2003 16:53:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLrvO05507 for ; Mon, 17 Mar 2003 16:53:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02888 for ; Mon, 17 Mar 2003 16:36:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLrWO05473; Mon, 17 Mar 2003 16:53:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLquO05380 for ; Mon, 17 Mar 2003 16:52:56 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02813 for ; Mon, 17 Mar 2003 16:35:49 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Mar 2003 13:38:00 -0800 X-Originating-IP: [130.129.134.198] From: "Richard Price" To: References: Subject: Re: [rohc] Formal notation, combined thread Date: Mon, 17 Mar 2003 13:37:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 17 Mar 2003 21:38:00.0973 (UTC) FILETIME=[7BD3E3D0:01C2ECCD] Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hi all, > > After last weeks discussions, I found it useful to let all new insights > come to rest before answering again. Below, I have tried to group the > issues, although they are of course all closely related to each other. > > BR > /L-E > > > 1. Specification vs. implementation > > We have to separate specification from implementation. Even if > implementation is in the back of our heads when we specify our > protocols, the specification is not about how to implement it. Yes! Ideally, the way we specify a profile should give implementers the freedom to use any implementation strategy they like, without being biased towards any one strategy in particular. > What we define for header compression are data structures > (compressed headers), as well as compression rules for what to put > in compressed headers and how to interpret what is sent. Even if > you would implement a ROHC profile using a "notation compiler", > what we do is to define the notation language, and in the profile > specification we will use it as a reference (we do not have to > redefine these for each case). > > > RP: An "oracle" function is just a function which returns an > > implementation-specific value. Whenever the compressed header > > formats offer a choice for implementers, the notation calls > > an oracle function to find out what choice the implementer > > wants to make. > > The oracle functions is thus an implementation issue about > choosing proper compressed formats, so we do not even have to > mention these anywhere, right? We define the means to communicate > and how to interpret what is communicated, but not what to say. All that needs to be specified is the point at which an implementation decision must be made. The exact choice of function to use in making the decision is of course up to the implementer. > > RP: From the notation's perspective the oracle function can be > > called just like any other function (e.g. the CRC). When the > > notation is compiled, an implementation of each of these basic > > functions must of course be provided. > > I guess you mean "when a profile specified using the notation > language is compiled...". The oracle functions is just an > implementation issue, as it is part of "compress" (i.e. not > specified). We must be careful and separate implementation from > specification. Yes. > > > LEJ: Note that the notation itself would not be something that > > > would be implementable. > > > > RP: I don't understand the above statement. The notation is a > > language, so it's possible to implement a compiler which converts > > (say) a description of TCP/IP written in the notation into > > executable code. > > Yes, you might do a compiler FOR specifications based on the notation. > > > > LEJ: Of course, the various mechanisms described by the notation > > > could be implemented, but not the notation itself. The notation > > > is not a machine, it is a language. > > > > RP: Yes, which is why it's possible to implement a compiler for > > the notation. > > Yes, and such a compiler could of course be a useful tool when > implementing profiles defined using that notation. But that is only > about implementation. > > > > LEJ: The point is that, I believe the notation should be > > > about.........notating, nothing else. > > > > RP: Absolutely. Would it be possible to point out any specific > > statements which seem to contradict the above (particularly if > > they're in the notation draft itself)? > > Yes, for example section 4.2 in the notation draft, which talks about > "implementing the notation". To clarify the above, we should instead say something like "implementing a profile specified using the notation". > 2. Field encoding vs. discriminator encoding > > > > > RP: It shouldn't matter whether the function compresses a > > > > single field, a whole protocol header, or even the entire > > > > packet. Also, it shouldn't matter whether the function outputs > > > > compressed bits that are considered to lie in the > > > > "discriminator" or in the "compressed body" part of the > > > > header. > > > > > > LEJ: Here I would strongly disagree. I rather think we should > > > have a few different terms for the different kind of "encoding > > > methods", since I think that would heavily simplify > > > understanding, and make it easier to separate the various > > > pieces. > > > > RP: However, a single term is still needed for the concept of an > > "encoding method" as a whole. > > Actually, I do not think we really need that. Encoding of fields is > a rather different thing than "discriminator encoding" (or maybe > "branch encoding"?), and we should make that clear in the notation. In general it's rather tough to partition the set of encoding methods into the above categories. Some encoding methods (e.g. LSB) are clearly field encodings, and others (e.g. EPIC) are clearly discriminator encodings. However, certain encoding methods (e.g. list encoding) output both compressed fields and discriminator bits, whilst others (e.g. label) don't output any compressed bits at all. > A good name for these would be really useful, as "self-describing > values" as just another method does not say much about what it is > or how different the method really is. > > > > LEJ: Methods to use for generating the actual compressed header > > > formats, e.g. EPIC-lite, are rather different. > > > > RP: However, from the point of view of the notation language, is > > there any reason to treat EPIC-lite differently from the other > > encoding methods? > > Yes, because there is a significant difference between these. > Normal encoding methods are chosen based on how fields behave, > while it is a subjective profile specification decision to pick > a "discriminator encoding method" for the profile. The statement that "normal encoding methods are chosen based on how fields behave" is just as applicable to the so-called discriminator encoding methods. For example, EPIC can calculate an optimally efficient set of discriminator bits using only knowledge about how the uncompressed header behaves. So if compression efficiency is the main goal then EPIC is the correct discriminator encoding to use. Of course, there may be a good reason *not* to use EPIC as the discriminator encoding (e.g. IPR, complexity), and the final decision is always up to the profile writers. But this is exactly the same as for the "normal" encoding methods! For example, if we decide that LSB encoding is too complicated for a certain profile then nothing prevents us from using IRREGULAR encoding instead. > > RP: The notation language itself shouldn't make a distinction > > between EPIC-lite and any other encoding method. > > As I have said above, I think it is important to make a clear > distinction between these, as they are so different. That is also > what we said last year, when we talked about field encoding vs. > compressed header encoding. As above, I can't see any reason to think of the discriminator encodings as "special", or to treat them differently in some way. The distinction between the various types of encoding method that we made last year was only intended to clarify how the notation handles all of the different compression techniques needed by ROHC profiles. From a technical perspective the notation has never given special treatment to the discriminator encodings, and I think that it would be confusing and unnecessarily restrictive to do so. > 3. Notating the content or the compressed formats > > > RP: In my view, a ROHC-FN description is a complete specification > > of "bits on the wire" (assuming of course that all of the basic > > encoding methods have been defined). > > This is not what we discussed last year when we started the > notation discussion and talked about field encoding versus > encoding the complete compressed headers. The notation was said > to capture only the first. I had not heard anything else so I > assumed this was still the case. That absolutely caused some > confusion on my side. I think that the confusion might arise because of the split between the notation and the encoding methods themselves. The notation captures the choice of encoding methods for compressing a particular header, and for each encoding method it also captures all of the parameters needed to specify the header behaviour. For example, with LSB encoding the notation must specify two parameters: the number of LSBs and their offset. However, on its own this information does *not* specify any "bits on the wire". We still need the definition of LSB encoding itself - there is plenty of room for manoeuvre, as we could choose e.g. to byte-swap the compressed bits, invert them, XOR them with an arbitrary constant and so on, all without affecting the efficiency of the encoding. Exactly the same situation occurs with the discriminator encodings. The notation captures all of the needed inputs (in this case the probabilities), but we only get "bits on the wire" once we've defined the discriminator encoding methods themselves. > > RP: If the compressed header formats are created manually then the > > ROHC-FN description captures the exact hand-crafted packet > > formats - not just the content of the compressed headers, but the > > hand-crafted "discriminator" bits as well. > > OK, but then we would not even need the notation as a tool, if > the actual formats (in written form) would just mean the same. The notation provides a really useful benefit even when describing hand-crafted compressed headers, which is the extra implementation option of writing a "notation compiler" to automatically convert a notated description of the packet formats into running code. Of course, not everyone will want to use this implementation approach - some folks may still want to implement a particular profile by hand. But the key advantage of the notation-based packet formats is that both implementation options are equally valid - in contrast, if we describe the packet formats by hand then we're forced to implement them by hand, which is unnecessarily restrictive. > I think the notation should capture the field compression part and > provide all details useful for arbitrary "discriminator encodings", > as that would provide flexibility for profile specifications to use > the same general notation independent of which discriminator method > is then defined to be used for the profile. We already have this flexibility, due to the way that the discriminator encodings are currently defined. What we notice is that a large class of discriminator encodings (EPIC, EPIC-lite, arithmetic encoding etc.) all require the same inputs - namely a set of probability values whenever we offer a choice of more than one encoding method. To accommodate this, we define a new encoding method called "pick" (denoted by the symbol "|") whose purpose is to assign the probability values to the different branches. The "pick" encoding method itself outputs no bits on the wire - all it does is provide the inputs for the profile writer's choice of discriminator encoding (EPIC, EPIC-lite etc.). > > RP: The notation describes more than just the compressed header > > content - it describes the exact packet formats (i.e. bits on the > > wire). > > Now I get this, from the definition of "/". However, I do think the > "/" method should not be totally defined, only have defined > parameters, then the notated fields would look the same independent > of which discriminator method is used for the profile. A profile > might choose to use the current definition of "/", define it as > "EPIC-Lite", any other method, or define the actual formats by hand. > The generic "/" should have probability values as parameters, as > that is essential information independent of how the > discriminators/formats are defined (not for the simple per-branch > bit mask as the current "/" uses, but for any sophisticated method). We already have an encoding method which does exactly this - namely the "pick" encoding method that I mentioned above. Note however that this is a completely different encoding method from the "self-describing values" encoding which offers a choice of two branches and then outputs a 1-bit indicator flag depending on which branch is chosen. The two encoding methods work very differently. "Self-describing values" encoding generates its own bits on the wire, whereas "pick" just defines the probability values of each branch, and leaves the choice of bits on the wire up to a different encoding method (e.g. EPIC). Also, "self-describing values" generates a local discriminator every time a branch is chosen, whilst "pick" allows a global discriminator to be used to indicate many different choices. Since the notation offers both of the above encoding methods, a profile writer has the flexibility to employ either depending on the situation. "Self-describing values" are less efficient, but simpler (plus they can help to reduce the memory requirements of a profile, by reducing the overall number of packet formats). It's even possible to use a combination of both approaches within the same profile (just as is done in RFC 3095). > > RP: The probabilities aren't part of the notation - they're just > > the parameters which EPIC-lite needs in order to calculate the > > bits on the wire. If the notation is describing hand-crafted > > packet formats, then the probabilities aren't included (because > > they're not needed to describe the packet formats). > > As explained above, I would like to make the notation a formal way > of defining what information to put in compressed headers, but not > include defining the actual headers (although a profile might choose > to define "/" formally to be used as you suggest). The difference is > basically that the "/" should just be an unspecified "branch" or > "discriminator" method, which a profile specification defines the > meaning of (might be current "/" definition, "EPIC-L", or something > else). The "unspecified discriminator" method is already available to the notation, but we don't make it mandatory - the simpler "self-describing values" encoding is also available, and it's up to the profile writers to choose which approach to adopt (or perhaps use a combination of both). A minor point - whilst it's certainly possible to define the various encoding methods differently for each profile, I'd rather avoid doing this as it will lead to no end of confusion! Thus, we should use different symbols to denote the two approaches to creating discriminator flags. The symbol "/" always denotes "self-describing values" encoding, where the discriminator flag is created locally. The symbol "|" always denotes the so-called "unspecified discriminator" encoding. The latter approach requires a further encoding method (e.g. EPIC) to be applied to the whole header in order to get the final bits on the wire - rather than changing the definition of "|" on a per-profile basis, we should just include our choice of discriminator encoding separately as part of the notation (e.g. by writing EPIC, EPIC-lite or whatever at the start of the notated packet formats). > 4. Discriminators > > > > LEJ: I followed you up to "single discriminator", but there you > > > lost me. Can you elaborate on this? > > > RP: This last point is just talking about a specific feature of > > EPIC-lite, which is that it always generates a single > > discriminator for the *entire* packet (as opposed to RFC 3095, > > where there is usually a discriminator to indicate the overall > > packet format, as well as separate discriminators on the front > > of each individual compressed protocol header). > > Do you mean like the bit mask we have in Ext3, which is an additional > discriminator for compressed header, on top of the "packet type"? Yes. RFC 3095 adopts a hybrid approach to packet format design - some choices of encoding methods are indicated using a "global" discriminator similar to the one generated by EPIC-lite, but other choices are indicated locally using a version of the "self- describing values" encoding. Both approaches have their advantages - the EPIC- lite approach is always more efficient, but the self- describing values approach is simpler and less memory-intensive. From the notation perspective we should therefore make sure that both approaches are supported, and leave it up to profile writers to select the correct approach for a given situation. > 5. Notation "completeness" > > I think we agree that we can not know that the notation will be > "complete" for all future needs, but it might have to be extended > in the future to capture new things we might want to do. However, > this is actually not a problem, but might even be a good thing, > as after accepting this we do not have to worry about the future > at all. You can of course do a compiler for the notation (if that > is a preferred choice when implementing a profile), but that > compiler might have to be modified if new methods are defined and > used by future profile specifications. The point is that since a > "notation compiler" is just an implementation tool (in the same > way as the notation itself is a specification tool), having to > modify it when implementing new profiles should not be a concern. Absolutely - ensuring that the notation is future- proof is much less important than, say, for SigComp, where we defined a proper virtual machine (as a mandatory part of a SigComp implementation). The notation is just a useful tool for profile writers, and if it needs to be modified or extended in the future then this is not a problem, since we lose nothing compared with the hand- written approach to profile design. > 6. Human-readable vs machine-readable > > > RP: In the notation draft we have a specific section devoted to > > "list encoding methods" which handle lists of items. However, > > the notation language itself doesn't treat these encoding methods > > differently from any others. > > This is actually one of my main concerns. Everything is forced to > become "just another encoding method", and that does not make the > whole thing clearer. Just because it is possible to do, you do not > necessary have to do it that way. I think that it makes the notation much clearer if we avoid trying to make any artificial distinctions between the different types of encoding method. When using the notation, if we want to compress a field using LSB encoding then we write "LSB" followed by the necessary parameters. If we want to compress a list of items then we write "list" followed by the parameters needed by list encoding. How are the two cases different? > > RP: The big advantage of making the adjustments within ROHC-FN > > is that the description of the compressed packet formats remain > > machine-readable > > We are defining standards, which should be human-readable. There > are probably disagreements in this regard, but personally I think > human-readability is more important than machine-readability. I agree that human-readability is at least as important as machine-readability. However, in my opinion a notated set of packet formats is actually rather more human-readable than a set of packet formats drawn out pictorially. What I dislike about the pictorial version of packet formats is that the pictures themselves don't include all of the necessary parameters for the various different encoding methods (e.g. for LSB encoding, the offset of the interpretation interval is missing). The remaining parameters must be documented separately, which is confusing. > 7. EPIC-Lite > > The EPIC and EPIC-Lite terms have been overloaded several times by > now, and they actually do not say much about what they really do. > If we want to use the "EPIC-Lite" method for "discriminator > encoding" and potentially define it in the general notation > document, we should come up with a name that tells us what it does. > > Any ideas? We originally used the term "EPIC-lite" to mean the entire notation-based solution, including the notation itself and the complete library of encoding methods. The algorithm for generating the discriminator bits is actually nothing more than ordinary Huffman encoding, so perhaps we could just call it that instead? Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 17 17:37:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05154 for ; Mon, 17 Mar 2003 17:37:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HMsSa10575 for rohc-archive@odin.ietf.org; Mon, 17 Mar 2003 17:54:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMsSO10572 for ; Mon, 17 Mar 2003 17:54:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05130 for ; Mon, 17 Mar 2003 17:37:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMsGO10560; Mon, 17 Mar 2003 17:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMr9O10518 for ; Mon, 17 Mar 2003 17:53:09 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05093 for ; Mon, 17 Mar 2003 17:36:03 -0500 (EST) Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h2HMc8Ns006962; Mon, 17 Mar 2003 23:38:09 +0100 (MET) Date: Mon, 17 Mar 2003 23:38:05 +0100 Subject: Re: [rohc] Formal notation, combined thread Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Carsten Bormann , To: "Richard Price" From: Carsten Bormann In-Reply-To: Message-Id: <1E7BD161-58C9-11D7-9767-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Both approaches have their advantages - the EPIC- > lite approach is always more efficient, but the self- > describing values approach is simpler and less > memory-intensive. From the notation perspective > we should therefore make sure that both approaches > are supported, and leave it up to profile writers to > select the correct approach for a given situation. I envision it like this: Given a set of rules like: a --> b | c. b --> d | e. c --> f | g. and so on, you would wrap this whole thing into something like: z --> epic(a). Now this would collect the information in the notation tree opened by the above rules and prefix the values generated by a to g with an EPIC discriminator. I.e., a discriminator value is a value still to be compressed, and you have to use a meta-encoding method (an encoding method that is supplied an encoding method as a parameter) to convert it into actual compressed values. It would be an error to have discriminator values left at the root encoding method. If you want to use a different discriminator encoding method, just say z --> huffman(a). or z --> arith(a). Does that work? Gruesse, Carsten PS.: The above "|" notation is missing the probabilities. So it will look different in the end. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 17 18:48:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08525 for ; Mon, 17 Mar 2003 18:48:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I05XI15811 for rohc-archive@odin.ietf.org; Mon, 17 Mar 2003 19:05:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I05WO15808 for ; Mon, 17 Mar 2003 19:05:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08506 for ; Mon, 17 Mar 2003 18:48:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I05KO15798; Mon, 17 Mar 2003 19:05:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I04rO15735 for ; Mon, 17 Mar 2003 19:04:53 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08478 for ; Mon, 17 Mar 2003 18:47:45 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2HNnwB3004847 for ; Tue, 18 Mar 2003 00:49:58 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 18 Mar 2003 00:49:58 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Tue, 18 Mar 2003 00:49:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Slightly modified agenda Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Robust Header Compression WG (rohc) Monday, March 17 at 19:30-22:00 ================================== CHAIRS: Carsten Bormann Lars-Erik Jonsson AGENDA: Chair admonishments and agenda bashing (Bormann/Jonsson) 10 - NOTE: It is assumed that people have read all drafts WG and document status update (Bormann/Jonsson) 20 - Published: RFC3095, RTP RFC3096, RTP requirements RFC3241, ROHC over PPP RFC3242, LLA RFC3243, 0-byte RTP requirements RFC3408, LLA R-mode RFC3409, ROHC RTP lower layer guidelines RFC3320, Signaling Compression (SigComp) - NEW RFC - RFC3321, SigComp - Extended Operations - NEW RFC - RFC3322, SigComp Req's & Assumptions - NEW RFC - RFC3485, SigComp SIP/SDP static dictionary - NEW SIPPING RFC - RFC3486, Compressing SIP with SigComp - NEW SIPPING RFC - - Approved/in RFC editor queue: None! - Submitted to IESG: draft-ietf-rohc-mib-rtp-06.txt draft-ietf-rohc-terminology-and-examples-02.txt - Current WG drafts: RTP/Framework: 3 (impl.guide/IP/test) TCP profile: 4 (req./behavior/profile/enhance) SCTP profile: 1 (req., work postponed) Notation: 1 - WG administration issues - WG items not covered by the meeting agenda + Modified RTP/UDP profiles for UDP-Lite compression + TCP profile + SCTP profile Signaling compression 30 * Documents: draft-roach-sigcomp-nack-01.txt - SigComp Feedback (Roach) (15) - SigComp interoperability report (West) (10) - The SigComp Binary multiplexing issue (Price) (5) ROHC RTP (Jonsson) 10 * Documents: draft-ietf-rohc-rtp-impl-guide-02.txt draft-ietf-rohc-rtp-rfc3095-interoperability-00.txt draft-ietf-rohc-ip-only-00.txt - Implementer's Guide (5) - Implementation status & feature test list (3) - A ROHC profile for IP only (2) Formal header compression notation (Bormann/Ozegovic/Price) 60 * Documents: draft-ietf-rohc-formal-notation-01.txt draft-ozegovic-mornar-dccp-epic-00.txt ================================ DRAFT SUMMARY: Approved for publication: None! Submitted to IESG: RFW/RTP: draft-ietf-rohc-mib-rtp-06.txt RFW/RTP: draft-ietf-rohc-terminology-and-examples-02.txt Current WG drafts: RTP: draft-ietf-rohc-rtp-impl-guide-03.txt RTP: draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt RTP: draft-ietf-rohc-ip-only-01.txt TCP: draft-ietf-rohc-tcp-requirements-05.txt (not on agenda) TCP: draft-ietf-rohc-tcp-field-behavior-02.txt (not on agenda) TCP: draft-ietf-rohc-tcp-03.txt (not on agenda) TCP: draft-ietf-rohc-tcp-enhancement-00.txt (not on agenda) SCP: draft-ietf-rohc-sctp-requirements-02.txt NOT: draft-ietf-rohc-formal-notation-01.txt Individual submissions: SIG: draft-price-rohc-sigcomp-user-guide-01.txt (not on agenda) SIG: draft-price-rohc-sigcomp-torture-tests-00.txt (not on agenda) SIG: draft-roach-sigcomp-nack-01.txt NOT: draft-ozegovic-mornar-dccp-epic-00.txt Legend: RFW: ROHC Framework RTP: ROHC RTP, including IP, UDP, ESP, etc SIG: ROHC Signaling Compression NOT: Compression notation TCP: ROHC TCP SCP: ROHC SCTP _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Mar 17 20:11:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11604 for ; Mon, 17 Mar 2003 20:11:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I1SQ022252 for rohc-archive@odin.ietf.org; Mon, 17 Mar 2003 20:28:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I1SQO22249 for ; Mon, 17 Mar 2003 20:28:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11600 for ; Mon, 17 Mar 2003 20:11:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I1SEO22238; Mon, 17 Mar 2003 20:28:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I1RZO22208 for ; Mon, 17 Mar 2003 20:27:35 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11557 for ; Mon, 17 Mar 2003 20:10:26 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Mar 2003 17:12:39 -0800 X-Originating-IP: [130.129.134.198] From: "Richard Price" To: "Carsten Bormann" , References: <1E7BD161-58C9-11D7-9767-00039390397C@tzi.org> Subject: Re: [rohc] Formal notation, combined thread Date: Mon, 17 Mar 2003 17:12:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 18 Mar 2003 01:12:39.0254 (UTC) FILETIME=[77E19F60:01C2ECEB] Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Both approaches have their advantages - the EPIC- > > lite approach is always more efficient, but the self- > > describing values approach is simpler and less > > memory-intensive. From the notation perspective > > we should therefore make sure that both approaches > > are supported, and leave it up to profile writers to > > select the correct approach for a given situation. > > I envision it like this: > > Given a set of rules like: > > a --> b | c. > b --> d | e. > c --> f | g. > and so on, > > you would wrap this whole thing into something like: > > z --> epic(a). > > Now this would collect the information in the notation tree opened by > the above rules and prefix the values generated by a to g with an EPIC > discriminator. I.e., a discriminator value is a value still to be > compressed, and you have to use a meta-encoding method (an encoding > method that is supplied an encoding method as a parameter) to convert > it into actual compressed values. It would be an error to have > discriminator values left at the root encoding method. > > If you want to use a different discriminator encoding method, just say > > z --> huffman(a). > or > z --> arith(a). > > Does that work? I certainly hope so! This is exactly how I'm hoping to invoke the discriminator encoding methods. I can't foresee any problems in doing this - it's similar to the mechanism that we already use to invoke list encoding, which seems to work ok. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 20 13:21:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28075 for ; Thu, 20 Mar 2003 13:21:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KIddV13471 for rohc-archive@odin.ietf.org; Thu, 20 Mar 2003 13:39:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KIdcO13468 for ; Thu, 20 Mar 2003 13:39:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28055 for ; Thu, 20 Mar 2003 13:21:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KIdLO13434; Thu, 20 Mar 2003 13:39:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KIc5O13335 for ; Thu, 20 Mar 2003 13:38:05 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27976 for ; Thu, 20 Mar 2003 13:19:36 -0500 (EST) Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h2KILnP0014266; Thu, 20 Mar 2003 19:21:50 +0100 (MET) Date: Thu, 20 Mar 2003 19:21:47 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Carsten Bormann To: rohc@ietf.org From: Carsten Bormann Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [rohc] IETF 56 slides now at http://www.dmn.tzi.org/ietf/rohc/rohc-56.pdf Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ROHCers, the slides from Monday's ROHC meeting at IETF 56 are now at http://www.dmn.tzi.org/ietf/rohc/rohc-56.pdf -- enjoy. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Mar 25 13:02:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23300 for ; Tue, 25 Mar 2003 13:02:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PIMvb31963 for rohc-archive@odin.ietf.org; Tue, 25 Mar 2003 13:22:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PIMvO31960 for ; Tue, 25 Mar 2003 13:22:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23290 for ; Tue, 25 Mar 2003 13:02:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PIJWO31794; Tue, 25 Mar 2003 13:19:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PIIGO31710 for ; Tue, 25 Mar 2003 13:18:16 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23157; Tue, 25 Mar 2003 12:57:20 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PHxea22170; Tue, 25 Mar 2003 11:59:40 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Mar 2003 11:59:34 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Mar 2003 11:59:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Tue, 25 Mar 2003 11:59:30 -0600 Message-ID: Thread-Topic: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcLpVL875wZKKes8SNWZDhb0yP7KAQAIsPiAAl9uKWA= To: , Cc: , X-OriginalArrivalTime: 25 Mar 2003 17:59:31.0185 (UTC) FILETIME=[4916FE10:01C2F2F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PIIHO31711 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Carsten and Lars-Erik, I've volunteered to submit a personal draft on this issue. From ROHC WG chairs' point of view, do you think this is the way to proceed? Of course, I understood during the IETF56 that Carsten had some doubts on whether this is indeed an issue. My email below explained the issue a bit. I don't know if it's clear. Either way, we can continue discuss this in ROHC mailing list http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg04115.html BR, Zhigang > -----Original Message----- > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: March 13, 2003 9:55 AM > To: Gonzalo.Camarillo@lmf.ericsson.se > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > I agree. How to handling binary content is a generic issue for any > application messages. What I have in mind is to give generic > descriptions/requirements (mainly on the SigComp receiver > parsing part), > then touch on SIP (perhaps RTSP too) as a particular example. > > Unless someone objects, I'll submit it in ROHC. > > Zhigang > > > > -----Original Message----- > > From: ext Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: March 13, 2003 5:36 AM > > To: Liu Zhigang.C (NRC/Dallas) > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > mwatson@nortelnetworks.com; sipping@ietf.org > > Subject: Re: [Sipping] SIGCOMP and large binary content SIP messages > > > > > > Zhigang, > > > > you can submit that draft to ROHC. SIPPING can review it afterwards. > > IMO, the competence needed to generate this draft can be found more > > easily in ROHC than in SIPPING. > > > > Besides, you could use SigComp to compress RTSP messages, > for instance > > And RTSP is not handle by SIPPING either. > > > > Gonzalo > > > > zhigang.c.liu@nokia.com wrote: > > > > > > Yes, that is also what I had in mind for SIP. But my point is that > > > a SigComp receiver now needs to have some knowledge about > > application > > > message format and do parsing to determine the end of an > > uncompressed > > > message. This is something new (or at least unspecified) > in RFC 3320 > > > and needs to be spelled out in a new (standard track) RFC. > > The document > > > will be short, but I think it's needed for interoperability. > > > > > > I'll write up an I-D and submit it after IETF 56. But I'd > > like to know > > > if folks in SIPPING think it should be done here or in ROHC. > > > > > > Zhigang > > > > > > > -----Original Message----- > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > > Sent: March 11, 2003 9:03 PM > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > > Subject: RE: [Sipping] SIGCOMP and large binary content > > SIP messages > > > > > > > > > > > > > -----Original Message----- > > > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > > > > > > > Having binary content in SIP messages may have two impacts on > > > > > SigComp: > > > > > > > > > > a) multiplexing of uncompressed messages with SigComp > > > > messages on the > > > > > same port. > > > > ... > > > > > For a), it is only an issue for SigComp/TCP, not > > > > SigComp/UDP (where one > > > > > SigComp message maps to one UDP packet). Adam's point 1 and > > > > 2 are related > > > > > to this. As to point 1, I think the SigComp receiver still > > > > needs to know > > > > > (somehow) the end of an uncompressed message, or at least > > > > the end of the > > > > > binary part of each SIP messages. Otherwise, a bit > > pattern 11111 in > > > > > the binary part will be mistaken by SigComp as the > > > > beginning of a SigComp > > > > > message. As to point 2, I would add that the delimiter > > > > 0xFFFF can appear > > > > > at the both the beginning and the end of a SigComp > > message. So, the > > > > > receiver needs to have the same parsing logic just > > mentioned for bit > > > > pattern > > > > > 11111. > > > > > > > > This isn't any more of an issue than it is without SigComp. SIP > > > > messages provide their own framing, and SigComp messages do the > > > > same. They can be trivially mixed on the same stream: > > > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > > > 2. If it is 0xf8 or higher, the next message in the stream is > > > > a SigComp message. The message continues until a 0xFFFF is > > > > encountered in the stream. > > > > > > > > 3. Otherwise, the next message in the stream is a SIP message. > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > > the headers, and then read the number of bytes specified > > > > in the "Content-Length" header. > > > > > > > > 4. Return to step 1. > > > > > > > > /a > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 26 08:37:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25478 for ; Wed, 26 Mar 2003 08:37:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QDw6w29728 for rohc-archive@odin.ietf.org; Wed, 26 Mar 2003 08:58:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDw5O29725 for ; Wed, 26 Mar 2003 08:58:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25447 for ; Wed, 26 Mar 2003 08:36:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDshO29568; Wed, 26 Mar 2003 08:54:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDpwO29456 for ; Wed, 26 Mar 2003 08:51:58 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25287 for ; Wed, 26 Mar 2003 08:30:38 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QDWwHR021176; Wed, 26 Mar 2003 14:32:59 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Mar 2003 14:32:44 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'zhigang.c.liu@nokia.com'" Cc: rohc@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Wed, 26 Mar 2003 14:32:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, Actually, the proposal from the SFO meeting was to create a new WG draft to define what we think should be defined for the case of "SigComp for SIP", as RFC 3486 does not seem to be sufficient. However, we need to get the minutes out before we can go on with that. I therefore think it would be useful to get discussions going on the list, both regarding the specific issue you have brought, and other things that should be specified for applying SigComp on SIP. If you want to, you can of course also submit an individual draft to provide more discussion material. Such material might later on be reused in a potential new WG draft. OK? /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 25 mars 2003 19:00 > To: cabo@tzi.org; Lars-Erik Jonsson (EAB) > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Hi Carsten and Lars-Erik, > > I've volunteered to submit a personal draft on this issue. From > ROHC WG chairs' point of view, do you think this is the way > to proceed? > > Of course, I understood during the IETF56 that Carsten had some > doubts on whether this is indeed an issue. My email below explained > the issue a bit. I don't know if it's clear. Either way, we > can continue > discuss this in ROHC mailing list > http://www1.ietf.org/mail-archive/working-groups/sipping/curre nt/msg04115.html > > BR, > Zhigang > > > -----Original Message----- > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: March 13, 2003 9:55 AM > > To: Gonzalo.Camarillo@lmf.ericsson.se > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > messages > > > > > > I agree. How to handling binary content is a generic issue for any > > application messages. What I have in mind is to give generic > > descriptions/requirements (mainly on the SigComp receiver > > parsing part), > > then touch on SIP (perhaps RTSP too) as a particular example. > > > > Unless someone objects, I'll submit it in ROHC. > > > > Zhigang > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 26 08:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26474 for ; Wed, 26 Mar 2003 08:59:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QEKeV31986 for rohc-archive@odin.ietf.org; Wed, 26 Mar 2003 09:20:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEKeO31983 for ; Wed, 26 Mar 2003 09:20:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26459 for ; Wed, 26 Mar 2003 08:59:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEH5O31796; Wed, 26 Mar 2003 09:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEGZO31736 for ; Wed, 26 Mar 2003 09:16:35 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26268; Wed, 26 Mar 2003 08:55:13 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 13:57:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F206@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , cabo@tzi.org, Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org, sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Wed, 26 Mar 2003 13:57:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I think that the issue with SigComp and large binary content SIP messages is part of a more general issue - namely that before using SigComp to compress a particular application we need to standardise the following: 1. Mechanism for SigComp discovery 2. Resources offered by SigComp 3. How to delimit messages 4. When to save state Currently the SIPPING WG has provided RFCs for 1 and 2, but not for 3 and 4. It would be useful to get a draft out for these ASAP, as it would clarify several issues on how to get SigComp working with SIP (including the issue with large binary content SIP messages). > Unless someone objects, I'll submit it in ROHC. I think that any WG draft should be a product of the SIPPING WG, because the proposed solution for delimiting SigComp messages will need to take into account the behaviour of SIP itself (or we won't be able to multiplex SigComp and SIP messages on the same port). However, it would be good to get the ROHC WG involved in generating the draft as well! Regards, Richard P.S. For anyone who's interested, the mechanisms that particular applications need to provide before they can use SigComp are as follows... ------------------------------------------------------ 1. Mechanism for SigComp discovery - How does the application know when to use SigComp? For SIP this issue is already sorted (RFC 3486). ------------------------------------------------------ 2. Resources offered by SigComp - Does the application need to offer more than the minimum amount of resources? - Does the application need any extra state (e.g. a static dictionary)? For SIP we've already got a static dictionary (RFC 3485). However, we haven't currently discussed how much memory should be provided in a SigComp implementation for SIP. If we don't specify a value then SigComp defaults to the minimum possible (2K), which is rather tight for some of the more generously sized SIP messages! ------------------------------------------------------ 3. How to delimit messages - How does the application distinguish between SigComp messages and uncompressed messages? - Is the application allowed to use "continuous mode"? This is the issue that's been raised for large binary content SIP messages. If we want to send a mix of uncompressed and SigComp messages within the same TCP connection, how do we delimit the end of one message and the start of another? A related issue is how to handle very large SIP messages (> 64K). SigComp is able to compress large SIP messages by using "continuous mode", where the message boundaries are ignored completely and the application data is just transmitted as a stream. However, this mode of operation raises some additional security issues, so it's up to the SIPPING WG to decide whether or not to use it in SigComp for SIP. ------------------------------------------------------ 4. When to save state - How much security is needed in order to save state? - Which messages belong to each state "compartment"? - How long should the application keep state? This is quite an important issue that doesn't seem to have been discussed in the SIPPING WG. It's up to the application whether or not to let SigComp save state, and for interoperability it's important to have at least a general idea of how long to keep saved state, when to reject state due to insufficient security etc. ------------------------------------------------------ > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Tuesday, March 25, 2003 6:00 PM > To: cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Hi Carsten and Lars-Erik, > > I've volunteered to submit a personal draft on this issue. From > ROHC WG chairs' point of view, do you think this is the way > to proceed? > > Of course, I understood during the IETF56 that Carsten had some > doubts on whether this is indeed an issue. My email below explained > the issue a bit. I don't know if it's clear. Either way, we > can continue discuss this in ROHC mailing list > http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg04115.html > > BR, > Zhigang > > > -----Original Message----- > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: March 13, 2003 9:55 AM > > To: Gonzalo.Camarillo@lmf.ericsson.se > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > messages > > > > > > I agree. How to handling binary content is a generic issue for any > > application messages. What I have in mind is to give generic > > descriptions/requirements (mainly on the SigComp receiver parsing part), > > then touch on SIP (perhaps RTSP too) as a particular example. > > > > Unless someone objects, I'll submit it in ROHC. > > > > Zhigang > > > > > > > -----Original Message----- > > > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: March 13, 2003 5:36 AM > > > To: Liu Zhigang.C (NRC/Dallas) > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > mwatson@nortelnetworks.com; sipping@ietf.org > > > Subject: Re: [Sipping] SIGCOMP and large binary content SIP messages > > > > > > > > > Zhigang, > > > > > > you can submit that draft to ROHC. SIPPING can review it afterwards. > > > IMO, the competence needed to generate this draft can be found more > > > easily in ROHC than in SIPPING. > > > > > > Besides, you could use SigComp to compress RTSP messages, for instance > > > And RTSP is not handle by SIPPING either. > > > > > > Gonzalo > > > > > > zhigang.c.liu@nokia.com wrote: > > > > > > > > Yes, that is also what I had in mind for SIP. But my point is that > > > > a SigComp receiver now needs to have some knowledge about application > > > > message format and do parsing to determine the end of an uncompressed > > > > message. This is something new (or at least unspecified) in RFC 3320 > > > > and needs to be spelled out in a new (standard track) RFC. The document > > > > will be short, but I think it's needed for interoperability. > > > > > > > > I'll write up an I-D and submit it after IETF 56. But I'd like to know > > > > if folks in SIPPING think it should be done here or in ROHC. > > > > > > > > Zhigang > > > > > > > > > -----Original Message----- > > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > > > Sent: March 11, 2003 9:03 PM > > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > > > Subject: RE: [Sipping] SIGCOMP and large binary content SIP messages > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > > > > > > > > > Having binary content in SIP messages may have two impacts on > > > > > > SigComp: > > > > > > > > > > > > a) multiplexing of uncompressed messages with SigComp messages on the > > > > > > same port. > > > > > ... > > > > > > For a), it is only an issue for SigComp/TCP, not SigComp/UDP (where one > > > > > > SigComp message maps to one UDP packet). Adam's point 1 and 2 are related > > > > > > to this. As to point 1, I think the SigComp receiver still needs to know > > > > > > (somehow) the end of an uncompressed message, or at least the end of the > > > > > > binary part of each SIP messages. Otherwise, a bit pattern 11111 in > > > > > > the binary part will be mistaken by SigComp as the beginning of a SigComp > > > > > > message. As to point 2, I would add that the delimiter 0xFFFF can appear > > > > > > at the both the beginning and the end of a SigComp message. So, the > > > > > > receiver needs to have the same parsing logic just mentioned for bit pattern > > > > > > 11111. > > > > > > > > > > This isn't any more of an issue than it is without SigComp. SIP > > > > > messages provide their own framing, and SigComp messages do the > > > > > same. They can be trivially mixed on the same stream: > > > > > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > > > > > 2. If it is 0xf8 or higher, the next message in the stream is > > > > > a SigComp message. The message continues until a 0xFFFF is > > > > > encountered in the stream. > > > > > > > > > > 3. Otherwise, the next message in the stream is a SIP message. > > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > > > the headers, and then read the number of bytes specified > > > > > in the "Content-Length" header. > > > > > > > > > > 4. Return to step 1. > > > > > > > > > > /a > > > > > > > > > _______________________________________________ > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 26 19:13:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24037 for ; Wed, 26 Mar 2003 19:13:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R0YSm16824 for rohc-archive@odin.ietf.org; Wed, 26 Mar 2003 19:34:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0YSO16821 for ; Wed, 26 Mar 2003 19:34:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24030 for ; Wed, 26 Mar 2003 19:12:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0YEO16810; Wed, 26 Mar 2003 19:34:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0XOO16784 for ; Wed, 26 Mar 2003 19:33:24 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24003 for ; Wed, 26 Mar 2003 19:11:52 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2R0ECs23222 for ; Wed, 26 Mar 2003 18:14:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Mar 2003 18:14:11 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 18:13:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Wed, 26 Mar 2003 18:13:06 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcLznD1YGDnBW2/LSkmioY6naEW6awATsSBw To: Cc: X-OriginalArrivalTime: 27 Mar 2003 00:13:07.0477 (UTC) FILETIME=[A4A77450:01C2F3F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2R0XOO16785 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, > Actually, the proposal from the SFO meeting was to create a new > WG draft to define what we think should be defined for the case > of "SigComp for SIP", as RFC 3486 does not seem to be sufficient. Yes, this is the document Carsten proposed to "bind" SigComp and SIP. If I understand correctly, it will address SIP specific issues: larger DMS, SigComp compartment mapping, etc. I volunteered to be the editor of this document. This is clear to me and not my question here. My question is the handling of binary content in application messages. In my view, this is a generic issue although it started with SIP. My thought was to have a *separate* document that addresses this issue (and perhaps other generic SigComp "bugs" if we find out). So, my question is: 1) Does it make sense to have two separate documents, as I explained above? 2) If the answer is yes, how do we proceed for the second one (i.e. on binary content)? I discussed the issue on SIPPING list and volunteered to write a draft. I guess from your reply that it's OK for me to submit a personal draft to ROHC WG. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Mar 26 20:00:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25811 for ; Wed, 26 Mar 2003 20:00:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R1LNq20305 for rohc-archive@odin.ietf.org; Wed, 26 Mar 2003 20:21:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R1LNO20302 for ; Wed, 26 Mar 2003 20:21:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25786 for ; Wed, 26 Mar 2003 19:59:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R1L8O20284; Wed, 26 Mar 2003 20:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R1KwO20267 for ; Wed, 26 Mar 2003 20:20:58 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25777; Wed, 26 Mar 2003 19:59:20 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2R11ja14554; Wed, 26 Mar 2003 19:01:45 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Mar 2003 19:01:39 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 19:01:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Wed, 26 Mar 2003 19:00:32 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcLzn6pqXoqC6rorQdiuEEYa5enOlAAVyZkg To: , , Cc: , X-OriginalArrivalTime: 27 Mar 2003 01:01:06.0486 (UTC) FILETIME=[58AD5D60:01C2F3FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2R1KwO20268 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Richard, I agree on most of your comments. What I want to clarify and ask for input is the way to organize documents. Based on comments from Gonzalo and my own view, we should have *two* documents: Document-1. Not specific to SIP. Deal with how to apply SigComp to application protocol whose messages may contain binary (i.e. non UTF-8 encoded) data. It should contain at least two parts: a) multiplexing between uncompressed and SigComp messages on the same TCP port, and b) performance implication. Part a) should be normative and b) should be just recommendations. Document-2. SIP Specific. Deal with issues on how to apply SigComp to SIP, e.g. default DMS, compartment mapping/management, how to deal with binary data in SIP messages, etc. If we agree on the two documents approach, I think Document-1 should be ROHC WG document as it is not SIP specific. As to document-2, I tend to agree with you that it should be done in SIPPING WG. But I really don't have strong feeling, as long as it is done. During the ROHC meeting in IETF-56, I've volunteered to be the editor of document-2. I see you've made many good points here. So, here is my proposal. I'll write a skeleton draft with TOC, fill in some sections that looks obvious to me (e.g. DMS, binary content, and perhaps compartment mapping) and then send to you so you can change and fill with other issues you pointed out below. I'll try to do that in the next 2~3 weeks. Hopefully, people will agree which WG to home the document by then. :-) BR, Zhigang > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: March 26, 2003 7:58 AM > To: Liu Zhigang.C (NRC/Dallas); cabo@tzi.org; > Lars-Erik.Jonsson@epl.ericsson.se > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Hi, > > I think that the issue with SigComp and large binary > content SIP messages is part of a more general issue - > namely that before using SigComp to compress a particular > application we need to standardise the following: > > 1. Mechanism for SigComp discovery > 2. Resources offered by SigComp > 3. How to delimit messages > 4. When to save state > > Currently the SIPPING WG has provided RFCs for 1 and 2, > but not for 3 and 4. It would be useful to get a draft > out for these ASAP, as it would clarify several issues on > how to get SigComp working with SIP (including the issue > with large binary content SIP messages). > > > Unless someone objects, I'll submit it in ROHC. > > I think that any WG draft should be a product of the > SIPPING WG, because the proposed solution for delimiting > SigComp messages will need to take into account the > behaviour of SIP itself (or we won't be able to multiplex > SigComp and SIP messages on the same port). However, it > would be good to get the ROHC WG involved in generating > the draft as well! > > Regards, > > Richard > > P.S. For anyone who's interested, the mechanisms that > particular applications need to provide before they can > use SigComp are as follows... > > ------------------------------------------------------ > > 1. Mechanism for SigComp discovery > > - How does the application know when to use SigComp? > > For SIP this issue is already sorted (RFC 3486). > > ------------------------------------------------------ > > 2. Resources offered by SigComp > > - Does the application need to offer more than the > minimum amount of resources? > > - Does the application need any extra state (e.g. > a static dictionary)? > > For SIP we've already got a static dictionary (RFC 3485). > However, we haven't currently discussed how much memory > should be provided in a SigComp implementation for SIP. > If we don't specify a value then SigComp defaults to the > minimum possible (2K), which is rather tight for some of > the more generously sized SIP messages! > > ------------------------------------------------------ > > 3. How to delimit messages > > - How does the application distinguish between > SigComp messages and uncompressed messages? > > - Is the application allowed to use "continuous mode"? > > This is the issue that's been raised for large binary > content SIP messages. If we want to send a mix of > uncompressed and SigComp messages within the same TCP > connection, how do we delimit the end of one message and > the start of another? > > A related issue is how to handle very large SIP messages > (> 64K). SigComp is able to compress large SIP messages > by using "continuous mode", where the message boundaries > are ignored completely and the application data is just > transmitted as a stream. However, this mode of operation > raises some additional security issues, so it's up to the > SIPPING WG to decide whether or not to use it in SigComp > for SIP. > > ------------------------------------------------------ > > 4. When to save state > > - How much security is needed in order to save state? > > - Which messages belong to each state "compartment"? > > - How long should the application keep state? > > This is quite an important issue that doesn't seem to > have been discussed in the SIPPING WG. It's up to the > application whether or not to let SigComp save state, > and for interoperability it's important to have at > least a general idea of how long to keep saved state, > when to reject state due to insufficient security etc. > > ------------------------------------------------------ > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: Tuesday, March 25, 2003 6:00 PM > > To: cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se > > Cc: rohc@ietf.org; sipping@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary > content SIP > > messages > > > > > > Hi Carsten and Lars-Erik, > > > > I've volunteered to submit a personal draft on this issue. From > > ROHC WG chairs' point of view, do you think this is the way > > to proceed? > > > > Of course, I understood during the IETF56 that Carsten had some > > doubts on whether this is indeed an issue. My email below explained > > the issue a bit. I don't know if it's clear. Either way, we > > can continue discuss this in ROHC mailing list > > > http://www1.ietf.org/mail-archive/working-groups/sipping/curre > nt/msg04115.html > > > > BR, > > Zhigang > > > > > -----Original Message----- > > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: March 13, 2003 9:55 AM > > > To: Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > > messages > > > > > > > > > I agree. How to handling binary content is a generic issue for any > > > application messages. What I have in mind is to give generic > > > descriptions/requirements (mainly on the SigComp receiver > parsing part), > > > then touch on SIP (perhaps RTSP too) as a particular example. > > > > > > Unless someone objects, I'll submit it in ROHC. > > > > > > Zhigang > > > > > > > > > > -----Original Message----- > > > > From: ext Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: March 13, 2003 5:36 AM > > > > To: Liu Zhigang.C (NRC/Dallas) > > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > > mwatson@nortelnetworks.com; sipping@ietf.org > > > > Subject: Re: [Sipping] SIGCOMP and large binary content > SIP messages > > > > > > > > > > > > Zhigang, > > > > > > > > you can submit that draft to ROHC. SIPPING can review > it afterwards. > > > > IMO, the competence needed to generate this draft can > be found more > > > > easily in ROHC than in SIPPING. > > > > > > > > Besides, you could use SigComp to compress RTSP > messages, for instance > > > > And RTSP is not handle by SIPPING either. > > > > > > > > Gonzalo > > > > > > > > zhigang.c.liu@nokia.com wrote: > > > > > > > > > > Yes, that is also what I had in mind for SIP. But my > point is that > > > > > a SigComp receiver now needs to have some knowledge > about application > > > > > message format and do parsing to determine the end of > an uncompressed > > > > > message. This is something new (or at least > unspecified) in RFC 3320 > > > > > and needs to be spelled out in a new (standard track) > RFC. The document > > > > > will be short, but I think it's needed for interoperability. > > > > > > > > > > I'll write up an I-D and submit it after IETF 56. But > I'd like to know > > > > > if folks in SIPPING think it should be done here or in ROHC. > > > > > > > > > > Zhigang > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > > > > Sent: March 11, 2003 9:03 PM > > > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > > > > Subject: RE: [Sipping] SIGCOMP and large binary > content SIP messages > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: zhigang.c.liu@nokia.com > [mailto:zhigang.c.liu@nokia.com] > > > > > > > > > > > > > > Having binary content in SIP messages may have > two impacts on > > > > > > > SigComp: > > > > > > > > > > > > > > a) multiplexing of uncompressed messages with > SigComp messages on the > > > > > > > same port. > > > > > > ... > > > > > > > For a), it is only an issue for SigComp/TCP, not > SigComp/UDP (where one > > > > > > > SigComp message maps to one UDP packet). Adam's > point 1 and 2 are related > > > > > > > to this. As to point 1, I think the SigComp > receiver still needs to know > > > > > > > (somehow) the end of an uncompressed message, or > at least the end of the > > > > > > > binary part of each SIP messages. Otherwise, a > bit pattern 11111 in > > > > > > > the binary part will be mistaken by SigComp as > the beginning of a SigComp > > > > > > > message. As to point 2, I would add that the > delimiter 0xFFFF can appear > > > > > > > at the both the beginning and the end of a > SigComp message. So, the > > > > > > > receiver needs to have the same parsing logic > just mentioned for bit pattern > > > > > > > 11111. > > > > > > > > > > > > This isn't any more of an issue than it is without > SigComp. SIP > > > > > > messages provide their own framing, and SigComp > messages do the > > > > > > same. They can be trivially mixed on the same stream: > > > > > > > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > > > > > > > 2. If it is 0xf8 or higher, the next message in the > stream is > > > > > > a SigComp message. The message continues until a > 0xFFFF is > > > > > > encountered in the stream. > > > > > > > > > > > > 3. Otherwise, the next message in the stream is a > SIP message. > > > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > > > > the headers, and then read the number of bytes specified > > > > > > in the "Content-Length" header. > > > > > > > > > > > > 4. Return to step 1. > > > > > > > > > > > > /a > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 27 03:21:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19806 for ; Thu, 27 Mar 2003 03:21:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R8gg628932 for rohc-archive@odin.ietf.org; Thu, 27 Mar 2003 03:42:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R8ggO28929 for ; Thu, 27 Mar 2003 03:42:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19802 for ; Thu, 27 Mar 2003 03:20:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R8gGO28907; Thu, 27 Mar 2003 03:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R8foO28869 for ; Thu, 27 Mar 2003 03:41:51 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19770 for ; Thu, 27 Mar 2003 03:20:07 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2R8MTbj028362; Thu, 27 Mar 2003 09:22:29 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 27 Mar 2003 09:22:24 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'zhigang.c.liu@nokia.com'" Cc: rohc@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 27 Mar 2003 09:17:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, > My question is the handling of binary content in application > messages. In my view, this is a generic issue although it started > with SIP. My thought was to have a *separate* document that > addresses this issue (and perhaps other generic SigComp "bugs" if > we find out). First of all, it is not yet clear to me that this is a general issue, at least I have not been able to see consensus on that. Secondly, if we have general unclear issues with SigComp, those would go into the Implementer's guide at this point. Currently, I therefore think we can and should avoid having even more documents. However, you can always provide input by writing a draft, that is up to you. Regarding the SigComp&SIP document, it does not matter much in which WG it is "hosted", as long as it is written and well reviewed by people from both sides. Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 27 06:08:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23116 for ; Thu, 27 Mar 2003 06:08:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RBTGJ07604 for rohc-archive@odin.ietf.org; Thu, 27 Mar 2003 06:29:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RBTGO07601 for ; Thu, 27 Mar 2003 06:29:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23082 for ; Thu, 27 Mar 2003 06:07:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RBT0O07516; Thu, 27 Mar 2003 06:29:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RBNpO07365 for ; Thu, 27 Mar 2003 06:23:51 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22972; Thu, 27 Mar 2003 06:02:04 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 11:04:24 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F209@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , cabo@tzi.org, Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org, sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 27 Mar 2003 11:04:14 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I agree on most of your comments. What I want to clarify and ask > for input is the way to organize documents. Based on comments > from Gonzalo and my own view, we should have *two* documents: > > Document-1. Not specific to SIP. Deal with how to apply SigComp > to application protocol whose messages may contain binary (i.e. > non UTF-8 encoded) data. It should contain at least two parts: > a) multiplexing between uncompressed and SigComp messages on > the same TCP port, and b) performance implication. Part a) should > be normative and b) should be just recommendations. Hi, Regarding point a), I don't see how this can be done without talking about specific protocols. Adam already made a proposal for how to do the multiplexing in the case of SIP, which is as follows: 1. Peek at the first byte waiting in the stream. 2. If it is 0xf8 or higher, the next message in the stream is a SigComp message. The message continues until a 0xFFFF is encountered in the stream. 3. Otherwise, the next message in the stream is a SIP message. Read the stream until a CR/LF/CR/LF is encountered. Parse the headers, and then read the number of bytes specified in the "Content-Length" header. 4. Return to step 1. However, the above mechanism works only for SIP - different multiplexing mechanisms would be needed when using SigComp to compress different protocols. Regarding point b), it might be good to have some recommendations on how to implement an efficient compressor for messages with binary content. A suitable home for these would be the SigComp User Guide, which already talks about the various different compressors that can be used in conjunction with SigComp. > Document-2. SIP Specific. Deal with issues on how to apply SigComp > to SIP, e.g. default DMS, compartment mapping/management, how to > deal with binary data in SIP messages, etc. > > If we agree on the two documents approach, I think Document-1 should > be ROHC WG document as it is not SIP specific. As to document-2, I > tend to agree with you that it should be done in SIPPING WG. But > I really don't have strong feeling, as long as it is done. > > During the ROHC meeting in IETF-56, I've volunteered to be the editor > of document-2. I see you've made many good points here. So, here is > my proposal. I'll write a skeleton draft with TOC, fill in some sections > that looks obvious to me (e.g. DMS, binary content, and perhaps > compartment mapping) and then send to you so you can change and fill with > other issues you pointed out below. I'll try to do that in the next 2~3 weeks. > Hopefully, people will agree which WG to home the document by then. :-) Sounds ok to me. Of course, we'll need more mailing-list discussion on some of the open issues - how much memory should be provided by each SigComp endpoint and so on. Regards, Richard > BR, > Zhigang > > > -----Original Message----- > > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: March 26, 2003 7:58 AM > > To: Liu Zhigang.C (NRC/Dallas); cabo@tzi.org; > > Lars-Erik.Jonsson@epl.ericsson.se > > Cc: rohc@ietf.org; sipping@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > messages > > > > > > Hi, > > > > I think that the issue with SigComp and large binary > > content SIP messages is part of a more general issue - > > namely that before using SigComp to compress a particular > > application we need to standardise the following: > > > > 1. Mechanism for SigComp discovery > > 2. Resources offered by SigComp > > 3. How to delimit messages > > 4. When to save state > > > > Currently the SIPPING WG has provided RFCs for 1 and 2, > > but not for 3 and 4. It would be useful to get a draft > > out for these ASAP, as it would clarify several issues on > > how to get SigComp working with SIP (including the issue > > with large binary content SIP messages). > > > > > Unless someone objects, I'll submit it in ROHC. > > > > I think that any WG draft should be a product of the > > SIPPING WG, because the proposed solution for delimiting > > SigComp messages will need to take into account the > > behaviour of SIP itself (or we won't be able to multiplex > > SigComp and SIP messages on the same port). However, it > > would be good to get the ROHC WG involved in generating > > the draft as well! > > > > Regards, > > > > Richard > > > > P.S. For anyone who's interested, the mechanisms that > > particular applications need to provide before they can > > use SigComp are as follows... > > > > ------------------------------------------------------ > > > > 1. Mechanism for SigComp discovery > > > > - How does the application know when to use SigComp? > > > > For SIP this issue is already sorted (RFC 3486). > > > > ------------------------------------------------------ > > > > 2. Resources offered by SigComp > > > > - Does the application need to offer more than the > > minimum amount of resources? > > > > - Does the application need any extra state (e.g. > > a static dictionary)? > > > > For SIP we've already got a static dictionary (RFC 3485). > > However, we haven't currently discussed how much memory > > should be provided in a SigComp implementation for SIP. > > If we don't specify a value then SigComp defaults to the > > minimum possible (2K), which is rather tight for some of > > the more generously sized SIP messages! > > > > ------------------------------------------------------ > > > > 3. How to delimit messages > > > > - How does the application distinguish between > > SigComp messages and uncompressed messages? > > > > - Is the application allowed to use "continuous mode"? > > > > This is the issue that's been raised for large binary > > content SIP messages. If we want to send a mix of > > uncompressed and SigComp messages within the same TCP > > connection, how do we delimit the end of one message and > > the start of another? > > > > A related issue is how to handle very large SIP messages > > (> 64K). SigComp is able to compress large SIP messages > > by using "continuous mode", where the message boundaries > > are ignored completely and the application data is just > > transmitted as a stream. However, this mode of operation > > raises some additional security issues, so it's up to the > > SIPPING WG to decide whether or not to use it in SigComp > > for SIP. > > > > ------------------------------------------------------ > > > > 4. When to save state > > > > - How much security is needed in order to save state? > > > > - Which messages belong to each state "compartment"? > > > > - How long should the application keep state? > > > > This is quite an important issue that doesn't seem to > > have been discussed in the SIPPING WG. It's up to the > > application whether or not to let SigComp save state, > > and for interoperability it's important to have at > > least a general idea of how long to keep saved state, > > when to reject state due to insufficient security etc. > > > > ------------------------------------------------------ > > > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: Tuesday, March 25, 2003 6:00 PM > > > To: cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se > > > Cc: rohc@ietf.org; sipping@ietf.org > > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > > messages > > > > > > > > > Hi Carsten and Lars-Erik, > > > > > > I've volunteered to submit a personal draft on this issue. From > > > ROHC WG chairs' point of view, do you think this is the way > > > to proceed? > > > > > > Of course, I understood during the IETF56 that Carsten had some > > > doubts on whether this is indeed an issue. My email below explained > > > the issue a bit. I don't know if it's clear. Either way, we > > > can continue discuss this in ROHC mailing list > > > > > http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg04115.html > > > > > > BR, > > > Zhigang > > > > > > > -----Original Message----- > > > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > Sent: March 13, 2003 9:55 AM > > > > To: Gonzalo.Camarillo@lmf.ericsson.se > > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > > > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > > > messages > > > > > > > > > > > > I agree. How to handling binary content is a generic issue for any > > > > application messages. What I have in mind is to give generic > > > > descriptions/requirements (mainly on the SigComp receiver parsing part), > > > > then touch on SIP (perhaps RTSP too) as a particular example. > > > > > > > > Unless someone objects, I'll submit it in ROHC. > > > > > > > > Zhigang > > > > > > > > > > > > > -----Original Message----- > > > > > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: March 13, 2003 5:36 AM > > > > > To: Liu Zhigang.C (NRC/Dallas) > > > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > > > mwatson@nortelnetworks.com; sipping@ietf.org > > > > > Subject: Re: [Sipping] SIGCOMP and large binary content SIP messages > > > > > > > > > > > > > > > Zhigang, > > > > > > > > > > you can submit that draft to ROHC. SIPPING can review it afterwards. > > > > > IMO, the competence needed to generate this draft can be found more > > > > > easily in ROHC than in SIPPING. > > > > > > > > > > Besides, you could use SigComp to compress RTSP messages, for instance > > > > > And RTSP is not handle by SIPPING either. > > > > > > > > > > Gonzalo > > > > > > > > > > zhigang.c.liu@nokia.com wrote: > > > > > > > > > > > > Yes, that is also what I had in mind for SIP. But my point is that > > > > > > a SigComp receiver now needs to have some knowledge about application > > > > > > message format and do parsing to determine the end of an uncompressed > > > > > > message. This is something new (or at least unspecified) in RFC 3320 > > > > > > and needs to be spelled out in a new (standard track) RFC. The document > > > > > > will be short, but I think it's needed for interoperability. > > > > > > > > > > > > I'll write up an I-D and submit it after IETF 56. But I'd like to know > > > > > > if folks in SIPPING think it should be done here or in ROHC. > > > > > > > > > > > > Zhigang > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > > > > > Sent: March 11, 2003 9:03 PM > > > > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > > > > > Subject: RE: [Sipping] SIGCOMP and large binary content SIP messages > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > > > > > > > > > > > > > Having binary content in SIP messages may have two impacts on > > > > > > > > SigComp: > > > > > > > > > > > > > > > > a) multiplexing of uncompressed messages with SigComp messages on the > > > > > > > > same port. > > > > > > > ... > > > > > > > > For a), it is only an issue for SigComp/TCP, not SigComp/UDP (where one > > > > > > > > SigComp message maps to one UDP packet). Adam's point 1 and 2 are related > > > > > > > > to this. As to point 1, I think the SigComp receiver still needs to know > > > > > > > > (somehow) the end of an uncompressed message, or at least the end of the > > > > > > > > binary part of each SIP messages. Otherwise, a bit pattern 11111 in > > > > > > > > the binary part will be mistaken by SigComp as the beginning of a SigComp > > > > > > > > message. As to point 2, I would add that the delimiter 0xFFFF can appear > > > > > > > > at the both the beginning and the end of a SigComp message. So, the > > > > > > > > receiver needs to have the same parsing logic just mentioned for bit pattern > > > > > > > > 11111. > > > > > > > > > > > > > > This isn't any more of an issue than it is without SigComp. SIP > > > > > > > messages provide their own framing, and SigComp messages do the > > > > > > > same. They can be trivially mixed on the same stream: > > > > > > > > > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > > > > > > > > > 2. If it is 0xf8 or higher, the next message in the stream is > > > > > > > a SigComp message. The message continues until a 0xFFFF is > > > > > > > encountered in the stream. > > > > > > > > > > > > > > 3. Otherwise, the next message in the stream is a SIP message. > > > > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > > > > > the headers, and then read the number of bytes specified > > > > > > > in the "Content-Length" header. > > > > > > > > > > > > > > 4. Return to step 1. > > > > > > > > > > > > > > /a > > > > > > > > > > > > > _______________________________________________ > > > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Mar 27 20:51:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00873 for ; Thu, 27 Mar 2003 20:51:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S2CXo12071 for rohc-archive@odin.ietf.org; Thu, 27 Mar 2003 21:12:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2CXO12068 for ; Thu, 27 Mar 2003 21:12:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00804 for ; Thu, 27 Mar 2003 20:50:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2CJO12052; Thu, 27 Mar 2003 21:12:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2BDO11984 for ; Thu, 27 Mar 2003 21:11:13 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00708; Thu, 27 Mar 2003 20:49:04 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2S1p4s22945; Thu, 27 Mar 2003 19:51:14 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Mar 2003 19:50:55 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Mar 2003 19:50:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 27 Mar 2003 19:50:29 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL0Oh0S9278a4G2TwGrlMF2MA/VLAAjOLXA To: Cc: , X-OriginalArrivalTime: 28 Mar 2003 01:50:30.0476 (UTC) FILETIME=[69C418C0:01C2F4CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2S2BDO11985 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, IMO, binary content in application message is a general issue for SigComp multiplexing. It's not specific to SIP. I already explained this in rohc and sipping mailing list. But here is a simple example. Let's say endpoint A already knows endpoint B supports SigComp on TCP port number 5000. A sends, on port 5000, uncompressed message 1 followed by message 2 compressed using SigComp. From RFC 3320, message 2 starts with bit pattern 11111. So, if message 1 has no binary content, endpoint B can easily detect the beginning of message 2 (i.e. end of message 1) by detecting 11111. However, if message 1 contains binary content, that means the (uncompressed) binary part may contain byte 11111xxx. This "mimicking" will make endpoint B mistakenly think a new SigComp message starts at that byte. Obviously, things will be messed up from that point. This is what I referred to as the multiplexing issue. I hope I explained it better this time for you. Anyway, I'll submit a personal draft to help the discussion, although the above example should make it obvious already. Zhigang > -----Original Message----- > From: ext Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: March 27, 2003 2:18 AM > To: Liu Zhigang.C (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Zhigang, > > > My question is the handling of binary content in application > > messages. In my view, this is a generic issue although it started > > with SIP. My thought was to have a *separate* document that > > addresses this issue (and perhaps other generic SigComp "bugs" if > > we find out). > > First of all, it is not yet clear to me that this is a general issue, > at least I have not been able to see consensus on that. Secondly, if > we have general unclear issues with SigComp, those would go into the > Implementer's guide at this point. > > Currently, I therefore think we can and should avoid having even more > documents. However, you can always provide input by writing a draft, > that is up to you. > > Regarding the SigComp&SIP document, it does not matter much > in which WG it is "hosted", as long as it is written and well > reviewed > by people from both sides. > > > Rgds, > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 28 02:23:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19281 for ; Fri, 28 Mar 2003 02:23:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S7jVg11897 for rohc-archive@odin.ietf.org; Fri, 28 Mar 2003 02:45:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7jVO11894 for ; Fri, 28 Mar 2003 02:45:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19263 for ; Fri, 28 Mar 2003 02:23:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7jJO11853; Fri, 28 Mar 2003 02:45:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7i2O11725 for ; Fri, 28 Mar 2003 02:44:02 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19193; Fri, 28 Mar 2003 02:21:49 -0500 (EST) From: Robert.Sugar@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2S7MgU16360; Fri, 28 Mar 2003 09:22:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Mar 2003 09:24:08 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Mar 2003 09:24:10 +0200 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Mar 2003 09:24:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Fri, 28 Mar 2003 08:24:09 +0100 Message-ID: <21B200DF0688CC45ACF38F49D227983206386D@buebe002.europe.nokia.com> Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL0Oh0S9278a4G2TwGrlMF2MA/VLAAjOLXAAAxkv+A= To: Cc: , X-OriginalArrivalTime: 28 Mar 2003 07:24:10.0735 (UTC) FILETIME=[06C52FF0:01C2F4FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2S7i2O11728 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Zhigang, I don't think it is a problem with SigComp multiplexing, but more like a SIP internal issue. What if there is a TCP stream of SIP messages and the Content-Length header is missing or false? They will screw up the same way with or without SigComp. During normal functioning both SIP and SigComp provide their own flow separation mechanism and they work just fine. As for other applications the requirement is that the messages must not start with 11111xxx and the end of the messages must be detected. If that is assured binary content is not a problem anymore. Besides, whatever pattern you choose to distinguish SigComp it might appear in application messages for example if we attach a Sigcomp message as application/octet stream . Only the possibility for screwing up will be lower. Best Regards, Robert > -----Original Message----- > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: March 28,2003 2:50 > To: Lars-Erik.Jonsson@epl.ericsson.se > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Lars-Erik, > > IMO, binary content in application message is a general issue for > SigComp multiplexing. It's not specific to SIP. I already explained > this in rohc and sipping mailing list. But here is a simple example. > > Let's say endpoint A already knows endpoint B supports SigComp on TCP > port number 5000. A sends, on port 5000, uncompressed message > 1 followed > by message 2 compressed using SigComp. From RFC 3320, message 2 starts > with bit pattern 11111. So, if message 1 has no binary > content, endpoint > B can easily detect the beginning of message 2 (i.e. end of message 1) > by detecting 11111. However, if message 1 contains binary content, > that means the (uncompressed) binary part may contain byte 11111xxx. > This "mimicking" will make endpoint B mistakenly think a new SigComp > message starts at that byte. Obviously, things will be messed up > from that point. > > This is what I referred to as the multiplexing issue. I hope > I explained > it better this time for you. > > Anyway, I'll submit a personal draft to help the discussion, > although the > above example should make it obvious already. > > Zhigang > > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (EAB) > > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > > Sent: March 27, 2003 2:18 AM > > To: Liu Zhigang.C (NRC/Dallas) > > Cc: rohc@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary > content SIP > > messages > > > > > > Zhigang, > > > > > My question is the handling of binary content in application > > > messages. In my view, this is a generic issue although it started > > > with SIP. My thought was to have a *separate* document that > > > addresses this issue (and perhaps other generic SigComp "bugs" if > > > we find out). > > > > First of all, it is not yet clear to me that this is a > general issue, > > at least I have not been able to see consensus on that. Secondly, if > > we have general unclear issues with SigComp, those would go into the > > Implementer's guide at this point. > > > > Currently, I therefore think we can and should avoid having > even more > > documents. However, you can always provide input by > writing a draft, > > that is up to you. > > > > Regarding the SigComp&SIP document, it does not matter much > > in which WG it is "hosted", as long as it is written and well > > reviewed > > by people from both sides. > > > > > > Rgds, > > /L-E > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 28 02:29:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19456 for ; Fri, 28 Mar 2003 02:29:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S7pFZ12295 for rohc-archive@odin.ietf.org; Fri, 28 Mar 2003 02:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7pFO12292 for ; Fri, 28 Mar 2003 02:51:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19451 for ; Fri, 28 Mar 2003 02:29:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7p4O12269; Fri, 28 Mar 2003 02:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7oJO12215 for ; Fri, 28 Mar 2003 02:50:19 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19430 for ; Fri, 28 Mar 2003 02:28:08 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2S7UUY9022636 for ; Fri, 28 Mar 2003 08:30:30 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Mar 2003 08:30:31 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Fri, 28 Mar 2003 08:25:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, Both Richard and Adam have expressed a different opinion on this issue, and I fail to see how this can be addressed in general, as it is about possible application messages, and thus would be application dependent. Anyway, submit a draft, that might enhance discussions. BR /L-E > IMO, binary content in application message is a general issue for > SigComp multiplexing. It's not specific to SIP. I already explained > this in rohc and sipping mailing list. But here is a simple example. > > Let's say endpoint A already knows endpoint B supports SigComp on TCP > port number 5000. A sends, on port 5000, uncompressed message > 1 followed > by message 2 compressed using SigComp. From RFC 3320, message 2 starts > with bit pattern 11111. So, if message 1 has no binary > content, endpoint > B can easily detect the beginning of message 2 (i.e. end of message 1) > by detecting 11111. However, if message 1 contains binary content, > that means the (uncompressed) binary part may contain byte 11111xxx. > This "mimicking" will make endpoint B mistakenly think a new SigComp > message starts at that byte. Obviously, things will be messed up > from that point. > > This is what I referred to as the multiplexing issue. I hope > I explained > it better this time for you. > > Anyway, I'll submit a personal draft to help the discussion, > although the > above example should make it obvious already. > > Zhigang > > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (EAB) > > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > > Sent: March 27, 2003 2:18 AM > > To: Liu Zhigang.C (NRC/Dallas) > > Cc: rohc@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary > content SIP > > messages > > > > > > Zhigang, > > > > > My question is the handling of binary content in application > > > messages. In my view, this is a generic issue although it started > > > with SIP. My thought was to have a *separate* document that > > > addresses this issue (and perhaps other generic SigComp "bugs" if > > > we find out). > > > > First of all, it is not yet clear to me that this is a > general issue, > > at least I have not been able to see consensus on that. Secondly, if > > we have general unclear issues with SigComp, those would go into the > > Implementer's guide at this point. > > > > Currently, I therefore think we can and should avoid having > even more > > documents. However, you can always provide input by > writing a draft, > > that is up to you. > > > > Regarding the SigComp&SIP document, it does not matter much > > in which WG it is "hosted", as long as it is written and well > > reviewed > > by people from both sides. > > > > > > Rgds, > > /L-E > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 28 02:35:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19687 for ; Fri, 28 Mar 2003 02:35:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S7vIT12617 for rohc-archive@odin.ietf.org; Fri, 28 Mar 2003 02:57:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7vHO12614 for ; Fri, 28 Mar 2003 02:57:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19644 for ; Fri, 28 Mar 2003 02:35:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7v5O12588; Fri, 28 Mar 2003 02:57:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7u8O12552 for ; Fri, 28 Mar 2003 02:56:08 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19591; Fri, 28 Mar 2003 02:33:57 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2S7YoU27852; Fri, 28 Mar 2003 09:34:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Mar 2003 09:36:08 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Mar 2003 09:36:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Fri, 28 Mar 2003 09:36:09 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE744F@esebe019.ntc.nokia.com> Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL0Oh0S9278a4G2TwGrlMF2MA/VLAAjOLXAAA0mRMA= To: , Cc: , X-OriginalArrivalTime: 28 Mar 2003 07:36:10.0995 (UTC) FILETIME=[B4142430:01C2F4FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2S7u8O12553 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit SIP has this header called content-length that tells how long the body of a sip message is regardless of its binary of UTF-8 contents. The SIP parser will read the content-length value and then take that many octets from whatever follows the sip headers as body. If the body has binary with pattern 11111, the parser doesn't care and doesn't even look in the body. Any protocol that wants to make use of sigcomp should fix its own problems. Regards, Hisham > -----Original Message----- > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Friday, March 28, 2003 3:50 AM > To: Lars-Erik.Jonsson@epl.ericsson.se > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Lars-Erik, > > IMO, binary content in application message is a general issue for > SigComp multiplexing. It's not specific to SIP. I already explained > this in rohc and sipping mailing list. But here is a simple example. > > Let's say endpoint A already knows endpoint B supports SigComp on TCP > port number 5000. A sends, on port 5000, uncompressed message > 1 followed > by message 2 compressed using SigComp. From RFC 3320, message 2 starts > with bit pattern 11111. So, if message 1 has no binary > content, endpoint > B can easily detect the beginning of message 2 (i.e. end of message 1) > by detecting 11111. However, if message 1 contains binary content, > that means the (uncompressed) binary part may contain byte 11111xxx. > This "mimicking" will make endpoint B mistakenly think a new SigComp > message starts at that byte. Obviously, things will be messed up > from that point. > > This is what I referred to as the multiplexing issue. I hope > I explained > it better this time for you. > > Anyway, I'll submit a personal draft to help the discussion, > although the > above example should make it obvious already. > > Zhigang > > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (EAB) > > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > > Sent: March 27, 2003 2:18 AM > > To: Liu Zhigang.C (NRC/Dallas) > > Cc: rohc@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary > content SIP > > messages > > > > > > Zhigang, > > > > > My question is the handling of binary content in application > > > messages. In my view, this is a generic issue although it started > > > with SIP. My thought was to have a *separate* document that > > > addresses this issue (and perhaps other generic SigComp "bugs" if > > > we find out). > > > > First of all, it is not yet clear to me that this is a > general issue, > > at least I have not been able to see consensus on that. Secondly, if > > we have general unclear issues with SigComp, those would go into the > > Implementer's guide at this point. > > > > Currently, I therefore think we can and should avoid having > even more > > documents. However, you can always provide input by > writing a draft, > > that is up to you. > > > > Regarding the SigComp&SIP document, it does not matter much > > in which WG it is "hosted", as long as it is written and well > > reviewed > > by people from both sides. > > > > > > Rgds, > > /L-E > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Mar 28 10:32:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03822 for ; Fri, 28 Mar 2003 10:32:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SFseL13702 for rohc-archive@odin.ietf.org; Fri, 28 Mar 2003 10:54:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SFseO13699 for ; Fri, 28 Mar 2003 10:54:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03809 for ; Fri, 28 Mar 2003 10:32:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SFsQO13689; Fri, 28 Mar 2003 10:54:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SFrGO13660 for ; Fri, 28 Mar 2003 10:53:16 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03746 for ; Fri, 28 Mar 2003 10:30:55 -0500 (EST) Received: from tzi.org (IDENT:rwbaTIIyolk1SfilvbqmHAAS4Odtagwi@roman.informatik.uni-bremen.de [134.102.218.120]) by nmh.informatik.uni-bremen.de (8.12.8/8.10.1) with ESMTP id h2SFXHkh019203; Fri, 28 Mar 2003 16:33:17 +0100 (MET) Date: Fri, 28 Mar 2003 16:24:13 +0100 Subject: Re: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Carsten Bormann To: rohc@ietf.org From: Carsten Bormann In-Reply-To: Message-Id: <54B6239E-6131-11D7-881C-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ROHCers, in San Francisco, I promised to come back to the "binary multiplexing" issue after the IETF. It has taken me a while to even understand what is being talked about: There is an assumption in this whole thread that I don't know where it came from. We designed SigComp messages so that they always start with a byte that cannot be used as a coding symbol in UTF-8 (see draft-yergeau-rfc2279bis-04.txt for the updated version of RFC2279 that defines the contemporary version of UTF-8). The assumption was that most signalling protocols would use UTF-8 headers, so this would allow some self-describing-ness of SigComp messages. RFC3320 says: All SigComp messages contain a prefix (the five most-significant bits of the first byte are set to one) that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port. Applications can still reserve a new port specifically for SigComp however (e.g., as part of the discovery mechanism). I now see that this might be phrased a bit misleading ("multiplexing"). But clearly, the scheme discussed is about using the same port for two different *transports*: the raw transport and the SigComp-compressed transport. Nowhere does it say that you would multiplex messages from these two *on the same connection*. I don't believe this is possible or even necessary. Record Marking (4.2.2) is used to delimit SigComp messages on stream transports (TCP, TLS). The assumption, of course, is that the connection carrying these messages already has been disambiguated to run SigComp instead of the raw transport protocol. This is the end of my main argument for this message. If you disagree with it, please discuss it and not the interesting speculation below.
It is somewhat conceivable to occasionally intersperse uncompressed messages in the SigComp record marking transport, but it remains clear that the record marking layer is in effect at all times: For a stream-based transport, the dispatcher delimits messages by parsing the compressed data stream for instances of 0xFF and taking the following actions: So, we are talking about a situation where the data flows to a SigComp dispatcher, not to an entity that still needs to find out whether we are running SigComp or not. Could SigComp record marking be used to carry both compressed and uncompressed messages on one connection? (Remember that this is not part of the standard, but of course could be part of an extension to RFC 3320.) In principle, yes, but there is a problem (see below). In any case, though, Content-Length headers or any other application message delimiting protocol would not enter the picture at all -- the SigComp record marking layer remains in effect throughout a SigComp connection. Now the problem: If you don't have any other way to find out (e.g., different port numbers for compressed and uncompressed), it becomes hard to decide whether such a compressed/uncompressed multiplexed stream is SigComp or not. If it starts with a non-UTF-8 coding symbol, you know it's SigComp. But if the first message you want to send on the connection happens to be uncompressed, you need another way of indicating that a SigComp transport is being used. Of course, you could simply send 0xFFFF and trust that the receiver will discard empty messages. So to make this multiplexing business work, you will have to add a mandate that says empty messages (or at least one 0xFFFF at the beginning of the connection) are discarded. Of course, none of this applys to any hypothetical SigComp application that does not use UTF-8 headers in their messages -- the multiplexing would not work this way at all, period. So you would devise another way of multiplexing, which I'm too lazy to do right now.
Oh, and we still have to do the work on the SIP binding for SigComp, which is completely unrelated to this whole thread. There is no known problem with SigComp-compressing large binary layloads in SIP messages (except, maybe, that there won't be very good compression schemes for data that already have been compressed). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc