From exim@www1.ietf.org Thu Apr 1 00:26:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05222 for ; Thu, 1 Apr 2004 00:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uiF-0006t9-By for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 00:26:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i315Px6A026477 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 00:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uiF-0006sy-76 for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 00:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05105 for ; Thu, 1 Apr 2004 00:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8uiC-0001BB-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 00:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8uhA-00010u-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 00:24:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8ugK-0000wm-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 00:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugL-00069f-TX; Thu, 01 Apr 2004 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8tYc-0001uE-NP for rohc@optimus.ietf.org; Wed, 31 Mar 2004 23:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01105 for ; Wed, 31 Mar 2004 23:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tYY-0004j9-00 for rohc@ietf.org; Wed, 31 Mar 2004 23:11:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tXe-0004e3-00 for rohc@ietf.org; Wed, 31 Mar 2004 23:10:59 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B8tWn-0004Rg-00 for rohc@ietf.org; Wed, 31 Mar 2004 23:10:06 -0500 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVH0080V4SLPR@mta0.huawei.com> for rohc@ietf.org; Thu, 01 Apr 2004 12:07:35 +0800 (CST) Date: Thu, 01 Apr 2004 09:40:27 +0530 From: suman Subject: Re: [rohc] SigComp byte copying question To: Stefan Foeckel , rohc@ietf.org Message-id: <000d01c4179f$445274f0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <883144150.20040331233239@fokus.fraunhofer.de> Content-Transfer-Encoding: QUOTED-PRINTABLE 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE hi Stefan, If the first address of a byte-copying instruction is byte_copy_ri= ght, then the first byte is copied at byte_copy_right, and the next byte i= f copied at byte_copy_left. thanks suman ----- Original Message ----- =46rom: "Stefan Foeckel" To: Sent: Thursday, April 01, 2004 3:02 AM Subject: [rohc] SigComp byte copying question Hello, I am looking for some clarification regarding byte copying in SigComp= . Section 8.4 RFC 3320 states: "... if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows: k :=3D m + 1 (modulo 2^16) If k =3D byte_copy_right then set n :=3D byte_copy_left, else set n := =3D k =2E.." What is the expected destination address, if the first address of a byte-copying instruction is byte_copy_right ? I would assume it is no= t byte_copy_left. Am I right ? Thanks in advance. Stefan -- Mit freundlichen Gr=FCssen Phone: +49 30 34637141 Stefan Foeckel Fax : +49 30 34638141 http://www.fokus.fraunhofer.de ICQ : 46655019 _______________________________________________ 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 exim@www1.ietf.org Thu Apr 1 01:52:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08177 for ; Thu, 1 Apr 2004 01:52:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8w3f-0004wh-3D for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 01:52:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i316qB5v019012 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 01:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8w3e-0004wZ-TT for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 01:52:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08135 for ; Thu, 1 Apr 2004 01:52:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8w3b-0007lV-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 01:52:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8w2l-0007aX-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 01:51:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8w1W-0007K6-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 01:49:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8w1Z-0004f4-33; Thu, 01 Apr 2004 01:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8w0f-0004Ww-KR for rohc@optimus.ietf.org; Thu, 01 Apr 2004 01:49:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07745 for ; Thu, 1 Apr 2004 01:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8w0c-00078R-00 for rohc@ietf.org; Thu, 01 Apr 2004 01:49:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8vzZ-00070q-00 for rohc@ietf.org; Thu, 01 Apr 2004 01:47:58 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1B8vz0-0006tr-00 for rohc@ietf.org; Thu, 01 Apr 2004 01:47:22 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i315hSU2028317 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Apr 2004 07:43:29 +0200 Message-ID: <406BBA21.2070803@effnet.com> Date: Thu, 01 Apr 2004 08:43:45 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhigang.c.liu@nokia.com CC: kd.singh@enst-bretagne.fr, szym_paw@wp.pl, lars-erik.jonsson@ericsson.com, rohc@ietf.org Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field References: <7B5AF06E216CB74DA8A5960A3181B5B815372A@ajebe001.americas.nokia.com> In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B815372A@ajebe001.americas.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit zhigang.c.liu@nokia.com wrote: >>One comment is that the method that I described was something >>I whipped while writing that mail, since it seemed like the >>logical interpretation. Therefore, I described the principle >>of how I understood it to work than the exact method to use it. >>It might need some further analysis of how it can work. I'll >>try to look at that later this week. > > > I thought you have been "convinced" that "there cannot be room > for a slope" because of this? > > It looks to me that you are now *developing* your understanding. > Do we fall into the trap that if one can develop a different > method than what is described in RFC 3095, then it proves that > slope does not exist in RFC 3095? > You're taking that comment out of its context. What I intended all along with that was that "in the spec, as it is written today, there cannot be room for a slope". Sorry if I confused you. The same goes for the next comment. > >>My comments are based around the assumption that "there is no >>slope", so I am not claiming that they are the same thing. > > > Sorry, have you said the following in your earlier email? > http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02033.html > > "if we narrow this down to TS, then we get TS = SN * slope + offset. > Compare this to the formula in 4.5.3 (quoted above), then suddenly > it becomes clear that "slope" really means TS_STRIDE in this section." > > >>Some testcase made some implementation set the TS_STRIDE to zero, > > > This is simply an incorrect implementation (see section 4.5.3). > > It also demonstrated again the fundamental difference between > slope and TS_STRIDE. The former can be zero, while the latter > cannot. > Ok, now I see one reason that we both base ourselves on the spec but reach opposite conclusions. This example in 4.5.3 actually explains your thinking: In the case of video, there is usually a TS_STRIDE as well when the video frame level is considered. The sample rate for most video codecs is 90 kHz. If the video frame rate is fixed, say, to 30 frames/second, the TS will increase by n * 3000 (= n * 90000 / 30) between video frames. Note that a video frame is often divided into several RTP packets to increase robustness against packet loss. In this case several RTP packets will carry the same TS. That is a contradiction of 2.0: Timestamp stride The timestamp stride (TS_STRIDE) is the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers. 4.5.3 talks about stride as the "frame delta" and 2.0 as the "packet delta". So yes, if 4.5.3 "overrides" 2.0 then you're right that the stride cannot be 0, and then I can see why you think I'm silly to say we must define modulus 0. But if 2.0 overriders 4.5.3, then I still think I'm right. That's one quite fundamental difference. So, one is wrong. Which one? BR, Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 1 04:54:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03886 for ; Thu, 1 Apr 2004 04:54:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ytZ-0002RA-Ou for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 04:53:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i319rvPl009364 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 04:53:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ytZ-0002Qx-H9 for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:53:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03859 for ; Thu, 1 Apr 2004 04:53:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ytW-0006O9-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 04:53:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ysa-0006Hj-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 04:52:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8yrf-0006CL-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 04:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yrh-0002LO-LF; Thu, 01 Apr 2004 04:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yqo-0002Iy-9s for rohc@optimus.ietf.org; Thu, 01 Apr 2004 04:51:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03703 for ; Thu, 1 Apr 2004 04:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yql-00068L-00 for rohc@ietf.org; Thu, 01 Apr 2004 04:51:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ypt-00062G-00 for rohc@ietf.org; Thu, 01 Apr 2004 04:50:10 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B8ypO-0005xT-00 for rohc@ietf.org; Thu, 01 Apr 2004 04:49:38 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i319ndqY023289 for ; Thu, 1 Apr 2004 11:49:39 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 11:49:39 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 11:49:49 +0200 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'suman'" , Stefan Foeckel , rohc@ietf.org Subject: RE: [rohc] SigComp byte copying question Date: Thu, 1 Apr 2004 11:51:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Apr 2004 09:49:39.0779 (UTC) FILETIME=[A6871930:01C417CE] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Suman, You're right that the first byte is copied to byte_copy_right, but the = next one is copied to byte_copy_right + 1 (unless it is beyond the = UDVM). This is because the destination is increased by one before = checked against byte_copy_right, so the if condition will never be true = in this case. Either you finish the byte copying successfully or reach = the end of UDVM with decompression failure. BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of = suman Sent: Thursday, April 01, 2004 6:10 AM To: Stefan Foeckel; rohc@ietf.org Subject: Re: [rohc] SigComp byte copying question hi Stefan, If the first address of a byte-copying instruction is = byte_copy_right, then the first byte is copied at byte_copy_right, and the next byte if copied at byte_copy_left. thanks suman ----- Original Message ----- From: "Stefan Foeckel" To: Sent: Thursday, April 01, 2004 3:02 AM Subject: [rohc] SigComp byte copying question Hello, I am looking for some clarification regarding byte copying in SigComp. Section 8.4 RFC 3320 states: "... if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows: k :=3D m + 1 (modulo 2^16) If k =3D byte_copy_right then set n :=3D byte_copy_left, else set n = :=3D k ..." What is the expected destination address, if the first address of a byte-copying instruction is byte_copy_right ? I would assume it is not byte_copy_left. Am I right ? Thanks in advance. Stefan -- Mit freundlichen Gr=FCssen Phone: +49 30 34637141 Stefan Foeckel Fax : +49 30 34638141 http://www.fokus.fraunhofer.de ICQ : 46655019 _______________________________________________ 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 exim@www1.ietf.org Thu Apr 1 05:27:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04998 for ; Thu, 1 Apr 2004 05:27:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zPr-0005LF-NH for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 05:27:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31ARJGJ020534 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 05:27:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zPr-0005L7-GE for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 05:27:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04921 for ; Thu, 1 Apr 2004 05:27:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8zPo-0001Mp-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 05:27:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8zOv-0001DE-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 05:26:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8zNj-000140-02 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 05:25:07 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8zFs-0000Jl-Sk for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 05:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zFs-00050B-6i; Thu, 01 Apr 2004 05:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zF6-0004zI-BF for rohc@optimus.ietf.org; Thu, 01 Apr 2004 05:16:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04619 for ; Thu, 1 Apr 2004 05:16:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8zF3-0000Si-00 for rohc@ietf.org; Thu, 01 Apr 2004 05:16:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8zEC-0000Mx-00 for rohc@ietf.org; Thu, 01 Apr 2004 05:15:16 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1B8zDc-0000HZ-00 for rohc@ietf.org; Thu, 01 Apr 2004 05:14:41 -0500 Received: from courrier.rennes.enst-bretagne.fr (f1-clust.rennes.enst-bretagne.fr [193.52.74.16]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i31AE2L25130; Thu, 1 Apr 2004 12:14:02 +0200 Received: from pcrsm7 ([193.52.74.238]) by courrier.rennes.enst-bretagne.fr (8.12.11/8.12.11/2004.01.01) with SMTP id i31AE2oE024838; Thu, 1 Apr 2004 12:14:02 +0200 (MEST) Message-ID: <016901c417d2$0e920c80$ee4a34c1@rennes.enstbretagne.fr> From: "kamal deep singh" To: "Kristofer Sandlund" , Cc: , , References: <7B5AF06E216CB74DA8A5960A3181B5B815372A@ajebe001.americas.nokia.com> <406BBA21.2070803@effnet.com> Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Thu, 1 Apr 2004 12:14:01 +0200 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Kristofer, We can still avoid the confusion given by 2.0 if we consider that TS_STRIDE is "expected" increase and not everytime increase. > That is a contradiction of 2.0: > > Timestamp stride > > The timestamp stride (TS_STRIDE) is the expected increase in the > timestamp value between two RTP packets with consecutive sequence > numbers. > > 4.5.3 talks about stride as the "frame delta" and 2.0 as the "packet delta". > So yes, if 4.5.3 "overrides" 2.0 then you're right that the stride cannot be 0, > and then I can see why you think I'm silly to say we must define modulus 0. But > if 2.0 overriders 4.5.3, then I still think I'm right. > That's one quite fundamental difference. > > So, one is wrong. Which on regards, Kamal _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 1 07:25:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08642 for ; Thu, 1 Apr 2004 07:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Fo-00077b-MH for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 07:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CP4Q2027371 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 07:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Fo-00077O-H0 for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08609 for ; Thu, 1 Apr 2004 07:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91Fo-0003MU-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:25:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91Ep-0003HV-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:24:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91Dp-0003DI-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Dp-0006sI-TB; Thu, 01 Apr 2004 07:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91D3-0006rD-JZ for rohc@optimus.ietf.org; Thu, 01 Apr 2004 07:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08565 for ; Thu, 1 Apr 2004 07:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91D3-00039J-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:22:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91CE-00034P-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:21:23 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B91BN-0002qN-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:20:30 -0500 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVH00IH2RHVGG@mta0.huawei.com> for rohc@ietf.org; Thu, 01 Apr 2004 20:17:57 +0800 (CST) Date: Thu, 01 Apr 2004 17:50:48 +0530 From: suman Subject: Re: [rohc] SigComp byte copying question To: "Lajos Zaccomer (IJ/ETH)" , Stefan Foeckel , rohc@ietf.org Message-id: <001301c417e3$c4fa2780$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: QUOTED-PRINTABLE 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Zacco, The existing rule is as follows: "... if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows: k :=3D m + 1 (modulo 2^16) If k =3D byte_copy_right then set n :=3D byte_copy_left, else set n := =3D k =2E.." It gives the logic how to calculate the address of where the next byt= e is to be copied under the assumption that a byte is already been copied. but if we consider the case, where the first byte to be copied is its= elf at address byte_copy_right then the above rule does not hold good... I think the rule has to be rephrased as follows: " =2E.. if a byte is copied from/to Address m the actual Address n wher= e n is calculated as follows: if (m > byte_copy_right) n :=3D byte_copy_left else n:=3D k..." I am recommending this rule just to make sure that in all cases, the = byte copy operations should be within the limits set by the values of byte_copy_left and byte_copy_r= ight. thanks suman ----- Original Message ----- =46rom: "Lajos Zaccomer (IJ/ETH)" To: "'suman'" ; "Stefan Foeckel" ; Sent: Thursday, April 01, 2004 3:21 PM Subject: RE: [rohc] SigComp byte copying question Hi Suman, You're right that the first byte is copied to byte_copy_right, but th= e next one is copied to byte_copy_right + 1 (unless it is beyond the UDVM). = This is because the destination is increased by one before checked against byte_copy_right, so the if condition will never be true in this case.= Either you finish the byte copying successfully or reach the end of UDVM wit= h decompression failure. BR/Zacco -----Original Message----- =46rom: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of = suman Sent: Thursday, April 01, 2004 6:10 AM To: Stefan Foeckel; rohc@ietf.org Subject: Re: [rohc] SigComp byte copying question hi Stefan, If the first address of a byte-copying instruction is byte_copy_ri= ght, then the first byte is copied at byte_copy_right, and the next byte i= f copied at byte_copy_left. thanks suman ----- Original Message ----- =46rom: "Stefan Foeckel" To: Sent: Thursday, April 01, 2004 3:02 AM Subject: [rohc] SigComp byte copying question Hello, I am looking for some clarification regarding byte copying in SigComp= . Section 8.4 RFC 3320 states: "... if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows: k :=3D m + 1 (modulo 2^16) If k =3D byte_copy_right then set n :=3D byte_copy_left, else set n := =3D k =2E.." What is the expected destination address, if the first address of a byte-copying instruction is byte_copy_right ? I would assume it is no= t byte_copy_left. Am I right ? Thanks in advance. Stefan -- Mit freundlichen Gr=FCssen Phone: +49 30 34637141 Stefan Foeckel Fax : +49 30 34638141 http://www.fokus.fraunhofer.de ICQ : 46655019 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 1 07:37:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09082 for ; Thu, 1 Apr 2004 07:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91RP-0007nN-Az for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 07:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Cb3hu029961 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 07:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91RP-0007n5-6B for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:37:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09063 for ; Thu, 1 Apr 2004 07:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91RO-0004XV-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91QP-0004Qv-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:36:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91PQ-0004FB-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91PQ-0007en-Qa; Thu, 01 Apr 2004 07:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91OV-0007Wk-Sn for rohc@optimus.ietf.org; Thu, 01 Apr 2004 07:34:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09000 for ; Thu, 1 Apr 2004 07:34:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91OV-0004B4-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:34:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91NX-00045s-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:33:04 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B91MZ-00040I-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:32:03 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31CW2qY012844 for ; Thu, 1 Apr 2004 14:32:02 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 14:32:01 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2AA70742>; Thu, 1 Apr 2004 14:32:01 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'zhigang.c.liu@nokia.com'" , szym_paw@wp.pl, rohc@ietf.org Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Thu, 1 Apr 2004 14:31:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-2" X-OriginalArrivalTime: 01 Apr 2004 12:32:01.0867 (UTC) FILETIME=[5543C1B0:01C417E5] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Zhigang, Thanks for pointing us to this discussion in the archives, it was useful reading at least for me. Unfortunately, this is not what is captured in 3095, and I think (at least) we all agree that there is a need to resolve this issue and make clarifications, although we have not yet figured out and agreed on exactly what to clarify and how. As has been noted before, there are a number of questions one may ask here: 1) What was discussed during the development of 3095 in 1999-2000? 2) What was 3095 intended to say, back in 2000? 3) What is 3095 really saying? 4) How can 3095 be interpreted? 5) Now 2004, which solution do we think makes most sense, technically? 6) Now 2004, which solution would make most sense if we consider 3)? 7) How do we realize 6) in the implementers guide to ensure interoperability? Kamal initially noted that it is unclear whether there really is a slope. When I took a first look at this issue by reading 3095 and the mail thread Kamal had pointed to, my observation was that 3095 is really not defining slopes. One would have to read a lot between the lines to find what Zhigang has explained was the intended meaning. I read the mails from Kristofer as if he also thinks there is no slope defined in 3095, but while Kamal believes there is a need to use implicitly updated slopes, Kristofer seems to be sceptical to that, although it is clear that also a solution without the implicit slopes means there are things that do not "compile", e.g. TS_STRIDE=0, which would have to be defined as it currently would result in a division by 0. We obviously are far from having answered questions 3-7, and even if Zhigang has explained much about 1-2, the history about why things are like they are and what was really intended at that time is still just background information, we need to be responsible, accept what we have, and find the proper solution considering what is really in 3095 today. It might also be so that our preferred solution today, even not considering 3095, will be different than what it was back in 2000. So, what I want you all to think of is to stay open-minded, constructive, and be nice to each other. We all have one single goal, to find the best technical and practical solutions and document them in an unambiguous way. It is not about being right or being wrong, it is about having the courage to ask stupid questions, and thereby getting the discussion forward. It is a good thing to say, "ok, you are right, I did not think about that", since that means we (as a group) has progressed and we have all learned something. Keep up discussing, constructively, as we have a problem to resolve! /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 31 mars 2004 20:19 > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > Subject: RE: [rohc] Slope used to compress/decompress RTP > Timestamp field > > > > The mail list discussions indicates that there were proposals > > to have such principles, but the discussions point in the > direction of > > giving up these ideas. > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch ive/msg00953.html > > That is not true. > > If you read the emails below, you can see my proposal for the > decompressor > to learn slope was agreed upon. > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch ive/msg00934.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00935.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00952.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00957.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00960.html The email you mentioned above is a discussion on only one logic branch in my proposal, i.e., whether the default-slope or the previous learned slope ("old_slope") should be used by the decompressor when it receives only one context update. It is NOT about the slope learning itself, which has already been agreed. In the end, you can see that my proposal to use "old_slope" in the case of one "FO" update was also agreed. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 1 07:45:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09340 for ; Thu, 1 Apr 2004 07:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91ZA-00007Y-Od for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 07:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Cj4fc000460 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 07:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91ZA-00007L-JD for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09298 for ; Thu, 1 Apr 2004 07:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91Z9-0005BG-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:45:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91YA-00054w-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:44:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91XB-0004zJ-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 07:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91XB-0008Fx-A1; Thu, 01 Apr 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91WI-0008Dk-E6 for rohc@optimus.ietf.org; Thu, 01 Apr 2004 07:42:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09210 for ; Thu, 1 Apr 2004 07:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91WH-0004vi-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91VL-0004rq-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:41:07 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1B91Uc-0004mC-00 for rohc@ietf.org; Thu, 01 Apr 2004 07:40:22 -0500 Received: from [IPv6:::1] (imh.informatik.uni-bremen.de [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i31Ce7Sb001123; Thu, 1 Apr 2004 14:40:08 +0200 (MEST) In-Reply-To: <001301c417e3$c4fa2780$6d05120a@sumanccl20088> References: <001301c417e3$c4fa2780$6d05120a@sumanccl20088> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Stefan Foeckel , Carsten Bormann , "Lajos Zaccomer (IJ/ETH)" , rohc@ietf.org From: Carsten Bormann Subject: Re: [rohc] SigComp byte copying question Date: Thu, 1 Apr 2004 14:40:09 +0200 To: suman X-Mailer: Apple Mail (2.613) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I am recommending this rule Suman, RFC3320 is an IETF "Proposed Standard", i.e. people are implementing it from the specification under the assumption that it is stable. I agree that there are other ways this could be designed, but since the spec seems to be quite clear the way it is, a change seems uncalled for unless there is a demonstrated serious interoperability problem caused by the current design. I haven't seen bytecode that would ever cause the pointer to start at byte_copy_right, and I assume this is unlikely to occur in practice. Even if this assumption is false, it *is* easy to work around this problem (by spending some more bytes of UDVM code -- which we would want to avoid if we were doing this from scratch, but which may be an appropriate price to pay for a stable specification). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 01:06:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11597 for ; Fri, 2 Apr 2004 01:06:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E8b-0005lR-6x for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 21:10:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322ATs7022152 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 21:10:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Bkh-0008Ox-SN for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09629 for ; Thu, 1 Apr 2004 18:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bke-0002we-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 18:37:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Bjn-0002qQ-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 18:36:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bj2-0002jJ-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 18:35:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99Y9-00081u-Kp; Thu, 01 Apr 2004 16:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B92mv-0002yK-1y for rohc@optimus.ietf.org; Thu, 01 Apr 2004 09:03:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13692 for ; Thu, 1 Apr 2004 09:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92mh-0006Gy-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:03:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92lk-0006BX-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:02:09 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B92l1-00067p-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:01:24 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31E1JYG004748 for ; Thu, 1 Apr 2004 16:01:23 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 16:01:19 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FBAHYR; Thu, 1 Apr 2004 16:01:54 +0200 Received: by lms001.lu.erisoft.se id QAA07186; Thu, 1 Apr 2004 16:01:23 +0200 (MET DST) Message-ID: <406C209B.53971CC5@ericsson.com> Date: Thu, 01 Apr 2004 16:00:59 +0200 X-Sybari-Trust: 1d66ffd5 2c4885b5 7a61c793 00000138 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rohc@ietf.org CC: zhigang.c.liu@nokia.com, lars-erik.jonsson@ericsson.com, szym_paw@wp.pl, Kristofer Sandlund Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field References: <7B5AF06E216CB74DA8A5960A3181B5B815372C@ajebe001.americas.nokia.com> Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 01 Apr 2004 14:01:19.0189 (UTC) FILETIME=[CE7A3850:01C417F1] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id i31E1JYG004748 Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I have looked through the specs, as well as through both the current and old mail discussions on this topic. My take is that although it may seem as if there was an agreement in older mail list discussions regarding the use of a "slope" and how to "learn a slope", I can not find that this resulted in any normative text anywhere in 3095; therefore I tend to agree with Kristofer as to that these concepts do not exist in 3095. Also, I wonder why this additional "learned slope" would help at all. If TS_STRIDE represents the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers, what is this slope trying to correct? Does this not mean that the value of TS_STRIDE needs to be updated? In the case of video that was discussed, it seem to make more sense to update TS_STRIDE (or TS_OFFSET as Kristofer suggested), as for both U/O-mode and R-mode (2 ACKs, min 1 RTT) this will be faster than to update the "slope" based on 2 packets in U/O-mode or the reception of 2 ACKs in R-mode. Also, regarding the following text in 5.5.1.2. For example, in a typical case where the string pattern has the form of non-SN-field =3D SN * slope + offset, one ACK is enough if the slope has been previously established by the decompressor (i.e., only the new offset needs to be synchronized). Otherwise, two ACKs are required since the decompressor needs two headers to learn both the new slope and the new offset. In the SO state, R-0* packets will be sent. This, in my opinion, is informative text - it does not specify anything. Furthermore, I cannot find any normative equivalent or any normative follow-up to this anywhere in 3095. Going with what is actually written in the specs, I therefore tend to agree in general with Kristofer's opinions on this matter. /Ghyslain zhigang.c.liu@nokia.com wrote: >=20 > > The mail list discussions indicates that there were proposals > > to have such principles, but the discussions point in the direction o= f > > giving up these ideas. > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg= 00953.html >=20 > That is not true. >=20 > If you read the emails below, you can see my proposal for the decompres= sor > to learn slope was agreed upon. >=20 > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 934.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 935.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 952.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 953.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 957.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 960.html >=20 > The email you mentioned above is a discussion on only one logic branch = in my > proposal, i.e., whether the default-slope or the previous learned slope= ("old_slope") > should be used by the decompressor when it receives only one context up= date. > It is NOT about the slope learning itself, which has already been agree= d. In the > end, you can see that my proposal to use "old_slope" in the case of one= "FO" > update was also agreed. >=20 > BR, > Zhigang >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 04:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29949 for ; Fri, 2 Apr 2004 04:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GH2-00010R-I9 for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 23:27:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324RKRn003868 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 23:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9DQM-0007w9-E5 for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 20:24:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18268 for ; Thu, 1 Apr 2004 20:24:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9DQK-00028F-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:24:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9DPN-0001y4-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:23:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DOb-0001o6-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:22:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ABl-0007d7-Jy; Thu, 01 Apr 2004 16:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Lq-00011G-2T for rohc@optimus.ietf.org; Thu, 01 Apr 2004 11:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13931 for ; Thu, 1 Apr 2004 09:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92rX-0006mK-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:08:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92qZ-0006g9-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:07:08 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B92pd-0006ax-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:06:10 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31E65Ah005833 for ; Thu, 1 Apr 2004 16:06:08 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 16:06:05 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQARAKN; Thu, 1 Apr 2004 16:06:15 +0200 Received: by lms001.lu.erisoft.se id QAA07261; Thu, 1 Apr 2004 16:06:09 +0200 (MET DST) Message-ID: <406C21B9.747B111D@ericsson.com> Date: Thu, 01 Apr 2004 16:05:45 +0200 X-Sybari-Trust: 02881aca 272a6e05 71032c23 00000139 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (LU/EAB)" , rohc@ietf.org CC: "'zhigang.c.liu@nokia.com'" , szym_paw@wp.pl, Kristofer Sandlund Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field References: Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 01 Apr 2004 14:06:05.0443 (UTC) FILETIME=[79191D30:01C417F2] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i31E65Ah005833 Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Maybe the way forward is to clarify the following in the implementer's guide: - The informative text regarding "non-SN-field =3D SN * slope + offset" in 5.5.1.2. was meant to be generic and informative, but introduces confusion because it has no normative equivalent meaning; Therefore it is a bug (void text); - TS_STRIDE can be zero. Then should also be added that "if STRIDE=3D0 then TS_OFFSET =3D TS" and that in such case the Timestamp value is compressed as-is and cannot be scaled. - The three occurances of default-slope should be interpreted as a generic name for "the rate of variation of a parameter with respect to the RTP SN, used to decompress this parameter". Or something similar. Regards, /Ghyslain "Lars-Erik Jonsson (LU/EAB)" wrote: >=20 > Zhigang, >=20 > Thanks for pointing us to this discussion in the archives, it was usefu= l reading at > least for me. Unfortunately, this is not what is captured in 3095, and = I think (at > least) we all agree that there is a need to resolve this issue and make= clarifications, > although we have not yet figured out and agreed on exactly what to clar= ify and how. >=20 > As has been noted before, there are a number of questions one may ask h= ere: > 1) What was discussed during the development of 3095 in 1999-2000? > 2) What was 3095 intended to say, back in 2000? > 3) What is 3095 really saying? > 4) How can 3095 be interpreted? > 5) Now 2004, which solution do we think makes most sense, technically? > 6) Now 2004, which solution would make most sense if we consider 3)? > 7) How do we realize 6) in the implementers guide to ensure interoperab= ility? >=20 > Kamal initially noted that it is unclear whether there really is a slop= e. When I took a > first look at this issue by reading 3095 and the mail thread Kamal had = pointed to, my > observation was that 3095 is really not defining slopes. One would have= to read a lot > between the lines to find what Zhigang has explained was the intended m= eaning. I > read the mails from Kristofer as if he also thinks there is no slope de= fined in 3095, > but while Kamal believes there is a need to use implicitly updated slop= es, Kristofer > seems to be sceptical to that, although it is clear that also a solutio= n without the > implicit slopes means there are things that do not "compile", e.g. TS_S= TRIDE=3D0, > which would have to be defined as it currently would result in a divisi= on by 0. >=20 > We obviously are far from having answered questions 3-7, and even if Zh= igang has > explained much about 1-2, the history about why things are like they ar= e and what > was really intended at that time is still just background information, = we need to be > responsible, accept what we have, and find the proper solution consider= ing what > is really in 3095 today. It might also be so that our preferred solutio= n today, even > not considering 3095, will be different than what it was back in 2000. >=20 > So, what I want you all to think of is to stay open-minded, constructiv= e, and be > nice to each other. We all have one single goal, to find the best techn= ical and > practical solutions and document them in an unambiguous way. It is not = about > being right or being wrong, it is about having the courage to ask stupi= d questions, > and thereby getting the discussion forward. It is a good thing to say, = "ok, you > are right, I did not think about that", since that means we (as a group= ) has > progressed and we have all learned something. >=20 > Keep up discussing, constructively, as we have a problem to resolve! > /L-E >=20 > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: den 31 mars 2004 20:19 > > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > Timestamp field > > > > > > > The mail list discussions indicates that there were proposals > > > to have such principles, but the discussions point in the > > direction of > > > giving up these ideas. > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > ive/msg00953.html > > > > That is not true. > > > > If you read the emails below, you can see my proposal for the > > decompressor > > to learn slope was agreed upon. > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > ive/msg00934.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 935.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 952.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 953.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 957.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00= 960.html >=20 > The email you mentioned above is a discussion on only one logic branch = in my > proposal, i.e., whether the default-slope or the previous learned slope= ("old_slope") > should be used by the decompressor when it receives only one context up= date. > It is NOT about the slope learning itself, which has already been agree= d. In the > end, you can see that my proposal to use "old_slope" in the case of one= "FO" > update was also agreed. >=20 > BR, > Zhigang >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 04:18:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00471 for ; Fri, 2 Apr 2004 04:18:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GZ8-0002WC-CC for rohc-archive@odin.ietf.org; Thu, 01 Apr 2004 23:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324k2IQ009674 for rohc-archive@odin.ietf.org; Thu, 1 Apr 2004 23:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9DvP-0006HT-8b for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 20:56:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21494 for ; Thu, 1 Apr 2004 20:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9DvM-0007BX-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:56:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Dtm-0006oA-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:55:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Dt1-0006cC-06 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:54:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Ds8-0000id-OX for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 20:53:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9AC5-0007g9-SO; Thu, 01 Apr 2004 16:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Ld-00011G-Ie for rohc@optimus.ietf.org; Thu, 01 Apr 2004 11:47:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13950 for ; Thu, 1 Apr 2004 09:08:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92rg-0006nX-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92qo-0006iN-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:07:22 -0500 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1B92qE-0006bo-00 for rohc@ietf.org; Thu, 01 Apr 2004 09:06:46 -0500 Received: (wp-smtpd smtp.wp.pl 29654 invoked from network); 1 Apr 2004 16:06:15 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 1 Apr 2004 16:06:15 +0200 Date: Thu, 1 Apr 2004 16:06:14 +0200 From: "Pawel Szymanski" To: rohc@ietf.org Message-ID: <406c21d6e1363@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.173.14 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA13951 Subject: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I've run into a problem with UOR-2 packet Tsc field equal to 1 Extension = 3 and=20 with TS_STRIDE. Is it legal to send such packets ? If Yes, how decompressor should calculate new TS_OFFSET to decompress the= =20 scaled TS value compressed in the packet ?=20 Should it calculate the new TS_OFFSET using the reference timestamp value= (i.e.=20 the value sent in the last successfully decompressed packet containing TS= =20 field) ?=20 Another option is to calculate the new TS_OFFSET using the tiemstamp valu= e sent=20 in the last decompressed packet (which can be diffrent from the reference= =20 timestamp value) ? Or should decompressor use the old TS_OFFSET to decompress the received p= acket ? Best Regards=20 Pawel ---------------------------------------------------- Co przyniesie w tym roku Zaj=B1c? Chcesz mu pom=F3c? Kicnij si=EA na wielkanocne zakupy.wp.pl http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fzakupy.wp.pl%2Fwielkanoc.html&sid=3D= 155 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 04:40:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01422 for ; Fri, 2 Apr 2004 04:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Hok-0005II-Vv for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 01:06:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3266EKU020351 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 01:06:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E8B-0005fW-9k for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 21:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23106 for ; Thu, 1 Apr 2004 21:09:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9E88-0001rB-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 21:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9E5A-0001VM-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 21:06:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9E3k-00016Q-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 21:05:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ADm-0007wq-LG; Thu, 01 Apr 2004 16:59:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98mn-0007pt-AM for rohc@optimus.ietf.org; Thu, 01 Apr 2004 15:27:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29886 for ; Thu, 1 Apr 2004 15:27:16 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98mT-0006Ko-00 for rohc@ietf.org; Thu, 01 Apr 2004 15:27:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98lY-0006G9-00 for rohc@ietf.org; Thu, 01 Apr 2004 15:26:20 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B98kp-00069x-00 for rohc@ietf.org; Thu, 01 Apr 2004 15:25:36 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31KPY311110; Thu, 1 Apr 2004 23:25:34 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 23:24:43 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i31KOh5q029472; Thu, 1 Apr 2004 23:24:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00UR9hhw; Thu, 01 Apr 2004 23:24:42 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31KOds09596; Thu, 1 Apr 2004 23:24:40 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 14:23:24 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Thu, 1 Apr 2004 15:23:22 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B815372F@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQXtVyvXz9iw1SoRAGp4qq4JUZ39wAbiqTw To: Cc: , , , X-OriginalArrivalTime: 01 Apr 2004 20:23:24.0449 (UTC) FILETIME=[2EFF4910:01C41827] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > You're taking that comment out of its context. What I=20 > intended all along with that was that "in the spec, as it=20 > is written today, there cannot be room for a=20 > slope". Sorry if I confused you. The same goes for the next comment. That's fine. At least you agree that slope is not the same thing as TS_STRIDE. So it is not a valid argument for your belief that "there cannot be room for a slope". OK? BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 07:37:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06726 for ; Fri, 2 Apr 2004 07:37:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KpU-0005Qs-Uq for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 04:19:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i329JCi2020880 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 04:19:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GbO-0002lA-TO for rohc-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 23:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06251 for ; Thu, 1 Apr 2004 23:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9GbM-00009j-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 23:48:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9GUF-0006T7-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 23:41:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9GNB-0004wz-00 for rohc-web-archive@ietf.org; Thu, 01 Apr 2004 23:33:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dg6-0001Hv-Em; Thu, 01 Apr 2004 20:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99he-0002dd-8r for rohc@optimus.ietf.org; Thu, 01 Apr 2004 16:26:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02935 for ; Thu, 1 Apr 2004 16:26:18 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B99hb-0005Ql-00 for rohc@ietf.org; Thu, 01 Apr 2004 16:26:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B99gg-0005Kj-00 for rohc@ietf.org; Thu, 01 Apr 2004 16:25:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B99g7-0005GP-00 for rohc@ietf.org; Thu, 01 Apr 2004 16:24:47 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31LOkh10274; Fri, 2 Apr 2004 00:24:46 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 00:21:38 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i31LLcoS023992; Fri, 2 Apr 2004 00:21:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 006GuHEV; Fri, 02 Apr 2004 00:21:26 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31LLNs11127; Fri, 2 Apr 2004 00:21:23 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 15:20:47 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Thu, 1 Apr 2004 16:20:46 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153731@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQX0r2E3KSXFPUmSZep+a2ufIWuQAAVHKCg To: , Cc: , , X-OriginalArrivalTime: 01 Apr 2004 21:20:47.0874 (UTC) FILETIME=[33703E20:01C4182F] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Kamal. It's clear that TS_STRIDE means what it means in section 4.5.3. TS_STRIDE is the scaling factor. Period. This is also reinforced in many other sections. On the other hand, I do agree that the terminology section could=20 have been written better. But as Kamal commented, there is no real=20 contradiction. Still, I'd like to propose the following text in=20 the implementation I-D to clarify the issue: ----------------- As it is described in section 4.5.3 and other places in RFC 3095, TS_STRIDE is the factor by which an RTP Timestamp is downscaled before compression. Obviously, it cannot be 0 (zero). The wording of TS_STRIDE definition in section 2 may be incorrectly interpreted as TS_STRIDE is always equal to the increase in TS value between two RTP packets with consecutive sequence number. This is not the intent of the specification. It is the compressor that decides whether TS=20 scaling should be used and if yes, what is the best value of=20 TS_STRIDE. How this is done is an implementation issue.=20 However, an implementation must follow section 4.5.3, 4.5.6=20 and 5.7 on how to initialize, encode, and synchronize=20 TS_STRIDE between the compressor and decompressor. Note: TS_STRIDE is not the same as slope described in section=20 5.5.1.2 and 5.7. -------------------- I think the above text addresses Kristofer's concern. Comments? BR, Zhigang > -----Original Message----- > From: ext kamal deep singh [mailto:kd.singh@enst-bretagne.fr] > Sent: 01 April, 2004 04:14 AM > To: Kristofer Sandlund; Liu Zhigang.C (Nokia-NRC/Dallas) > Cc: szym_paw@wp.pl; lars-erik.jonsson@ericsson.com; rohc@ietf.org > Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp > field >=20 >=20 >=20 > hi Kristofer, >=20 > We can still avoid the confusion given by 2.0 if we consider that > TS_STRIDE is "expected" increase and not everytime increase. >=20 > > That is a contradiction of 2.0: > > > > Timestamp stride > > > > The timestamp stride (TS_STRIDE) is the expected=20 > increase in the > > timestamp value between two RTP packets with=20 > consecutive sequence > > numbers. > > > > 4.5.3 talks about stride as the "frame delta" and 2.0 as the "packet > delta". > > So yes, if 4.5.3 "overrides" 2.0 then you're right that the=20 > stride cannot > be 0, > > and then I can see why you think I'm silly to say we must=20 > define modulus > 0. But > > if 2.0 overriders 4.5.3, then I still think I'm right. > > That's one quite fundamental difference. > > > > So, one is wrong. Which on >=20 > regards, > Kamal >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 07:56:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07594 for ; Fri, 2 Apr 2004 07:56:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9L9i-0006wH-1N for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 04:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i329e540026660 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 04:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HgU-00059g-Nf for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 00:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11329 for ; Fri, 2 Apr 2004 00:57:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HgS-00016z-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 00:57:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Hfa-00010q-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 00:56:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hev-0000ul-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 00:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E8A-0005fB-7u; Thu, 01 Apr 2004 21:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BX5-0005bO-BW for rohc@optimus.ietf.org; Thu, 01 Apr 2004 18:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08577 for ; Thu, 1 Apr 2004 18:23:30 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BX2-0001LT-00 for rohc@ietf.org; Thu, 01 Apr 2004 18:23:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BW9-0001FQ-00 for rohc@ietf.org; Thu, 01 Apr 2004 18:22:38 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B9BVf-000196-00 for rohc@ietf.org; Thu, 01 Apr 2004 18:22:07 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31NLw326465; Fri, 2 Apr 2004 02:21:58 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 02:23:57 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i31NNvKR009071; Fri, 2 Apr 2004 02:23:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 003leLRm; Fri, 02 Apr 2004 02:23:56 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31NLHF06276; Fri, 2 Apr 2004 02:21:18 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 17:21:17 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Thu, 1 Apr 2004 18:21:15 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153733@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQX5ffNaOcJFhA8SDmaL/XADqYXgAAU3IXw To: , , X-OriginalArrivalTime: 01 Apr 2004 23:21:17.0432 (UTC) FILETIME=[08973F80:01C41840] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lars-Erik, IMHO, we should clearly separate clarifying RFC 3095 from redefining it: - As I said, some text in RFC 3095 could have been written better = (though it doesn't mean we haven't tried). The slope is one of them, in = which case we should clarify what RFC 3095 intended to say. - However, it is a completely different subject to say we do not need = slope. If that is indeed the conclusion at the end of this discussion, = we should define a new profile that excludes it. Mixing this with above = is not a constructive approach. > So, what I want you all to think of is to stay open-minded, = constructive, and be nice to each other. I cannot agree more. And here is my understanding - if I may - on how to = do it in practice (I've been trying them myself): - Be conservative of what you say. Try best to verify the = reasoning/observations/facts on which you make a claim. - Everyone makes mistakes or has incorrect information. That's perfectly = OK, but admit it. - Being nice to others means reading their emails *carefully*, = especially when you disagree. If you agree, say so. If not, give = reasons. - Be honest and straight to the point. BR, Zhigang > -----Original Message----- > From: ext Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com] > Sent: 01 April, 2004 06:32 AM > To: Liu Zhigang.C (Nokia-NRC/Dallas); szym_paw@wp.pl; rohc@ietf.org > Subject: RE: [rohc] Slope used to compress/decompress RTP=20 > Timestamp field >=20 >=20 > Zhigang, >=20 > Thanks for pointing us to this discussion in the archives, it=20 > was useful reading at > least for me. Unfortunately, this is not what is captured in=20 > 3095, and I think (at > least) we all agree that there is a need to resolve this=20 > issue and make clarifications, > although we have not yet figured out and agreed on exactly=20 > what to clarify and how. >=20 > As has been noted before, there are a number of questions one=20 > may ask here: > 1) What was discussed during the development of 3095 in 1999-2000? > 2) What was 3095 intended to say, back in 2000? > 3) What is 3095 really saying? > 4) How can 3095 be interpreted? > 5) Now 2004, which solution do we think makes most sense, technically? > 6) Now 2004, which solution would make most sense if we consider 3)? > 7) How do we realize 6) in the implementers guide to ensure=20 > interoperability? >=20 > Kamal initially noted that it is unclear whether there really=20 > is a slope. When I took a > first look at this issue by reading 3095 and the mail thread=20 > Kamal had pointed to, my > observation was that 3095 is really not defining slopes. One=20 > would have to read a lot=20 > between the lines to find what Zhigang has explained was the=20 > intended meaning. I > read the mails from Kristofer as if he also thinks there is=20 > no slope defined in 3095, > but while Kamal believes there is a need to use implicitly=20 > updated slopes, Kristofer > seems to be sceptical to that, although it is clear that also=20 > a solution without the > implicit slopes means there are things that do not "compile",=20 > e.g. TS_STRIDE=3D0, > which would have to be defined as it currently would result=20 > in a division by 0.=20 >=20 > We obviously are far from having answered questions 3-7, and=20 > even if Zhigang has > explained much about 1-2, the history about why things are=20 > like they are and what > was really intended at that time is still just background=20 > information, we need to be > responsible, accept what we have, and find the proper=20 > solution considering what > is really in 3095 today. It might also be so that our=20 > preferred solution today, even > not considering 3095, will be different than what it was back=20 > in 2000.=20 >=20 > So, what I want you all to think of is to stay open-minded,=20 > constructive, and be > nice to each other. We all have one single goal, to find the=20 > best technical and > practical solutions and document them in an unambiguous way.=20 > It is not about > being right or being wrong, it is about having the courage to=20 > ask stupid questions, > and thereby getting the discussion forward. It is a good=20 > thing to say, "ok, you=20 > are right, I did not think about that", since that means we=20 > (as a group) has > progressed and we have all learned something.=20 >=20 > Keep up discussing, constructively, as we have a problem to resolve! > /L-E >=20 >=20 >=20 > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: den 31 mars 2004 20:19 > > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > > Subject: RE: [rohc] Slope used to compress/decompress RTP=20 > > Timestamp field > >=20 > >=20 > > > The mail list discussions indicates that there were proposals=20 > > > to have such principles, but the discussions point in the=20 > > direction of=20 > > > giving up these ideas. > > >=20 > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > ive/msg00953.html > >=20 > > That is not true.=20 > >=20 > > If you read the emails below, you can see my proposal for the=20 > > decompressor > > to learn slope was agreed upon.=20 > >=20 > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > ive/msg00934.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch ive/msg00935.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0095= 2.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0095= 3.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0095= 7.html http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0096= 0.html The email you mentioned above is a discussion on only one logic branch = in my proposal, i.e., whether the default-slope or the previous learned slope = ("old_slope")=20 should be used by the decompressor when it receives only one context = update.=20 It is NOT about the slope learning itself, which has already been = agreed. In the=20 end, you can see that my proposal to use "old_slope" in the case of one = "FO"=20 update was also agreed.=20 BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 15:34:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27499 for ; Fri, 2 Apr 2004 15:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SHO-0007OL-M3 for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 12:16:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32HGUcV028413 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 12:16:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QGz-0008Ns-Cr for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 10:07:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11926 for ; Fri, 2 Apr 2004 10:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QGx-0003zE-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 10:07:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QG0-0003qm-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 10:06:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9QFE-0003i2-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 10:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N4l-00027M-PX; Fri, 02 Apr 2004 06:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9IeU-00072e-R7 for rohc@optimus.ietf.org; Fri, 02 Apr 2004 01:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12465 for ; Fri, 2 Apr 2004 01:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9IeR-0007TG-00 for rohc@ietf.org; Fri, 02 Apr 2004 01:59:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9IdV-0007O9-00 for rohc@ietf.org; Fri, 02 Apr 2004 01:58:41 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B9IdI-0007Im-00 for rohc@ietf.org; Fri, 02 Apr 2004 01:58:28 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i326wSqY010110 for ; Fri, 2 Apr 2004 08:58:28 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 08:58:28 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <2AA8HMM5>; Fri, 2 Apr 2004 08:58:28 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'zhigang.c.liu@nokia.com'" , kd.singh@enst-bretagne.fr, kristofer.sandlund@effnet.com Cc: szym_paw@wp.pl, rohc@ietf.org Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Fri, 2 Apr 2004 08:58:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Apr 2004 06:58:28.0645 (UTC) FILETIME=[E6DE2D50:01C4187F] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Zhigang, > ----------------- > As it is described in section 4.5.3 and other places in RFC > 3095, TS_STRIDE is the factor by which an RTP Timestamp is > downscaled before compression. Obviously, it cannot be 0 (zero). > > The wording of TS_STRIDE definition in section 2 may be > incorrectly interpreted as TS_STRIDE is always equal to > the increase in TS value between two RTP packets with > consecutive sequence number. This is not the intent of the > specification. I think we have still not reached an agreement on this point. It seems like the logic would had been unambigous if TS had never been constant, then scaling factor and "increase in TS between two RTP packets" had obviously been the same. However, as TS might be constant, one can argue that these two can not be the same as one can not divide with a value of 0. On the other hand, why should it not be possible to have a scaling FACTOR of 0. I agree we can not have a scaling DENOMINATOR of 0, but it is fine to have a factor of 0. > It is the compressor that decides whether TS > scaling should be used and if yes, what is the best value of > TS_STRIDE. How this is done is an implementation issue. Yes, it is an implementation issue, and to me the video example seems to be a reasonable argument for enforcing the TS_STRIDE definition from section 2, and thus allow it to be 0. > However, an implementation must follow section 4.5.3, 4.5.6 > and 5.7 on how to initialize, encode, and synchronize > TS_STRIDE between the compressor and decompressor. > > Note: TS_STRIDE is not the same as slope described in section > 5.5.1.2 and 5.7. > -------------------- > > I think the above text addresses Kristofer's concern. Comments? This proposal still does not address the original concern about the concept of slopes not at all being defined in 3095. That is the major issue here, I think. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 16:06:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28939 for ; Fri, 2 Apr 2004 16:06:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SKG-0007js-8I for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 12:19:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32HJSIp029745 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 12:19:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QZe-0005vq-AS for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 10:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13782 for ; Fri, 2 Apr 2004 10:27:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QZc-0006kF-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 10:27:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QYk-0006bS-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 10:26:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9QY9-0006S0-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 10:25:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N9a-0002pP-Ep; Fri, 02 Apr 2004 06:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9K0g-0002Dr-Vx for rohc@optimus.ietf.org; Fri, 02 Apr 2004 03:26:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28692 for ; Fri, 2 Apr 2004 03:26:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9K0e-0001cM-00 for rohc@ietf.org; Fri, 02 Apr 2004 03:26:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Jzl-0001WJ-00 for rohc@ietf.org; Fri, 02 Apr 2004 03:25:46 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B9JzA-0001QU-00 for rohc@ietf.org; Fri, 02 Apr 2004 03:25:08 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i328P8Ah015035 for ; Fri, 2 Apr 2004 10:25:08 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 10:25:08 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <212X9ADL>; Fri, 2 Apr 2004 10:25:17 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: rohc@ietf.org Cc: "'zhigang.c.liu@nokia.com'" Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Fri, 2 Apr 2004 09:21:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-2" X-OriginalArrivalTime: 02 Apr 2004 08:25:08.0729 (UTC) FILETIME=[025C0690:01C4188C] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Zhigang, > Lars-Erik, > > IMHO, we should clearly separate clarifying RFC 3095 from > redefining it: Yes, absolutely, but since we are discussing things that are not clearly defined in the specification, we must consider what is actually there, and not what was the original intention. > - As I said, some text in RFC 3095 could have been written > better (though it doesn't mean we haven't tried). The slope > is one of them, in which case we should clarify what RFC 3095 > intended to say. Well, the motivation for clarifying anything at all is to ensure interoperability, not necessarily to enforce principles that we intended to build upon but never wrote in the specification. We need to find out what would be the smallest possible deviation from the current spec, that would be consistent and ensure interoperability. The original intention is of secondary importance > - However, it is a completely different subject to say we do > not need slope. If that is indeed the conclusion at the end > of this discussion, we should define a new profile that > excludes it. Mixing this with above is not a constructive approach. Since existing profiles are not defined by the original intention of the authors, but rather by what is actually in the specification, one could instead argue that a new profile would be needed to *include* the concept of slopes. However, I do not think such discussions are useful at this point, but we should first figure out what are the possible approaches and what each of these would imply in terms of "clarifications" to what is currently in RFC 3095. Then we are ready to discuss which approach best serves our objective of ensuring interoperability. Cheers, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 16:27:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01204 for ; Fri, 2 Apr 2004 16:27:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WBP-0008GY-9B for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 16:26:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LQZMB031773 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 16:26:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WBO-0008GL-QF for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:26:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01165 for ; Fri, 2 Apr 2004 16:26:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WBN-0004DN-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:26:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WAP-00043T-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:25:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9W9w-0003tP-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W9x-0007pg-44; Fri, 02 Apr 2004 16:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9T9E-0003ac-FQ for rohc@optimus.ietf.org; Fri, 02 Apr 2004 13:12:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21498 for ; Fri, 2 Apr 2004 13:12:06 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9T9C-0007Jb-00 for rohc@ietf.org; Fri, 02 Apr 2004 13:12:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9T8L-0007Cd-00 for rohc@ietf.org; Fri, 02 Apr 2004 13:11:14 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B9T82-00074p-00 for rohc@ietf.org; Fri, 02 Apr 2004 13:10:54 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32IAmF16192; Fri, 2 Apr 2004 21:10:48 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 21:09:07 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i32I97Xx015537; Fri, 2 Apr 2004 21:09:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00datRn6; Fri, 02 Apr 2004 21:09:05 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32I92s13287; Fri, 2 Apr 2004 21:09:02 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 12:07:58 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Fri, 2 Apr 2004 13:07:56 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153735@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQYVr3o/y6kiBbmRMuM8zhojkszEgAfl7hg To: , , Cc: , X-OriginalArrivalTime: 02 Apr 2004 18:07:58.0621 (UTC) FILETIME=[6E0A14D0:01C418DD] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ghyslain, This is amazing. I hesitate to say this, but what I see seems to be=20 a campaign to make fundamental changes to RFC 3095, instead of=20 genuine effort to clarify some misunderstanding/maturity in 3095. I hope this is not the case. I disagree with you on your three points. And here is why. RE your first point: - Do you call the fundamental of RFC 3095 a bug? The confusion is not=20 caused by the presence of "non-SN-field =3D SN * slope + offset",=20 but by its not being clear enough. The right thing to do is clarifying it, not removing it. RE your second point: - TS_STRIDE is scale factor for TS, as clearly stated in section 4.5.3.=20 Do you agree? - TS_OFFSET and its calculation is clearly defined in section 4.5.3. = Agree? - Whether TS is scaled or not is indicated by Tsc. Agree? - Do you mean you want to change all of above, instead of my simple proposal to clarify the confusion caused by TS_STRIDE definition? RE your third point: - I don't understand. If you read through the email discussion by RFC = 3095 authors and text in 5.5.1.2, the meaning of slope and default-slope is=20 obvious. Why not just clarify that in the implementation I-D? - Moreover, your interpretation is incorrect: slope is about the rate of variation of a header field w.r.t. SN, not a parameter.=20 BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Ghyslain Pelletier > Sent: 01 April, 2004 08:06 AM > To: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > Cc: Liu Zhigang.C (Nokia-NRC/Dallas); szym_paw@wp.pl;=20 > Kristofer Sandlund > Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp > field >=20 >=20 > Hi all, >=20 > Maybe the way forward is to clarify the following in the implementer's > guide: >=20 > - The informative text regarding "non-SN-field =3D SN * slope + = offset" > in 5.5.1.2. was meant to be generic and informative, but introduces > confusion because it has no normative equivalent meaning; > Therefore it is a bug (void text); >=20 > - TS_STRIDE can be zero. Then should also be added that > "if STRIDE=3D0 then TS_OFFSET =3D TS" and that in such case the > Timestamp value is compressed as-is and cannot be scaled. >=20 > - The three occurances of default-slope should be interpreted as > a generic name for "the rate of variation of a parameter with > respect to the RTP SN, used to decompress this parameter". > Or something similar. >=20 > Regards, >=20 > /Ghyslain >=20 > "Lars-Erik Jonsson (LU/EAB)" wrote: > >=20 > > Zhigang, > >=20 > > Thanks for pointing us to this discussion in the archives,=20 > it was useful reading at > > least for me. Unfortunately, this is not what is captured=20 > in 3095, and I think (at > > least) we all agree that there is a need to resolve this=20 > issue and make clarifications, > > although we have not yet figured out and agreed on exactly=20 > what to clarify and how. > >=20 > > As has been noted before, there are a number of questions=20 > one may ask here: > > 1) What was discussed during the development of 3095 in 1999-2000? > > 2) What was 3095 intended to say, back in 2000? > > 3) What is 3095 really saying? > > 4) How can 3095 be interpreted? > > 5) Now 2004, which solution do we think makes most sense,=20 > technically? > > 6) Now 2004, which solution would make most sense if we consider 3)? > > 7) How do we realize 6) in the implementers guide to ensure=20 > interoperability? > >=20 > > Kamal initially noted that it is unclear whether there=20 > really is a slope. When I took a > > first look at this issue by reading 3095 and the mail=20 > thread Kamal had pointed to, my > > observation was that 3095 is really not defining slopes.=20 > One would have to read a lot > > between the lines to find what Zhigang has explained was=20 > the intended meaning. I > > read the mails from Kristofer as if he also thinks there is=20 > no slope defined in 3095, > > but while Kamal believes there is a need to use implicitly=20 > updated slopes, Kristofer > > seems to be sceptical to that, although it is clear that=20 > also a solution without the > > implicit slopes means there are things that do not=20 > "compile", e.g. TS_STRIDE=3D0, > > which would have to be defined as it currently would result=20 > in a division by 0. > >=20 > > We obviously are far from having answered questions 3-7,=20 > and even if Zhigang has > > explained much about 1-2, the history about why things are=20 > like they are and what > > was really intended at that time is still just background=20 > information, we need to be > > responsible, accept what we have, and find the proper=20 > solution considering what > > is really in 3095 today. It might also be so that our=20 > preferred solution today, even > > not considering 3095, will be different than what it was=20 > back in 2000. > >=20 > > So, what I want you all to think of is to stay open-minded,=20 > constructive, and be > > nice to each other. We all have one single goal, to find=20 > the best technical and > > practical solutions and document them in an unambiguous=20 > way. It is not about > > being right or being wrong, it is about having the courage=20 > to ask stupid questions, > > and thereby getting the discussion forward. It is a good=20 > thing to say, "ok, you > > are right, I did not think about that", since that means we=20 > (as a group) has > > progressed and we have all learned something. > >=20 > > Keep up discussing, constructively, as we have a problem to resolve! > > /L-E > >=20 > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: den 31 mars 2004 20:19 > > > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > > Timestamp field > > > > > > > > > > The mail list discussions indicates that there were proposals > > > > to have such principles, but the discussions point in the > > > direction of > > > > giving up these ideas. > > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00953.html > > > > > > That is not true. > > > > > > If you read the emails below, you can see my proposal for the > > > decompressor > > > to learn slope was agreed upon. > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00934.html > >=20 http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0093= 5.html > = http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0095= 2.html > = http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0095= 3.html > = http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0095= 7.html > = http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg0096= 0.html >=20 > The email you mentioned above is a discussion on only one logic branch = in my > proposal, i.e., whether the default-slope or the previous learned = slope ("old_slope") > should be used by the decompressor when it receives only one context = update. > It is NOT about the slope learning itself, which has already been = agreed. In the > end, you can see that my proposal to use "old_slope" in the case of = one "FO" > update was also agreed. >=20 > BR, > Zhigang >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ 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 exim@www1.ietf.org Fri Apr 2 16:44:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03267 for ; Fri, 2 Apr 2004 16:44:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WSN-0001jm-SD for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 16:44:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Li7h7006678 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 16:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UWh-0007uF-JC for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 14:40:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24278 for ; Fri, 2 Apr 2004 14:40:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UWe-00038n-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 14:40:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UVu-0002yu-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 14:39:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9UUq-0002oQ-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 14:38:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9RyY-0005KW-HP; Fri, 02 Apr 2004 11:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Onz-0008Sg-UG for rohc@optimus.ietf.org; Fri, 02 Apr 2004 08:33:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08696 for ; Fri, 2 Apr 2004 08:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ony-0007Uz-00 for rohc@ietf.org; Fri, 02 Apr 2004 08:33:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9On0-0007OR-00 for rohc@ietf.org; Fri, 02 Apr 2004 08:32:56 -0500 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B9OmD-0007I6-00 for rohc@ietf.org; Fri, 02 Apr 2004 08:32:05 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i32DW3WR001870 for ; Fri, 2 Apr 2004 15:32:03 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 15:32:03 +0200 Received: from caffreys (caffreys.ericsson.se [147.214.181.21]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FBLFYG; Fri, 2 Apr 2004 15:32:41 +0200 Date: Fri, 2 Apr 2004 15:37:30 +0200 (CEST) From: Vicknesan Ayadurai X-X-Sender: vick@caffreys.ericsson.se To: zhigang.c.liu@nokia.com cc: Lars-Erik Jonsson , , ROHC mail list Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Message-ID: <20040402152144.X269-100000@caffreys.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Apr 2004 13:32:03.0573 (UTC) FILETIME=[E2763A50:01C418B6] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, I might've missed the start of this thread, but have been watching the passionate discussion over recent days and am getting confused about what the original point was. Hence, I thought I'd join in the fray with my 2-cents worth... :-) Looking back at the archives this morning, I guess the original question was raised by Pawel regarding "slope", how it's defined, and used. I believe the general definition of the slope as being "the line joining two points" (or something similar), which someone mentioned, is pretty much my (2-dimensional) view as well. In my mind, "slope" in RFC3095 was meant to be the general term for the difference of a certain field, in consecutive packets. I further assumed that "slope" for the TS field was labelled TS_STRIDE, which my following text focuses upon. Specific to the TS field, there should be no need for the decompressor to determine any "slope"/TS_STRIDE at all, since the RFC states: ------ ... ... TS = TS_SCALED * TS_STRIDE + TS_OFFSET TS_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to the decompressor. The following algorithm is used: ... ... ------ indicating, to my understanding, that the decompressor shouldn't have to figure out "slope"/TS_STRIDE at all. This assumption is consistent with my perception of the overall ROHC algorithm, which makes the compressor out to be the intelligent entity, capable of huge feats of analysis in order to generate the optimally (small) header, while the decompressor is the "brute-force" entity, not very bright, but able to handle all packets thrown at it simply because it's provided all the necessary information by the smart guy. Someone also mentioned that TS_SCALED could look like: 2, 4, 6, 8, ... which I don't quite follow. If the compressor initially notes the delta between consecutive TSs is, say 320, it'll then explicitly convey TS_STRIDE as 320 to the decompressor. It subsequently then sends (say for a "well-behaved" RTP stream) UO-0 packets. If it later notes that there is a delta of 160, it needs to explicitly inform the decompressor that TS_STRIDE is 160, and subsequently send (say) UO-1-TS packets whenever a delta of 320 is observed. In this scenario, one delta of 160 would trigger the ROHC compressor to effectively generate the larger UO-1-TS packet stream, instead of a UO-0 stream. A smart compressor should probably notice this 2, 4, 6, 8, ... behaviour and perhaps re-evaluate/rectify it's value of TS_STRIDE. The point however is that the decompressor doesn't have to compute any slope or deltas or stride values for the TS, but is explicitly told what it is. While this has all been my personal interpretation the "slope" and TS_STRIDE is, I'm probably not alone in this since it should be also pointed out that this has not been an issue during the four interops taken place so far. While we never explicitly tested for this, it would almost certainly have popped up if there were situations where the compressor and decompressor were both independently trying to figure out deltas/slopes/strides for TS. Regards, vick +----------------------------------------------------+ Vicknesan AYADURAI Ericsson Research: IP Networks - Stockholm, Sweden Phone : +46 8 5087 8084 / Fax: +46 8 404 7020 +----------------------------------------------------+ On Thu, 1 Apr 2004 zhigang.c.liu@nokia.com wrote: > Lars-Erik, > > IMHO, we should clearly separate clarifying RFC 3095 from redefining it: > > - As I said, some text in RFC 3095 could have been written better (though it doesn't mean we haven't tried). The slope is one of them, in which case we should clarify what RFC 3095 intended to say. > - However, it is a completely different subject to say we do not need slope. If that is indeed the conclusion at the end of this discussion, we should define a new profile that excludes it. Mixing this with above is not a constructive approach. > > > So, what I want you all to think of is to stay open-minded, constructive, and be nice to each other. > > I cannot agree more. And here is my understanding - if I may - on how to do it in practice (I've been trying them myself): > > - Be conservative of what you say. Try best to verify the reasoning/observations/facts on which you make a claim. > - Everyone makes mistakes or has incorrect information. That's perfectly OK, but admit it. > - Being nice to others means reading their emails *carefully*, especially when you disagree. If you agree, say so. If not, give reasons. > - Be honest and straight to the point. > > BR, > Zhigang > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > > Sent: 01 April, 2004 06:32 AM > > To: Liu Zhigang.C (Nokia-NRC/Dallas); szym_paw@wp.pl; rohc@ietf.org > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > Timestamp field > > > > > > Zhigang, > > > > Thanks for pointing us to this discussion in the archives, it > > was useful reading at > > least for me. Unfortunately, this is not what is captured in > > 3095, and I think (at > > least) we all agree that there is a need to resolve this > > issue and make clarifications, > > although we have not yet figured out and agreed on exactly > > what to clarify and how. > > > > As has been noted before, there are a number of questions one > > may ask here: > > 1) What was discussed during the development of 3095 in 1999-2000? > > 2) What was 3095 intended to say, back in 2000? > > 3) What is 3095 really saying? > > 4) How can 3095 be interpreted? > > 5) Now 2004, which solution do we think makes most sense, technically? > > 6) Now 2004, which solution would make most sense if we consider 3)? > > 7) How do we realize 6) in the implementers guide to ensure > > interoperability? > > > > Kamal initially noted that it is unclear whether there really > > is a slope. When I took a > > first look at this issue by reading 3095 and the mail thread > > Kamal had pointed to, my > > observation was that 3095 is really not defining slopes. One > > would have to read a lot > > between the lines to find what Zhigang has explained was the > > intended meaning. I > > read the mails from Kristofer as if he also thinks there is > > no slope defined in 3095, > > but while Kamal believes there is a need to use implicitly > > updated slopes, Kristofer > > seems to be sceptical to that, although it is clear that also > > a solution without the > > implicit slopes means there are things that do not "compile", > > e.g. TS_STRIDE=0, > > which would have to be defined as it currently would result > > in a division by 0. > > > > We obviously are far from having answered questions 3-7, and > > even if Zhigang has > > explained much about 1-2, the history about why things are > > like they are and what > > was really intended at that time is still just background > > information, we need to be > > responsible, accept what we have, and find the proper > > solution considering what > > is really in 3095 today. It might also be so that our > > preferred solution today, even > > not considering 3095, will be different than what it was back > > in 2000. > > > > So, what I want you all to think of is to stay open-minded, > > constructive, and be > > nice to each other. We all have one single goal, to find the > > best technical and > > practical solutions and document them in an unambiguous way. > > It is not about > > being right or being wrong, it is about having the courage to > > ask stupid questions, > > and thereby getting the discussion forward. It is a good > > thing to say, "ok, you > > are right, I did not think about that", since that means we > > (as a group) has > > progressed and we have all learned something. > > > > Keep up discussing, constructively, as we have a problem to resolve! > > /L-E > > > > > > > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: den 31 mars 2004 20:19 > > > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > > Timestamp field > > > > > > > > > > The mail list discussions indicates that there were proposals > > > > to have such principles, but the discussions point in the > > > direction of > > > > giving up these ideas. > > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00953.html > > > > > > That is not true. > > > > > > If you read the emails below, you can see my proposal for the > > > decompressor > > > to learn slope was agreed upon. > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00934.html > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > ive/msg00935.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00952.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00957.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00960.html > > The email you mentioned above is a discussion on only one logic branch in my > proposal, i.e., whether the default-slope or the previous learned slope ("old_slope") > should be used by the decompressor when it receives only one context update. > It is NOT about the slope learning itself, which has already been agreed. In the > end, you can see that my proposal to use "old_slope" in the case of one "FO" > update was also agreed. > > BR, > Zhigang > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > +----------------------------------------------------+ Vicknesan AYADURAI Ericsson Research: IP Networks - Stockholm, Sweden Phone : +46 8 5087 8084 / Fax: +46 8 404 7020 +----------------------------------------------------+ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 16:58:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04754 for ; Fri, 2 Apr 2004 16:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wfr-0001Up-BQ for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lw3Q2005747 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wfq-0001UX-Lu for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04617 for ; Fri, 2 Apr 2004 16:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wfo-0002dy-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wc1-0001nI-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaF-0001Ld-01 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:15 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WWp-00083K-Bs for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:48:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VMY-0006Go-Si; Fri, 02 Apr 2004 15:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SBD-00078L-1s for rohc@optimus.ietf.org; Fri, 02 Apr 2004 12:10:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19034 for ; Fri, 2 Apr 2004 12:10:04 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9SBB-0006eM-00 for rohc@ietf.org; Fri, 02 Apr 2004 12:10:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9SAI-0006X3-00 for rohc@ietf.org; Fri, 02 Apr 2004 12:09:11 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B9S9k-0006PH-00 for rohc@ietf.org; Fri, 02 Apr 2004 12:08:41 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32H8U311756; Fri, 2 Apr 2004 20:08:30 +0300 (EET DST) X-Scanned: Fri, 2 Apr 2004 20:08:01 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i32H81PW011808; Fri, 2 Apr 2004 20:08:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00O3lV8p; Fri, 02 Apr 2004 20:08:00 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32H7ws07236; Fri, 2 Apr 2004 20:07:58 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 11:07:00 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Fri, 2 Apr 2004 12:06:58 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153734@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQYTHkoGyXLO9d0TiqpcbOJbgCHKAAf4Zxg To: , Cc: , , X-OriginalArrivalTime: 02 Apr 2004 17:07:00.0405 (UTC) FILETIME=[E9929E50:01C418D4] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ghyslain, > My take is that although it may seem as if there was an agreement in > older mail list discussions regarding the use of a "slope" and how to > "learn a slope",=20 It's not "may seem as if ...", it is the *fact*.=20 > I can not find that this resulted in any normative text > anywhere in 3095; therefore I tend to agree with Kristofer as to that > these concepts do not exist in 3095. As I mentioned earlier, we thought the text about function from SN to=20 non-SN field (described in section 3.4, 4.1, 4.3.1.3, 5.2.7, 5.7.7.1 and 5.7.7.2) covers the slope, which is a parameter of the function. Also, we defined default-slope so that it can reduce synchronization overhead in the cases where the default-slope fits the property of packet streams. That itself indicates that 3095 expects the compressor to use a different learned slope. Having said that, I do agree that RFC 3095 would be clearer if we had=20 included more text on slope (e.g. those email discussions). At that time, 3095 authors didn't think it's necessary. However, now that the question was raised, we should clarify it in implementation I-D,=20 which is setup to clarify ambiguous points. > Also, I wonder why this additional "learned slope" would help=20 > at all.=20 This has already been discussed and concluded in the old email=20 thread which I pointed out and you said you have looked through.=20 > If TS_STRIDE represents the expected increase in the timestamp value > between two RTP packets with consecutive sequence numbers,=20 > what is this slope trying to correct?=20 As I repeated many times (sorry for those who must be tired of this): 1) The definition of TS_STRIDE in section 2 is misleading. I've proposed text to clarify that. 2) TS_STRIDE is a scale factor, this is clear from section 4.5.3.=20 3) Scaling is a further optimization for TS, on top of the basic=20 compression scheme (SN to non-SN function, slope and offset, etc). Also clear from section 4.5.3. 4) Scaling is secondary to slope and offest. You can compress without scaling. Again, clearly stated in section 4.5.3 and other places in = 3095. > Also, regarding the following text in 5.5.1.2. >=20 > For example, in a typical case where the string > pattern has the form of non-SN-field =3D SN * slope + offset, one = ACK > is enough if the slope has been previously established by the > decompressor (i.e., only the new offset needs to be synchronized). > Otherwise, two ACKs are required since the decompressor needs two > headers to learn both the new slope and the new offset. In the SO > state, R-0* packets will be sent. >=20 > This, in my opinion, is informative text - it does not specify = anything. > Furthermore, I cannot find any normative equivalent or any normative > follow-up to this anywhere in 3095. The text further explains the concept of SN to non-SN function, which is the fundamental to RFC 3095 (and in fact those header compression RFCs preceding 3095). I used the word "for example" because not all SN=20 to non-SN functions are linear.=20 BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 2 17:00:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05379 for ; Fri, 2 Apr 2004 17:00:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Whk-0001wt-Es for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 17:00:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32M00MF007487 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 17:00:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Whk-0001wb-9M for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:00:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05248 for ; Fri, 2 Apr 2004 16:59:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Whi-00035x-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:59:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wdw-0002DE-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:56:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaZ-0001Tw-01 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:35 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WPA-0007gY-UB for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 16:40:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UTS-0007Xm-L2; Fri, 02 Apr 2004 14:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9RNl-0001uu-Vd for rohc@optimus.ietf.org; Fri, 02 Apr 2004 11:19:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16651 for ; Fri, 2 Apr 2004 11:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RNl-0006pI-00 for rohc@ietf.org; Fri, 02 Apr 2004 11:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RMq-0006iZ-00 for rohc@ietf.org; Fri, 02 Apr 2004 11:18:05 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1B9RMN-0006bf-00 for rohc@ietf.org; Fri, 02 Apr 2004 11:17:35 -0500 Received: from courrier.rennes.enst-bretagne.fr (f1-clust.rennes.enst-bretagne.fr [193.52.74.16]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i32GGvE12285; Fri, 2 Apr 2004 18:16:57 +0200 Received: from pcrsm7 ([193.52.74.238]) by courrier.rennes.enst-bretagne.fr (8.12.11/8.12.11/2004.01.01) with SMTP id i32GGvom017317; Fri, 2 Apr 2004 18:16:58 +0200 (MEST) Message-ID: <034901c418cd$ec8c5a80$ee4a34c1@rennes.enstbretagne.fr> From: "kamal deep singh" To: "Kristofer Sandlund" , , , , References: <7B5AF06E216CB74DA8A5960A3181B5B8153733@ajebe001.americas.nokia.com> Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Fri, 2 Apr 2004 18:16:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I would like to thank L-E and Zhigang for their encouraging words about the discussion and also for making our discussion more focussed. I agree with Zhigang Zhigang >>As I said, some text in RFC 3095 could have been written better (though it doesn't Zhigang >>mean we haven't tried). The slope is one of them, in which case we should clarify Zhigang >>what RFC 3095 intended to say. In addition I can only say that We can try to give only clarification and clarification would mean only clarification. That is Not adding any concept and not removing any concept to or from RFC. Adding any concept or removing any will result in new profile or new standard. I agree with L-E that we need to answer the questions which he has put forward. and as he again said that we need to all agree first on many points and have to figure out "on exactly what to clarify and how". I feel that a clarification on "how to compress TS" is needed. Please read below my clarification of compressing TS and I intend only to use the concepts "that are given in RFC" and nothing else. Though I ALSO "add examples" on how that concepts can be represented mathematically. Please provide your comments on the example algorithm below. In addition to what Zhigang has said, my clarification on TS compression is as follows. Please provide refinements. TS Compression ----------------- i) TS compression follows as quoted from RFC section 3.4 "The way ROHC RTP compression operates, then, is to first establish functions from SN to the other fields, and then reliably communicate the SN." One of the ways (there are other ways too) to represent this function is: TS = function(SN) or TS (scaled or unscaled) = SN*slope + offset; ii) offset and TS_OFFSET (in sec 4.5.3) are DIFFERENT as offset refers to above equation whereas TS_OFFSET refers to the following equation: TS = TS_SCALED*TS_STRIDE + TS_OFFSET which is used in TS scaled Encoding. Scaled encoding is one of the encoding methods like WLSB. Moreover scaled encoding is independent from compression and MAY or MAY NOT be used but, in contrast compression MUST be used ALWAYS. iii)So, to avoid the CONFUSION we will use offset2 as the word for representing offset from now and will leave TS_OFFSET (a parameter for scaling) as it is. iv)"One of the ways" or algorithms of implementing the TS compression is as follows: Example algorithm: COMPRESSOR SIDE ----------------------- 1. If Tsc = 0, then TS is compressed as is but, if Tsc = 1, then TS is first scaled by TS_STRIDE and then compressed. 2. If Tsc = 1 then TS_STRIDE needs to be communicated so that decompressor will know the TS_STRIDE value and side by side will calculate TS_OFFSET. Note that these above parameters are just used for scaling and descaling. 3. Compression. i) Compressor will send TS(scaled or absolute depending on Tsc) with SN. ii) As soon as Compressor is sure that decompressor has all the parameter for the pattern or the function TS = function(SN) ( i.e. TS = SN*slope + offset2 or (TS - TS_prev) = (SN - SN_prev)*slope), it will stop sending TS bits and will just send SN going to SO state. To quote from RFC "For transition from the FO to the SO state, the compressor should be confident that the decompressor has all parameters needed to decompress according to a fixed pattern." DECOMPRESSOR SIDE --------------------------- 1. Decompressor will use default value of slope as given in section 5.7 of RFC unless updated. Note: that default value of offset2 is not needed if we look at the equation in another way i.e. TS = TS_prev + slope* (delta SN); 2. If decompressor receives TS_STRIDE value then it will update TS_STRIDE and TS_OFFSET. 3. If it receives TS and SN then it updates the parameter of TS = function(SN). (Note one of the ways of representing this function is TS = SN*slope + offset2 and here decompressor will update slope and offset2) 4. If it receives only SN then it will calculate TS from TS = function(SN) 5. If Tsc = 1 then scaling was used. TS will be descaled by using TS_STRIDE and TS_OFFSET. i.e. by following: TS = TS(scaled resulting from 3 or 4.) * TS_STRIDE + TS_OFFSET regards, Kamal ----- Original Message ----- From: To: ; ; Sent: Friday, April 02, 2004 1:21 AM Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field > Lars-Erik, > > IMHO, we should clearly separate clarifying RFC 3095 from redefining it: > > - As I said, some text in RFC 3095 could have been written better (though it doesn't mean we haven't tried). The slope is one of them, in which case we should clarify what RFC 3095 intended to say. > - However, it is a completely different subject to say we do not need slope. If that is indeed the conclusion at the end of this discussion, we should define a new profile that excludes it. Mixing this with above is not a constructive approach. > > > So, what I want you all to think of is to stay open-minded, constructive, and be nice to each other. > > I cannot agree more. And here is my understanding - if I may - on how to do it in practice (I've been trying them myself): > > - Be conservative of what you say. Try best to verify the reasoning/observations/facts on which you make a claim. > - Everyone makes mistakes or has incorrect information. That's perfectly OK, but admit it. > - Being nice to others means reading their emails *carefully*, especially when you disagree. If you agree, say so. If not, give reasons. > - Be honest and straight to the point. > > BR, > Zhigang > > > -----Original Message----- > > From: ext Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > > Sent: 01 April, 2004 06:32 AM > > To: Liu Zhigang.C (Nokia-NRC/Dallas); szym_paw@wp.pl; rohc@ietf.org > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > Timestamp field > > > > > > Zhigang, > > > > Thanks for pointing us to this discussion in the archives, it > > was useful reading at > > least for me. Unfortunately, this is not what is captured in > > 3095, and I think (at > > least) we all agree that there is a need to resolve this > > issue and make clarifications, > > although we have not yet figured out and agreed on exactly > > what to clarify and how. > > > > As has been noted before, there are a number of questions one > > may ask here: > > 1) What was discussed during the development of 3095 in 1999-2000? > > 2) What was 3095 intended to say, back in 2000? > > 3) What is 3095 really saying? > > 4) How can 3095 be interpreted? > > 5) Now 2004, which solution do we think makes most sense, technically? > > 6) Now 2004, which solution would make most sense if we consider 3)? > > 7) How do we realize 6) in the implementers guide to ensure > > interoperability? > > > > Kamal initially noted that it is unclear whether there really > > is a slope. When I took a > > first look at this issue by reading 3095 and the mail thread > > Kamal had pointed to, my > > observation was that 3095 is really not defining slopes. One > > would have to read a lot > > between the lines to find what Zhigang has explained was the > > intended meaning. I > > read the mails from Kristofer as if he also thinks there is > > no slope defined in 3095, > > but while Kamal believes there is a need to use implicitly > > updated slopes, Kristofer > > seems to be sceptical to that, although it is clear that also > > a solution without the > > implicit slopes means there are things that do not "compile", > > e.g. TS_STRIDE=0, > > which would have to be defined as it currently would result > > in a division by 0. > > > > We obviously are far from having answered questions 3-7, and > > even if Zhigang has > > explained much about 1-2, the history about why things are > > like they are and what > > was really intended at that time is still just background > > information, we need to be > > responsible, accept what we have, and find the proper > > solution considering what > > is really in 3095 today. It might also be so that our > > preferred solution today, even > > not considering 3095, will be different than what it was back > > in 2000. > > > > So, what I want you all to think of is to stay open-minded, > > constructive, and be > > nice to each other. We all have one single goal, to find the > > best technical and > > practical solutions and document them in an unambiguous way. > > It is not about > > being right or being wrong, it is about having the courage to > > ask stupid questions, > > and thereby getting the discussion forward. It is a good > > thing to say, "ok, you > > are right, I did not think about that", since that means we > > (as a group) has > > progressed and we have all learned something. > > > > Keep up discussing, constructively, as we have a problem to resolve! > > /L-E > > > > > > > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: den 31 mars 2004 20:19 > > > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > > Timestamp field > > > > > > > > > > The mail list discussions indicates that there were proposals > > > > to have such principles, but the discussions point in the > > > direction of > > > > giving up these ideas. > > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00953.html > > > > > > That is not true. > > > > > > If you read the emails below, you can see my proposal for the > > > decompressor > > > to learn slope was agreed upon. > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00934.html > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > ive/msg00935.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00952.h tml > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.h tml > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00957.h tml > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00960.h tml > > The email you mentioned above is a discussion on only one logic branch in my > proposal, i.e., whether the default-slope or the previous learned slope ("old_slope") > should be used by the decompressor when it receives only one context update. > It is NOT about the slope learning itself, which has already been agreed. In the > end, you can see that my proposal to use "old_slope" in the case of one "FO" > update was also agreed. > > BR, > 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 exim@www1.ietf.org Fri Apr 2 17:25:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09295 for ; Fri, 2 Apr 2004 17:25:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6I-00027D-5y for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 17:25:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MPMLD008132 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 17:25:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X6H-000271-RR for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:25:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09085 for ; Fri, 2 Apr 2004 17:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X6F-0000is-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 17:25:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X1u-0007cr-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 17:20:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WyC-0006bI-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 17:17:00 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WoX-0000Jo-NQ for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 17:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WoX-0004R7-Vr; Fri, 02 Apr 2004 17:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wnu-00041o-BT for rohc@optimus.ietf.org; Fri, 02 Apr 2004 17:06:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06163 for ; Fri, 2 Apr 2004 17:06:19 -0500 (EST) From: kd.singh@enst-bretagne.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wns-0004OL-00 for rohc@ietf.org; Fri, 02 Apr 2004 17:06:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wke-0003nK-00 for rohc@ietf.org; Fri, 02 Apr 2004 17:03:01 -0500 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by ietf-mx with esmtp (Exim 4.12) id 1B9WhY-0002y3-00 for rohc@ietf.org; Fri, 02 Apr 2004 16:59:48 -0500 Received: from digemer.enst-bretagne.fr (digemer.enst-bretagne.fr [192.44.75.206]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i32Lx9Z30528; Fri, 2 Apr 2004 23:59:09 +0200 Received: (from www@localhost) by digemer.enst-bretagne.fr (8.11.6/8.11.6) id i32Lx8x19631; Fri, 2 Apr 2004 23:59:08 +0200 (MET DST) Received: from d80-170-15-245.cust.tele2.fr (d80-170-15-245.cust.tele2.fr [80.170.15.245]) by diogel.enst-bretagne.fr (IMP) with HTTP for ; Fri, 2 Apr 2004 23:59:08 +0200 Message-ID: <1080943148.406de22c529e1@diogel.enst-bretagne.fr> Date: Fri, 2 Apr 2004 23:59:08 +0200 To: zhigang.c.liu@nokia.com Cc: Ghyslain.Pelletier@ericsson.com, rohc@ietf.org, lars-erik.jonsson@ericsson.com, szym_paw@wp.pl, kristofer.sandlund@effnet.com Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field References: <7B5AF06E216CB74DA8A5960A3181B5B8153734@ajebe001.americas.nokia.com> In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B8153734@ajebe001.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) /ENSTB X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Content-Transfer-Encoding: 8bit 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit hi all, I agree with Zhigang. Instead of opposing his concepts totally, we should only provide refinements if any. In case of disagreement, it will be helpful if one tells the points with which one disagrees and "why so". regards, Kamal Quoting zhigang.c.liu@nokia.com: > Ghyslain, > > > My take is that although it may seem as if there was an agreement in > > older mail list discussions regarding the use of a "slope" and how to > > "learn a slope", > > It's not "may seem as if ...", it is the *fact*. > > > I can not find that this resulted in any normative text > > anywhere in 3095; therefore I tend to agree with Kristofer as to that > > these concepts do not exist in 3095. > > As I mentioned earlier, we thought the text about function from SN to > non-SN field (described in section 3.4, 4.1, 4.3.1.3, 5.2.7, 5.7.7.1 > and 5.7.7.2) covers the slope, which is a parameter of the function. > Also, we defined default-slope so that it can reduce synchronization > overhead in the cases where the default-slope fits the property of > packet streams. That itself indicates that 3095 expects the compressor > to use a different learned slope. > > Having said that, I do agree that RFC 3095 would be clearer if we had > included more text on slope (e.g. those email discussions). At that > time, 3095 authors didn't think it's necessary. However, now that > the question was raised, we should clarify it in implementation I-D, > which is setup to clarify ambiguous points. > > > Also, I wonder why this additional "learned slope" would help > > at all. > > This has already been discussed and concluded in the old email > thread which I pointed out and you said you have looked through. > > > If TS_STRIDE represents the expected increase in the timestamp value > > between two RTP packets with consecutive sequence numbers, > > what is this slope trying to correct? > > As I repeated many times (sorry for those who must be tired of this): > > 1) The definition of TS_STRIDE in section 2 is misleading. I've proposed > text to clarify that. > 2) TS_STRIDE is a scale factor, this is clear from section 4.5.3. > 3) Scaling is a further optimization for TS, on top of the basic > compression scheme (SN to non-SN function, slope and offset, etc). > Also clear from section 4.5.3. > 4) Scaling is secondary to slope and offest. You can compress without > scaling. Again, clearly stated in section 4.5.3 and other places in > 3095. > > > Also, regarding the following text in 5.5.1.2. > > > > For example, in a typical case where the string > > pattern has the form of non-SN-field = SN * slope + offset, one ACK > > is enough if the slope has been previously established by the > > decompressor (i.e., only the new offset needs to be synchronized). > > Otherwise, two ACKs are required since the decompressor needs two > > headers to learn both the new slope and the new offset. In the SO > > state, R-0* packets will be sent. > > > > This, in my opinion, is informative text - it does not specify > anything. > > Furthermore, I cannot find any normative equivalent or any normative > > follow-up to this anywhere in 3095. > > The text further explains the concept of SN to non-SN function, which > is the fundamental to RFC 3095 (and in fact those header compression > RFCs preceding 3095). I used the word "for example" because not all SN > to non-SN functions are linear. > > BR, > 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 exim@www1.ietf.org Fri Apr 2 19:32:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15339 for ; Fri, 2 Apr 2004 19:32:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z5A-0004Fn-7P for rohc-archive@odin.ietf.org; Fri, 02 Apr 2004 19:32:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i330WKX4016351 for rohc-archive@odin.ietf.org; Fri, 2 Apr 2004 19:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z5A-0004Fd-1X for rohc-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 19:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15318 for ; Fri, 2 Apr 2004 19:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z58-0002Wq-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 19:32:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Z4F-0002Q1-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 19:31:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z3s-0002Ih-00 for rohc-web-archive@ietf.org; Fri, 02 Apr 2004 19:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z3s-0003Oh-CQ; Fri, 02 Apr 2004 19:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z3A-00038D-Tm for rohc@optimus.ietf.org; Fri, 02 Apr 2004 19:30:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15278 for ; Fri, 2 Apr 2004 19:30:15 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z38-0002HE-00 for rohc@ietf.org; Fri, 02 Apr 2004 19:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Z2A-0002AW-00 for rohc@ietf.org; Fri, 02 Apr 2004 19:29:15 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z1U-00024F-00 for rohc@ietf.org; Fri, 02 Apr 2004 19:28:32 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i330SRF28938; Sat, 3 Apr 2004 03:28:27 +0300 (EET DST) X-Scanned: Sat, 3 Apr 2004 03:27:54 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i330Rsum031189; Sat, 3 Apr 2004 03:27:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00yty0DU; Sat, 03 Apr 2004 03:27:52 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i330Ros09568; Sat, 3 Apr 2004 03:27:50 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 18:27:49 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Fri, 2 Apr 2004 19:27:48 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153737@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQYgG5GAl73srOeTMOQOUEC1D3W2AAc/lIA To: , , Cc: , X-OriginalArrivalTime: 03 Apr 2004 00:27:49.0439 (UTC) FILETIME=[7E6CECF0:01C41912] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lars-Erik, Please see comments below. BR, Zhigang > On the other hand, why should it not be possible to have a scaling > FACTOR of 0.=20 Because that is not what section 4.5.3 says. =20 > to me the video example > seems to be a reasonable argument for enforcing the TS_STRIDE > definition from section 2, and thus allow it to be 0. Why did you say the video example is an argument for enforcing the TS_STRIDE definition in section 2? Could you please elaborate? > This proposal still does not address the original concern about > the concept of slopes not at all being defined in 3095. That is > the major issue here, I think. OK. If the meaning of slope is not obvious to you, why don't we=20 have a clarification as follows? I also added other clarifications to address other confusions I've seen so far. Now I'm risk of=20 being too verbose, but it seems the only way to avoid confusion.=20 Comments? ------------------------------------------------------------ As it is described in section 4.5.3 and other places in RFC 3095, TS_STRIDE is the factor by which an RTP Timestamp is downscaled before compression. Obviously, it cannot be 0 (zero). The wording of TS_STRIDE definition in section 2 is confusing and may be incorrectly interpreted as TS_STRIDE is always equal to the increase in TS value between two RTP packets with consecutive sequence number. This is not the intent of the specification. It is the compressor that decides whether TS=20 scaling should be used and if yes, what is the best value of=20 TS_STRIDE. See section 4.5.3 for information. How this is done=20 is an implementation issue. However, an implementation must follow=20 section 4.5.3, 4.5.6 and 5.7 on how to initialize, encode, and=20 synchronize TS_STRIDE between the compressor and decompressor. Note: TS_STRIDE is not the same as slope described in section=20 5.5.1.2 and 5.7. Here, slope has the general meaning in mathematics. Namely, slope(X) equals the change of a non-SN field X between two packets divided by the change of SN field between the same two packets. It is one of the two parameters (the other one being offset) that define a linear function from SN to field X. The concept can also be visualized as a line, with SN being the horizontal coordinate and the field X being the vertical=20 coordinate. For TS, this applies regardless whether it is scaled=20 or not. In case the TS is scaled, the linear function (or equivalently its slope and offset) is from SN to the TS_SCALED. Note: it should be clear from section 4.5.3 that when scale is used for TS, two steps are involved: 1) downscale of the=20 original TS to TS_SCALED; and 2) compression of TS_SCALED. The decompressor follows the reverse procedure with two steps. Following are two examples to further illustrate this. Example 1 (audio stream with TS_STRIDE =3D 160): <------ String 1 ------> <-- String 2 ---> SN 11 12 13 14 ... 60 61 62 63 ... TS 200 360 420 580 ... 8040 16040 16200 16360 ...=20 TS_SCALED 1 2 3 4 ... 50 100 101 102 ... TS_OFFSET 40 40 40 40 40 40 40 40 ... slope <-------- 1 ----------> <----- 1 -------> offset <-------- (-10)--------> <----- (39) ----> Example 2 (video stream with TS_STRIDE =3D 3000): <------ String 1 ------> <-- String 2 ---> SN 11 12 13 ... 25 26 27 28 ... TS 4000 4000 4000 ... 4000 7000 7000 7000 ...=20 TS_SCALED 1 1 1 ... 1 2 2 2 ... TS_OFFSET 1000 1000 1000 ... 1000 1000 1000 1000 ...=20 slope <-------- 0 ----------> <----- 0 -------> offset <--------- 1 ----------> <----- 2 -------> Note: the default-slope(X) specified in section 5.7 is to be used=20 by the compressor and decompressor to initialize the slope of the=20 linear function from SN to field X. This is an optimization to=20 save synchronization overhead at the beginning of an RTP packet=20 stream. Namely, if the actual slope of X in the first string matches=20 the default-slope(X), the compressor can enter SO state and send=20 Type 0 packets once it is confident that one - instead of two in=20 the normal case - packet carrying field(X) has been correctly=20 decompressed by the decompressor. This is enough for the decompressor to determine the other parameter, i.e. offset, for the linear function from SN to X. After the fist string, the decompressor will update the linear function from SN to X depending on how many packets carrying field(X) have been correctly decompressed. If the number is 1, the decompressor will assume the new slope(X) =3D previously established slope(X), and the update offset(X) based on field(X) received. If the=20 number is 2, the decompressor will update both slope(X) and offset(X). Note that the decompressor always uses the latest received packet(s) to update the function. For instance, in Example 1 above, the compressor can enter SO state once it is confident that one packet carrying TS has been correctly = decompressed=20 by the decompressor. This is because the actual slope of TS (after = scaling) equals the default-slope. Of course, the TS_STRIDE =3D 3000 must be=20 synchronized also, which can be done within the same packet.=20 Example 2 is different. The actual slope (=3D 0) of scaled TS does not = equal the default-slope (=3D 1). Therefore, during the first string of the = packet=20 stream, the compressor has to ensure that two packets carrying TS info have been correctly decompressed by the decompressor. This allows the decompressor to establish both the slope and offset for function from SN to scaled TS. However, for subsequent strings, only one correctly decompressed packet is needed since slope =3D 0 has already been = established and thus can be reused. -------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sat Apr 3 07:17:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17480 for ; Sat, 3 Apr 2004 07:17:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9k4u-0002je-Em for rohc-archive@odin.ietf.org; Sat, 03 Apr 2004 07:16:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33CGmao010513 for rohc-archive@odin.ietf.org; Sat, 3 Apr 2004 07:16:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9k4u-0002jU-AN for rohc-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 07:16:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17465 for ; Sat, 3 Apr 2004 07:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9k4t-0003Ze-00 for rohc-web-archive@ietf.org; Sat, 03 Apr 2004 07:16:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9k40-0003Rp-00 for rohc-web-archive@ietf.org; Sat, 03 Apr 2004 07:15:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9k3B-0003KU-00 for rohc-web-archive@ietf.org; Sat, 03 Apr 2004 07:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9k3B-0001kj-2s; Sat, 03 Apr 2004 07:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9k2r-0001Yr-UW for rohc@optimus.ietf.org; Sat, 03 Apr 2004 07:14:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17402 for ; Sat, 3 Apr 2004 07:14:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9k2r-0003HJ-00 for rohc@ietf.org; Sat, 03 Apr 2004 07:14:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9k1t-00039L-00 for rohc@ietf.org; Sat, 03 Apr 2004 07:13:41 -0500 Received: from mailrelay2.lntinfotech.com ([203.199.54.34]) by ietf-mx with esmtp (Exim 4.12) id 1B9k0v-0002wT-00 for rohc@ietf.org; Sat, 03 Apr 2004 07:12:41 -0500 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004040317415712:8671 ; Sat, 3 Apr 2004 17:41:57 +0530 Subject: Re: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 To: "Pawel Szymanski" , rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kavitha KR" Date: Sat, 3 Apr 2004 17:39:48 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 04/03/2004 05:39:49 PM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/03/2004 05:41:57 PM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/03/2004 05:42:41 PM, Serialize complete at 04/03/2004 05:42:41 PM Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pawel, >I've run into a problem with UOR-2 packet Tsc field equal to 1 Extensi= on 3 and with TS_STRIDE. Is it legal to send such packets ? As I have understood, while using UOR-2 packets with ext 3, we can send only one of the following fields in that packet. (1) TS (Scaled or unscaled) (2) TS_STRIDE (3) TIME_STRIDE All the above three fields are "variable-octet" fields and hence each of the above field is to be encoded according to section 4.5.6. That means the TS bits in the base header will indic= ate the the number of octets of whichever field present in the header. Then, if TSS bit set to 1, it the TS_STRIDE field's number of octets that had been indicated in the base header. Similarly, when TIME_STRIDE is to be sent, TIS is set to 1. When TS is to be sent, both TSS & TIS cannot be set to 1. Tsc can be 1 o 0 , depending on whether TS is scaled or unscaled. > If Yes, how decompressor should calculate new TS_OFFSET to decompress= the scaled TS value compressed in the packet ? Probably you should be using IR-DYN packets to transmit the absolute va= lue of TS as well as the TS_STRIDE together. Regards, Kavitha = =20 "Pawel Szymanski" = =20 To: rohc@ietf.org = =20 Sent by: cc: = =20 rohc-admin@ietf.o Subject: [rohc] UOR-2 p= ackets with TS_STRIDE and Tsc equal to 1 in Extension 3 =20 rg = =20 = =20 = =20 04/01/2004 07:36 = =20 PM = =20 = =20 = =20 Hi, I've run into a problem with UOR-2 packet Tsc field equal to 1 Extensio= n 3 and with TS_STRIDE. Is it legal to send such packets ? If Yes, how decompressor should calculate new TS_OFFSET to decompress t= he scaled TS value compressed in the packet ? Should it calculate the new TS_OFFSET using the reference timestamp val= ue (i.e. the value sent in the last successfully decompressed packet containing = TS field) ? Another option is to calculate the new TS_OFFSET using the tiemstamp va= lue sent in the last decompressed packet (which can be diffrent from the referen= ce timestamp value) ? Or should decompressor use the old TS_OFFSET to decompress the received= packet ? Best Regards Pawel ---------------------------------------------------- Co przyniesie w tym roku Zaj=B1c? Chcesz mu pom=F3c? Kicnij si=EA na wielkanocne zakupy.wp.pl http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fzakupy.wp.pl%2Fwielkanoc.html&sid= =3D155 _______________________________________________ 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 exim@www1.ietf.org Sun Apr 4 23:55:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24863 for ; Sun, 4 Apr 2004 23:55:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALCU-0003mK-QM for rohc-archive@odin.ietf.org; Sun, 04 Apr 2004 23:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i353t6SW014525 for rohc-archive@odin.ietf.org; Sun, 4 Apr 2004 23:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALCR-0003m7-SH for rohc-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 23:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24848 for ; Sun, 4 Apr 2004 23:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BALCP-0007NY-00 for rohc-web-archive@ietf.org; Sun, 04 Apr 2004 23:55:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BALBR-0007H4-00 for rohc-web-archive@ietf.org; Sun, 04 Apr 2004 23:54:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BALAS-0007Ag-00 for rohc-web-archive@ietf.org; Sun, 04 Apr 2004 23:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BALAS-0003aP-MS; Sun, 04 Apr 2004 23:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAL9c-0003Qv-AS for rohc@optimus.ietf.org; Sun, 04 Apr 2004 23:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24826 for ; Sun, 4 Apr 2004 23:52:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAL9a-00076j-00 for rohc@ietf.org; Sun, 04 Apr 2004 23:52:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAL8k-00071G-00 for rohc@ietf.org; Sun, 04 Apr 2004 23:51:14 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BAL8E-0006pM-00 for rohc@ietf.org; Sun, 04 Apr 2004 23:50:43 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVO00L1JIFWOV@mta0.huawei.com> for rohc@ietf.org; Mon, 05 Apr 2004 11:45:34 +0800 (CST) Date: Mon, 05 Apr 2004 09:18:27 +0530 From: suman To: rohc@ietf.org Message-id: <005b01c41ac0$db3b0de0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_OW/ZNjo9NxpaCJL4Y22s+g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] doubt regarding shared compression in rfc 3321 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_OW/ZNjo9NxpaCJL4Y22s+g) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Section 5.2 of rfc 3321 speaks about Shared Compression as follows. 1. compressor 1 saves the state M which is the uncompressed version of the current message compressed and sent. 2. At the decompressor 2 in the receiving endpoint, SHA-1 instruction is used to calculate the state-id for state M. I am not able to figure out, over which piece of information should the SHA-1 instruction be executed ??? Could anybody clarify my doubt in this regard, thanks suman --Boundary_(ID_OW/ZNjo9NxpaCJL4Y22s+g) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Section 5.2 of rfc 3321 speaks about Shared Compression as follows.
 
1. compressor 1 saves the state M which is the uncompressed version of the current message
compressed and sent.
 
2. At the decompressor 2 in the receiving endpoint, SHA-1 instruction is used to calculate the
state-id for state M.
 
I am not able to figure out, over which piece of information should the SHA-1 instruction be executed ???
 
Could anybody clarify my doubt in this regard,
 
thanks
suman
 
 
--Boundary_(ID_OW/ZNjo9NxpaCJL4Y22s+g)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 04:20:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16780 for ; Mon, 5 Apr 2004 04:20:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKU-0001Oh-NE for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 04:19:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i358JcAW005367 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 04:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKU-0001OU-JF for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 04:19:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16686 for ; Mon, 5 Apr 2004 04:19:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPKR-000596-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:19:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPJJ-0004wM-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:18:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPID-0004ff-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:17:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPI3-0000c5-Hg; Mon, 05 Apr 2004 04:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAOJF-0007hm-5i for rohc@optimus.ietf.org; Mon, 05 Apr 2004 03:14:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14832 for ; Mon, 5 Apr 2004 03:14:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAOJD-0005sv-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:14:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAOIL-0005ms-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:13:22 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BAOHQ-0005gu-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:12:24 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i357COPA016912 for ; Mon, 5 Apr 2004 09:12:24 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 09:12:24 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <212YTTFT>; Mon, 5 Apr 2004 09:12:24 +0200 Message-ID: From: "Hans Hannu (LU/EAB)" To: "'suman'" , rohc@ietf.org Subject: RE: [rohc] doubt regarding shared compression in rfc 3321 Date: Mon, 5 Apr 2004 09:12:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 07:12:24.0723 (UTC) FILETIME=[5872CE30:01C41ADD] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, >From RFC 3320, END-MESSAGE instruction, page 52. "The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the byte string formed by concatenating the state_length, state_address, state_instruction, minimum_access_length and state_value (in the order given). This is the state_identifier." >From RFC 3321, page 9. "To make use of shared compression a compressing endpoint saves the uncompressed version of the compressed message as a state (shared state). As described in Section 2 the reference to a shared state is referred to as shared_state_id. The shared state's parameters state_address and state_instruction must be set to zero. The state_retention_priority must be set to 65535," state_length is known from the decompressed message. state_address is zero state_instruction is zero Start of with minimum_access_length equal the length as in the advertised list of states. state_value is the decompressed message BR, /Hans Hannu >-----Original Message----- >From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman >Sent: den 5 april 2004 05:48 >To: rohc@ietf.org >Subject: [rohc] doubt regarding shared compression in rfc 3321 > > >Section 5.2 of rfc 3321 speaks about Shared Compression as follows. > >1. compressor 1 saves the state M which is the uncompressed version of the current message >compressed and sent. > >2. At the decompressor 2 in the receiving endpoint, SHA-1 instruction is used to calculate the >state-id for state M. > >I am not able to figure out, over which piece of information should the SHA-1 instruction be executed ??? > >Could anybody clarify my doubt in this regard, > > >thanks >suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 04:20:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16797 for ; Mon, 5 Apr 2004 04:20:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKS-0001ON-Kn for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 04:19:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i358Jaax005352 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 04:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKS-0001OF-BJ for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 04:19:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16683 for ; Mon, 5 Apr 2004 04:19:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPKP-00058t-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPJH-0004w2-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:18:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPIB-0004ke-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:17:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPIA-0000fm-O9; Mon, 05 Apr 2004 04:17:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAOoK-0004Cn-IK for rohc@optimus.ietf.org; Mon, 05 Apr 2004 03:46:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15786 for ; Mon, 5 Apr 2004 03:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAOoI-0001TG-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:46:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAOnZ-0001Mr-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:45:37 -0400 Received: from mailrelay2.lntinfotech.com ([203.199.54.34]) by ietf-mx with esmtp (Exim 4.12) id 1BAOmk-0001DF-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:44:47 -0400 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004040513141421:1548 ; Mon, 5 Apr 2004 13:14:14 +0530 Subject: Re: [rohc] Protocol Convergence Layer for header compression negotiation To: aniruddha.kulkarni@effnet.com, rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kavitha KR" Date: Mon, 5 Apr 2004 13:12:04 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 04/05/2004 01:12:06 PM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/05/2004 01:14:14 PM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/05/2004 01:14:48 PM, Serialize complete at 04/05/2004 01:14:48 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Anirudh, Your proposal of a standard Protocol Convergence Layer (PCL) for ROHC is interesting. I have a few comments. General protocol convergence layer requirements: Further extending your ideas, let me try to list down, what are the requirements of such a layer. Basically this layer should take care of all the configuration & negotiation parameters for the compression protocol and adapt the frames to the link layer below. Control Plane (1) Header Compression negotiation with peer ROHC. (2) Configuring the various (MIB) ROHC protocol parameters. (as in PDCP specs) User Plane (3) Framing (4) Segmentation (if not available in link layer) (5) Buffering to handle packet reordering (6) Context relocation to handle mobility (PDCP specs) (7) Detection of packet losses (PDCP seq numbering) Existing Scenario As you had also noted, this functionalities are covered somehow in the existing networks through proprietary solutions. To consolidate a few, (1) ROHC o PPP for PPP links. (2) PDCP protocol supports ROHC in case of UMTS networks, (3) In case of 3GPP2 CDMA HRU-HRL concepts are applied, where HRL is an adaptation layer almost equivalent, to what you have suggested,. But there HRL takes care of user plane requirements, PPP itself takes care of signalling plane requirements. (4) 802.16 & Bluetooth have their own header compression schemes. (5) 802.11 is a potential candidate. There was a proposal for ROHC o WEM (Wireless Ethernet Medium) suggested & expired. (6) MANET is yet another potential candidate, and the draft for ROHC o MANET has been recently released. Questions (1) Is it really possible to standardize it at this stage? (2) Has any work been done to compare the efficienies of ROHC protocol and the header compressions followed in 802.16 or bluetooth? (If ROHC gets to be proved as a better one, on these networks, it could pave a way for standardization) Regards Kavitha. This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Thanks _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 04:20:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16814 for ; Mon, 5 Apr 2004 04:20:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKd-0001Pe-Co for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 04:19:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i358JlKp005426 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 04:19:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKd-0001PR-0e for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 04:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16706 for ; Mon, 5 Apr 2004 04:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPKa-00059w-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:19:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPJR-0004xU-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:18:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPIJ-0004kg-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 04:17:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPIB-0000gE-8n; Mon, 05 Apr 2004 04:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAOpI-0004Ef-IF for rohc@optimus.ietf.org; Mon, 05 Apr 2004 03:47:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15808 for ; Mon, 5 Apr 2004 03:47:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAOpG-0001aL-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:47:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAOoK-0001Tw-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:46:25 -0400 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1BAOnw-0001Lj-00 for rohc@ietf.org; Mon, 05 Apr 2004 03:46:00 -0400 Received: (wp-smtpd smtp.wp.pl 22977 invoked from network); 5 Apr 2004 09:45:30 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 5 Apr 2004 09:45:30 +0200 Date: Mon, 5 Apr 2004 09:45:30 +0200 From: "Pawel Szymanski" To: Kavitha KR Cc: rohc@ietf.org Subject: Re: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 Message-ID: <40710e9a246df@wp.pl> References: In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.173.14 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA15809 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kavitha, I can't see why UOR-2* packet can contain either TS or TS_STRIDE. I think= UOR- 2* packets can carry both TS and TS_STRIDE at the same time.=20 For example the following UOR-2 packet format is possible: Base UOR-2 header +---+---+---+---+---+---+---+---+ | 1 1 0 | TS | +=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D+=3D=3D=3D= +=3D=3D=3D+ |TS | M | SN | +---+---+---+---+---+---+---+---+ |X=3D1| CRC | +---+---+---+---+---+---+---+---+ Extension 3 +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 1 | S=3D0 |R-TS=3D0|Tsc=3D1| I=3D0 |ip=3D0 |rtp=3D1| = =20 +-----+-----+-----+-----+-----+-----+-----+-----+ RTP header flags and fields ..... ..... ..... ..... ..... ..... ..... ..... | Mode |R-PT =3D0| M | R-X |CSRC=3D0 | TSS=3D1 | TIS=3D1 | ..... ..... ..... ..... ..... ..... ..... ..... / TS_STRIDE / 1-4 oct if TSS =3D = 1 ..... ..... ..... ..... ..... ..... ..... .... In fact, I have no doubt what decompressor should do when it receives UOR= -2*=20 with TS is unscaled form (i.e. Tsc =3D 0) and TS_STRIDE present (i.e. TSS= =3D 1).=20 But I still don't know what is correct decompressor's behaviour in case i= t=20 receives UOR-2* packet with scaled TS (i.e. Tsc =3D 1) and TS_STRIDE pres= ent=20 (i.e. TSS =3D1). How it can calculate TS_OFFSET needed to decompress the = received=20 scaled TS value ? Note that the following text from RFC 3095 section 5.7.5 page 85: " Tsc: Tsc =3D 0 indicates that TS is not scaled; Tsc =3D 1 indicates that TS is scaled according to section 4.5.3, using value(TS_STRIDE). " For me the fact that the TS is scaled using "value(TS_STRIDE)" and not co= ntext (TS_STRIDE) suggests that the TS can be scaled using TS_STRIDE sent in th= e same=20 packet as the TS field.=20 Regards Pawel >=20 > Hi Pawel, >=20 > >I've run into a problem with UOR-2 packet Tsc field equal to 1 Extensi= on 3 > and > with TS_STRIDE. Is it legal to send such packets ? >=20 > As I have understood, while using UOR-2 packets with ext 3, > we can send only one of the following fields in that packet. >=20 > (1) TS (Scaled or unscaled) > (2) TS_STRIDE > (3) TIME_STRIDE >=20 > All the above three fields are "variable-octet" fields and hence > each of the above field is to be encoded according > to section 4.5.6. That means the TS bits in the base header will indic= ate > the > the number of octets of whichever field present in the header. >=20 > Then, if TSS bit set to 1, it the TS_STRIDE field's number of > octets that had been indicated in the base header. >=20 > Similarly, when TIME_STRIDE is to be sent, TIS is set to 1. >=20 > When TS is to be sent, both TSS & TIS cannot be set to 1. > Tsc can be 1 o 0 , depending on whether TS is scaled or unscaled. >=20 > > If Yes, how decompressor should calculate new TS_OFFSET to decompress= the >=20 > scaled TS value compressed in the packet ? >=20 > Probably you should be using IR-DYN packets to transmit the absolute va= lue > of TS as well as the > TS_STRIDE together. >=20 > Regards, > Kavitha >=20 >=20 >=20 >=20 > = =20 =20 > "Pawel=20 Szymanski" = =20 =20 > To: =20 rohc@ietf.org = =20 > Sent by: =20 cc: = =20 =20 > rohc-admin@ietf.o Subject: [rohc] UOR-2 p= ackets=20 with TS_STRIDE and Tsc equal to 1 in Extension 3 =20 > =20 rg = =20 =20 > = =20 =20 > = =20 =20 > 04/01/2004=20 07:36 = =20 =20 > =20 PM = =20 =20 > = =20 =20 > = =20 =20 >=20 >=20 >=20 >=20 > Hi, >=20 > I've run into a problem with UOR-2 packet Tsc field equal to 1 Extensio= n 3 > and > with TS_STRIDE. Is it legal to send such packets ? >=20 > If Yes, how decompressor should calculate new TS_OFFSET to decompress t= he > scaled TS value compressed in the packet ? > Should it calculate the new TS_OFFSET using the reference timestamp val= ue > (i.e. > the value sent in the last successfully decompressed packet containing = TS > field) ? >=20 > Another option is to calculate the new TS_OFFSET using the tiemstamp va= lue > sent > in the last decompressed packet (which can be diffrent from the referen= ce > timestamp value) ? >=20 > Or should decompressor use the old TS_OFFSET to decompress the received > packet ? >=20 > Best Regards >=20 > Pawel >=20 > ---------------------------------------------------- > Co przyniesie w tym roku Zaj=B1c? Chcesz mu pom=F3c? > Kicnij si=EA na wielkanocne zakupy.wp.pl > http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fzakupy.wp.pl%2Fwielkanoc.html&sid= =3D155 >=20 >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 ---------------------------------------------------- Fani zespo=B3u Metallica =B3=B1czcie si=EA! Do=B3=B1czamy do majowego kon= certu! http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.html%3Fidn%3= D829&sid=3D157 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 06:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22431 for ; Mon, 5 Apr 2004 06:48:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARe9-0006d4-Js for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 06:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Am5SF025482 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 06:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARe9-0006cv-Eq for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 06:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22311 for ; Mon, 5 Apr 2004 06:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BARe5-0007Lt-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 06:48:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BARcZ-000725-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 06:46:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BARam-0006Yn-01 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 06:44:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BARLz-0001IE-4Z for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 06:29:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARLp-0002oO-FL; Mon, 05 Apr 2004 06:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAQKT-00025h-13 for rohc@optimus.ietf.org; Mon, 05 Apr 2004 05:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18825 for ; Mon, 5 Apr 2004 05:23:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAQKP-0004lr-00 for rohc@ietf.org; Mon, 05 Apr 2004 05:23:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAQJQ-0004eS-00 for rohc@ietf.org; Mon, 05 Apr 2004 05:22:37 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BAQIq-0004FT-00 for rohc@ietf.org; Mon, 05 Apr 2004 05:22:03 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVO004A5XDM85@mta0.huawei.com> for rohc@ietf.org; Mon, 05 Apr 2004 17:08:15 +0800 (CST) Date: Mon, 05 Apr 2004 14:41:06 +0530 From: suman Subject: Re: [rohc] doubt regarding shared compression in rfc 3321 To: "Hans Hannu (LU/EAB)" , rohc@ietf.org Message-id: <002001c41aed$edeab5d0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT My doubt is not regarding the usage of SHA-1 hash instruction. I am reiterating my question again.. RFC 3321 speaks about shared compression procedures as follows: (1): Compressor 1 saves e.g., state(M), which is the uncompressed version of the current application message to be compressed and sent. (2): The UDVM bytecode to indicate the presence of state(M) at endpoint 1 is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): The SHA-1 instruction is used at endpoint 2 to calculate the shared_state_id for state(M). The indication is passed to the state handler, by placing the shared identifier at the location of the "returned SigComp parameters" [SIGCOMP]. The location of the "returned SigComp parameters" is given to the state handler using the END-MESSAGE instruction. (4): If endpoint 2 uses shared compression, it compares the state identifier values in the "returned SigComp parameters" information with the value it has calculated for the current decompressed message received from endpoint 1. If there is a match then endpoint 2 uses the shared state together with the state it would normally use if shared compression is not supported to compress the next message. (5): The UDVM bytecode that will use the shared state (state(M)) in the decompression process at decompressor 1 is either carried in the compressed message, or can be retrieved by decompressor 1 from a state already saved at endpoint 1. I am not able to figure out the difference between step 3 and step4. Step 3 says that the shared_state_id is calculated using SHA-1 and stored in location of "returned Sigcomp Parameters" before passed to state handler. Step 4 says that the state identifer value in "returned Sigcomp Parameters" is compared against the state value computed value of state id for the decompressed message. But as per your explanation below, it seems to me like step 3 and step 4 are trying to compute the state id over the same piece of data.(i.e. the uncompressed message...)using the same procedures.(SHA-1). In this case, the results of state 3 and state 4 wil always be the same...and a match would always occur.. So if step 4 computes the state id over the decompressed message, step 3 should be something different. otherwise it does not make sense... correct me if i am wrong in my understanding, thanks suman ----- Original Message ----- From: "Hans Hannu (LU/EAB)" To: "'suman'" ; Sent: Monday, April 05, 2004 12:42 PM Subject: RE: [rohc] doubt regarding shared compression in rfc 3321 > Hi, > > From RFC 3320, END-MESSAGE instruction, page 52. > > "The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the > byte string formed by concatenating the state_length, state_address, > state_instruction, minimum_access_length and state_value (in the > order given). This is the state_identifier." > > From RFC 3321, page 9. > > "To make use of shared compression a compressing endpoint saves the > uncompressed version of the compressed message as a state (shared > state). As described in Section 2 the reference to a shared state is > referred to as shared_state_id. The shared state's parameters > state_address and state_instruction must be set to zero. The > state_retention_priority must be set to 65535," > > state_length is known from the decompressed message. > state_address is zero > state_instruction is zero > Start of with minimum_access_length equal the length as in the advertised list of states. > state_value is the decompressed message > > BR, > /Hans Hannu > > > >-----Original Message----- > >From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman > >Sent: den 5 april 2004 05:48 > >To: rohc@ietf.org > >Subject: [rohc] doubt regarding shared compression in rfc 3321 > > > > > >Section 5.2 of rfc 3321 speaks about Shared Compression as follows. > > > >1. compressor 1 saves the state M which is the uncompressed version of the current message > >compressed and sent. > > > >2. At the decompressor 2 in the receiving endpoint, SHA-1 instruction is used to calculate the > >state-id for state M. > > > >I am not able to figure out, over which piece of information should the SHA-1 instruction be executed ??? > > > >Could anybody clarify my doubt in this regard, > > > > > >thanks > >suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 08:02:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25866 for ; Mon, 5 Apr 2004 08:02:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASnF-0007B2-Gq for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 08:01:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35C1Xs0027588 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 08:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASnF-0007At-CV for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:01:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25836 for ; Mon, 5 Apr 2004 08:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASnE-00010U-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:01:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASmI-0000tG-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:00:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BASll-0000mW-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASll-0006nz-1I; Mon, 05 Apr 2004 08:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASlM-0006mp-EF for rohc@optimus.ietf.org; Mon, 05 Apr 2004 07:59:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25689 for ; Mon, 5 Apr 2004 07:59:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASlL-0000js-00 for rohc@ietf.org; Mon, 05 Apr 2004 07:59:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASkF-0000bO-00 for rohc@ietf.org; Mon, 05 Apr 2004 07:58:28 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BASjN-0000TD-00 for rohc@ietf.org; Mon, 05 Apr 2004 07:57:33 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35BvVPA000706 for ; Mon, 5 Apr 2004 13:57:31 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 13:57:31 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <212YXAJS>; Mon, 5 Apr 2004 13:57:31 +0200 Message-ID: From: "Hans Hannu (LU/EAB)" To: "'suman'" , rohc@ietf.org Subject: RE: [rohc] doubt regarding shared compression in rfc 3321 Date: Mon, 5 Apr 2004 13:57:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 11:57:31.0411 (UTC) FILETIME=[2CD43E30:01C41B05] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Step (3) is what your uploaded bytecode does in order to "announce" the shared state. In order to save a number of transmitted bytes per message the calculation of the shared_state_id was included. However, you could omit the calculation of the shared_state_id in step (3) by sending the shared_state_id as is over the link instead of having your bytecode calculate it and then announce it. BR, /Hans Hannu > > RFC 3321 speaks about shared compression procedures as follows: > > (1): Compressor 1 saves e.g., state(M), which is the uncompressed > version of the current application message to be > compressed and > sent. > (2): The UDVM bytecode to indicate the presence of state(M) at > endpoint 1 is either carried in the compressed message, or can > be retrieved by decompressor 2 from a state already saved at > endpoint 2. > (3): The SHA-1 instruction is used at endpoint 2 to calculate the > shared_state_id for state(M). The indication is passed to the > state handler, by placing the shared identifier at > the location > of the "returned SigComp parameters" [SIGCOMP]. The > location of > the "returned SigComp parameters" is given to the > state handler > using the END-MESSAGE instruction. > (4): If endpoint 2 uses shared compression, it compares the state > identifier values in the "returned SigComp parameters" > information with the value it has calculated for the current > decompressed message received from endpoint 1. If there is a > match then endpoint 2 uses the shared state together with the > state it would normally use if shared compression is not > supported to compress the next message. > (5): The UDVM bytecode that will use the shared state (state(M)) in > the decompression process at decompressor 1 is either carried > in the compressed message, or can be retrieved by > decompressor 1 > from a state already saved at endpoint 1. > > I am not able to figure out the difference between step 3 and > step4. Step 3 > says that the shared_state_id > is calculated using SHA-1 and stored in location of "returned Sigcomp > Parameters" before passed to state handler. > > Step 4 says that the state identifer value in "returned > Sigcomp Parameters" > is compared against > the state value computed value of state id for the > decompressed message. > > But as per your explanation below, it seems to me like step 3 > and step 4 are > trying to compute the > state id over the same piece of data.(i.e. the uncompressed > message...)using > the same procedures.(SHA-1). > In this case, the results of state 3 and state 4 wil always be the > same...and a match would always occur.. > > So if step 4 computes the state id over the decompressed > message, step 3 > should be something different. > otherwise it does not make sense... > > correct me if i am wrong in my understanding, > > thanks > suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 08:32:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26770 for ; Mon, 5 Apr 2004 08:32:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATGJ-0004pN-QV for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 08:31:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35CVZDi018555 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 08:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATGJ-0004pC-L6 for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:31:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26675 for ; Mon, 5 Apr 2004 08:31:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATGI-0004Lg-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:31:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATF8-00046x-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:30:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BATE9-000408-03 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:29:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BATBt-0005mJ-MB for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATBs-0003xK-P7; Mon, 05 Apr 2004 08:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATBH-0003nw-63 for rohc@optimus.ietf.org; Mon, 05 Apr 2004 08:26:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26538 for ; Mon, 5 Apr 2004 08:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATBG-0003iW-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:26:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATAG-0003cY-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:25:20 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAT9H-0003Ui-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:24:19 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35COIWR020983 for ; Mon, 5 Apr 2004 14:24:18 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 14:24:17 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 212YXN9D; Mon, 5 Apr 2004 14:24:17 +0200 Received: by lms001.lu.erisoft.se id OAA13147; Mon, 5 Apr 2004 14:24:22 +0200 (MET DST) Message-ID: <40714FEF.92AB278B@ericsson.com> Date: Mon, 05 Apr 2004 14:24:15 +0200 X-Sybari-Trust: 8fe196b7 2c4885b5 5b88d8b7 00000138 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "rohc@ietf.org" Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 05 Apr 2004 12:24:17.0588 (UTC) FILETIME=[EA2F6740:01C41B08] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i35COIWR020983 Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC-CR - Updated version - draft-ietf-rohc-context-replication-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ROHCers, An updated version of the draft describing context replication for ROHC profiles, , has been submitted. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-rohc-context-replication-0= 2.txt Minor changes based on previous discussions are included. In particular, the following has been updated: * A new section (3.5.3)with text clarifying the properties of the BCID has been added; * In section 3.3.3.1, text was added to clarify what part of a base context must have been ACKed to make it suitable for replication; * In section 3.4.3, implications of a decompressor implementation not sending a STATIC-NACK for a decompressor performing strict memory management have been added; * some very minor editorial changes; Remaining open issues to be discussed: * Is inter-profile context replication worth doing/motivated? * If yes: - How do we define the export interface for replication? - Should the export interface be limited to new profiles (or versions) only? - If a profile supporting CR is negotiated, what does this mean for the other profiles? Does this mandate that all other profiles implement the export interface for inter-profile context replication?=20 Please review the updated version and provide feedback on the above issues. Regards, /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 08:32:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26796 for ; Mon, 5 Apr 2004 08:32:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATGL-0004pf-KS for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 08:31:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35CVbEl018571 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 08:31:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATGL-0004pS-G8 for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:31:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26685 for ; Mon, 5 Apr 2004 08:31:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATGK-0004Lv-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:31:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATFB-00047R-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:30:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BATEA-000408-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:29:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BATAw-0005kV-Su for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATAv-0003l8-OL; Mon, 05 Apr 2004 08:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATAM-0003a0-Tp for rohc@optimus.ietf.org; Mon, 05 Apr 2004 08:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26530 for ; Mon, 5 Apr 2004 08:25:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATAL-0003dH-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAT9R-0003Xo-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:24:30 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BAT9D-0003S7-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:24:16 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35COEAh030531 for ; Mon, 5 Apr 2004 14:24:15 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 14:24:14 +0200 Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FVZZVS; Mon, 5 Apr 2004 14:24:14 +0200 Received: by lms001.lu.erisoft.se id OAA13143; Mon, 5 Apr 2004 14:24:20 +0200 (MET DST) Message-ID: <40714FEC.C6D138A7@ericsson.com> Date: Mon, 05 Apr 2004 14:24:12 +0200 X-Sybari-Trust: e181a74b 2c4885b5 5b88d8b7 00000138 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "rohc@ietf.org" Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 05 Apr 2004 12:24:14.0853 (UTC) FILETIME=[E88E1350:01C41B08] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i35COEAh030531 Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC-TCP - Updated version - draft-ietf-rohc-tcp-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ROHCers, An updated version of the draft describing the ROHC profile of TCP, , has been submitted. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-06.txt Some changes based on previous discussions are included. In particular, the following has been updated: - The IP-ID behavior has been clarified (section 3.2); - Recommendation on sending feedback upon decompression failures has been made somewhat less strict (section 5.2.7)=20 - MSN initializes to a random value, instead of being initialized to zero (section 6.3) - The format of the IR-CR packet is now specified with a "profile_specific_part", instead of with "replicate_common" and "replicate_formats" - The context memory feedback option has been added (section 6.6.3) - Other minor editorial changes Note that the packet formats using the formal notation have not been updated; the next version will update these formats. Please comment on these changes and the updated version in general. Regards, /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 08:36:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27017 for ; Mon, 5 Apr 2004 08:36:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATKC-0005cU-Qv for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 08:35:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35CZaVY021600 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 08:35:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATKC-0005cJ-NN for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:35:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26980 for ; Mon, 5 Apr 2004 08:35:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATKB-0004zY-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:35:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATIT-0004jm-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:33:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BATHg-0004az-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATHh-000535-HH; Mon, 05 Apr 2004 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATGj-0004qu-VJ for rohc@optimus.ietf.org; Mon, 05 Apr 2004 08:32:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26752 for ; Mon, 5 Apr 2004 08:31:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATGi-0004PJ-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:32:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATFa-0004As-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:30:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BATEG-000408-01 for rohc@ietf.org; Mon, 05 Apr 2004 08:29:29 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAT3N-0005P0-KN for rohc@ietf.org; Mon, 05 Apr 2004 08:18:14 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVP0085O6176Z@mta0.huawei.com> for rohc@ietf.org; Mon, 05 Apr 2004 20:15:09 +0800 (CST) Date: Mon, 05 Apr 2004 17:48:03 +0530 From: suman Subject: Re: [rohc] doubt regarding shared compression in rfc 3321 To: "Hans Hannu (LU/EAB)" , rohc@ietf.org Message-id: <001401c41b08$0bda9820$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Hans, I got your point now..and I appreciate the need to avoid sending the shared_state_id each time. But i am not able to figure out how this bytecode could be intelligent enough to "announce" the shared state.. How exactly will the bytecode generate the shared state which should be same as step 4. Could u throw some more light on this ?? All I know for now is that bytecode cannot perform the SHA-Hash over the ucompressed message.. because in that case, it would be same as Step (4). thanks suman ----- Original Message ----- From: "Hans Hannu (LU/EAB)" To: "'suman'" ; Sent: Monday, April 05, 2004 5:27 PM Subject: RE: [rohc] doubt regarding shared compression in rfc 3321 > Step (3) is what your uploaded bytecode does in order to "announce" the shared state. In order to save a number of transmitted bytes per message the calculation of the shared_state_id was included. > However, you could omit the calculation of the shared_state_id in step (3) by sending the shared_state_id as is over the link instead of having your bytecode calculate it and then announce it. > > BR, > /Hans Hannu > > > > > RFC 3321 speaks about shared compression procedures as follows: > > > > (1): Compressor 1 saves e.g., state(M), which is the uncompressed > > version of the current application message to be > > compressed and > > sent. > > (2): The UDVM bytecode to indicate the presence of state(M) at > > endpoint 1 is either carried in the compressed message, or can > > be retrieved by decompressor 2 from a state already saved at > > endpoint 2. > > (3): The SHA-1 instruction is used at endpoint 2 to calculate the > > shared_state_id for state(M). The indication is passed to the > > state handler, by placing the shared identifier at > > the location > > of the "returned SigComp parameters" [SIGCOMP]. The > > location of > > the "returned SigComp parameters" is given to the > > state handler > > using the END-MESSAGE instruction. > > (4): If endpoint 2 uses shared compression, it compares the state > > identifier values in the "returned SigComp parameters" > > information with the value it has calculated for the current > > decompressed message received from endpoint 1. If there is a > > match then endpoint 2 uses the shared state together with the > > state it would normally use if shared compression is not > > supported to compress the next message. > > (5): The UDVM bytecode that will use the shared state (state(M)) in > > the decompression process at decompressor 1 is either carried > > in the compressed message, or can be retrieved by > > decompressor 1 > > from a state already saved at endpoint 1. > > > > I am not able to figure out the difference between step 3 and > > step4. Step 3 > > says that the shared_state_id > > is calculated using SHA-1 and stored in location of "returned Sigcomp > > Parameters" before passed to state handler. > > > > Step 4 says that the state identifer value in "returned > > Sigcomp Parameters" > > is compared against > > the state value computed value of state id for the > > decompressed message. > > > > But as per your explanation below, it seems to me like step 3 > > and step 4 are > > trying to compute the > > state id over the same piece of data.(i.e. the uncompressed > > message...)using > > the same procedures.(SHA-1). > > > > > In this case, the results of state 3 and state 4 wil always be the > > same...and a match would always occur.. > > > > So if step 4 computes the state id over the decompressed > > message, step 3 > > should be something different. > > otherwise it does not make sense... > > > > correct me if i am wrong in my understanding, > > > > thanks > > suman > > _______________________________________________ > 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 exim@www1.ietf.org Mon Apr 5 08:37:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27116 for ; Mon, 5 Apr 2004 08:37:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATLJ-0005nn-5L for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 08:36:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Cajvf022299 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 08:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATLJ-0005na-0y for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:36:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27074 for ; Mon, 5 Apr 2004 08:36:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATLH-0005Dr-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:36:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATKJ-00051G-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:35:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BATIf-0004lT-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 08:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATIf-0005Gi-R2; Mon, 05 Apr 2004 08:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATIO-0005FW-1X for rohc@optimus.ietf.org; Mon, 05 Apr 2004 08:33:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26926 for ; Mon, 5 Apr 2004 08:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATIM-0004id-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:33:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATHQ-0004ZD-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:32:45 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BATGX-0004Nk-00 for rohc@ietf.org; Mon, 05 Apr 2004 08:31:49 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35CVmAh032589 for ; Mon, 5 Apr 2004 14:31:48 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 14:31:48 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <212YXRF0>; Mon, 5 Apr 2004 14:31:48 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Vicknesan Ayadurai (KI/EAB)" , zhigang.c.liu@nokia.com Cc: szym_paw@wp.pl, ROHC mail list Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Mon, 5 Apr 2004 14:31:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 12:31:48.0324 (UTC) FILETIME=[F6D84240:01C41B09] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Vick, Thanks for expressing your views on these matters as an implementer. Especially the point about this never being an issue at the various interops was really valuable. /L-E P.S. Thanks also for noting that it was Pawel who started the thread, I mistakenly wrote Kamal in my previous mail, sorry for that!! > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Vicknesan Ayadurai (KI/EAB) > Sent: den 2 april 2004 15:38 > To: zhigang.c.liu@nokia.com > Cc: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; ROHC mail list > Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp > field > > > Hi all, > > I might've missed the start of this thread, but have been watching the > passionate discussion over recent days and am getting confused about > what the original point was. Hence, I thought I'd join in the fray > with my 2-cents worth... :-) > > Looking back at the archives this morning, I guess the original > question was raised by Pawel regarding "slope", how it's defined, and > used. > > I believe the general definition of the slope as being "the line > joining two points" (or something similar), which someone mentioned, > is pretty much my (2-dimensional) view as well. In my mind, "slope" in > RFC3095 was meant to be the general term for the difference of a > certain field, in consecutive packets. I further assumed that "slope" > for the TS field was labelled TS_STRIDE, which my following text > focuses upon. > > Specific to the TS field, there should be no need for the decompressor > to determine any "slope"/TS_STRIDE at all, since the RFC states: > > ------ > ... > ... > TS = TS_SCALED * TS_STRIDE + TS_OFFSET > > TS_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to the > decompressor. The following algorithm is used: > ... > ... > > ------ > > indicating, to my understanding, that the decompressor shouldn't have > to figure out "slope"/TS_STRIDE at all. > > This assumption is consistent with my perception of the overall ROHC > algorithm, which makes the compressor out to be the intelligent > entity, capable of huge feats of analysis in order to generate the > optimally (small) header, while the decompressor is the "brute-force" > entity, not very bright, but able to handle all packets thrown at it > simply because it's provided all the necessary information by the > smart guy. > > Someone also mentioned that TS_SCALED could look like: 2, 4, 6, 8, ... > which I don't quite follow. If the compressor initially notes the > delta between consecutive TSs is, say 320, it'll then explicitly > convey TS_STRIDE as 320 to the decompressor. It subsequently then > sends (say for a "well-behaved" RTP stream) UO-0 packets. If it later > notes that there is a delta of 160, it needs to explicitly inform the > decompressor that TS_STRIDE is 160, and subsequently send (say) > UO-1-TS packets whenever a delta of 320 is observed. In this scenario, > one delta of 160 would trigger the ROHC compressor to effectively > generate the larger UO-1-TS packet stream, instead of a UO-0 stream. A > smart compressor should probably notice this 2, 4, 6, 8, ... > behaviour and perhaps re-evaluate/rectify it's value of TS_STRIDE. > > The point however is that the decompressor doesn't have to compute any > slope or deltas or stride values for the TS, but is explicitly told > what it is. > > While this has all been my personal interpretation the "slope" and > TS_STRIDE is, I'm probably not alone in this since it should be also > pointed out that this has not been an issue during the four interops > taken place so far. While we never explicitly tested for this, it > would almost certainly have popped up if there were situations where > the compressor and decompressor were both independently trying to > figure out deltas/slopes/strides for TS. > > Regards, > vick > +----------------------------------------------------+ > Vicknesan AYADURAI > Ericsson Research: IP Networks - Stockholm, Sweden > Phone : +46 8 5087 8084 / Fax: +46 8 404 7020 > +----------------------------------------------------+ > > On Thu, 1 Apr 2004 zhigang.c.liu@nokia.com wrote: > > > Lars-Erik, > > > > IMHO, we should clearly separate clarifying RFC 3095 from > redefining it: > > > > - As I said, some text in RFC 3095 could have been written > better (though it doesn't mean we haven't tried). The slope > is one of them, in which case we should clarify what RFC 3095 > intended to say. > > - However, it is a completely different subject to say we > do not need slope. If that is indeed the conclusion at the > end of this discussion, we should define a new profile that > excludes it. Mixing this with above is not a constructive approach. > > > > > So, what I want you all to think of is to stay > open-minded, constructive, and be nice to each other. > > > > I cannot agree more. And here is my understanding - if I > may - on how to do it in practice (I've been trying them myself): > > > > - Be conservative of what you say. Try best to verify the > reasoning/observations/facts on which you make a claim. > > - Everyone makes mistakes or has incorrect information. > That's perfectly OK, but admit it. > > - Being nice to others means reading their emails > *carefully*, especially when you disagree. If you agree, say > so. If not, give reasons. > > - Be honest and straight to the point. > > > > BR, > > Zhigang > > > > > -----Original Message----- > > > From: ext Lars-Erik Jonsson (LU/EAB) > > > [mailto:lars-erik.jonsson@ericsson.com] > > > Sent: 01 April, 2004 06:32 AM > > > To: Liu Zhigang.C (Nokia-NRC/Dallas); szym_paw@wp.pl; > rohc@ietf.org > > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > > Timestamp field > > > > > > > > > Zhigang, > > > > > > Thanks for pointing us to this discussion in the archives, it > > > was useful reading at > > > least for me. Unfortunately, this is not what is captured in > > > 3095, and I think (at > > > least) we all agree that there is a need to resolve this > > > issue and make clarifications, > > > although we have not yet figured out and agreed on exactly > > > what to clarify and how. > > > > > > As has been noted before, there are a number of questions one > > > may ask here: > > > 1) What was discussed during the development of 3095 in 1999-2000? > > > 2) What was 3095 intended to say, back in 2000? > > > 3) What is 3095 really saying? > > > 4) How can 3095 be interpreted? > > > 5) Now 2004, which solution do we think makes most sense, > technically? > > > 6) Now 2004, which solution would make most sense if we > consider 3)? > > > 7) How do we realize 6) in the implementers guide to ensure > > > interoperability? > > > > > > Kamal initially noted that it is unclear whether there really > > > is a slope. When I took a > > > first look at this issue by reading 3095 and the mail thread > > > Kamal had pointed to, my > > > observation was that 3095 is really not defining slopes. One > > > would have to read a lot > > > between the lines to find what Zhigang has explained was the > > > intended meaning. I > > > read the mails from Kristofer as if he also thinks there is > > > no slope defined in 3095, > > > but while Kamal believes there is a need to use implicitly > > > updated slopes, Kristofer > > > seems to be sceptical to that, although it is clear that also > > > a solution without the > > > implicit slopes means there are things that do not "compile", > > > e.g. TS_STRIDE=0, > > > which would have to be defined as it currently would result > > > in a division by 0. > > > > > > We obviously are far from having answered questions 3-7, and > > > even if Zhigang has > > > explained much about 1-2, the history about why things are > > > like they are and what > > > was really intended at that time is still just background > > > information, we need to be > > > responsible, accept what we have, and find the proper > > > solution considering what > > > is really in 3095 today. It might also be so that our > > > preferred solution today, even > > > not considering 3095, will be different than what it was back > > > in 2000. > > > > > > So, what I want you all to think of is to stay open-minded, > > > constructive, and be > > > nice to each other. We all have one single goal, to find the > > > best technical and > > > practical solutions and document them in an unambiguous way. > > > It is not about > > > being right or being wrong, it is about having the courage to > > > ask stupid questions, > > > and thereby getting the discussion forward. It is a good > > > thing to say, "ok, you > > > are right, I did not think about that", since that means we > > > (as a group) has > > > progressed and we have all learned something. > > > > > > Keep up discussing, constructively, as we have a problem > to resolve! > > > /L-E > > > > > > > > > > > > > -----Original Message----- > > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > > Sent: den 31 mars 2004 20:19 > > > > To: Lars-Erik Jonsson (LU/EAB); szym_paw@wp.pl; rohc@ietf.org > > > > Subject: RE: [rohc] Slope used to compress/decompress RTP > > > > Timestamp field > > > > > > > > > > > > > The mail list discussions indicates that there were proposals > > > > > to have such principles, but the discussions point in the > > > > direction of > > > > > giving up these ideas. > > > > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > > ive/msg00953.html > > > > > > > > That is not true. > > > > > > > > If you read the emails below, you can see my proposal for the > > > > decompressor > > > > to learn slope was agreed upon. > > > > > > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > > ive/msg00934.html > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch > > ive/msg00935.html > > > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch ive/msg00952.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00957.html > http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00960.html > > The email you mentioned above is a discussion on only one logic branch in my > proposal, i.e., whether the default-slope or the previous learned slope ("old_slope") > should be used by the decompressor when it receives only one context update. > It is NOT about the slope learning itself, which has already been agreed. In the > end, you can see that my proposal to use "old_slope" in the case of one "FO" > update was also agreed. > > BR, > Zhigang > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > +----------------------------------------------------+ Vicknesan AYADURAI Ericsson Research: IP Networks - Stockholm, Sweden Phone : +46 8 5087 8084 / Fax: +46 8 404 7020 +----------------------------------------------------+ _______________________________________________ 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 exim@www1.ietf.org Mon Apr 5 09:46:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00815 for ; Mon, 5 Apr 2004 09:46:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUPz-0002UD-Hq for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 09:45:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Djd3u009555 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 09:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUPz-0002U2-CQ for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 09:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00805 for ; Mon, 5 Apr 2004 09:45:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUPx-00073m-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 09:45:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUOx-0006wx-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 09:44:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAUOO-0006qR-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 09:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUOP-00025V-AY; Mon, 05 Apr 2004 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUO3-00023H-Jt for rohc@optimus.ietf.org; Mon, 05 Apr 2004 09:43:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00696 for ; Mon, 5 Apr 2004 09:43:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUO1-0006os-00 for rohc@ietf.org; Mon, 05 Apr 2004 09:43:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUN3-0006fH-00 for rohc@ietf.org; Mon, 05 Apr 2004 09:42:37 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAUM8-0006US-00 for rohc@ietf.org; Mon, 05 Apr 2004 09:41:40 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35DfdWR012666 for ; Mon, 5 Apr 2004 15:41:40 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 15:41:38 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <212YY4VN>; Mon, 5 Apr 2004 15:41:04 +0200 Message-ID: From: "Hans Hannu (LU/EAB)" To: "'suman'" , rohc@ietf.org Subject: RE: [rohc] doubt regarding shared compression in rfc 3321 Date: Mon, 5 Apr 2004 15:40:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 13:41:39.0457 (UTC) FILETIME=[B8F46710:01C41B13] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Suman, > But i am not able to figure out how this bytecode could be intelligent > enough to "announce" the shared state.. > How exactly will the bytecode generate the shared state which > should be same > as step 4. > If I remember correctly there was a chapter in the "SigComp User Guide", by Richard Price et al., giving such a bytecode. However, that draft seems to have expired, but perhaps someone else has that information. BR, /Hans Hannu _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 09:54:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01183 for ; Mon, 5 Apr 2004 09:54:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUXk-0003hp-Qw for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 09:53:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Drex0014241 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 09:53:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUXk-0003hc-KW for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 09:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01139 for ; Mon, 5 Apr 2004 09:53:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUXi-0000FE-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 09:53:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUWn-00007o-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 09:52:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAUW7-00000G-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 09:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUW9-0003Q2-5E; Mon, 05 Apr 2004 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUVs-0003PG-BX for rohc@optimus.ietf.org; Mon, 05 Apr 2004 09:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01070 for ; Mon, 5 Apr 2004 09:51:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUVp-0007n4-00 for rohc@ietf.org; Mon, 05 Apr 2004 09:51:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUUt-0007fW-00 for rohc@ietf.org; Mon, 05 Apr 2004 09:50:44 -0400 Received: from mailrelay2.lntinfotech.com ([203.199.54.34]) by ietf-mx with esmtp (Exim 4.12) id 1BAUUF-0007VX-00 for rohc@ietf.org; Mon, 05 Apr 2004 09:50:03 -0400 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004040519193062:3137 ; Mon, 5 Apr 2004 19:19:30 +0530 Subject: Re: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 To: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kavitha KR" Date: Mon, 5 Apr 2004 19:17:21 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 04/05/2004 07:17:22 PM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/05/2004 07:19:30 PM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/05/2004 07:20:04 PM, Serialize complete at 04/05/2004 07:20:04 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Pawel, >I have no doubt what decompressor should do when it receives UOR-2* >with TS is unscaled form (i.e. Tsc = 0) and TS_STRIDE present (i.e. TSS = 1). >But I still don't know what is correct decompressor's behaviour in case it >receives UOR-2* packet with scaled TS (i.e. Tsc = 1) and TS_STRIDE present >(i.e. TSS =1). How it can calculate TS_OFFSET needed to decompress the received >scaled TS value ? ====> Yeah. I see your point.It is not possible to decompress without the new TS_OFFSET value. But new TS_OFFSET can be obtained only if you decompress the TS field. So there is a confusion of whether to use context(TS) or the last successfully decompressed value of TS to get the TS_OFFSET. >Note that the following text from RFC 3095 section 5.7.5 page 85: >" Tsc: Tsc = 0 indicates that TS is not scaled; > Tsc = 1 indicates that TS is scaled according to section > 4.5.3, using value(TS_STRIDE). " >For me the fact that the TS is scaled using "value(TS_STRIDE)" and not context >(TS_STRIDE) suggests that the TS can be scaled using TS_STRIDE sent in the same >packet as the TS field. ====>Yes,it seems that ROHC allows sending of packets that contain TS_STRIDE and the TS_SCALED value, that is compressed using the same TS_STRIDE in a single packet. But on the other hand, when we want to communicate TS_STRIDE, we are basically initializing the timestamp context. In which we should explicitly communicate TS_STRIDE and implicitly communicate TS_OFFSET as well. Which means we must send unscaled TS and TS_STRIDE for some packets until decompressor confidence is obtained. [Please refer section 4.5.3 Page 29, Point 1 of RFC3095.] Regards, Kavitha. This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Thanks _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 10:31:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03983 for ; Mon, 5 Apr 2004 10:31:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAV7Z-0000xL-15 for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 10:30:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35EUfqQ003676 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 10:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAV7Y-0000wz-HX for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 10:30:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03945 for ; Mon, 5 Apr 2004 10:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAV7S-00055I-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 10:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAV6a-0004yy-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 10:29:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAV5v-0004sR-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 10:28:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAV5w-0000EN-It; Mon, 05 Apr 2004 10:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAV5P-00007c-9W for rohc@optimus.ietf.org; Mon, 05 Apr 2004 10:28:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03700 for ; Mon, 5 Apr 2004 10:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAV5M-0004pi-00 for rohc@ietf.org; Mon, 05 Apr 2004 10:28:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAV4N-0004hp-00 for rohc@ietf.org; Mon, 05 Apr 2004 10:27:24 -0400 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1BAV3O-0004SJ-00 for rohc@ietf.org; Mon, 05 Apr 2004 10:26:22 -0400 Received: (wp-smtpd smtp.wp.pl 18629 invoked from network); 5 Apr 2004 16:25:50 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 5 Apr 2004 16:25:50 +0200 Date: Mon, 5 Apr 2004 16:25:49 +0200 From: "Pawel Szymanski" To: Kavitha KR Cc: rohc@ietf.org Subject: Re: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 Message-ID: <40716c6d59abc@wp.pl> References: In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.173.14 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA03701 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kavitha, See my comment below. >=20 > Hi Pawel, >=20 > >I have no doubt what decompressor should do when it receives UOR-2* > >with TS is unscaled form (i.e. Tsc =3D 0) and TS_STRIDE present (i.e. = TSS =3D > 1). > >But I still don't know what is correct decompressor's behaviour in cas= e it >=20 > >receives UOR-2* packet with scaled TS (i.e. Tsc =3D 1) and TS_STRIDE p= resent >=20 > >(i.e. TSS =3D1). How it can calculate TS_OFFSET needed to decompress t= he > received > >scaled TS value ? >=20 > =3D=3D=3D=3D> Yeah. I see your point.It is not possible to decompress w= ithout the > new > TS_OFFSET value. But new TS_OFFSET can be obtained only if you > decompress > the TS field. So there is a confusion of whether to use context(T= S) > or the last successfully decompressed value of TS to get the > TS_OFFSET. >=20 > >Note that the following text from RFC 3095 section 5.7.5 page 85: > >" Tsc: Tsc =3D 0 indicates that TS is not scaled; > > Tsc =3D 1 indicates that TS is scaled according to section > > 4.5.3, using value(TS_STRIDE). " > >For me the fact that the TS is scaled using "value(TS_STRIDE)" and not > context > >(TS_STRIDE) suggests that the TS can be scaled using TS_STRIDE sent in= the > same > >packet as the TS field. >=20 > =3D=3D=3D=3D>Yes,it seems that ROHC allows sending of packets that cont= ain > TS_STRIDE and > the TS_SCALED value, that is compressed using the same TS_STRIDE i= n a > single > packet. > But on the other hand, when we want to communicate TS_STRIDE, we > are basically initializing the timestamp context. In which we shou= ld > explicitly > communicate TS_STRIDE and implicitly communicate TS_OFFSET as well. > Which means > we must send unscaled TS and TS_STRIDE for some packets until > decompressor > confidence is obtained. [Please refer section 4.5.3 Page 29, Point= 1 > of RFC3095.] >=20 > Regards, > Kavitha. Do you think that section 4.5.3 Page 29, Point 1 means that sending packe= ts=20 containing both scaled TS field and TS_STRIDE is illegal ? In my opinion, the point you are refering to only describes the most comm= on=20 scenario of initializing TS_STRIDE and TS_OFFSET parameters. However it d= oes=20 not state clearly that other scenarios are illegal. I know that in most cases it does not make sense to send such packets, bu= t from=20 the implementors point of view I would expect a clear statemenet (for exa= mple=20 in the implementation guide) whether such packets are legal and what is t= he=20 correct behaviour of the decompressor when it receives such a packet. Regards=20 Pawel ---------------------------------------------------- Fani zespo=B3u Metallica =B3=B1czcie si=EA! Do=B3=B1czamy do majowego kon= certu! http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.html%3Fidn%3= D829&sid=3D157 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 12:07:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10557 for ; Mon, 5 Apr 2004 12:07:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWbs-0002p8-Mb for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 12:06:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35G5ssD010738 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 12:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWbg-0002mD-3v for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 12:05:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10089 for ; Mon, 5 Apr 2004 12:05:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWbZ-00041d-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 12:05:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWOr-00025u-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 11:52:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAWDp-00004T-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 11:41:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAW4F-0007uE-Hj; Mon, 05 Apr 2004 11:31:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAVQH-0005Lx-0F for rohc@optimus.ietf.org; Mon, 05 Apr 2004 10:50:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05272 for ; Mon, 5 Apr 2004 10:49:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAVQ6-0000GT-00 for rohc@ietf.org; Mon, 05 Apr 2004 10:49:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAVP6-00007t-00 for rohc@ietf.org; Mon, 05 Apr 2004 10:48:48 -0400 Received: from mailrelay2.lntinfotech.com ([203.199.54.34]) by ietf-mx with esmtp (Exim 4.12) id 1BAVOd-0007nB-00 for rohc@ietf.org; Mon, 05 Apr 2004 10:48:20 -0400 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004040520174724:3228 ; Mon, 5 Apr 2004 20:17:47 +0530 Subject: Re: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 To: "Pawel Szymanski" Cc: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kavitha KR" Date: Mon, 5 Apr 2004 20:15:37 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 04/05/2004 08:15:39 PM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/05/2004 08:17:47 PM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/05/2004 08:18:20 PM, Serialize complete at 04/05/2004 08:18:20 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Pawel, >Do you think that section 4.5.3 Page 29, Point 1 means that sending packets >containing both scaled TS field and TS_STRIDE is illegal ? ===> Surely I dont think so. Whether the packet under our discussion is legal, is not clearly asserted by the RFC. I do agree. I only was indicating that in your example, since there seems to be no other go to communicate both the parameters clearly, (in the current RFC or imple guide) we can as well resort to the "most common" initialization scenario. : -) Well, such subtle points should really go into implementation guide. Regards, Kavitha. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 13:27:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16398 for ; Mon, 5 Apr 2004 13:27:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXsQ-0005VS-BJ for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 13:27:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35HREiB021162 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 13:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXsQ-0005VA-6H for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 13:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16240 for ; Mon, 5 Apr 2004 13:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAXsO-00005t-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:27:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXXj-0005Ps-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:05:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAXRq-0004cn-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 12:59:46 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAXGl-0000XK-LK for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 12:48:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXDy-00031X-Pq; Mon, 05 Apr 2004 12:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWe8-0003WG-3z for rohc@optimus.ietf.org; Mon, 05 Apr 2004 12:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10856 for ; Mon, 5 Apr 2004 12:08:20 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWe6-0004Xu-00 for rohc@ietf.org; Mon, 05 Apr 2004 12:08:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWUd-00036A-00 for rohc@ietf.org; Mon, 05 Apr 2004 11:58:36 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BAWJX-00015y-00 for rohc@ietf.org; Mon, 05 Apr 2004 11:47:07 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35Fl1h21565; Mon, 5 Apr 2004 18:47:01 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 18:46:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i35FktCR018224; Mon, 5 Apr 2004 18:46:55 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00WFJCcv; Mon, 05 Apr 2004 18:46:53 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35FkqF25596; Mon, 5 Apr 2004 18:46:52 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 10:46:18 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Mon, 5 Apr 2004 11:46:17 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153738@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQYtyPiN5vnq9z5Sae+whcfM9Qm6QCYSuiQ To: Cc: , , X-OriginalArrivalTime: 05 Apr 2004 15:46:18.0659 (UTC) FILETIME=[22E80F30:01C41B25] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vick, > I further assumed that "slope" > for the TS field was labelled TS_STRIDE, which my following text > focuses upon. It becomes clear to me that this is the crux of the confusion. I've=20 tried to explain the difference between slope and TS_STRIDE in the=20 email below (in particular, please look at the end of email). Please=20 let me know if you have comments on that. http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02042.ht= ml Also, the text below (from section 5.7) indicates slope and TS_STRIDE are two *independent* concepts, though they may have the same values in certain cases. TS: The compressed RTP Timestamp value. If value(TIME_STRIDE) > 0, timer-based compression of the RTP Timestamp is used (see section 4.5.4). If value(Tsc) =3D 1, Scaled RTP Timestamp encoding is used before compression (see section 4.5.3), and default-slope(TS) =3D 1. If value(Tsc) =3D 0, the Timestamp value is compressed as-is, and default-slope(TS) =3D value(TS_STRIDE). > While this has all been my personal interpretation the "slope" and > TS_STRIDE is, I'm probably not alone in this since it should be also > pointed out that this has not been an issue during the four interops > taken place so far. While we never explicitly tested for this, it > would almost certainly have popped up if there were situations where > the compressor and decompressor were both independently trying to > figure out deltas/slopes/strides for TS. Could you explain how the TS is decompressed in your implementation when the decompressor receives a Type 0 packet? For certain cases, the two interpretation can yield the same result. That may explain why the issue has not been raised. However, I didn't have time to follow ROHC interops. So, I don't know the details. One=20 thing I do know is that in Nokia's implementation (which I participated = in at beginning), scaling and compression (FO, SO, etc.) are two separate steps. Unfortunately, Nokia's team were not able to participate in all the four interops. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 13:27:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16434 for ; Mon, 5 Apr 2004 13:27:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXsO-0005UC-Pr for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 13:27:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35HRCAM021077 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 13:27:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXsO-0005T7-40 for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 13:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16226 for ; Mon, 5 Apr 2004 13:27:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAXsM-00005R-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:27:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXXe-0005PJ-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:05:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAXRq-0004XT-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 12:59:46 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAXGk-0000TJ-CA for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 12:48:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXDt-0002wp-Qw; Mon, 05 Apr 2004 12:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWdZ-0003Mx-UZ for rohc@optimus.ietf.org; Mon, 05 Apr 2004 12:07:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10746 for ; Mon, 5 Apr 2004 12:07:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWdY-0004T2-00 for rohc@ietf.org; Mon, 05 Apr 2004 12:07:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWTc-0002vE-00 for rohc@ietf.org; Mon, 05 Apr 2004 11:57:32 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BAWIg-0000ws-00 for rohc@ietf.org; Mon, 05 Apr 2004 11:46:14 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i35FkDAh015291 for ; Mon, 5 Apr 2004 17:46:13 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 17:46:13 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <212Y5293>; Mon, 5 Apr 2004 17:46:13 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kavitha KR'" , Pawel Szymanski Cc: rohc@ietf.org Subject: RE: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Ext ension 3 Date: Mon, 5 Apr 2004 17:45:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2004 15:46:13.0318 (UTC) FILETIME=[1FB91660:01C41B25] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 The editor appreciates any text proposals that the group can consider and hopefully reach consensus on. At the moment, we are trying to figure out what to do with the slope(s) issue, so I guess that will still be my focus for a while (it is a tricky issue but hopefully we will soon start to understand each other). Please continue also this discussion and propose text. Cheers, /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Kavitha KR > Sent: den 5 april 2004 16:46 > To: Pawel Szymanski > Cc: rohc@ietf.org > Subject: Re: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in > Extension 3 > > > > Hi Pawel, > > >Do you think that section 4.5.3 Page 29, Point 1 means that sending > packets > >containing both scaled TS field and TS_STRIDE is illegal ? > > ===> Surely I dont think so. Whether the packet under our > discussion is > legal, > is not clearly asserted by the RFC. I do agree. > I only was indicating that in your example, since there > seems to be no > other > go to communicate both the parameters clearly, (in the > current RFC or > imple guide) > we can as well resort to the "most common" > initialization scenario. : > -) > > Well, such subtle points should really go into > implementation guide. > > Regards, > Kavitha. > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Apr 5 14:11:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20214 for ; Mon, 5 Apr 2004 14:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAYZ8-0000O0-Iv for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 14:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35IBMtF001483 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 14:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAYZ8-0000No-8H for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 14:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20032 for ; Mon, 5 Apr 2004 14:11:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAYZ5-0005ec-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 14:11:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAY8i-00037G-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:44:06 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAY5z-0002da-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:41:15 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAY4D-0005PN-Fs for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 13:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAY3q-0002ht-KC; Mon, 05 Apr 2004 13:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAY3G-0002W8-6y for rohc@optimus.ietf.org; Mon, 05 Apr 2004 13:38:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18803 for ; Mon, 5 Apr 2004 13:38:23 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAY3E-00023I-00 for rohc@ietf.org; Mon, 05 Apr 2004 13:38:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXvL-0000bl-00 for rohc@ietf.org; Mon, 05 Apr 2004 13:30:17 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BAXdI-00061h-00 for rohc@ietf.org; Mon, 05 Apr 2004 13:11:36 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35HBRx10037; Mon, 5 Apr 2004 20:11:27 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 20:11:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i35HBNd0014240; Mon, 5 Apr 2004 20:11:23 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 001SiiZe; Mon, 05 Apr 2004 20:11:22 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i35HBJs29605; Mon, 5 Apr 2004 20:11:20 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 5 Apr 2004 12:10:29 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 Date: Mon, 5 Apr 2004 13:10:26 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153739@ajebe001.americas.nokia.com> Thread-Topic: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 Thread-Index: AcQbGwt1guPgHxVuQgO2a1Bc5xqImwAEo8sg To: , Cc: X-OriginalArrivalTime: 05 Apr 2004 17:10:29.0078 (UTC) FILETIME=[E530D760:01C41B30] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Good question and discussion. You have identified a fuzzy point in RFC 3095 that needs to be clarified. Please see my comments below. BR, Zhigang [Pawel wrote:] > > >Note that the following text from RFC 3095 section 5.7.5 page 85: > > >" Tsc: Tsc =3D 0 indicates that TS is not scaled; > > > Tsc =3D 1 indicates that TS is scaled according to section > > > 4.5.3, using value(TS_STRIDE). " > > >For me the fact that the TS is scaled using "value(TS_STRIDE)" and = not context > > >(TS_STRIDE) suggests that the TS can be scaled using TS_STRIDE = sent in the > > >same packet as the TS field. Good point. This is probably something we overlooked. IMHO, it should = really be=20 context(TS_STRIDE). [Kavitha wrote:] > > But on the other hand, when we want to communicate TS_STRIDE, = we > > are basically initializing the timestamp context. In which we = should explicitly > > communicate TS_STRIDE and implicitly communicate TS_OFFSET as = well. Which means > > we must send unscaled TS and TS_STRIDE for some packets until = decompressor > > confidence is obtained. [Please refer section 4.5.3 Page 29, = Point 1 of RFC3095.] Right. [Pawel wrote:] > I know that in most cases it does not make sense to send such packets, = but from > the implementors point of view I would expect a clear statemenet (for = example > in the implementation guide) whether such packets are legal and what = is the > correct behaviour of the decompressor when it receives such a packet. My suggestion would be to clarify the following in the implementation = guide. Comments? - Text on Extension 3 in section 5.7.5 should read context(TS_STRIDE) - When a compressor uses Extension 3 to re-establish a new value for = TS_STRIDE, it must send unscaled TS and TS_STRIDE for some packets until = decompressor confidence is obtained. In other words, Tsc must be set to 0 (zero) in = Extension 3 when TS_STRIDE field is present. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 5 19:49:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22684 for ; Mon, 5 Apr 2004 19:49:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAdpY-0001FR-TV for rohc-archive@odin.ietf.org; Mon, 05 Apr 2004 19:48:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35NmeJM004797 for rohc-archive@odin.ietf.org; Mon, 5 Apr 2004 19:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAdpY-0001FI-Mw for rohc-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 19:48:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22643 for ; Mon, 5 Apr 2004 19:48:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAdpW-00074T-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 19:48:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAdKu-0004IS-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 19:17:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAdBo-0002vP-00 for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 19:07:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAd9I-00015i-NI for rohc-web-archive@ietf.org; Mon, 05 Apr 2004 19:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAd9J-00017W-9w; Mon, 05 Apr 2004 19:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAd8l-0000zL-Ok for rohc@optimus.ietf.org; Mon, 05 Apr 2004 19:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20543 for ; Mon, 5 Apr 2004 19:04:22 -0400 (EDT) From: davegreen@comcast.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAd8i-0002hK-00 for rohc@ietf.org; Mon, 05 Apr 2004 19:04:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAcv1-0000Mt-00 for rohc@ietf.org; Mon, 05 Apr 2004 18:50:19 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BAcPF-00057E-00 for rohc@ietf.org; Mon, 05 Apr 2004 18:17:25 -0400 Received: from 204.127.205.144 ([204.127.205.144]) by comcast.net (sccrmhc11) with SMTP id <2004040522164801100c47p9e>; Mon, 5 Apr 2004 22:16:48 +0000 Received: from [192.172.8.13] by 204.127.205.144; Mon, 05 Apr 2004 22:16:47 +0000 To: rohc@ietf.org Cc: "Lars-Erik Jonsson (LU/EAB)" Subject: [rohc] Multipoint Robust Compression for MANET Date: Mon, 05 Apr 2004 22:16:47 +0000 Message-Id: <040520042216.1022.4071DACF000415C8000003FE2200734840FF919A9A8D989A899E@comcast.net> X-Mailer: AT&T Message Center Version 1 (Mar 22 2004) X-Authenticated-Sender: ZGF2ZWdyZWVuQGNvbWNhc3QubmV0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NextPart_Webmail_9m3u9jl4l_1022_1081203407" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,MIME_BASE64_TEXT, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.60 --NextPart_Webmail_9m3u9jl4l_1022_1081203407 Content-Type: text/plain Content-Transfer-Encoding: 8bit I'm designing a MANET system suitable for handheld and automobile portable radios that can operate on the move with link rages greater than 1 km. We will be adding IPv6 to the system so header compression has become a necessity as the network generally achieves less than 100kbps on links. In order to maximize bandwidth efficiency we are using broadcast and multicast traffic (multipoint traffic) to our neighbor nodes. I propose that we either create an extension to ROHC for multipoint links or come up with a method to efficiently use the current version in multipoint MANETS. I have been in contact with representatives from Effnet and Procito who are interested in designing the compression scheme. I have included a problem statement that defines the issues that I think need to be addressed and suggest that the ROHC group take this up as a new action item. Please let me know what you think, and if the we can address this problem within the working group. Thank you, David Green SRI International EMail: david.green@sri.com > David, > > Please reformat and submit the document as an Internet-Draft. > > Thanks! > /Lars-Erik, ROHC chair > > > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > > davegreen@comcast.net > > Sent: den 30 mars 2004 00:06 > > To: rohc@ietf.org > > Subject: [rohc] Multipoint Robust Compression for MANET > > > > > > I'm designing a MANET system suitable for handheld and > > automobile portable radios that can operate on the move with > > link rages greater than 1 km. We will be adding IPv6 to the > > system so header compression has become a necessity as the > > network generally achieves less than 100kbps on links. In > > order to maximize bandwidth efficiency we are using broadcast > > and multicast traffic (multipoint traffic) to our neighbor > > nodes. I propose that we either create an extension to ROHC > > for multipoint links or come up with a method to efficiently > > use the current version in multipoint MANETS. I have been in > > contact with representatives from Effnet and Procito who are > > interested in designing the compression scheme. I have > > included a problem statement that defines the issues that I > > think need to be addressed and suggest that the ROHC group > > take this up as a new action item. > > > > Please let me know what you think, and if the we can address > > this problem within the working group. > > > > Thank you, > > > > David Green > > SRI International > > EMail: david.green@sri.com > > > > This communication is confidential and intended solely for the addressee(s). Any > unauthorized review, use, disclosure or distribution is prohibited. If you > believe this message has been sent to you in error, please notify the sender by > replying to this transmission and delete the message without disclosing it. > Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, > unauthorized amendment, tampering and viruses, and we only send and receive > e-mails on the basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any consequences thereof. > --NextPart_Webmail_9m3u9jl4l_1022_1081203407 Content-Type: text/plain; name="draft-ietf-green-ROHC-multipoint-MANET.01.txt" Content-Transfer-Encoding: base64 DQoNCiAgIFJPSEMgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gR3JlZW4gDQogICBEb2N1bWVudDogZHJhZnQt aWV0Zi1ncmVlbi1ST0hDLW11bHRpcG9pbnQtICAgICAgICBTUkkgSW50ZXJuYXRpb25hbCANCiAg IE1BTkVULjAxLnR4dCANCiAgIEV4cGlyZXM6IE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDA0IA0KICAgIA0KICAgIA0KICAgICAgICAgICAg ICAgICBQcm9ibGVtIFN0YXRlbWVudDogUk9idXN0IEhlYWRlciBDb21wcmVzc2lvbiAoUk9IQykg DQogICAgICAgICAgICAgICAgICAgICAgaW4gTXVsdGlwb2ludCBNb2JpbGUgQWRob2MgTkV0d29y ayAoTUFORVQpIA0KICAgICAgICAgICAgICAgICAgIDxkcmFmdC1pZXRmLWdyZWVuLVJPSEMtbXVs dGlwb2ludC1NQU5FVC4wMS50eHQ+IA0KICAgIA0KICAgIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyAN CiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1 bGwgY29uZm9ybWFuY2Ugd2l0aCANCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2Yg UkZDMjAyNiBbMV0uICANCiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0KICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCAgICAgIA0KICAg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50 ZXJuZXQtDQogICBEcmFmdHMuIA0KICAgIA0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0KICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiIgDQogICAgDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0K QWJzdHJhY3QgDQogICAgDQogICBUaGlzIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50IHBvc2Vz IHRoZSBpc3N1ZXMgdGhhdCBuZWVkIHRvIGJlIA0KICAgYWRkcmVzc2VkIHRvIG9wdGltaXplIFJP SEMgZm9yIGEgTW9iaWxlIEFkaG9jIE5FdHdvcmsgKE1BTkVUKSANCiAgIGNvbnRhaW5pbmcgcG9p bnQtdG8tbXVsdGlwb2ludCAoYnJvYWRjYXN0IGFuZCBtdWx0aWNhc3QpIG1lc3NhZ2VzIA0KICAg c2VudCBhY3Jvc3MgYWQtaG9jIHJhZGlvIG5ldHdvcmsgdG9wb2xvZ2llcy4gDQogICAgDQogICAg DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogDQogDQpHcmVlbiAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIC0gT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDFd IA0KDQoNCg0KDQoMICAgICAgICAgICAgIFByb2JsZW0gU3RhdGVtZW50OiBST0hDIGluIE11bHRp cG9pbnQgTUFORVQgIEFwcmlsIDIwMDQ0IA0KIA0KIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gTmV0d29yayBEZXNpZ24gUmVxdWlyZW1lbnRz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMiANCiAgICAgIDIuMSBNdWx0aXBv aW50IE5ldHdvcmsgR2VuZXJhbCBBcHByb2FjaC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMgDQog ICAgICAyLjIgTUFORVQgR2VuZXJhbCBJc3N1ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4zIA0KICAgICAgMi4zIE1BTkVUIERhdGEtTGluayBMYXllciBDb25zaWRlcmF0 aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNCANCiAgICAgIDIuNCBNQU5FVCBOZXR3b3JrIExh eWVyIGNvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICAgICAyLjUg VW5pcXVlIElQdjYgY29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li41IA0KICAgMy4gQ29tYmluaW5nIE1BTkVUIGFuZCBST0hDIC0gU3BlY2lmaWMgQ2hhbGxlbmdl cy4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDQuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICBSZWZlcmVuY2VzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg QWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNyANCiAgIEF1dGhvcidzIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgDQogICAgDQoxLiBJbnRyb2R1Y3Rpb24g DQogICAgDQogICBSRkMgMzUwOSBbMl0sIGVudGl0bGVkICJST2J1c3QgSGVhZGVyIENvbXByZXNz aW9uIChST0hDKTogRnJhbWV3b3JrIA0KICAgYW5kIGZvdXIgcHJvZmlsZXM6IFJUUCwgVURQLCBF U1AsIGFuZCB1bmNvbXByZXNzZWQiIGdpdmVzIGEgZ29vZCANCiAgIG92ZXJ2aWV3IG9mIHRoZSBy ZXF1aXJlbWVudHMgZm9yIElQdjQgYW5kIElQdjYgaGVhZGVyIGNvbXByZXNzaW9uIGluIA0KICAg d2lyZWxlc3MgbmV0d29ya3MuIEl0IGRlc2NyaWJlcyB0aGUgdmFyaW91cyBpc3N1ZXMgYW5kIHJl cXVpcmVtZW50cyANCiAgIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgaW4gc3VjaCBhIG5ldHdv cmssIGFuZCBoYXMgbGVkIHRvIHRoZSANCiAgIGRldmVsb3BtZW50IG9mIGEgbnVtYmVyIG9mIGV4 dGVuc2lvbnMgdG8gdGhlIGJhc2UgcHJvdG9jb2wgWzNdIFs0XSANCiAgIFs1XSBbNl0uIA0KICAg IA0KICAgVGhlc2UgcHJvdG9jb2xzIHNwZWNpZmljYWxseSBhZGRyZXNzIG5ldHdvcmtzIGluIHdo aWNoIHRoZSBvbmx5LCBvciANCiAgIHRoZSBwcmltYXJ5LCBjb21tdW5pY2F0aW9uIHZlaGljbGUg aXMgYSBwb2ludC10by1wb2ludCByYWRpbyBsaW5rIA0KICAgd2l0aCBzaWduaWZpY2FudCBlcnJv ciByYXRlcywgYW5kIGxvbmcgcm91bmQtdHJpcCB0aW1lcy4gSW4gYWQgaG9jIA0KICAgcmFkaW8g bmV0d29ya3MgY29udGFpbmluZyBvciBjb250YWluZWQgd2l0aGluIGxhcmdlciBJUCBuZXR3b3Jr cywgDQogICBtYW55IG9mIHRoZSBjYXBhYmlsaXRpZXMgb2YgUk9IQyBhcmUgZGVzaXJhYmxlIGFu ZCBhcmd1YWJseSANCiAgIG5lY2Vzc2FyeSwgYnV0IGZvciBtYXhpbXVtIGVmZmljaWVuY3kgYWRk aXRpb25hbCBleHRlbnNpb25zIG5lZWQgdG8gDQogICBiZSBtYWRlIGZvciBwb2ludC10by1tdWx0 aXBvaW50IHRyYWZmaWMgc3VjaCBhcyBicm9hZGNhc3QgYW5kIA0KICAgbXVsdGljYXN0IHRyYWZm aWMuIA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBwb3NlcyB0aGUgaXNzdWVzIHRoYXQgbmVlZCB0 byBiZSBhZGRyZXNzZWQgdG8gbWFrZSBST0hDIA0KICAgd29yayB3ZWxsIGluIGEgbmV0d29yayBj b250YWluaW5nIGJvdGggdHJhZGl0aW9uYWwgcG9pbnQtdG8tcG9pbnQgDQogICAoY2VsbHVsYXIp IGFuZCBwb2ludCB0byBtdWx0aXBvaW50IChNQU5FVCkgcmFkaW8gbmV0d29yayB0b3BvbG9naWVz LiANCiAgICANCjIuIE5ldHdvcmsgRGVzaWduIFJlcXVpcmVtZW50cyANCiAgICANCiAgIEluIHRo ZSBwb3J0aW9ucyBvZiBuZXR3b3JrcyBsaW5rZWQgYnkgTUFORVQgY2FwYWJsZSByYWRpb3MsIHRo ZSByYWRpbyANCiAgIGZyZXF1ZW5jeSAoUkYpIHBoeXNpY2FsIG1lZGl1bSBpcyBlcnJvciBwcm9u ZSAoMTBeLTMgZXJyb3IgcmF0ZXMgYXJlIA0KICAgY29tbW9uKSwgZGF0YSByYXRlIGxpbWl0ZWQg KDI4OGticHMgb3IgbGVzcyBmb3IgbG9uZyByYW5nZSAxa20rIA0KICAgbW9iaWxlIGRhdGEgcmFk aW9zKSwgYW5kIGhpZ2ggZGVsYXkgKDEwcyB0byAxMDBzIG9mIG1pbGxpc2Vjb25kcyBwZXIgDQog ICBob3ApIG1lZGl1bSB3aGVuIGNvbXBhcmVkIHRvIHdpcmVkIG5ldHdvcmtzLiBXaGVuIG5ldHdv cmtzIGFyZSANCiAgIG9wZXJhdGluZyBvbiB0aGUgbW92ZSwgdGVycmFpbiBtYXNraW5nLCBmb2xp YWdlIHNjYXR0ZXJpbmcsIGFuZCB0aGUgDQoNCiANCiANCkdyZWVuICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgLSBPY3RvYmVyIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQoNCg0KDQoN CgwgICAgICAgICAgICAgUHJvYmxlbSBTdGF0ZW1lbnQ6IFJPSEMgaW4gTXVsdGlwb2ludCBNQU5F VCAgQXByaWwgMjAwNDQgDQogDQogDQogICBjaGFuZ2luZyBwcm9wYWdhdGlvbiBkaXN0YW5jZXMg YmV0d2VlbiBub2RlcyBhbGwgZXhhY2VyYmF0ZSBwYWNrZXQgDQogICBlcnJvcnMsIG5ldHdvcmsg b3V0YWdlcywgcm91dGVyIHRvcG9sb2d5IGNoYW5nZXMsIGFuZCBkZWxheXMuICANCiAgICANCiAg IER1ZSB0byB0aGUgYWQtaG9jIG5hdHVyZSBvZiBNQU5FVCBhcmNoaXRlY3R1cmVzLCB0aGUgcmFk aW8gc3lzdGVtIGlzIA0KICAgaW5oZXJlbnRseSBhIGJyb2FkY2FzdCBtZWRpdW0gd2hlcmUgYWxs IG5laWdoYm9yIHJhZGlvcyBtYXkgcmVjZWl2ZSANCiAgIHRoZSB0cmFuc21pc3Npb24gb2YgYW55 IHRyYW5zbWl0dGluZyByYWRpbyBpZiB0aGV5IGFyZSB3aXRoaW4gdGhlIFJGIA0KICAgcmFuZ2Ug b2YgdGhlIHRyYW5zbWl0dGVyLiBHaXZlbiB0aGUgaW5oZXJlbnQgYnJvYWRjYXN0IG5hdHVyZSBv ZiB0aGUgDQogICBSRiBtZWRpdW0sIE1BTkVUIHJhZGlvcyBtYXkgdHJhbnNtaXQgcG9pbnQtdG8t cG9pbnQgc3R5bGUgKHVuaWNhc3QpIA0KICAgbWVzc2FnZXMgdG8gc2luZ2xlIG5laWdoYm9ycyAo YW5kIG90aGVyIG5laWdoYm9ycyBkaXNjYXJkIHRoZSANCiAgIHRyYW5zbWlzc2lvbnMgbm90IG1l YW50IGZvciB0aGVtKSwgcG9pbnQtdG8tbXVsdGlwb2ludCAobXVsdGljYXN0KSANCiAgIG1lc3Nh Z2VzIHRvIGdyb3VwcyBvZiBuZWlnaGJvcnMgKG5laWdoYm9ycyBpbiB0aGUgbXVsdGlwb2ludCBn cm91cCANCiAgIGxpc3RlbiB0byB0aGUgbWVzc2FnZSB3aGlsZSBuZWlnaGJvcnMgbm90IGluIHRo ZSBncm91cCBkaXNjYXJkIHRoZSANCiAgIG1lc3NhZ2UpLCBvciBwb2ludC10by1hbGwgKGJyb2Fk Y2FzdCkgbWVzc2FnZXMgd2hpY2ggYXJlIHJlY2VpdmVkIGFuZCANCiAgIHByb2Nlc3NlZCBieSBh bGwgbmVpZ2hib3JzLiBUaGVzZSBjYXBhYmlsaXRpZXMgZW5hYmxlIHJhZGlvcyB0byANCiAgIHNl cnZpY2UgSW50ZXJuZXQgUHJvdG9jb2wgdW5pY2FzdCwgbXVsdGljYXN0LCBhbmQgYnJvYWRjYXN0 IHN0eWxlIA0KICAgbWVzc2FnZXMuICBTaW5jZSBtZXNzYWdpbmcgYXBwbGljYXRpb25zIGF0dGFj aGVkIHRvIE1BTkVUcyBvZnRlbiBuZWVkIA0KICAgdG8gc2VuZCBtZXNzYWdlcyB0byBtdWx0aXBs ZSBkZXN0aW5hdGlvbnMgd2l0aGluIHRoZSBNQU5FVCwgbXVsdGljYXN0IA0KICAgYW5kIGJyb2Fk Y2FzdCBtZXNzYWdlcyBhcmUgdXNlZCBoZWF2aWx5IGFzIHRoZXkgY29uc3VtZSBsZXNzIGRhdGEg DQogICBiYW5kd2lkdGggdGhhbiB0cmFuc21pdHRpbmcgbXVsdGlwbGUgcG9pbnQtdG8tcG9pbnQg dW5pY2FzdCBtZXNzYWdlcy4gDQogICAgIA0KICAgTUFORVQgbmV0d29ya3MgaGF2ZSB0aGUgc2Ft ZSBSRiBtZWRpdW0gY2hhcmFjdGVyaXN0aWNzIG9mIGhpZ2ggZXJyb3IgDQogICByYXRlcywgc2V2 ZXJlbHkgbGltaXRlZCBkYXRhIHJhdGVzLCBhbmQgaGlnaCBkZWxheSB0aGF0IHRoZSBST0hDIGJh c2UgDQogICBzcGVjaWZpY2F0aW9uIGFkZHJlc3NlcyB2aWEgcm9idXN0IFdpbmRvdy1iYXNlZCBM U0IgZW5jb2RpbmcuIE1BTkVUIA0KICAgbmV0d29ya3MgZGlmZmVyIGZyb20gdGhlIGN1cnJlbnQg ZXh0ZW5zaW9ucyBmb3IgUk9IQyBzaW5jZSB0aGV5IG11c3QgDQogICBzZXJ2aWNlLCBicm9hZGNh c3QgYW5kIG11bHRpY2FzdCBtZXNzYWdlcyBpbiBhZGRpdGlvbiB0byB1bmljYXN0IA0KICAgcG9p bnQtdG8tcG9pbnQgbWVzc2FnZXMuIFNpbmNlIHRoZSBSRiBwaHlzaWNhbCBtZWRpdW0gY2hhcmFj dGVyaXN0aWNzIA0KICAgYXJlIHdlbGwgYWRkcmVzc2VkIGJ5IFJPSEMsIGFuZCBvbmx5IHRoZSBj YXBhYmlsaXR5IHRvIGVmZmljaWVudGx5IA0KICAgc3VwcG9ydCBtdWx0aWNhc3QgYW5kIGJyb2Fk Y2FzdCB0cmFuc21pc3Npb25zIG1heSBub3Qgc3VwcG9ydGVkLCB3ZSANCiAgIHJlYXNvbiB0aGF0 IFJPSEMgbWF5IHByb3Blcmx5IHN1cHBvcnQgbXVsdGljYXN0IGFuZCBicm9hZGNhc3QgbGlua3Mg DQogICB3aXRoIGxpdHRsZSBvciBubyBtb2RpZmljYXRpb24uIA0KICAgIA0KMi4xIE11bHRpcG9p bnQgTmV0d29yayBHZW5lcmFsIEFwcHJvYWNoIA0KICAgIA0KICAgQSBub2RlIHNlbmRpbmcgYSBi cm9hZGNhc3Qgb3IgbXVsdGljYXN0IG1lc3NhZ2UgbmVlZHMgYSBtZXRob2QgdG8gDQogICBjaGVj ayBhbmQgc2VlIGlmIHRoZSBtZXNzYWdlIHJlY2lwaWVudHMgY29ycmVzcG9uZCB0byBjdXJyZW50 IGxheWVyIA0KICAgMS0yIChzaW5nbGUgaG9wKSBuZWlnaGJvcnMsIGFuZCBhIG1ldGhvZCB0byBs b29rIGludG8gYSBjb21wcmVzc2lvbiANCiAgIGNvbnRleHQgdGFibGUgdG8gZGV0ZXJtaW5lIGlm IGEgZnVsbCBoZWFkZXIgbmVlZHMgdG8gYmUgc2VudCBvciB3aGF0IA0KICAgbGV2ZWwgb2YgY29t cHJlc3Npb24gbWF5IGJlIHVzZWQuIEN1cnJlbnQgdW5pZGlyZWN0aW9uYWwtbW9kZSAodS0NCiAg IG1vZGUpIGNvbXByZXNzaW9uIGNhbiBzdXBwb3J0IG11bHRpcG9pbnQgZGF0YSBkaXNzZW1pbmF0 aW9uLCBidXQgDQogICBoaWdoZXIgbGV2ZWxzIG9mIGNvbXByZXNzaW9uIG1heSBiZSBnYWluZWQg dGhyb3VnaCBmZWVkYmFjayANCiAgIG1lY2hhbmlzbXMgaWYgdGhlIG1lY2hhbmlzbXMgZG8gbm90 IGNhdXNlIGV4Y2Vzc2l2ZSBvdmVyaGVhZC4gIA0KICAgQ29tcHJlc3Npb24gb24gcG9pbnQgdG8g bXVsdGlwb2ludCBsaW5rcyB3aWxsIHByb2JhYmx5IGhhdmUgYSBsb3dlciANCiAgIGF2ZXJhZ2Ug ZWZmaWNpZW5jeSB3aGVuIGNvbXBhcmVkIHRvIHBvaW50LXRvLXBvaW50IGxpbmtzLCBidXQgYSAN CiAgIHByb3Blcmx5IGRlc2lnbmVkIHNjaGVtZSBzaG91bGQgc2lnbmlmaWNhbnRseSBsb3dlciBJ UCBvdmVyaGVhZCBmb3IgDQogICBJUHY0IGFuZCB2NiBhbmQgcmVzdWx0IGluIGEgbmV0IHNhdmlu Z3MuIA0KICAgIA0KMi4yIE1BTkVUIEdlbmVyYWwgSXNzdWVzIA0KICAgIA0KICAgUkZDIDI1MDEg WzNdLCBpbiBzZWN0aW9uIDMsIGxpc3RzIGEgbnVtYmVyIG9mIGltcG9ydGFudCBwb2ludHMgYWJv dXQgDQogDQogDQpHcmVlbiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIC0gT2N0b2JlciAyMDA0 ICAgICAgICAgICAgICAgIFtQYWdlIDNdIA0KDQoNCg0KDQoMICAgICAgICAgICAgIFByb2JsZW0g U3RhdGVtZW50OiBST0hDIGluIE11bHRpcG9pbnQgTUFORVQgIEFwcmlsIDIwMDQ0IA0KIA0KIA0K ICAgTUFORVQgbmV0d29ya3MuIFRoZXkgaGF2ZSBkeW5hbWljIHRvcG9sb2dpZXMsIHdoaWNoIGlz IHRvIHNheSB0aGF0IGEgDQogICBzeXN0ZW0ncyBsaXN0IG9mIG5laWdoYm9yaW5nIGhvc3RzIGFu ZCByb3V0ZXJzIGNoYW5nZXMgZnJvbSB0aW1lIHRvIA0KICAgdGltZS4gVGhleSBhcmUgb2Z0ZW4g YmFuZHdpZHRoLWNvbnN0cmFpbmVkLCBib3RoIGJlY2F1c2UgdGhlIG1lZGl1bSANCiAgIGlzIHNo YXJlZCB3aXRoIG90aGVyIG5vZGVzIGFuZCBiZWNhdXNlIG9mIGxpbWl0YXRpb25zIG9mIHRoZSAN CiAgIHRlY2hub2xvZ3kuIFRoZXkgYXJlIGFsc28gb2Z0ZW4gcG93ZXItY29uc3RyYWluZWQgLSBh IG1hbiBwb3J0YWJsZSANCiAgIE1BTkVUIHN5c3RlbSBjYXJyaWVkIGJ5IGEgcGVyc29uIGlzIHJ1 bm5pbmcgb24gaXRzIGJhdHRlcnksIGFuZCB0aGUgDQogICBzaW1wbGUgYWN0IG9mIHRyYW5zbWlz c2lvbiBjYW4gYmUgYSBtYWpvciBwb3dlciBkcmFpbi4gVGhleSBhbHNvIA0KICAgZW5qb3kgbGlt aXRlZCBzZWN1cml0eTogZXZlbiBpZiBsb2NrZWQgaW4gYSByb29tLCB0aGVpciByYWRpbyANCiAg IHRyYW5zbWlzc2lvbnMgY2FuIGJlIGEgYmVhY29uIGlkZW50aWZ5aW5nIHRoZWlyIGxvY2F0aW9u IG9yIGdpdmluZyANCiAgIGF3YXkgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGZyZXF1ZW5jeSBhbmQg UkYgd2F2ZWZvcm0gd2l0aCB3aGljaCB0aGV5IA0KICAgdHJhbnNtaXQuICANCiAgICANCiAgIEZy b20gdGhlIHBlcnNwZWN0aXZlIG9mIGFkYXB0aW5nIGFuIGV4aXN0aW5nIGhlYWRlciBjb21wcmVz c2lvbiANCiAgIHByb3RvY29sLCB0aGVzZSBNQU5FVCBjaGFyYWN0ZXJpc3RpY3MgaGF2ZSBzcGVj aWZpYyBpbXBsaWNhdGlvbnMuIElmIA0KICAgdHJhbnNtaXNzaW9ucyBjb25zdW1lIHBvd2VyICYg YmFuZHdpZHRoIHdoaWxlIHBvdGVudGlhbGx5IA0KICAgY29tcHJvbWlzaW5nIHNlY3VyaXR5LCB1 bm5lY2Vzc2FyeSB0cmFuc21pc3Npb24gaXMgc29tZXRoaW5nIHRvIGJlIA0KICAgYXZvaWRlZC4g QXMgYSByZXN1bHQsIGlmIHRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdGhhdCBhIHBlZXIgbWlnaHQg DQogICBlc3RhYmxpc2ggY29tcHJlc3Npb24gY29udGV4dCAodXNpbmcgbXVsdGljYXN0IGFuZCBi cm9hZGNhc3QgdG8gDQogICBleGNoYW5nZSBjb21wcmVzc2lvbiBjb250ZXh0IGluZm9ybWF0aW9u IHRvIG11bHRpcGxlIG5laWdoYm9ycyANCiAgIHNpbXVsdGFuZW91c2x5LCBwaWdneWJhY2tpbmcg Y29tcHJlc3Npb24gb24gbWVzc2FnZXMgZm9yIG5laWdoYm9yIA0KICAgZGlzY292ZXJ5IG9yIHJv dXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2UsIGV0Yy4pLCBzZWxlY3RpbmcgdGhlIG9uZSANCiAg IHRoYXQgdXNlcyB0aGUgbGVhc3QgcG93ZXIgYW5kIGJhbmR3aWR0aCB3aWxsIGhhdmUgdGhlIGxl YXN0IGltcGFjdCAtIA0KICAgYXQgbGVhc3QgbGVzcyBpbXBhY3QgdGhhbiBhbGxvd2luZyBkdXBs aWNhdGVzLiBJZiB0aGUgbmV0d29yayBpcyANCiAgIGJhbmR3aWR0aC1jb25zdHJhaW5lZCwgbGlt aXRpbmcgdHJhbnNtaXNzaW9ucyBhbHNvIHByZXNlcnZlcyANCiAgIGJhbmR3aWR0aCBmb3Igb3Ro ZXIgdXNlcywgYW5kIGNvbXByZXNzaW5nIGRhdGEgaW4gd2F5cyB0aGF0IG1heGltaXplIA0KICAg YXZhaWxhYmxlIGJhbmR3aWR0aCBpcyBleHRyZW1lbHkgaGVscGZ1bC4gU2VjdXJpdHkgdGhyZWF0 cyBuZWVkIHRvIGJlIA0KICAgYWN0aXZlbHkgYWRkcmVzc2VkLCBhbmQgaW4gcmVnaW9ucyBvZiBy YXBpZCBuZXR3b3JrIGNoYW5nZSwgb3IgZHVyaW5nIA0KICAgcGVyaW9kcyBvZiByYXBpZCBuZXR3 b3JrIGNoYW5nZSwgdGhlIHRyYW5zbWlzc2lvbiBhbmQgY29tcHV0YXRpb24gDQogICBsb2FkcyBu ZWVkIHRvIGJlIG1pbmltaXplZC4gVGhlc2UgaXNzdWVzIGFyZSBvZnRlbiBkZWVtZWQgdW5pbXBv cnRhbnQgDQogICBpbiBwcm90b2NvbHMgZGVzaWduZWQgZm9yIGZpeGVkIHVzYWdlLiANCiAgICAN CjIuMyBNQU5FVCBEYXRhLUxpbmsgTGF5ZXIgQ29uc2lkZXJhdGlvbnMgDQogICAgDQogICBNQU5F VCBjYXBhYmxlIHJhZGlvcyBtYXkgYmUgYmFzZWQgb24gY29tbW9uIGNvbW1lcmNpYWwgdGVjaG5v bG9neSANCiAgIHN1Y2ggYXMgODAyLjExLCBlbWVyZ2VuY3kgc2VydmljZSBvciBtaWxpdGFyeSBy YWRpb3MsIG9yIG90aGVyIA0KICAgdGVjaG5vbG9naWVzLiBEZXNwaXRlIHRoZSB2YXJpYXRpb25z IGluIHJhZGlvIHRlY2hub2xvZ3ksIHRoZSByYWRpb3MgDQogICBhcmUgdXN1YWxseSBidWlsdCB1 c2luZyBhIHNtYWxsIHNldCBvZiBsaW5rLWxheWVyIHRlY2hub2xvZ2llcy4gTGluayANCiAgIGxh eWVyIGFzc2lzdGVkIHNjaGVtZXMgd2lsbCB2YXJ5IGJldHdlZW4gcmFkaW9zLCBvciBpbiB0aGUg Y2FzZSBvZiANCiAgIEpUUlMgYW5kIG90aGVyIHNvZnR3YXJlIGRlZmluZWQgcmFkaW9zOyB0aGV5 IHdpbGwgdmFyeSBhcyB0aGUgDQogICBzb2Z0d2FyZSBkZWZpbmVkIHdhdmVmb3JtIGNoYW5nZXMu IA0KICAgIA0KICAgR2VuZXJhbCBzaW1pbGFyaXRpZXMgb2YgbW9zdCBNQU5FVCBSYWRpb3M6IA0K ICAgKkRhdGEgTGluayAoTG9naWNhbCBMaW5rIENvbnRyb2wgc3ViIGxheWVyKSBQcm90b2NvbHMg c3VjaCBhcyBBUlAsIA0KICAgUkFSUCwgUkRJU0MgYXJlIGNvbW1vbiBhbmQgbWF5IGJlIGxldmVy YWdlZCBieSBtdWx0aXBvaW50IFJPSEMgDQogICAgIA0KICAgR2VuZXJhbCBkaWZmZXJlbmNlcyBi ZXR3ZWVuIG1vc3QgTUFORVQgUmFkaW9zOiANCiAgICpDaGFubmVsIGFjY2VzcyBwcm90b2NvbHMg dmFyeSBiZXR3ZWVuIENTTUEsIENETUEsIFRETUEsIGFuZCBoeWJyaWQgDQogICBzY2hlbWVzICAN CiAgICANCiANCiANCkdyZWVuICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgLSBPY3RvYmVyIDIw MDQgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoNCg0KDQoNCgwgICAgICAgICAgICAgUHJvYmxl bSBTdGF0ZW1lbnQ6IFJPSEMgaW4gTXVsdGlwb2ludCBNQU5FVCAgQXByaWwgMjAwNDQgDQogDQog DQogICAqTUFDIEZyYW1lIEZvcm1hdHMgb2Z0ZW4gdmFyeSANCiAgICANCjIuNCBNQU5FVCBOZXR3 b3JrIExheWVyIGNvbnNpZGVyYXRpb25zIA0KICAgKk1BTkVUUyBvcGVyYXRlIG9uIG1hbnkgZGlm ZmVyZW50IGV4cGVyaW1lbnRhbCByb3V0aW5nIHByb3RvY29scyANCiAgIChBT0RWLCBPTFNSLCBU QlJQRiwgT1NQRiB3aXRoIE1BTkVUIGV4dGVuc2lvbnMsIGFuZCBvdGhlcnMpIHNpbmNlIA0KICAg dGhlcmUgaXMgbm8gSUVURiBzdGFuZGFyZHMtdHJhY2sgTUFORVQgcHJvdG9jb2wgDQogICAgDQog ICAqTUFORVQgcHJvdG9jb2xzIHRoYXQgbWFpbnRhaW4gYWN0aXZlIG5laWdoYm9yIGxpc3RzIG1h eSBwcm92aWRlIHRoZSANCiAgIG5laWdoYm9yIHN0YXRlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBj aGVjayBhZ2FpbnN0IG11bHRpcG9pbnQgDQogICByZWNpcGllbnRzIHRvIGRldGVybWluZSBpZiBh IGNvbXByZXNzaW9uIGNvbnRleHQgaXMgZXN0YWJsaXNoZWQuIA0KICAgIA0KMi41IFVuaXF1ZSBJ UHY2IGNvbnNpZGVyYXRpb25zICANCiAgICpGb3IgaW5mb3JtYXRpb24gb24gSVB2NiByZWZlcmVu Y2UgWzddIA0KICAgKkxhcmdlciBhZGRyZXNzZXMgbWFrZSBoZWFkZXIgY29tcHJlc3Npb24gYSBt b3JlIHVyZ2VudCBuZWVkIA0KICAgKkF1dG9tYXRpYyBhZGRyZXNzIHJlYXNzaWdubWVudCB2aWEg YXV0b2Rpc2NvdmVyeSBhbmQgDQogICBhdXRvY29uZmlndXJhdGlvbiBjb3VsZCBpbXBhY3QgaGVh ZGVyIGNvbXByZXNzaW9uIA0KICAgKklQdjYgbmVpZ2hib3IgZGlzY292ZXJ5IChuZWlnaGJvciBz b2xpY2l0YXRpb24gYW5kIA0KICAgYWR2ZXJ0aXNlbWVudCkoUkZDIDI0NjEpIFs4XSBjb3VsZCBi ZSBhbiBlbmFibGluZyBtZWNoYW5pc20gdG8gZ2F0aGVyIA0KICAgaW5mb3JtYXRpb24gb24gbmVp Z2hib3JzIA0KICAgIA0KICAgIA0KMy4gQ29tYmluaW5nIE1BTkVUIGFuZCBST0hDIC0gU3BlY2lm aWMgQ2hhbGxlbmdlcyANCiANCiAgICpEZXRlcm1pbmluZyBpZiBtZXNzYWdlcyByZXF1aXJlIGJy b2FkY2FzdCBvciBtdWx0aWNhc3Qgc3VwcG9ydCANCiAgICpEZXRlcm1pbmluZy9kaXNjb3Zlcmlu ZyBuZWlnaGJvcnMgdG8gZXN0YWJsaXNoIGNvbXByZXNzaW9uIGNvbnRleHRzICANCiAgICpNZXRo b2QgZm9yIGNyb3NzY2hlY2tpbmcgbXVsdGljYXN0IG1lc3NhZ2UgcmVjaXBpZW50cyBhZ2FpbnN0 IA0KICAgbmVpZ2hib3IgdGFibGVzIA0KICAgKlUtbW9kZSBwcm9iYWJseSB3aWxsIHdvcmsgZm9y IGEgbG93IGxldmVsIG9mIGNvbXByZXNzaW9uIA0KICAgKlRvIGdldCBoaWdoZXIgZWZmaWNpZW5j eSwgd2UgbWlnaHQgbmVlZCB0byByZWRlc2lnbiB0aGUgZmVlZGJhY2sgDQogICBsb2dpYyBmb3Ig YmktZGlyZWN0aW9uYWwgbW9kZXMgdG8gaGFuZGxlIG11bHRpcG9pbnQgbGlua3Mgd2l0aG91dCAN CiAgIGdlbmVyYXRpbmcgY29sbGlzaW9ucyBvciBjb25nZXN0aW9uIGluIGRlbnNlIG5ldHdvcmtz ICANCiAgICpJbXBhaXJtZW50IGNvbnNpZGVyYXRpb25zIGZvciBtdWx0aXBvaW50IGxpbmtzIA0K ICAgKk1ldGhvZCBmb3IgY29udGV4dCByZXBhaXIgZm9yIG11bHRpcG9pbnQgbGlua3MgDQogDQog ICAgDQo0LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCiAgICANCiAgIEFzIGEgcHJvYmxlbSBz dGF0ZW1lbnQsIHRoaXMgbm90ZSBpbXBvc2VzIG5vIG5ldyBzZWN1cml0eSANCiAgIHJlcXVpcmVt ZW50cyBvbiBNQU5FVCBuZXR3b3JrcyB0aGF0IGFyZSBub3Qga25vd24gZnJvbSBSRkMgMjUwMSBb M10uIA0KICAgVGhvc2UgcHJvYmxlbXMgY2FuLCBob3dldmVyLCBiZSBleHRyZW1lLiBSRkMgMjUw MSdzIA0KICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgcmVhZDogDQogICAgICAgDQogICAgICCT TW9iaWxlIHdpcmVsZXNzIG5ldHdvcmtzIGFyZSBnZW5lcmFsbHkgbW9yZSBwcm9uZSB0byBwaHlz aWNhbCANCiAgICAgIHNlY3VyaXR5IHRocmVhdHMgdGhhbiBhcmUgZml4ZWQsIGhhcmR3aXJlZCBu ZXR3b3Jrcy4gRXhpc3RpbmcgDQogICAgICBsaW5rLWxldmVsIHNlY3VyaXR5IHRlY2huaXF1ZXMg KGUuZy4gZW5jcnlwdGlvbikgYXJlIG9mdGVuIA0KICAgICAgYXBwbGllZCB3aXRoaW4gd2lyZWxl c3MgbmV0d29ya3MgdG8gcmVkdWNlIHRoZXNlIHRocmVhdHMuIEFic2VudCANCiAgICAgIGxpbmst bGV2ZWwgZW5jcnlwdGlvbiwgYXQgdGhlIG5ldHdvcmsgbGF5ZXIsIHRoZSBtb3N0IHByZXNzaW5n IA0KICAgICAgaXNzdWUgaXMgb25lIG9mIGludGVyLXJvdXRlciBhdXRoZW50aWNhdGlvbiBwcmlv ciB0byB0aGUgZXhjaGFuZ2UgDQogICAgICBvZiBuZXR3b3JrIGNvbnRyb2wgaW5mb3JtYXRpb24u ICBTZXZlcmFsIGxldmVscyBvZiBhdXRoZW50aWNhdGlvbiANCiANCiANCkdyZWVuICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgLSBPY3RvYmVyIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgNV0g DQoNCg0KDQoNCgwgICAgICAgICAgICAgUHJvYmxlbSBTdGF0ZW1lbnQ6IFJPSEMgaW4gTXVsdGlw b2ludCBNQU5FVCAgQXByaWwgMjAwNDQgDQogDQogDQogICAgICByYW5naW5nIGZyb20gbm8gc2Vj dXJpdHkgKGFsd2F5cyBhbiBvcHRpb24pIGFuZCAgICAgICBzaW1wbGUgDQogICAgICBzaGFyZWQt a2V5IGFwcHJvYWNoZXMsIHRvIGZ1bGwgcHVibGljIGtleSBpbmZyYXN0cnVjdHVyZS1iYXNlZCAN CiAgICAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgd2lsbCBiZSBleHBsb3JlZCBieSB0aGUg Z3JvdXAuICBBcyBhbiANCiAgICAgIGFkanVuY3QgdG8gdGhlIHdvcmtpbmcgZ3JvdXBzIGVmZm9y dHMsIHNldmVyYWwgb3B0aW9uYWwgDQogICAgICBhdXRoZW50aWNhdGlvbiBtb2RlcyBtYXkgYmUg c3RhbmRhcmRpemVkIGZvciB1c2UgaW4gTUFORVRzLpQgDQogICAgDQogICBOb3RlLCBob3dldmVy LCB0aGF0IHRoZSBpc3N1ZXMgdGhhdCByb3V0aW5nIGluIGEgd2lyZWxlc3MgbmV0d29yayBhcmUg DQogICB2ZXJ5IHZ1bG5lcmFibGUgdG8gYXR0YWNrLCBhbmQgYXBwcm9wcmlhdGUgc2VjdXJpdHkg aXNzdWVzIG5lZWQgdG8gYmUgDQogICB0YWtlbiBzZXJpb3VzbHkuIA0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIA0KICAgIA0KUmVmZXJlbmNlcyANCiAgICANCiAgICAgICAgICAgICAgICAg ICAgIA0KICAgMSAgQnJhZG5lciwgUy4sICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3Mg LS0gUmV2aXNpb24gMyIsIEJDUCANCiAgICAgIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuIA0K ICAgIA0KICAgMiAgQm9ybWFubiwgQy4sIEJ1cm1laXN0ZXIsIEMuLCBEZWdlcm1hcmssIE0uLCBG dWt1c2hpbWEsIEguLCBIYW5udSwgDQogICAgICBILiwgSm9uc3NvbiwgTC1FLiwgSGFrZW5iZXJn LCBSLiwgS29yZW4sIFQuLExlLCBLLiwgTGl1LCBaLiwgDQogICAgICBNYXJ0ZW5zc29uLCBBLiwg TWl5YXpha2ksIEEuLCBTdmFuYnJvLCBLLiwgV2llYmtlLCBULiwgWW9zaGltdXJhLCANCiAgICAg IFQuIGFuZCBILiBaaGVuZywgIlJvYnVzdCBIZWFkZXIgQ29tcHJlc3Npb24gKFJPSEMpOiBGcmFt ZXdvcmsgYW5kIA0KICAgICAgZm91ciBwcm9maWxlczogUlRQLCBVRFAsIEVTUCwgYW5kIHVuY29t cHJlc3NlZCIsIFJGQyAzMDk1LCBKdWx5IA0KICAgICAgMjAwMS4gDQogICAgDQogICAzICBEZWdl cm1hcmssIE0uLCAiUmVxdWlyZW1lbnRzIGZvciBJUC9VRFAvUlRQIEhlYWRlciBDb21wcmVzc2lv biIsIA0KICAgICAgUkZDIDMwOTYsIEp1bHkgMjAwMS4gDQogICAgDQogICA0ICBKb25zc29uLCBM LUUuLCAiUk9idXN0IEhlYWRlciBDb21wcmVzc2lvbiAoUk9IQyk6IFJlcXVpcmVtZW50cyBhbmQg DQogICAgICBBc3N1bXB0aW9ucyBmb3IgMC1ieXRlIElQL1VEUC9SVFAgQ29tcHJlc3Npb24iLCBS RkMgMzI0MywgQXByaWwgDQogICAgICAyMDAyLiANCiAgICANCiAgIDUgIEMuIEJvcm1hbm4sICJS b2J1c3QgSGVhZGVyIENvbXByZXNzaW9uIChST0hDKSBvdmVyIFBQUCIsIFJGQyAzMjQxLCANCiAg ICAgIEFwcmlsIDIwMDIuIA0KICAgIA0KICAgNiAgSm9uc3NvbiwgTC4gYW5kIEcuIFBlbGxldGll ciwgIlJPYnVzdCBIZWFkZXIgQ29tcHJlc3Npb24gKFJPSEMpOiBBIA0KICAgICAgY29tcHJlc3Np b24gcHJvZmlsZSBmb3IgSVAiLCBJbnRlcm5ldCBkcmFmdCAod29yayBpbiBwcm9ncmVzcyksIA0K ICAgICAgT2N0b2JlciAyMDAzLCA8ZHJhZnQtaWV0Zi1yb2hjLWlwLSBvbmx5LTA1LnR4dD4gDQog ICAgDQogICA3ICBEZWVyaW5nLCBTLiBhbmQgUi4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2ws IFZlcnNpb24gKElQdjYpIA0KICAgICAgU3BlY2lmaWNhdGlvbiIsIFJGQyAyNDYwLCBEZWNlbWJl ciAxOTk4LiANCiAgICANCiAgIDggIE5hcnRlbiwgVC4sIE5vcmRtYXJrLCBFLiwgU2ltcHNvbiwg Vy4sIGFuZCBEYXlkcmVhbWVyLCAiTmVpZ2hib3IgDQogICAgICBEaXNjb3ZlcnkgZm9yIElwdjYi LCBSRkMgMjQ2MSwgRGVjZW1iZXIgMTk5OCANCiAgICANCg0KIA0KIA0KR3JlZW4gICAgICAgICAg ICAgICAgICAgRXhwaXJlcyAtIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSA2XSAN Cg0KDQoNCg0KDCAgICAgICAgICAgICBQcm9ibGVtIFN0YXRlbWVudDogUk9IQyBpbiBNdWx0aXBv aW50IE1BTkVUICBBcHJpbCAyMDA0NCANCiANCiANCiAgIFBvcnRpb25zIG9mIHRoaXMgZG9jdW1l bnQgaW4gaXRzIGN1cnJlbnQgc3RhdGUgaGF2ZSBiZWVuIHRha2VuIA0KICAgZGlyZWN0bHkgZnJv bSBodHRwOi8vd3d3LmlldGYub3JnL0RyYWZ0LVN0YXRlbWVudHMvZHJhZnQtYmFrZXItbWFuZXQt DQogICBvc3BmLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dCAgYXMgdGhpcyBkb2N1bWVudCByZWxh dGVzIHRvIGNyZWF0aW5nIA0KICAgYW4gT1NQRi1NQU5FVCByb3V0aW5nIHByb3RvY29sIGFuZCBt YW55IGdlbmVyYWwgY29uc2lkZXJhdGlvbnMgaW4gDQogICBCYWtlcidzIHByb2JsZW0gc3RhdGVt ZW50IG92ZXJsYXAgd2l0aCBjb25zaWRlcmF0aW9ucyBmb3IgZGV2ZWxvcGluZyANCiAgIGEgTUFO RVQgY29tcHJlc3Npb24gcHJvdG9jb2wuIA0KICAgIA0KICAgIA0KQWNrbm93bGVkZ21lbnRzIA0K ICAgIA0KICAgSW5pdGlhbCBjb21tZW50cyB3ZXJlIHJlY2VpdmVkIGZyb20gVG9tbXkgTHVuZGVt bywgSmVzdXMgQXJhbmdvLCBGcmVkIA0KICAgVGVtcGxpbiwgYW5kIFBldGUgU2hvbGFuZGVyIHRv IGhlbHAgZGVmaW5lIHRoaXMgcHJvYmxlbS4gDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNz ZXMgDQogICAgDQogICBEYXZpZCBHcmVlbiANCiAgIFNSSSBJbnRlcm5hdGlvbmFsIA0KICAgMzMz IFJhdmVuc3dvb2QgQXZlIA0KICAgTWVubG8gUGFyaywgQ2FsaWZvcm5pYSAgOTQwMjUgVVNBIA0K ICAgUGhvbmU6ICsxLTczMi01MzItNjcxNSANCiAgIEZheDogICArMS03MzItNDI3LTIwNjUgDQog ICBFTWFpbDogZGF2aWQuZ3JlZW5Ac3JpLmNvbSANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogDQogDQpHcmVlbiAgICAgICAgICAgICAgICAgICBF eHBpcmVzIC0gT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDddIA0KDQoNCg0KDQoM --NextPart_Webmail_9m3u9jl4l_1022_1081203407-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Apr 6 08:08:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09477 for ; Tue, 6 Apr 2004 08:08:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BApMq-0004AF-V7 for rohc-archive@odin.ietf.org; Tue, 06 Apr 2004 08:07:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36C7mrG016007 for rohc-archive@odin.ietf.org; Tue, 6 Apr 2004 08:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BApMq-0004A6-Em for rohc-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 08:07:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09334 for ; Tue, 6 Apr 2004 08:07:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BApMp-0000YM-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 08:07:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAp7W-0005E4-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 07:51:58 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAoYk-0002Md-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 07:16:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAoYl-0006mb-1x for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 07:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoYj-0000I9-8E; Tue, 06 Apr 2004 07:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoXn-0008UG-Av for rohc@optimus.ietf.org; Tue, 06 Apr 2004 07:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05597 for ; Tue, 6 Apr 2004 07:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoXm-00027y-00 for rohc@ietf.org; Tue, 06 Apr 2004 07:15:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoRB-0000t4-00 for rohc@ietf.org; Tue, 06 Apr 2004 07:08:14 -0400 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1BAoCQ-00060S-00 for rohc@ietf.org; Tue, 06 Apr 2004 06:52:58 -0400 Received: (wp-smtpd smtp.wp.pl 20369 invoked from network); 6 Apr 2004 12:52:24 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 6 Apr 2004 12:52:24 +0200 Date: Tue, 6 Apr 2004 12:52:22 +0200 From: "Pawel Szymanski" To: zhigang.c.liu@nokia.com Cc: Kavitha.KR@lntinfotech.com, rohc@ietf.org Subject: Odp: RE: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Extension 3 Message-ID: <40728be625508@wp.pl> References: <7B5AF06E216CB74DA8A5960A3181B5B8153739@ajebe001.americas.nokia.com> In-reply-to: <7B5AF06E216CB74DA8A5960A3181B5B8153739@ajebe001.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.172.152 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA05598 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Zhigang, I agree with you.=20 The clarifications you proposed are reasonable and they will definietly f= ix the=20 problem. Regards=20 Pawel > My suggestion would be to clarify the following in the implementation g= uide. > Comments? > - Text on Extension 3 in section 5.7.5 should read context(TS_STRIDE) > - When a compressor uses Extension 3 to re-establish a new value for=20 TS_STRIDE, > it must send unscaled TS and TS_STRIDE for some packets until decompres= sor > confidence is obtained. In other words, Tsc must be set to 0 (zero) in=20 Extension > 3 when TS_STRIDE field is present. >=20 > BR, > Zhigang >=20 ---------------------------------------------------- Fani zespo=B3u Metallica =B3=B1czcie si=EA! Do=B3=B1czamy do majowego kon= certu! http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.html%3Fidn%3= D829&sid=3D157 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Apr 6 14:08:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12901 for ; Tue, 6 Apr 2004 14:08:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuyu-0008Bt-3i for rohc-archive@odin.ietf.org; Tue, 06 Apr 2004 14:08:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36I7Icn031403 for rohc-archive@odin.ietf.org; Tue, 6 Apr 2004 14:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAu0m-00042X-Nz for rohc-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 13:05:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06258 for ; Tue, 6 Apr 2004 13:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAu0P-0001QQ-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 13:04:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAtdG-0006gi-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 12:41:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAt32-0004y1-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 12:03:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAt0Z-0002AC-3G; Tue, 06 Apr 2004 12:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAszZ-0001lZ-1h for rohc@optimus.ietf.org; Tue, 06 Apr 2004 12:00:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29893 for ; Tue, 6 Apr 2004 11:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAszX-0004OV-00 for rohc@ietf.org; Tue, 06 Apr 2004 11:59:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAsO2-0000bw-00 for rohc@ietf.org; Tue, 06 Apr 2004 11:21:15 -0400 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BAs70-0005VG-00 for rohc@ietf.org; Tue, 06 Apr 2004 11:03:38 -0400 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i36E2rU2025521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Apr 2004 16:02:54 +0200 Message-ID: <4072C6B4.1080102@effnet.com> Date: Tue, 06 Apr 2004 17:03:16 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Szymanski CC: rohc@ietf.org Subject: Re: [rohc] ROHC context reuse & mode References: <4072c21351863@wp.pl> In-Reply-To: <4072c21351863@wp.pl> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by effnet.com id i36E2rU2025521 Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pawel. Comments inlined. Pawel Szymanski wrote: > Hi Kristofer, >=20 > I found in the mailing list archive an interesting discussion about con= text=20 > reuse (see http://www1.ietf.org/mail-archive/working- > groups/rohc/current/msg02000.html). >=20 > I am particulary interested in the procedure of handling IR packets wih= tout=20 > dynamic header chain. You gave the following rules of processing such p= ackets: >=20 > "* IR-no-dynchain packets (see 5.7.7 and 5.7.7.2 in RFC3095) > These packets (which will be transmitted without payload), only update = the=20 > static part of the context and are then to be discarded, and not passed= on to=20 > upper layers. Since we allow context to be kept by the decompressor whe= n IR=20 > packets are received, we feel that this should not have to invalidate t= he=20 > dynamic chain, and we propose adding one sentence (impl. guide again) t= o=20 > describe that these packets only update the static chain." >=20 > Do you know in what circumstances compressor may decide to send IR pack= et=20 > without the dynamic chain ? >=20 Some examples of _possible_ ways to use this (the 3095-authors might have= more=20 realistic examples to give): One possible usage is to actually construct IR-no-dyn-no-payload packets = even=20 when no data is received (either as a "keep-alive" or as initialization i= f the=20 flow's static info is somehow known a priori). Another possible use is to discard the data of the first few packets and = only=20 send the static chain to initialize the context (to save bandwidth/delay = at=20 initialization). The most likely use case for this should be links with a limited maximum = packet=20 size. > What should be the state of the context in decompressor after successfu= l=20 > processing of such a packet ? I can see three possible alternatives: >=20 > 1. The state is left unchanged - but when the decompressor was in NO_CO= NTEXT=20 > state. Since the decompressor know knowns the static chain it should ra= ther=20 > advance the state to the STATIC_CONTEXT state. >=20 > 2. The state is set to STATIC_CONTEXT - but when the decompressor was i= n=20 > FULL_CONTEXT and we assume that the packet does not invalidate the dyna= mic=20 > chain, downgrading the state is not a good solution. >=20 > 3. If the decompressor is in NO_CONTEXT state, the new state is set to=20 > STATIC_CONTEXT. Otherwise, the state is left unchanged. =20 >=20 I would say that alternative 3 is what we meant with the text you quote. = Since=20 the impl. guide has not yet been updated with this (partially due to lack= of=20 anyone commenting on it), we should make some text that makes this point = clear=20 as soon as we update it. Rgds, Kristofer Sandlund, Effnet AB > Regards >=20 > Pawel >=20 > ---------------------------------------------------- > Fani zespo=B3u Metallica =B3=B1czcie si=EA! Do=B3=B1czamy do majowego k= oncertu! > http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.html%3Fidn= %3D829&sid=3D157 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Apr 6 16:07:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23302 for ; Tue, 6 Apr 2004 16:07:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwqI-0007Sw-73 for rohc-archive@odin.ietf.org; Tue, 06 Apr 2004 16:06:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36K6gHh028694 for rohc-archive@odin.ietf.org; Tue, 6 Apr 2004 16:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwqH-0007Sj-0p for rohc-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:06:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23197 for ; Tue, 6 Apr 2004 16:06:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwqF-0002s3-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 16:06:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwCd-0004MW-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 15:25:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAvRE-0007Jy-00 for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 14:36:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAvRE-0003NK-BS for rohc-web-archive@ietf.org; Tue, 06 Apr 2004 14:36:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvNm-0002ub-D6; Tue, 06 Apr 2004 14:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAtJ1-00061B-OD for rohc@optimus.ietf.org; Tue, 06 Apr 2004 12:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28561 for ; Tue, 6 Apr 2004 11:22:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAsPT-0000tZ-00 for rohc@ietf.org; Tue, 06 Apr 2004 11:22:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAsAv-0006GQ-00 for rohc@ietf.org; Tue, 06 Apr 2004 11:07:43 -0400 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1BAro3-0002PY-00 for rohc@ietf.org; Tue, 06 Apr 2004 10:44:03 -0400 Received: (wp-smtpd smtp.wp.pl 26300 invoked from network); 6 Apr 2004 16:43:32 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 6 Apr 2004 16:43:32 +0200 Date: Tue, 6 Apr 2004 16:43:31 +0200 From: "Pawel Szymanski" To: kristofer.sandlund@effnet.com Cc: rohc@ietf.org Subject: [rohc] ROHC context reuse & mode Message-ID: <4072c21351863@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.172.152 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA28562 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kristofer, I found in the mailing list archive an interesting discussion about conte= xt=20 reuse (see http://www1.ietf.org/mail-archive/working- groups/rohc/current/msg02000.html). I am particulary interested in the procedure of handling IR packets wihto= ut=20 dynamic header chain. You gave the following rules of processing such pac= kets: "* IR-no-dynchain packets (see 5.7.7 and 5.7.7.2 in RFC3095) These packets (which will be transmitted without payload), only update th= e=20 static part of the context and are then to be discarded, and not passed o= n to=20 upper layers. Since we allow context to be kept by the decompressor when = IR=20 packets are received, we feel that this should not have to invalidate the= =20 dynamic chain, and we propose adding one sentence (impl. guide again) to=20 describe that these packets only update the static chain." Do you know in what circumstances compressor may decide to send IR packet= =20 without the dynamic chain ? What should be the state of the context in decompressor after successful=20 processing of such a packet ? I can see three possible alternatives: 1. The state is left unchanged - but when the decompressor was in NO_CONT= EXT=20 state. Since the decompressor know knowns the static chain it should rath= er=20 advance the state to the STATIC_CONTEXT state. 2. The state is set to STATIC_CONTEXT - but when the decompressor was in=20 FULL_CONTEXT and we assume that the packet does not invalidate the dynami= c=20 chain, downgrading the state is not a good solution. 3. If the decompressor is in NO_CONTEXT state, the new state is set to=20 STATIC_CONTEXT. Otherwise, the state is left unchanged. =20 Regards Pawel ---------------------------------------------------- Fani zespo=B3u Metallica =B3=B1czcie si=EA! Do=B3=B1czamy do majowego kon= certu! http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.html%3Fidn%3= D829&sid=3D157 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 7 10:19:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27581 for ; Wed, 7 Apr 2004 10:19:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDtZ-00058B-Rd for rohc-archive@odin.ietf.org; Wed, 07 Apr 2004 10:19:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37EJDHr019717 for rohc-archive@odin.ietf.org; Wed, 7 Apr 2004 10:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDtZ-00056o-4I for rohc-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 10:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27420 for ; Wed, 7 Apr 2004 10:19:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDtW-0002rY-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 10:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBD5E-0003NC-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 09:27:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBBdn-0002vF-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 07:54:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBBdo-0004Uu-5n for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 07:54:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBc8-0006dJ-RA; Wed, 07 Apr 2004 07:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBbx-0006WL-RQ for rohc@optimus.ietf.org; Wed, 07 Apr 2004 07:52:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14492 for ; Wed, 7 Apr 2004 07:52:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBbw-0002aZ-00 for rohc@ietf.org; Wed, 07 Apr 2004 07:52:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAoj-000348-00 for rohc@ietf.org; Wed, 07 Apr 2004 07:02:03 -0400 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1BB9NV-00026A-00 for rohc@ietf.org; Wed, 07 Apr 2004 05:29:49 -0400 Received: (wp-smtpd smtp.wp.pl 3570 invoked from network); 7 Apr 2004 11:29:19 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 7 Apr 2004 11:29:19 +0200 Date: Wed, 7 Apr 2004 11:29:18 +0200 From: "Pawel Szymanski" To: Kristofer Sandlund Cc: rohc@ietf.org Subject: Re: [rohc] ROHC context reuse & mode Message-ID: <4073c9eebeb7a@wp.pl> References: <4072c21351863@wp.pl> <4072C6B4.1080102@effnet.com> In-reply-to: <4072c21351863@wp.pl> <4072C6B4.1080102@effnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.173.87 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA14494 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kristofer, See my comments below =20 > > What should be the state of the context in decompressor after success= ful=20 > > processing of such a packet ? I can see three possible alternatives: > >=20 > > 1. The state is left unchanged - but when the decompressor was in=20 NO_CONTEXT=20 > > state. Since the decompressor know knowns the static chain it should = rather=20 > > advance the state to the STATIC_CONTEXT state. > >=20 > > 2. The state is set to STATIC_CONTEXT - but when the decompressor was= in=20 > > FULL_CONTEXT and we assume that the packet does not invalidate the dy= namic=20 > > chain, downgrading the state is not a good solution. > >=20 > > 3. If the decompressor is in NO_CONTEXT state, the new state is set t= o=20 > > STATIC_CONTEXT. Otherwise, the state is left unchanged. =20 > >=20 >=20 > I would say that alternative 3 is what we meant with the text you quote= .=20 Since=20 > the impl. guide has not yet been updated with this (partially due to la= ck of=20 > anyone commenting on it), we should make some text that makes this poin= t=20 clear=20 > as soon as we update it. >=20 > Rgds, > Kristofer Sandlund, Effnet AB >=20 But isn't the option 3 against the RFC 3095, as the decompressor state=20 transition diagram (section 5.3.2, page 57] does not show transition from= =20 NO_CONTEXT to STATIC_CONTEXT ? Regards Pawel ---------------------------------------------------- Przegl=B1d Piosenki Aktorskiej "Arty=B6ci Europy".=20 Wroc=B3aw 23.04 - 2.05.2004 r. Gwiazdy, spektakle, recitale, koncerty specjalne! http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fwww.ppa.art.pl%2Fsub-ppa= .php%3Fpid%3D65&sid=3D158 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 7 13:58:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20510 for ; Wed, 7 Apr 2004 13:58:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHId-0004JB-Gj for rohc-archive@odin.ietf.org; Wed, 07 Apr 2004 13:57:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HvJIr016562 for rohc-archive@odin.ietf.org; Wed, 7 Apr 2004 13:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH8t-0007bu-EV for rohc-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10769 for ; Wed, 7 Apr 2004 13:01:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGQi-0004mG-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 13:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBExF-0002PW-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 11:27:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBDyD-0003Z2-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 10:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDyE-0007qf-KE; Wed, 07 Apr 2004 10:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDxK-0007TA-Bb for rohc@optimus.ietf.org; Wed, 07 Apr 2004 10:23:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28192 for ; Wed, 7 Apr 2004 10:23:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDxH-0003Pb-00 for rohc@ietf.org; Wed, 07 Apr 2004 10:23:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBDBV-0004JT-00 for rohc@ietf.org; Wed, 07 Apr 2004 09:33:42 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BBBoL-00041b-00 for rohc@ietf.org; Wed, 07 Apr 2004 08:05:50 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i37C5aPA023097 for ; Wed, 7 Apr 2004 14:05:40 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 14:05:34 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <23ZHK0HC>; Wed, 7 Apr 2004 14:05:34 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'zhigang.c.liu@nokia.com'" , szym_paw@wp.pl, Kavitha.KR@lntinfotech.com Cc: rohc@ietf.org Subject: RE: [rohc] UOR-2 packets with TS_STRIDE and Tsc equal to 1 in Ext ension 3 Date: Wed, 7 Apr 2004 13:31:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-2" X-OriginalArrivalTime: 07 Apr 2004 12:05:34.0274 (UTC) FILETIME=[A176CA20:01C41C98] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Agreed, good summary!! I'll put this to my list of things to fix in the implementers guide. Rgds, /L-E > My suggestion would be to clarify the following in the > implementation guide. > Comments? > - Text on Extension 3 in section 5.7.5 should read context(TS_STRIDE) > - When a compressor uses Extension 3 to re-establish a new value for > TS_STRIDE, it must send unscaled TS and TS_STRIDE for some > packets until decompressor confidence is obtained. In other words, > Tsc must be set to 0 (zero) in Extension 3 when TS_STRIDE field is present. > > BR, > Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 7 13:58:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20559 for ; Wed, 7 Apr 2004 13:58:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBHJ3-0004R4-7t for rohc-archive@odin.ietf.org; Wed, 07 Apr 2004 13:57:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Hvjft017045 for rohc-archive@odin.ietf.org; Wed, 7 Apr 2004 13:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH8u-0007YX-W0 for rohc-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:47:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10757 for ; Wed, 7 Apr 2004 13:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGQf-0004lY-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 13:01:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBEx8-0002OY-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 11:27:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBDyC-0003Yz-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 10:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDyE-0007px-5C; Wed, 07 Apr 2004 10:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDxH-0007Oc-2N for rohc@optimus.ietf.org; Wed, 07 Apr 2004 10:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28172 for ; Wed, 7 Apr 2004 10:22:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDxE-0003Oz-00 for rohc@ietf.org; Wed, 07 Apr 2004 10:23:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBDBN-0004Hm-00 for rohc@ietf.org; Wed, 07 Apr 2004 09:33:34 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BBBo3-000403-00 for rohc@ietf.org; Wed, 07 Apr 2004 08:05:23 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i37C5MAh020094 for ; Wed, 7 Apr 2004 14:05:22 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 14:05:22 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <23ZHK0BD>; Wed, 7 Apr 2004 14:05:22 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Subject: RE: [Fwd: Re: [rohc] ROHC context reuse & mode] Date: Wed, 7 Apr 2004 13:28:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 07 Apr 2004 12:05:22.0229 (UTC) FILETIME=[9A48DE50:01C41C98] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Below... > -------- Original Message -------- > Subject: Re: [rohc] ROHC context reuse & mode > Date: Wed, 7 Apr 2004 11:29:18 +0200 > From: Pawel Szymanski > Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ > To: Kristofer Sandlund > CC: rohc@ietf.org > References: <4072c21351863@wp.pl> <4072C6B4.1080102@effnet.com> > > Hi Kristofer, > > See my comments below > > > > What should be the state of the context in decompressor > > > after successful processing of such a packet ? I can see > > > three possible alternatives: > > > > > > 1. The state is left unchanged - but when the decompressor > > > was in NO_CONTEXT state. Since the decompressor knowns > > > the static chain it should rather advance the state to > > > the STATIC_CONTEXT state. > > > > > > 2. The state is set to STATIC_CONTEXT - but when the > > > decompressor was in FULL_CONTEXT and we assume that > > > the packet does not invalidate the dynamic chain, > > > downgrading the state is not a good solution. > > > > > > 3. If the decompressor is in NO_CONTEXT state, the new > > > state is set to STATIC_CONTEXT. Otherwise, the state > > > is left unchanged. > > > > I would say that alternative 3 is what we meant with the > > text you quote. Since the impl. guide has not yet been > > updated with this (partially due to lack of anyone > > commenting on it), we should make some text that makes > > this point clear as soon as we update it. > > But isn't the option 3 against the RFC 3095, as the decompressor > state transition diagram (section 5.3.2, page 57] does not show > transition from NO_CONTEXT to STATIC_CONTEXT ? You are correct that this case is not covered by the figures, but the reason for that is just that there were never any real discussions about the purpose of having IR's without the dynamic chain. I wrote these state transition diagrams long before the packet formats were finally agreed, and the D-bit did not exist at that point in time. This is not the only thing in 3095 that became inconsistent as a result of the rather chaotic process of writing a 170 page specification among 16 authors in 6 months. So, I would say that the use of IR without a dynamic chain is not specified at all, but it could be useful to add something to the implementer's guide. As always, I would appreciate simple solutions and what Kristofer proposed seems reasonable. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 7 16:52:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02942 for ; Wed, 7 Apr 2004 16:52:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK2B-00037n-B6 for rohc-archive@odin.ietf.org; Wed, 07 Apr 2004 16:52:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37KqVV1012012 for rohc-archive@odin.ietf.org; Wed, 7 Apr 2004 16:52:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK2A-00037f-M4 for rohc-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 16:52:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02816 for ; Wed, 7 Apr 2004 16:52:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK28-0001EL-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 16:52:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHy4-00042R-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 14:40:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBH1d-0002v3-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 13:39:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGeD-0007T9-9R; Wed, 07 Apr 2004 13:15:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBEsn-00064s-RN for rohc@optimus.ietf.org; Wed, 07 Apr 2004 11:22:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02682 for ; Wed, 7 Apr 2004 11:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBEsV-0001ZF-00 for rohc@ietf.org; Wed, 07 Apr 2004 11:22:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBDnA-0001l9-00 for rohc@ietf.org; Wed, 07 Apr 2004 10:12:37 -0400 Received: from mailrelay2.lntinfotech.com ([203.199.54.34]) by ietf-mx with esmtp (Exim 4.12) id 1BBCnr-0001wM-00 for rohc@ietf.org; Wed, 07 Apr 2004 09:09:15 -0400 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004040718383561:10178 ; Wed, 7 Apr 2004 18:38:35 +0530 Subject: Re: [rohc] ROHC context reuse & mode To: Kristofer Sandlund , Pawel Szymanski Cc: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kavitha KR" Date: Wed, 7 Apr 2004 18:36:27 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 04/07/2004 06:36:27 PM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/07/2004 06:38:35 PM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 04/07/2004 06:39:14 PM, Serialize complete at 04/07/2004 06:39:14 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi all, >Some examples of _possible_ ways to use this (the 3095-authors might have more >realistic examples to give): >One possible usage is to actually construct IR-no-dyn-no-payload packets even >when no data is received (either as a "keep-alive" or as initialization if the >flow's static info is somehow known a priori). >Another possible use is to discard the data of the first few packets and only >send the static chain to initialize the context (to save bandwidth/delay at >initialization). >The most likely use case for this should be links with a limited maximum packet >size. ===> One another possible reason to send IR-no-dyn-no-payload packets could be something like this.The dynamic fields contain additional fields and flags like TIME_STRIDE, RND etc.The values of these fields & flags cannot be determined by the compressor until it has checked 2-3 packets from the IP layer. The compressor has to conduct some heuristical analysis on the packets to observe these values. In the meanwhile,compressor would like to initialize the static context at the decompressor, using IR-no-dyn-no-payload packets. Again,as Kristofer said, the authors should confirm what they really had in mind while designing such packets. > 1. The state is left unchanged - but when the decompressor was in NO_CONTEXT > state. Since the decompressor know knowns the static chain it should rather > advance the state to the STATIC_CONTEXT state. > 3. If the decompressor is in NO_CONTEXT state, the new state is set to > STATIC_CONTEXT. Otherwise, the state is left unchanged. ====> Are not options 1 & 3 same? >But isn't the option 3 against the RFC 3095, as the decompressor state >transition diagram (section 5.3.2, page 57] does not show transition from >NO_CONTEXT to STATIC_CONTEXT ? ===> Yes!! There is no transition from NC to SC according to section 5.3.2. Also, everywhere in the RFC, SC state is portrayed only as a state to come back from FC due to failures. But the diagram, showing decompressor states in section 4.3.2, shows double-headed arrow between NC & SC states. Isn't it contradicting? Regards, Kavitha _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 7 21:55:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06794 for ; Wed, 7 Apr 2004 21:55:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOlC-0002UF-3Q for rohc-archive@odin.ietf.org; Wed, 07 Apr 2004 21:55:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i381tI2x009554 for rohc-archive@odin.ietf.org; Wed, 7 Apr 2004 21:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOlB-0002TX-RV for rohc-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 21:55:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06602 for ; Wed, 7 Apr 2004 21:55:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOl8-0000hW-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 21:55:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNX8-0003ZM-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 20:36:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBLDO-0005GG-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 18:08:10 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBLDO-0003T4-OT for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 18:08:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLDM-0000z7-1t; Wed, 07 Apr 2004 18:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLCP-0000Ot-Gl for rohc@optimus.ietf.org; Wed, 07 Apr 2004 18:07:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15262 for ; Wed, 7 Apr 2004 18:07:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBLCM-00053X-00 for rohc@ietf.org; Wed, 07 Apr 2004 18:07:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBK0S-0000u6-00 for rohc@ietf.org; Wed, 07 Apr 2004 16:50:46 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BBHuB-0003WE-00 for rohc@ietf.org; Wed, 07 Apr 2004 14:36:07 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i37Ia7Ah030279 for ; Wed, 7 Apr 2004 20:36:07 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 20:36:07 +0200 Received: from caffreys (caffreys.ericsson.se [147.214.181.21]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQCLRDD; Wed, 7 Apr 2004 20:36:38 +0200 Date: Wed, 7 Apr 2004 20:41:36 +0200 (CEST) From: Vicknesan Ayadurai X-X-Sender: vick@caffreys.ericsson.se To: zhigang.c.liu@nokia.com cc: lars-erik.jonsson@ericsson.com, , Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B8153738@ajebe001.americas.nokia.com> Message-ID: <20040407112321.W245-100000@caffreys.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Apr 2004 18:36:07.0183 (UTC) FILETIME=[3090F1F0:01C41CCF] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Zhigang, Thanks for attempting to clarify the issue. I actually have some questions based on the the two examples you provided in another mail, which I'll address seperately. However, you had a specific question in this mail below: > Could you explain how the TS is decompressed in your implementation > when the decompressor receives a Type 0 packet? Decompression is always based on a successfully decompressed reference header (HDR_ref). The incoming Type 0 packet contains SN-bits (and no TS bits). Hence, a. SN_new = some f(SN_ref, SN-bits); /* obtain SN_new from SN-bits */ b. TS_new = TS_ref + (TS_STRIDE * (SN_new - SN_ref)); where TS_STRIDE would've been explicitly sent by the compressor sometime earlier. This usually works since the compressor should've determined that there was no need to send any TS-bits, and hence, sent the Type 0 packet (at least it worked when we interop'd with Nokia's implementation before :-) Is this how you perceive the decompressor to respond to a PT-0 packet, or is there an alternative method? Regards, vick On Mon, 5 Apr 2004 zhigang.c.liu@nokia.com wrote: > Hi Vick, > > > I further assumed that "slope" > > for the TS field was labelled TS_STRIDE, which my following text > > focuses upon. > > It becomes clear to me that this is the crux of the confusion. I've > tried to explain the difference between slope and TS_STRIDE in the > email below (in particular, please look at the end of email). Please > let me know if you have comments on that. > > http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02042.html > > Also, the text below (from section 5.7) indicates slope and TS_STRIDE > are two *independent* concepts, though they may have the same values > in certain cases. > > TS: The compressed RTP Timestamp value. > > If value(TIME_STRIDE) > 0, timer-based compression of the RTP > Timestamp is used (see section 4.5.4). > > If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before > compression (see section 4.5.3), and default-slope(TS) = 1. > > If value(Tsc) = 0, the Timestamp value is compressed as-is, and > default-slope(TS) = value(TS_STRIDE). > > > While this has all been my personal interpretation the "slope" and > > TS_STRIDE is, I'm probably not alone in this since it should be also > > pointed out that this has not been an issue during the four interops > > taken place so far. While we never explicitly tested for this, it > > would almost certainly have popped up if there were situations where > > the compressor and decompressor were both independently trying to > > figure out deltas/slopes/strides for TS. > > Could you explain how the TS is decompressed in your implementation > when the decompressor receives a Type 0 packet? > > For certain cases, the two interpretation can yield the same result. > That may explain why the issue has not been raised. However, I didn't > have time to follow ROHC interops. So, I don't know the details. One > thing I do know is that in Nokia's implementation (which I participated in > at beginning), scaling and compression (FO, SO, etc.) are two separate > steps. Unfortunately, Nokia's team were not able to participate in > all the four interops. > > BR, > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 7 21:56:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06914 for ; Wed, 7 Apr 2004 21:56:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOla-0002gp-Hr for rohc-archive@odin.ietf.org; Wed, 07 Apr 2004 21:55:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i381tgvV010337 for rohc-archive@odin.ietf.org; Wed, 7 Apr 2004 21:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOla-0002ge-Bm for rohc-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 21:55:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06716 for ; Wed, 7 Apr 2004 21:55:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOlX-0000ll-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 21:55:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNXg-0003ek-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 20:37:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBLDx-0005ME-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 18:08:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBLDx-0003Tm-QO for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 18:08:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLDU-00014v-EV; Wed, 07 Apr 2004 18:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLCu-0000k1-F2 for rohc@optimus.ietf.org; Wed, 07 Apr 2004 18:07:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15404 for ; Wed, 7 Apr 2004 18:07:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBLCr-0005A4-00 for rohc@ietf.org; Wed, 07 Apr 2004 18:07:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBK2C-0001F9-00 for rohc@ietf.org; Wed, 07 Apr 2004 16:52:33 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BBHyJ-00044I-00 for rohc@ietf.org; Wed, 07 Apr 2004 14:40:23 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i37IeMAh030690 for ; Wed, 7 Apr 2004 20:40:22 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 20:40:22 +0200 Received: from caffreys (caffreys.ericsson.se [147.214.181.21]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FC8DMA; Wed, 7 Apr 2004 20:41:15 +0200 Date: Wed, 7 Apr 2004 20:46:32 +0200 (CEST) From: Vicknesan Ayadurai X-X-Sender: vick@caffreys.ericsson.se To: zhigang.c.liu@nokia.com cc: lars-erik.jonsson@ericsson.com, , , , Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B8153737@ajebe001.americas.nokia.com> Message-ID: <20040407114806.E245-100000@caffreys.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Apr 2004 18:40:22.0687 (UTC) FILETIME=[C8DBC2F0:01C41CCF] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Zhigang, Thanks for providing the examples at the end of your mail below - this is definitely helpful to illustrate the problem (to me anyway). Based on your examples: > Example 1 (audio stream with TS_STRIDE = 160): > > <------ String 1 ------> <-- String 2 ---> > SN 11 12 13 14 ... 60 61 62 63 ... > TS 200 360 420 580 ... 8040 16040 16200 16360 ... > TS_SCALED 1 2 3 4 ... 50 100 101 102 ... > TS_OFFSET 40 40 40 40 40 40 40 40 ... > slope <-------- 1 ----------> <----- 1 -------> > offset <-------- (-10)--------> <----- (39) ----> > > Example 2 (video stream with TS_STRIDE = 3000): > > <------ String 1 ------> <-- String 2 ---> > SN 11 12 13 ... 25 26 27 28 ... > TS 4000 4000 4000 ... 4000 7000 7000 7000 ... > TS_SCALED 1 1 1 ... 1 2 2 2 ... > TS_OFFSET 1000 1000 1000 ... 1000 1000 1000 1000 ... > slope <-------- 0 ----------> <----- 0 -------> > offset <--------- 1 ----------> <----- 2 -------> What's a little un-clear is: a. how "offset" is computed above (esp for Ex2)? b. what are slope & offset between pkts 60/61 and 25/26? Finally, as I mentioned before, the RFC states that: ---- ... ... bits for each compressed TS. TS and TS_SCALED satisfy the following equality: TS = TS_SCALED * TS_STRIDE + TS_OFFSET TS_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to the decompressor. The following algorithm is used: ... ... ---- c. Since, as you noted in your examples, TS_SCALED, TS_STRIDE and TS_OFFSET are obtainable and subsequently, plugging them into the equation above should give TS. Hence, is there any particular reason why "slope" or "offset" is needed...? Regards, vick On Fri, 2 Apr 2004 zhigang.c.liu@nokia.com wrote: > Lars-Erik, > > Please see comments below. > > BR, > Zhigang > > > On the other hand, why should it not be possible to have a scaling > > FACTOR of 0. > > Because that is not what section 4.5.3 says. > > > to me the video example > > seems to be a reasonable argument for enforcing the TS_STRIDE > > definition from section 2, and thus allow it to be 0. > > Why did you say the video example is an argument for enforcing > the TS_STRIDE definition in section 2? Could you please elaborate? > > > This proposal still does not address the original concern about > > the concept of slopes not at all being defined in 3095. That is > > the major issue here, I think. > > OK. If the meaning of slope is not obvious to you, why don't we > have a clarification as follows? I also added other clarifications > to address other confusions I've seen so far. Now I'm risk of > being too verbose, but it seems the only way to avoid confusion. > Comments? > > ------------------------------------------------------------ > As it is described in section 4.5.3 and other places in RFC > 3095, TS_STRIDE is the factor by which an RTP Timestamp is > downscaled before compression. Obviously, it cannot be 0 (zero). > > The wording of TS_STRIDE definition in section 2 is confusing > and may be incorrectly interpreted as TS_STRIDE is always equal > to the increase in TS value between two RTP packets with > consecutive sequence number. This is not the intent of the > specification. It is the compressor that decides whether TS > scaling should be used and if yes, what is the best value of > TS_STRIDE. See section 4.5.3 for information. How this is done > is an implementation issue. However, an implementation must follow > section 4.5.3, 4.5.6 and 5.7 on how to initialize, encode, and > synchronize TS_STRIDE between the compressor and decompressor. > > Note: TS_STRIDE is not the same as slope described in section > 5.5.1.2 and 5.7. Here, slope has the general meaning in mathematics. > Namely, slope(X) equals the change of a non-SN field X between > two packets divided by the change of SN field between the same > two packets. It is one of the two parameters (the other one > being offset) that define a linear function from SN to field X. > The concept can also be visualized as a line, with SN being > the horizontal coordinate and the field X being the vertical > coordinate. For TS, this applies regardless whether it is scaled > or not. In case the TS is scaled, the linear function (or equivalently > its slope and offset) is from SN to the TS_SCALED. > > Note: it should be clear from section 4.5.3 that when scale is > used for TS, two steps are involved: 1) downscale of the > original TS to TS_SCALED; and 2) compression of TS_SCALED. > The decompressor follows the reverse procedure with two steps. > Following are two examples to further illustrate this. > > Example 1 (audio stream with TS_STRIDE = 160): > > <------ String 1 ------> <-- String 2 ---> > SN 11 12 13 14 ... 60 61 62 63 ... > TS 200 360 420 580 ... 8040 16040 16200 16360 ... > TS_SCALED 1 2 3 4 ... 50 100 101 102 ... > TS_OFFSET 40 40 40 40 40 40 40 40 ... > slope <-------- 1 ----------> <----- 1 -------> > offset <-------- (-10)--------> <----- (39) ----> > > Example 2 (video stream with TS_STRIDE = 3000): > > <------ String 1 ------> <-- String 2 ---> > SN 11 12 13 ... 25 26 27 28 ... > TS 4000 4000 4000 ... 4000 7000 7000 7000 ... > TS_SCALED 1 1 1 ... 1 2 2 2 ... > TS_OFFSET 1000 1000 1000 ... 1000 1000 1000 1000 ... > slope <-------- 0 ----------> <----- 0 -------> > offset <--------- 1 ----------> <----- 2 -------> > > Note: the default-slope(X) specified in section 5.7 is to be used > by the compressor and decompressor to initialize the slope of the > linear function from SN to field X. This is an optimization to > save synchronization overhead at the beginning of an RTP packet > stream. Namely, if the actual slope of X in the first string matches > the default-slope(X), the compressor can enter SO state and send > Type 0 packets once it is confident that one - instead of two in > the normal case - packet carrying field(X) has been correctly > decompressed by the decompressor. This is enough for the decompressor > to determine the other parameter, i.e. offset, for the linear function > from SN to X. After the fist string, the decompressor will update the > linear function from SN to X depending on how many packets carrying > field(X) have been correctly decompressed. If the number is 1, > the decompressor will assume the new slope(X) = previously established > slope(X), and the update offset(X) based on field(X) received. If the > number is 2, the decompressor will update both slope(X) and offset(X). > Note that the decompressor always uses the latest received packet(s) > to update the function. > > For instance, in Example 1 above, the compressor can enter SO state once > it is confident that one packet carrying TS has been correctly decompressed > by the decompressor. This is because the actual slope of TS (after scaling) > equals the default-slope. Of course, the TS_STRIDE = 3000 must be > synchronized also, which can be done within the same packet. > > Example 2 is different. The actual slope (= 0) of scaled TS does not equal > the default-slope (= 1). Therefore, during the first string of the packet > stream, the compressor has to ensure that two packets carrying TS info > have been correctly decompressed by the decompressor. This allows the > decompressor to establish both the slope and offset for function from > SN to scaled TS. However, for subsequent strings, only one correctly > decompressed packet is needed since slope = 0 has already been established > and thus can be reused. > -------------------------------------------------------------------- > > _______________________________________________ > 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 exim@www1.ietf.org Thu Apr 8 00:11:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13525 for ; Thu, 8 Apr 2004 00:11:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBQsV-0001Dz-2Y for rohc-archive@odin.ietf.org; Thu, 08 Apr 2004 00:10:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i384AxDd004708 for rohc-archive@odin.ietf.org; Thu, 8 Apr 2004 00:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBQsU-0001Dr-P0 for rohc-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 00:10:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13437 for ; Thu, 8 Apr 2004 00:10:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBQsS-0004xJ-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 00:10:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBOX7-0006PV-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 21:40:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBNBA-00018Y-00 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 20:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNBB-0000XK-GG; Wed, 07 Apr 2004 20:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNAT-0000Tu-Q3 for rohc@optimus.ietf.org; Wed, 07 Apr 2004 20:13:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21226 for ; Wed, 7 Apr 2004 20:13:15 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNAR-00013d-00 for rohc@ietf.org; Wed, 07 Apr 2004 20:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBKtx-0002mJ-00 for rohc@ietf.org; Wed, 07 Apr 2004 17:48:06 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BBJiH-0006RX-00 for rohc@ietf.org; Wed, 07 Apr 2004 16:31:57 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i37KVth09595; Wed, 7 Apr 2004 23:31:55 +0300 (EET DST) X-Scanned: Wed, 7 Apr 2004 23:31:36 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i37KVaJ7005312; Wed, 7 Apr 2004 23:31:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00m8JT9N; Wed, 07 Apr 2004 23:31:35 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i37KVYF00712; Wed, 7 Apr 2004 23:31:34 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Apr 2004 15:31:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Wed, 7 Apr 2004 16:31:30 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153740@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQcz26X2W3tBci6TOuqWavL5NoJWgADQs+Q To: Cc: , , X-OriginalArrivalTime: 07 Apr 2004 20:31:34.0350 (UTC) FILETIME=[517ABEE0:01C41CDF] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vick, > b. TS_new =3D TS_ref + (TS_STRIDE * (SN_new - SN_ref)); Here is what I had in mind (or section 4.5.3 meant to specify): Step 1: TS_SCALED_new =3D TS_SCALED_ref + slope * (SN_new - SN_ref); Step 2: TS_new =3D TS_SCALED * TS_STRIDE + TS_OFFSET In other words, scaling is an additional step on top of the "normal" (i.e. unscaled) compression. >(at least it worked when we interop'd with Nokia's > implementation before :-) As I mentioned, this is probably because both interpretations yield the same result for certain cases, for instance, Example 1 I gave in my earlier email. More general, this occurs when=20 TS_STRIDE happens to be equal to slope. When they are not equal,=20 we should see the discrepancy between the two interpretations. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 8 02:03:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00460 for ; Thu, 8 Apr 2004 02:03:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBScb-0008Ho-LM for rohc-archive@odin.ietf.org; Thu, 08 Apr 2004 02:02:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3862f8c031847 for rohc-archive@odin.ietf.org; Thu, 8 Apr 2004 02:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSca-0008Gs-Iu for rohc-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 02:02:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29879 for ; Thu, 8 Apr 2004 02:02:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBScW-0005ie-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 02:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRHl-0007RN-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 00:37:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBOjA-0000Ef-01 for rohc-web-archive@ietf.org; Wed, 07 Apr 2004 21:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOj0-0001BI-Io; Wed, 07 Apr 2004 21:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOiK-00014w-M6 for rohc@optimus.ietf.org; Wed, 07 Apr 2004 21:52:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05737 for ; Wed, 7 Apr 2004 21:52:17 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOiH-000062-00 for rohc@ietf.org; Wed, 07 Apr 2004 21:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNQ3-0002hC-00 for rohc@ietf.org; Wed, 07 Apr 2004 20:29:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BBL7F-0004Dt-00 for rohc@ietf.org; Wed, 07 Apr 2004 18:01:50 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i37M1m807304; Thu, 8 Apr 2004 01:01:48 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 00:59:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i37Lxuq7002752; Thu, 8 Apr 2004 00:59:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00GkJQ4v; Thu, 08 Apr 2004 00:59:55 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i37Lxls12878; Thu, 8 Apr 2004 00:59:47 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Apr 2004 16:59:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Wed, 7 Apr 2004 17:59:45 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153741@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQc0w6ZpBQicyERSvSTD+vPlFFC7wADFdYw To: Cc: , , , , X-OriginalArrivalTime: 07 Apr 2004 21:59:46.0490 (UTC) FILETIME=[A3D739A0:01C41CEB] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vick, Please see my answers below. I hope they help, but feel free to=20 ask more questions. BR, Zhigang > a. how "offset" is computed above (esp for Ex2)? It follows the basic mathematics that two points determine a line.=20 The decompressor needs to receive two packets in order to=20 determine the linear function from SN to TS_SCALED: TS_SCALED =3D SN * slope + offset Let's assume that in example 2, the decompressor receives packet 11 and 12 that carry scaled TS info. Here is what happens: Step 1: decompress TS_SCALED according to W-LSB or timer-based compression (if enabled). It will derive TS_SCALED =3D 1 for both packet 11 and 12. Step 2: calculate the slope slope =3D (TS_SCALED_2 - TS_SCALED_1) / (SN_2 - SN_1) =3D (1 - 1) / (12 - 11)=20 =3D 0 Step 3: calculate the offset offset =3D TS_SCALED_1 - SN_1 * slope =3D 1 - 11 * 0 =3D 1 Step 4: derive the unscaled TS according to section 4.5.3. =20 > b. what are slope & offset between pkts 60/61 and 25/26? Following the formula above, (slope, offset) =3D (50, -2950) and (1, -24), respectively. Of course, they are transient and of no use. > c. Since, as you noted in your examples, TS_SCALED, TS_STRIDE and > TS_OFFSET are obtainable and subsequently, plugging them into the > equation above should give TS. Hence, is there any particular reason > why "slope" or "offset" is needed...? The question should actually be: why do we need scale? Please note that slope and offset are the fundamentals for compression. That's also why we used the word "First-Order" and "Second-Order". We only=20 added scale *later* as an enhancement. (Please refer to my earlier=20 emails explaining this.) Now, do we need both? The answer is yes. Besides the clear difference between the two in concept, here are some practical examples: - In example 2, the compressor can establish TS_STRIDE =3D 3000 and keep it that way. That save bits during FO state (compressing 1, 2, ..., instead of 4000, 7000, ...). At the same time,=20 (slope, offset) are used for SO state. This is cleaner and more efficient than changing TS_STRIDE as described in this email thread, which also conflicts with section 4.5.3. - In another example (I think I've mentioned this already), some application may change packetization characteristics in reaction to underneath transport conditions. For example, it may encapsulate 1 audio frames in one RTP packet for sometime and 2 frames per=20 packet for other period of time. In that scenario, the compressor=20 can establish TS_STRIDE corresponding to one audio frame (e.g. 160) for once, and then use different slope (e.g. 1 or 2) to cope with=20 the change of packetization.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 8 13:01:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03494 for ; Thu, 8 Apr 2004 13:01:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBctK-0003ES-Lk for rohc-archive@odin.ietf.org; Thu, 08 Apr 2004 13:00:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38H0c1s012424 for rohc-archive@odin.ietf.org; Thu, 8 Apr 2004 13:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBctA-0003DN-41 for rohc-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 13:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03384 for ; Thu, 8 Apr 2004 13:00:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBct8-0000HR-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 13:00:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaDx-0005ce-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 10:09:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBXuz-0005C5-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 07:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBXuz-0006gl-NL; Thu, 08 Apr 2004 07:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBXus-0006g3-Mh for rohc@optimus.ietf.org; Thu, 08 Apr 2004 07:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08460 for ; Thu, 8 Apr 2004 07:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBXur-0005B0-00 for rohc@ietf.org; Thu, 08 Apr 2004 07:41:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVwY-0004tC-00 for rohc@ietf.org; Thu, 08 Apr 2004 05:35:31 -0400 Received: from smtp.wp.pl ([212.77.101.160]) by ietf-mx with esmtp (Exim 4.12) id 1BBTic-0005AM-00 for rohc@ietf.org; Thu, 08 Apr 2004 03:12:58 -0400 Received: (wp-smtpd smtp.wp.pl 10398 invoked from network); 8 Apr 2004 09:12:23 +0200 Received: from ofree.wp-sa.pl (HELO localhost) ([212.77.101.203]) (envelope-sender ) by smtp.wp.pl (wp-smtpd) with SMTP for ; 8 Apr 2004 09:12:23 +0200 Date: Thu, 8 Apr 2004 09:12:22 +0200 From: "Pawel Szymanski" To: zhigang.c.liu@nokia.com Cc: vicknesan.ayadurai@ericsson.com, lars-erik.jonsson@ericsson.com, kd.singh@enst-bretagne.fr, kristofer.sandlund@effnet.com, rohc@ietf.org Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Message-ID: <4074fb5668f06@wp.pl> References: <7B5AF06E216CB74DA8A5960A3181B5B8153741@ajebe001.americas.nokia.com> In-reply-to: <7B5AF06E216CB74DA8A5960A3181B5B8153741@ajebe001.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline X-Mailer: Interfejs WWW poczty Wirtualnej Polski Organization: Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-IP: 192.55.37.193, 172.28.173.87 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. [wersja 2.0c] X-WP-AntySpam-Rezultat: NIE-SPAM Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA08461 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, > > c. Since, as you noted in your examples, TS_SCALED, TS_STRIDE and > > TS_OFFSET are obtainable and subsequently, plugging them into the > > equation above should give TS. Hence, is there any particular reason > > why "slope" or "offset" is needed...? >=20 > The question should actually be: why do we need scale? Please note > that slope and offset are the fundamentals for compression. That's > also why we used the word "First-Order" and "Second-Order". We only=20 > added scale *later* as an enhancement. (Please refer to my earlier=20 > emails explaining this.) >=20 > Now, do we need both? The answer is yes. Besides the clear difference > between the two in concept, here are some practical examples: >=20 > - In example 2, the compressor can establish TS_STRIDE =3D 3000 and > keep it that way. That save bits during FO state (compressing 1, > 2, ..., instead of 4000, 7000, ...). At the same time,=20 > (slope, offset) are used for SO state. This is cleaner and more > efficient than changing TS_STRIDE as described in this email > thread, which also conflicts with section 4.5.3. >=20 > - In another example (I think I've mentioned this already), some > application may change packetization characteristics in reaction > to underneath transport conditions. For example, it may encapsulate > 1 audio frames in one RTP packet for sometime and 2 frames per=20 > packet for other period of time. In that scenario, the compressor=20 > can establish TS_STRIDE corresponding to one audio frame (e.g. 160) > for once, and then use different slope (e.g. 1 or 2) to cope with=20 > the change of packetization.=20 Yet another example of using both TS_STRIDE and slope is AMR codec (widel= y used=20 in 3GPP). Normally the codec generates frames every 20 ms. But during sil= ence =20 periods, special frames (so called SIDs) are generated every 8*20 ms. In my example TS_STRIDE is once at the beginning of the phone call and is= equal=20 to 20 ms. While slope is changing during the call. Nomrally the slope is = equal=20 to 1, but during silence periods it is equal to 8. Pawel ---------------------------------------------------- Przegl=B1d Piosenki Aktorskiej "Arty=B6ci Europy".=20 Wroc=B3aw 23.04 - 2.05.2004 r. Gwiazdy, spektakle, recitale, koncerty specjalne! http://klik.wp.pl/?adr=3Dhttp%3A%2F%2Fwww.ppa.art.pl%2Fsub-ppa= .php%3Fpid%3D65&sid=3D158 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 8 19:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06229 for ; Thu, 8 Apr 2004 19:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBifo-00046H-Fo for rohc-archive@odin.ietf.org; Thu, 08 Apr 2004 19:11:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NB4Zt015761 for rohc-archive@odin.ietf.org; Thu, 8 Apr 2004 19:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBifa-00044e-Kr for rohc-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06010 for ; Thu, 8 Apr 2004 19:10:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBifW-00023e-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 19:10:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhuc-0004wR-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 18:22:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfsn-00038j-00 for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 16:12:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBedJ-0006Tv-GG for rohc-web-archive@ietf.org; Thu, 08 Apr 2004 14:52:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBed7-0004kV-GQ; Thu, 08 Apr 2004 14:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBecD-0004gh-TO for rohc@optimus.ietf.org; Thu, 08 Apr 2004 14:51:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10166 for ; Thu, 8 Apr 2004 14:51:02 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBec9-00047G-00 for rohc@ietf.org; Thu, 08 Apr 2004 14:51:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBbm9-0000QG-00 for rohc@ietf.org; Thu, 08 Apr 2004 11:49:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BBZfv-0000EG-00 for rohc@ietf.org; Thu, 08 Apr 2004 09:34:35 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38DYW814567; Thu, 8 Apr 2004 16:34:32 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 16:33:03 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i38DX3So025987; Thu, 8 Apr 2004 16:33:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00eX7eti; Thu, 08 Apr 2004 16:33:02 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38DWvs07810; Thu, 8 Apr 2004 16:32:57 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 08:32:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field Date: Thu, 8 Apr 2004 09:32:50 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153742@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Slope used to compress/decompress RTP Timestamp field Thread-Index: AcQdXurcw69NsHG1QVCerFjpYX6gOQADtsIw To: Cc: , , , , X-OriginalArrivalTime: 08 Apr 2004 13:32:51.0115 (UTC) FILETIME=[FD470FB0:01C41D6D] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Yet another example of using both TS_STRIDE and slope is AMR=20 > codec (widely used in 3GPP). Normally the codec generates frames = every 20 ms.=20 > But during silence periods, special frames (so called SIDs) are = generated every 8*20 ms. >=20 > In my example TS_STRIDE is once at the beginning of the phone=20 > call and is equal to 20 ms. While slope is changing during the call. = Nomrally=20 > the slope is equal to 1, but during silence periods it is equal to 8. Good point. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 9 01:44:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29051 for ; Fri, 9 Apr 2004 01:44:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBooN-0002Tq-0u for rohc-archive@odin.ietf.org; Fri, 09 Apr 2004 01:44:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i395iIGn009530 for rohc-archive@odin.ietf.org; Fri, 9 Apr 2004 01:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBooM-0002Td-SD for rohc-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 01:44:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29026 for ; Fri, 9 Apr 2004 01:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBooJ-0002Nx-00 for rohc-web-archive@ietf.org; Fri, 09 Apr 2004 01:44:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBok7-00028Q-00 for rohc-web-archive@ietf.org; Fri, 09 Apr 2004 01:39:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBogJ-0001s7-00 for rohc-web-archive@ietf.org; Fri, 09 Apr 2004 01:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBogK-0001Qd-OL; Fri, 09 Apr 2004 01:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBog9-0001Q9-7z for rohc@optimus.ietf.org; Fri, 09 Apr 2004 01:35:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28831 for ; Fri, 9 Apr 2004 01:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBog3-0001rd-00 for rohc@ietf.org; Fri, 09 Apr 2004 01:35:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBobY-0001aB-00 for rohc@ietf.org; Fri, 09 Apr 2004 01:31:05 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BBoY1-0001H9-00 for rohc@ietf.org; Fri, 09 Apr 2004 01:27:26 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVW004PN1Q87E@mta0.huawei.com> for rohc@ietf.org; Fri, 09 Apr 2004 13:25:22 +0800 (CST) Date: Fri, 09 Apr 2004 10:57:58 +0530 From: suman To: rohc@ietf.org Message-id: <001601c41df3$6c71c3f0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_2Gzt+oDP07e53/y5SaDw8A)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] Regarding feedback mechanism in SIGCOMP 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_2Gzt+oDP07e53/y5SaDw8A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, RFC 3320 and 3321 describe the feedback mechanism which helps the peer endpoints implementing SIGCOMP to synchronize and get confirmation about the states. Its seems to me that the feedback can be sent only by piggybacking along with an application message. If endpoint 1 supports stateful compression for all outgoing messages, and endpoint 2 supports decompression only for all incoming messages, (endpoint 2 does not support compression for outgoing messages), i dont find any mechanism for the endpoint 2 to send feedback about the states its has saved to endpoint 1. Let me know if my understanding is right... thanks suman --Boundary_(ID_2Gzt+oDP07e53/y5SaDw8A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
 
     RFC 3320 and 3321 describe the feedback mechanism which helps the peer endpoints implementing SIGCOMP to synchronize and get confirmation about the states. Its seems to me that the feedback can be sent only by piggybacking along with an application message.
 
   If endpoint 1 supports stateful compression for all outgoing messages,   and endpoint 2 supports decompression only for all incoming messages, (endpoint 2 does not support compression for outgoing messages), i dont find any mechanism for the endpoint 2 to send feedback about the states its has saved
to endpoint 1.
 
  Let me know if my understanding is right...
 
thanks
suman
--Boundary_(ID_2Gzt+oDP07e53/y5SaDw8A)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 14 02:16:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18751 for ; Wed, 14 Apr 2004 02:16:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdaU-0002lF-VW for rohc-archive@odin.ietf.org; Wed, 14 Apr 2004 02:09:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E69Uou010608 for rohc-archive@odin.ietf.org; Wed, 14 Apr 2004 02:09:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdUW-0007Gl-W4 for rohc-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 02:03:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07380 for ; Wed, 14 Apr 2004 02:03:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDdUT-00038l-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 02:03:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDdTg-00032m-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 02:02:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDdT6-0002vy-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 02:01:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdHx-0003nV-Tv; Wed, 14 Apr 2004 01:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDcSb-00058f-EJ for rohc@optimus.ietf.org; Wed, 14 Apr 2004 00:57:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01898 for ; Wed, 14 Apr 2004 00:57:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDcSY-0003hA-00 for rohc@ietf.org; Wed, 14 Apr 2004 00:57:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDcRb-0003bs-00 for rohc@ietf.org; Wed, 14 Apr 2004 00:56:15 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BDcRF-0003V6-00 for rohc@ietf.org; Wed, 14 Apr 2004 00:55:54 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HW50014G95MMW@mta1.huawei.com> for rohc@ietf.org; Wed, 14 Apr 2004 12:44:14 +0800 (CST) Date: Wed, 14 Apr 2004 10:25:41 +0530 From: suman To: rohc@ietf.org Cc: "Hans Hannu (LU/EAB)" Message-id: <001901c421dc$be6ef140$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_Y6qv2TbL4n9z2F74nHX9Lw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] Regarding feedback mechanism in SIGCOMP 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_Y6qv2TbL4n9z2F74nHX9Lw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, RFC 3320 and 3321 describe the feedback mechanism which helps the peer endpoints implementing SIGCOMP to synchronize and get confirmation about the states. Its seems to me that the feedback can be sent only by piggybacking along with an application message. If endpoint 1 supports stateful compression for all outgoing messages, and endpoint 2 supports decompression only for all incoming messages, (endpoint 2 does not support compression for outgoing messages), i dont find any mechanism for the endpoint 2 to send feedback about the states its has saved to endpoint 1. Let me know if my understanding is right... thanks suman --Boundary_(ID_Y6qv2TbL4n9z2F74nHX9Lw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
 
     RFC 3320 and 3321 describe the feedback mechanism which helps the peer endpoints implementing SIGCOMP to synchronize and get confirmation about the states. Its seems to me that the feedback can be sent only by piggybacking along with an application message.
 
   If endpoint 1 supports stateful compression for all outgoing messages,   and endpoint 2 supports decompression only for all incoming messages, (endpoint 2 does not support compression for outgoing messages), i dont find any mechanism for the endpoint 2 to send feedback about the states its has saved
to endpoint 1.
 
  Let me know if my understanding is right...
 
thanks
suman
--Boundary_(ID_Y6qv2TbL4n9z2F74nHX9Lw)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 14 10:45:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28619 for ; Wed, 14 Apr 2004 10:45:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlXt-0002T4-1t for rohc-archive@odin.ietf.org; Wed, 14 Apr 2004 10:39:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEdLW1009486 for rohc-archive@odin.ietf.org; Wed, 14 Apr 2004 10:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlWI-0001z9-P5 for rohc-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:37:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28406 for ; Wed, 14 Apr 2004 10:37:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlWG-00060D-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 10:37:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlVN-0005tb-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 10:36:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlUk-0005mU-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 10:36:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlKz-00089h-MN; Wed, 14 Apr 2004 10:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlC3-0004wr-OQ for rohc@optimus.ietf.org; Wed, 14 Apr 2004 10:16:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27373 for ; Wed, 14 Apr 2004 10:16:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlC1-0003Vg-00 for rohc@ietf.org; Wed, 14 Apr 2004 10:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlB6-0003Ml-00 for rohc@ietf.org; Wed, 14 Apr 2004 10:15:48 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BDlAh-0003EW-00 for rohc@ietf.org; Wed, 14 Apr 2004 10:15:23 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3EEF7PA009247 for ; Wed, 14 Apr 2004 16:15:09 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Apr 2004 16:15:07 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25R3B4W8>; Wed, 14 Apr 2004 16:15:07 +0200 Message-ID: From: "Hans Hannu (LU/EAB)" To: "'suman'" , rohc@ietf.org Subject: RE: [rohc] Regarding feedback mechanism in SIGCOMP Date: Wed, 14 Apr 2004 16:14:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Apr 2004 14:15:07.0758 (UTC) FILETIME=[E3B690E0:01C4222A] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, According to RFC 3320, section 4.3 and 9.4.9, the supply of the compartment identifier grants the UDVM to forward the possible accompanying feedback data. Thus, if the application does not return a valid compartment identifier the requested/returned feedback will not be forward. Hence, when the application requires an application message to return a valid compartment identifier then I believe your understanding is right. BR /Hans H -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: den 14 april 2004 06:56 To: rohc@ietf.org Cc: Hans Hannu (LU/EAB) Subject: [rohc] Regarding feedback mechanism in SIGCOMP Hi all, RFC 3320 and 3321 describe the feedback mechanism which helps the peer endpoints implementing SIGCOMP to synchronize and get confirmation about the states. Its seems to me that the feedback can be sent only by piggybacking along with an application message. If endpoint 1 supports stateful compression for all outgoing messages, and endpoint 2 supports decompression only for all incoming messages, (endpoint 2 does not support compression for outgoing messages), i dont find any mechanism for the endpoint 2 to send feedback about the states its has saved to endpoint 1. Let me know if my understanding is right... thanks suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 14 17:19:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27547 for ; Wed, 14 Apr 2004 17:19:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrfI-00021Y-Ce for rohc-archive@odin.ietf.org; Wed, 14 Apr 2004 17:11:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELBO5B007779 for rohc-archive@odin.ietf.org; Wed, 14 Apr 2004 17:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrNB-0003IO-P3 for rohc-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 16:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25109 for ; Wed, 14 Apr 2004 16:52:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrN9-0002dL-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 16:52:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrM6-0002WJ-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 16:51:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrLC-0002RB-00 for rohc-web-archive@ietf.org; Wed, 14 Apr 2004 16:50:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGO-0003cM-Rp; Wed, 14 Apr 2004 15:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqCZ-0004mz-H2 for rohc@optimus.ietf.org; Wed, 14 Apr 2004 15:37:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18601 for ; Wed, 14 Apr 2004 15:37:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDqCY-0002m9-00 for rohc@ietf.org; Wed, 14 Apr 2004 15:37:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDqBi-0002jD-00 for rohc@ietf.org; Wed, 14 Apr 2004 15:36:47 -0400 Received: from didox.de ([217.160.216.42] helo=mail.didox.de) by ietf-mx with esmtp (Exim 4.12) id 1BDqAq-0002ff-00 for rohc@ietf.org; Wed, 14 Apr 2004 15:35:53 -0400 Received: from sfo.somewhere.de (pD9E7E494.dip.t-dialin.net [217.231.228.148]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.didox.de (Postfix) with ESMTP id B57C91467 for ; Wed, 14 Apr 2004 21:35:46 +0200 (CEST) Date: Wed, 14 Apr 2004 21:35:11 +0200 From: Stefan Foeckel Reply-To: Stefan Foeckel Organization: Fraunhofer Institut Fokus, Deutschland X-Priority: 3 (Normal) Message-ID: <1467929918.20040414213511@fokus.fraunhofer.de> To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [rohc] SigComp state management question 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello rohc, I have a question regarding the state management in sigcomp. Consider the following situation: The state handler contains a state item with id X, which is assoiated to a certain compartment with retention_priority n. Now, assume the state handler receives a request to create state with the same id X, for the same compartment, but with a different priority m. What is the appropriate course of action ? Should the new state item added to the compartment (together with the new priority), or is the already existing state to be updated (with respect to its retention_priority) ? Best regards Stefan -- Mit freundlichen Gr=FCssen Phone: +49 30 34637141 Stefan Foeckel Fax : +49 30 34638141 http://www.fokus.fraunhofer.de ICQ : 46655019 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 15 03:46:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08845 for ; Thu, 15 Apr 2004 03:46:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Td-0005Gb-6j for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 03:40:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F7e1vF020243 for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 03:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1Qw-0004If-40 for rohc-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 03:37:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08338 for ; Thu, 15 Apr 2004 03:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1Qt-0005QS-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 03:37:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1Oh-00051Z-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 03:34:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BE1MO-0004aw-01 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 03:32:32 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BE16C-0003KI-1W for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 03:15:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0ww-00029S-Cs; Thu, 15 Apr 2004 03:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0vl-0001OS-Kh for rohc@optimus.ietf.org; Thu, 15 Apr 2004 03:05:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06381 for ; Thu, 15 Apr 2004 03:04:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0vh-0002X8-00 for rohc@ietf.org; Thu, 15 Apr 2004 03:04:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0un-0002Tt-00 for rohc@ietf.org; Thu, 15 Apr 2004 03:04:02 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BE0uY-0002QE-00 for rohc@ietf.org; Thu, 15 Apr 2004 03:03:46 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <2M893CKW>; Thu, 15 Apr 2004 08:03:11 +0100 Message-ID: From: "Surtees, Abigail" To: "'Stefan Foeckel'" , rohc@ietf.org Subject: RE: [rohc] SigComp state management question Date: Thu, 15 Apr 2004 08:03:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Stefan, This has been discussed previously on the list and the conclusion = (update the existing state) is in the implementer's guide available = from = http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-0= 2.txt (section 5.2). Best regards, Abbie > -----Original Message----- > From: Stefan Foeckel [mailto:stefan.foeckel@fokus.fraunhofer.de]=20 > Sent: Wednesday, April 14, 2004 8:35 PM > To: rohc@ietf.org > Subject: [rohc] SigComp state management question >=20 >=20 > Hello rohc, >=20 > I have a question regarding the state management in sigcomp. >=20 > Consider the following situation: >=20 > The state handler contains a state item with id X, which is assoiated > to a certain compartment with retention_priority n. >=20 > Now, assume the state handler receives a request to create state with > the same id X, for the same compartment, but with a different = priority > m. >=20 > What is the appropriate course of action ? Should the new state item > added to the compartment (together with the new priority), or is the > already existing state to be updated (with respect to its > retention_priority) ? >=20 > Best regards > Stefan >=20 > -- > Mit freundlichen Gr=FCssen Phone: +49 30 34637141 > Stefan Foeckel Fax : +49 30 34638141 > http://www.fokus.fraunhofer.de ICQ : 46655019 >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 15 11:23:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00400 for ; Thu, 15 Apr 2004 11:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8be-0007fU-Bo for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 11:16:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFGkuc029470 for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 11:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8H2-0007yW-Gi for rohc-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 10:55:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28607 for ; Thu, 15 Apr 2004 10:55:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8H0-0002JD-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 10:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8G8-0002DP-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 10:54:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE8FL-00026S-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 10:53:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE89p-0005PU-TU; Thu, 15 Apr 2004 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE80P-0001fU-VI for rohc@optimus.ietf.org; Thu, 15 Apr 2004 10:38:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27722 for ; Thu, 15 Apr 2004 10:38:14 -0400 (EDT) From: sauragupta@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE80N-0000kV-00 for rohc@ietf.org; Thu, 15 Apr 2004 10:38:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7zW-0000fx-00 for rohc@ietf.org; Thu, 15 Apr 2004 10:37:23 -0400 Received: from [61.16.168.135] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BE7yz-0000b1-00 for rohc@ietf.org; Thu, 15 Apr 2004 10:36:50 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3FEZED12225 for ; Thu, 15 Apr 2004 20:05:36 +0530 To: rohc@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Thu, 15 Apr 2004 20:06:08 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/15/2004 08:06:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Examples for Uni-Directional Compression 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi all, RFC 3320 mentions that unidirectional compression is possible using SIGCOMP. According to my understanding A B | SiGComp Compressed Message | |---------------------->----------------------------------- | | | | | | Un Compressed Message (normal) | |-----------------------<---------------------------------- | | | | | That means that Endpoint B is also SIGCOMP aware . My basic doubts is in which pratical scenario Endpoint B will choose to send normal message in place of the compressed messages.This is will drastically effect the compression ratio. Thanks & Regards Saurabh Saurabh Gupta - HSS Bangalore Ext 7067 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 15 11:47:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01362 for ; Thu, 15 Apr 2004 11:47:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8ue-00055d-EB for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 11:36:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFaOTC019556 for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 11:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8no-0003Lq-3x for rohc-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 11:29:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00662 for ; Thu, 15 Apr 2004 11:29:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8nn-0006CY-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 11:29:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8mw-00066y-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 11:28:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE8mL-000615-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 11:27:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8ds-0000HI-P8; Thu, 15 Apr 2004 11:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8ZV-0006yX-Pw for rohc@optimus.ietf.org; Thu, 15 Apr 2004 11:14:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29736 for ; Thu, 15 Apr 2004 11:14:31 -0400 (EDT) From: Paulius.Meskauskas@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8ZV-0004au-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:14:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8Ya-0004Sj-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:13:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BE8Xl-0004Lm-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:12:45 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FFCZH06496; Thu, 15 Apr 2004 18:12:35 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 18:12:28 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3FFCSmA032637; Thu, 15 Apr 2004 18:12:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00e6vJ1U; Thu, 15 Apr 2004 18:12:27 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FFCNs03866; Thu, 15 Apr 2004 18:12:23 +0300 (EET DST) Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 18:12:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Examples for Uni-Directional Compression Date: Thu, 15 Apr 2004 18:12:00 +0300 Message-ID: <19E3AC24C8317C45B6F86092F087B2200260C471@esebe007.ntc.nokia.com> Thread-Topic: [rohc] Examples for Uni-Directional Compression Thread-Index: AcQi+gyeubB7Sji4Spqdyi99UyGAsAAAPayQ To: , X-OriginalArrivalTime: 15 Apr 2004 15:12:00.0768 (UTC) FILETIME=[00705000:01C422FC] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, This could happen with erroneous SIP implementation that does not comform to RFC3486 i.e. does not set comp=3Dsigcomp flag in the Via header field of SIP request. br, paulius > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > sauragupta@hss.hns.com > Sent: Thursday, April 15, 2004 5:36 PM > To: rohc@ietf.org > Subject: [rohc] Examples for Uni-Directional Compression >=20 >=20 >=20 >=20 >=20 >=20 > Hi all, > RFC 3320 mentions that unidirectional compression is=20 > possible using > SIGCOMP. > According to my understanding >=20 > A > B > | SiGComp Compressed Message | > |---------------------->----------------------------------- | > | | > | | > | Un Compressed Message (normal) | > |-----------------------<---------------------------------- | > | | > | | >=20 > That means that Endpoint B is also SIGCOMP aware . > My basic doubts is in which pratical scenario Endpoint B will=20 > choose to > send > normal message in place of the compressed messages.This is=20 > will drastically > effect the compression ratio. >=20 > Thanks & Regards > Saurabh >=20 > Saurabh Gupta - HSS Bangalore Ext 7067 >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 15 12:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02864 for ; Thu, 15 Apr 2004 12:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Rw-0006P9-Cz for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 12:10:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGAm4G024615 for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 12:10:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Hu-0003iO-E9 for rohc-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:00:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01848 for ; Thu, 15 Apr 2004 12:00:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Ht-0001Gp-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 12:00:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9H6-0001BZ-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 11:59:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9GN-00015X-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 11:58:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE96r-00011X-GG; Thu, 15 Apr 2004 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8xR-00068d-JS for rohc@optimus.ietf.org; Thu, 15 Apr 2004 11:39:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01116 for ; Thu, 15 Apr 2004 11:39:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8xQ-0007Fo-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:39:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8wd-0007Aq-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:38:27 -0400 Received: from bay12-f69.bay12.hotmail.com ([64.4.35.69] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BE8vs-00071v-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:37:40 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Apr 2004 08:37:08 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Thu, 15 Apr 2004 15:37:08 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: sauragupta@hss.hns.com, rohc@ietf.org Subject: RE: [rohc] Examples for Uni-Directional Compression Date: Thu, 15 Apr 2004 16:37:08 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Apr 2004 15:37:08.0334 (UTC) FILETIME=[8304A0E0:01C422FF] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Saurabh, Compression is relatively expensive in terms of memory and processing power, so it might be worth only compressing in one direction if there is an asymmetric link in the network (e.g. a satellite link). You could compress in the direction where bandwidth is scarce, and leave the messages uncompressed in the direction where bandwidth is plentiful. Regards, Richard >From: sauragupta@hss.hns.com >To: rohc@ietf.org >Subject: [rohc] Examples for Uni-Directional Compression >Date: Thu, 15 Apr 2004 20:06:08 +0530 > > > > > >Hi all, > RFC 3320 mentions that unidirectional compression is possible using >SIGCOMP. >According to my understanding > > A >B > | SiGComp Compressed Message | > |---------------------->----------------------------------- | > | | > | | > | Un Compressed Message (normal) | > |-----------------------<---------------------------------- | > | | > | | > >That means that Endpoint B is also SIGCOMP aware . >My basic doubts is in which pratical scenario Endpoint B will choose to >send >normal message in place of the compressed messages.This is will drastically >effect the compression ratio. > >Thanks & Regards >Saurabh > >Saurabh Gupta - HSS Bangalore Ext 7067 > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 15 12:30:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02971 for ; Thu, 15 Apr 2004 12:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9hz-00046E-S8 for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 12:27:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGRNNb015740 for rohc-archive@odin.ietf.org; Thu, 15 Apr 2004 12:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9LZ-0004OS-Sa for rohc-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01977 for ; Thu, 15 Apr 2004 12:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9LY-0001ae-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 12:04:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9Kh-0001WV-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 12:03:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Jt-0001S4-00 for rohc-web-archive@ietf.org; Thu, 15 Apr 2004 12:02:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE96u-00015y-J6; Thu, 15 Apr 2004 11:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE90E-00077K-BR for rohc@optimus.ietf.org; Thu, 15 Apr 2004 11:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01217 for ; Thu, 15 Apr 2004 11:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE90D-0007TE-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:42:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8zI-0007PJ-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:41:13 -0400 Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1BE8yU-0007Ld-00 for rohc@ietf.org; Thu, 15 Apr 2004 11:40:23 -0400 Received: from [IPv6:::1] (imh.informatik.uni-bremen.de [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i3FFdv3d006192; Thu, 15 Apr 2004 17:39:58 +0200 (MEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2BC645A2-8EF3-11D8-AF39-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org From: Carsten Bormann Subject: Re: [rohc] Examples for Uni-Directional Compression Date: Thu, 15 Apr 2004 17:40:07 +0200 To: sauragupta@hss.hns.com X-Mailer: Apple Mail (2.613) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > RFC 3320 mentions that unidirectional compression is possible > using > SIGCOMP. I think you are referring to the last paragraph of section 3: When compressing a bidirectional application protocol the choice to use SigComp can be made independently in both directions, and compression in one direction does not necessarily imply compression in the reverse direction. Moreover, even when two communicating endpoints send SigComp messages in both directions, there is no need to use the same compression algorithm in each direction. > My basic doubts is in which pratical scenario Endpoint B will choose to > send > normal message in place of the compressed messages.This is will > drastically > effect the compression ratio. This paragraph is more about describing how SigComp works than about making the right choices. It is very important that, in a bidirectional application, both SigComp directions are independent -- this allows the compressor to choose a compression algorithm without regard to what the other compressor can do. The fact that you can use SigComp in a unidirectional way may be useful if you cannot establish SigComp capability in the reverse direction. There may be other reasons (e.g., highly asymmetric data rates), but this is not of concern to RFC3320 -- it just provides the capability, and the implementation gets to decide whether to use it. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 16 01:40:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28904 for ; Fri, 16 Apr 2004 01:40:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEM18-0005XP-Td for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 01:35:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G5Zwl6021287 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 01:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEM0A-0005Ng-Mb for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 01:34:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28714 for ; Fri, 16 Apr 2004 01:34:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEM07-0000Si-Ib for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 01:34:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BELzE-0000Nv-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 01:34:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BELyH-0000Jw-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 01:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BELvP-0004g5-0w; Fri, 16 Apr 2004 01:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BELsQ-00047x-3d for rohc@optimus.ietf.org; Fri, 16 Apr 2004 01:26:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28373 for ; Fri, 16 Apr 2004 01:26:56 -0400 (EDT) From: jbhalla@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BELsN-0007dX-4a for rohc@ietf.org; Fri, 16 Apr 2004 01:26:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BELrY-0007Ya-00 for rohc@ietf.org; Fri, 16 Apr 2004 01:26:05 -0400 Received: from 210-210-93-102.lan.sify.net ([210.210.93.102] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BELqa-0007RG-00; Fri, 16 Apr 2004 01:25:04 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3G5NrD18891; Fri, 16 Apr 2004 10:53:53 +0530 In-Reply-To: Subject: RE: [rohc] Examples for Uni-Directional Compression To: "Richard Price" Cc: rohc@ietf.org, rohc-admin@ietf.org, sauragupta@hss.hns.com X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 16 Apr 2004 10:54:45 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/16/2004 10:54:51 AM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi Richard, I have another doubt in this :- Incase application wants to compress in one direction (say uplink) and not in other direction (day downlink) then how can "feedback mechanism" be used to establish the "state" (since the ack for the state established is sent in sigcomp message and remote application is not sending any sigcomp message). Further,that means in case the compression is uni-directional and feedback mechanism can not be used for establishing state ,So overall compression ratio will be very less (because decompression bytecode will be sent everytime). So, Doubt is that although in practical scenario, compression in one direction is possible but which mechanism does SigComp provide to achieve this feature so that compression ratio is less. regards Jyoti "Richard Price" To Sent by: sauragupta@hss.hns.com, rohc-admin@ietf.o rohc@ietf.org rg cc Subject 04/15/04 09:07 PM RE: [rohc] Examples for Uni-Directional Compression Hi Saurabh, Compression is relatively expensive in terms of memory and processing power, so it might be worth only compressing in one direction if there is an asymmetric link in the network (e.g. a satellite link). You could compress in the direction where bandwidth is scarce, and leave the messages uncompressed in the direction where bandwidth is plentiful. Regards, Richard >From: sauragupta@hss.hns.com >To: rohc@ietf.org >Subject: [rohc] Examples for Uni-Directional Compression >Date: Thu, 15 Apr 2004 20:06:08 +0530 > > > > > >Hi all, > RFC 3320 mentions that unidirectional compression is possible using >SIGCOMP. >According to my understanding > > A >B > | SiGComp Compressed Message | > |---------------------->----------------------------------- | > | | > | | > | Un Compressed Message (normal) | > |-----------------------<---------------------------------- | > | | > | | > >That means that Endpoint B is also SIGCOMP aware . >My basic doubts is in which pratical scenario Endpoint B will choose to >send >normal message in place of the compressed messages.This is will drastically >effect the compression ratio. > >Thanks & Regards >Saurabh > >Saurabh Gupta - HSS Bangalore Ext 7067 > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger _______________________________________________ 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 exim@www1.ietf.org Fri Apr 16 03:05:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17175 for ; Fri, 16 Apr 2004 03:05:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENOY-0004oy-Rl for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 03:04:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G74E7W018532 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 03:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENOG-0004dY-1w for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 03:03:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17136 for ; Fri, 16 Apr 2004 03:03:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENOC-0000z8-4i for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 03:03:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENNF-0000up-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 03:02:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENMP-0000qC-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 03:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENFg-0002zS-O9; Fri, 16 Apr 2004 02:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENDZ-0002dE-58 for rohc@optimus.ietf.org; Fri, 16 Apr 2004 02:52:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16651 for ; Fri, 16 Apr 2004 02:52:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENDV-00003Y-Ah for rohc@ietf.org; Fri, 16 Apr 2004 02:52:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENCY-0007m7-00 for rohc@ietf.org; Fri, 16 Apr 2004 02:51:51 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BENBe-0007gc-00 for rohc@ietf.org; Fri, 16 Apr 2004 02:50:54 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3G6osPA018675 for ; Fri, 16 Apr 2004 08:50:54 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Apr 2004 08:50:54 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25R3SQFW>; Fri, 16 Apr 2004 08:50:54 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kavitha KR'" , Kristofer Sandlund , Pawel Szymanski Cc: rohc@ietf.org Subject: RE: [rohc] ROHC context reuse & mode Date: Fri, 16 Apr 2004 08:50:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Apr 2004 06:50:54.0438 (UTC) FILETIME=[29EC3060:01C4237F] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > > But isn't the option 3 against the RFC 3095, as the > > decompressor state transition diagram (section 5.3.2, > > page 57] does not show transition from NO_CONTEXT > > to STATIC_CONTEXT ? > > ===> Yes!! There is no transition from NC to SC > according to section 5.3.2. Also, everywhere > in the RFC, SC state is portrayed only as a > state to come back from FC due to failures. > But the diagram, showing decompressor states > in section 4.3.2, shows double-headed arrow > between NC & SC states. > > Isn't it contradicting? Yes, I agree this can be seen as a contradiction, and as I wrote both sections I am for sure one to blame for it. The reason for this difference is that 4.3 was supposed to provide an informative overview without specifying the details, while the actual specification is in chapter 5. The double-headed arrows was supposed to show state relations on a general level, but I understand it might be confusing and we'll have to consider this when we progress the standard. Cheers, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 16 05:46:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26318 for ; Fri, 16 Apr 2004 05:46:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPtG-0002uy-VP for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 05:44:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G9i63Y011216 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 05:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPpQ-0002IN-6D for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 05:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25979 for ; Fri, 16 Apr 2004 05:40:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPpM-0002Da-LO for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 05:40:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPoR-000289-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 05:39:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEPnn-00022C-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 05:38:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPkT-0000zH-El; Fri, 16 Apr 2004 05:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPfc-0000B1-Cr for rohc@optimus.ietf.org; Fri, 16 Apr 2004 05:30:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25607 for ; Fri, 16 Apr 2004 05:29:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPfY-0001Dz-Rq for rohc@ietf.org; Fri, 16 Apr 2004 05:29:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPeb-00018b-00 for rohc@ietf.org; Fri, 16 Apr 2004 05:28:57 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BEPdl-00013h-00 for rohc@ietf.org; Fri, 16 Apr 2004 05:28:05 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3G9S6PA003940 for ; Fri, 16 Apr 2004 11:28:06 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Apr 2004 11:28:05 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <25R34C0Z>; Fri, 16 Apr 2004 11:28:05 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'shilong.zhao@samsung.com'" Cc: "'rohc@ietf.org'" Date: Fri, 16 Apr 2004 11:27:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" X-OriginalArrivalTime: 16 Apr 2004 09:28:05.0962 (UTC) FILETIME=[1F8C8AA0:01C42395] Subject: [rohc] RE: RFC3095 Question 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Shilong, This comment is closely related to the previous discussion on the rohc list, https://www1.ietf.org/mailman/listinfo/rohc, about the use of IR's without a dynamic chain. This possibility was never really addressed when we wrote 3095, apart from being allowed in the IR, and all other texts should be considered with that in mind. Other texts are thus not obviously applicable to the case when that feature is used. Rgds, /L-E P.S. Please direct further questions/comments to the ROHC list, rohc@ietf.org . > -----Original Message----- > From: shilong zhao [mailto:shilong.zhao@samsung.com] > Sent: den 13 april 2004 03:20 > To: cabo@tzi.org; burmeister@panasonic.de; > fukusima@isl.mei.com.jp; micke@cs.arizona.edu; Hans Hannu > (LU/EAB); Lars-Erik Jonsson (LU/EAB); khiem.le@nokia.com; > zhigang.liu@nokia.com; haihong.zheng@nokia.com > Subject: RFC3095 Question > > > hi, all experts: > There is a question when I want to implement RFC3095: > > in the Page 57 of RFC3095 > > > Success > > +-->------>------>------>------>------>--+ > | | > No Static | No Dynamic Success | Success > +-->--+ | +-->--+ +--->----->---+ +-->--+ > | | | | | | | | | > | v | | v | v | v > +--------------+ +----------------+ > +--------------+ > | No Context | | Static Context | | Full > Context | > +--------------+ +----------------+ > +--------------+ > ^ | ^ | > | k_2 out of n_2 failures | | k_1 out of n_1 failures | > +-----<------<------<-----+ +-----<------<------<-----+ > > > decompressor directly transits from NO context state to > Full context, however the following description: > > 5.3.2.2.1 Decide whether decompression is allowed > In Full Context state, decompression may be attempted > regardless of what kind of packet is received. However, for > the other states decompression is not always allowed. In the > No Context state only IR packets, which carry the static > information fields, may be decompressed. Further, when in the > Static Context state, only packets carrying a 7- or 8-bit CRC > can be decompressed (i.e., IR, IR-DYN, or UOR-2 packets). If > decompression may not be performed the packet is discarded, > unless the optional delayed decompression mechanism is used > > according section 5.3.2.2.1, If decompressor directly > transits from NO context state to Full context.It can only > get the static information. How it get Dynamic information ? > > > I think that the decompressor maybe have path directly > transit from No context to Static Context. > Do you think so ? > > Thank advance. > > Shilong Zhao > > > > CHINA SAMSUNG Telecom R&D Center > 4/F Science and Technology Tower > No.9 Zhongguancun Nandajie, Haidian District > Beijing, China 100081 > > TEL: (010) 6842-7711 - 2411 > FAX: (010) 6848-1891 > Mobile: 13621193636 > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 16 06:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27593 for ; Fri, 16 Apr 2004 06:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQK2-0007Oy-QG for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 06:11:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GABknm028447 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 06:11:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQFW-0006Rz-9r for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 06:07:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27220 for ; Fri, 16 Apr 2004 06:07:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEQFS-000535-Hh for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 06:07:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQEY-0004xC-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 06:06:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEQDg-0004rP-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 06:05:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQ8g-0005D1-Lr; Fri, 16 Apr 2004 06:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQ4q-0004fK-PK for rohc@optimus.ietf.org; Fri, 16 Apr 2004 05:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26572 for ; Fri, 16 Apr 2004 05:56:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEQ4m-0003ie-Le for rohc@ietf.org; Fri, 16 Apr 2004 05:56:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQ3j-0003aN-00 for rohc@ietf.org; Fri, 16 Apr 2004 05:54:55 -0400 Received: from bay12-f87.bay12.hotmail.com ([64.4.35.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BEQ2n-0003OQ-00 for rohc@ietf.org; Fri, 16 Apr 2004 05:53:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Apr 2004 02:53:28 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Fri, 16 Apr 2004 09:53:28 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: jbhalla@hss.hns.com Cc: rohc@ietf.org, sauragupta@hss.hns.com Subject: RE: [rohc] Examples for Uni-Directional Compression Date: Fri, 16 Apr 2004 10:53:28 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2004 09:53:28.0851 (UTC) FILETIME=[AB42F630:01C42398] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Jyoti, If you want to use the SigComp feedback mechanism to improve the compression ratio in the uplink direction, but don't need to compress the messages in the downlink direction, then you can apply SigComp to the downlink messages with a "null" compression algorithm. In other words, you can use SigComp in both directions, with an efficient, CPU-intensive algorithm in the uplink direction where compression is useful, and a null algorithm that just attaches a SigComp header to the raw uncompressed message in the downlink direction where compression isn't needed. Regards, Richard >From: jbhalla@hss.hns.com >To: "Richard Price" >CC: rohc@ietf.org, rohc-admin@ietf.org, sauragupta@hss.hns.com >Subject: RE: [rohc] Examples for Uni-Directional Compression >Date: Fri, 16 Apr 2004 10:54:45 +0530 > >Hi Richard, > I have another doubt in this :- Incase application wants to >compress in one direction (say uplink) and not in other direction >(day downlink) then how can "feedback mechanism" be used >to establish the "state" (since the ack for the state established >is sent in sigcomp message and remote application is not sending >any sigcomp message). Further,that means in case the >compression is uni-directional and feedback mechanism can not >be used for establishing state ,So overall compression ratio will >be very less (because decompression bytecode will be sent >everytime). > >So, Doubt is that although in practical scenario, compression in >one direction is possible but which mechanism does SigComp >provide to achieve this feature so that compression ratio is less. > > >regards >Jyoti _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 16 06:56:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00020 for ; Fri, 16 Apr 2004 06:56:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQx7-0006bt-6Z for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 06:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GAq9d3025398 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 06:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQv8-0006Dz-HM for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 06:50:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29775 for ; Fri, 16 Apr 2004 06:50:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEQv4-0002Zu-Dj for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 06:50:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQu8-0002Rj-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 06:49:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEQtA-0002F5-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 06:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQs9-0005TC-3E; Fri, 16 Apr 2004 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQoO-0004ro-Fs for rohc@optimus.ietf.org; Fri, 16 Apr 2004 06:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29234 for ; Fri, 16 Apr 2004 06:43:04 -0400 (EDT) From: jbhalla@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEQoK-0001RB-CB for rohc@ietf.org; Fri, 16 Apr 2004 06:43:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQnP-0001IR-00 for rohc@ietf.org; Fri, 16 Apr 2004 06:42:07 -0400 Received: from 210-210-93-102.lan.sify.net ([210.210.93.102] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BEQmP-00018e-00 for rohc@ietf.org; Fri, 16 Apr 2004 06:41:06 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3GAdMD23968; Fri, 16 Apr 2004 16:09:33 +0530 Subject: RE: [rohc] Examples for Uni-Directional Compression To: "Richard Price" , rohc@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 16 Apr 2004 16:10:16 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/16/2004 04:10:35 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Hi Richard, From your mail I understand that in downlink direction (which does not want to do compression), the sigcomp message can be formed with following specifications to achieve higher compression ratio:- 1. Returned feedback data containing state information 2. The 12-bit code_len field which specifies the size of the uploaded UDVM bytecode must be set to zero (to specify "null" decompression algorithm) So incase Decompressor dispatcher receives SigComp message which has code_len field set to zero then it must return the message as it to the application but it must process the feedback response. Please confirm if this understanding is correct. thanks and regards Jyoti "Richard Price" To jbhalla@hss.hns.com 04/16/04 03:23 PM cc rohc@ietf.org, sauragupta@hss.hns.com Subject RE: [rohc] Examples for Uni-Directional Compression Hi Jyoti, If you want to use the SigComp feedback mechanism to improve the compression ratio in the uplink direction, but don't need to compress the messages in the downlink direction, then you can apply SigComp to the downlink messages with a "null" compression algorithm. In other words, you can use SigComp in both directions, with an efficient, CPU-intensive algorithm in the uplink direction where compression is useful, and a null algorithm that just attaches a SigComp header to the raw uncompressed message in the downlink direction where compression isn't needed. Regards, Richard >From: jbhalla@hss.hns.com >To: "Richard Price" >CC: rohc@ietf.org, rohc-admin@ietf.org, sauragupta@hss.hns.com >Subject: RE: [rohc] Examples for Uni-Directional Compression >Date: Fri, 16 Apr 2004 10:54:45 +0530 > >Hi Richard, > I have another doubt in this :- Incase application wants to >compress in one direction (say uplink) and not in other direction >(day downlink) then how can "feedback mechanism" be used >to establish the "state" (since the ack for the state established >is sent in sigcomp message and remote application is not sending >any sigcomp message). Further,that means in case the >compression is uni-directional and feedback mechanism can not >be used for establishing state ,So overall compression ratio will >be very less (because decompression bytecode will be sent >everytime). > >So, Doubt is that although in practical scenario, compression in >one direction is possible but which mechanism does SigComp >provide to achieve this feature so that compression ratio is less. > > >regards >Jyoti _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 16 07:23:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01148 for ; Fri, 16 Apr 2004 07:23:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERPz-0002wy-00 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 07:21:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GBLwiq011336 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 07:21:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERJI-0001se-3h for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 07:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00659 for ; Fri, 16 Apr 2004 07:15:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BERJH-0005Eq-O6 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 07:15:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BERIL-00058G-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 07:14:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BERHb-00052E-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 07:13:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERBV-0000AE-6n; Fri, 16 Apr 2004 07:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BER8m-00084P-Qw for rohc@optimus.ietf.org; Fri, 16 Apr 2004 07:04:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00337 for ; Fri, 16 Apr 2004 07:04:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BER8i-00048B-Hg for rohc@ietf.org; Fri, 16 Apr 2004 07:04:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BER7o-000429-00 for rohc@ietf.org; Fri, 16 Apr 2004 07:03:13 -0400 Received: from bay12-f52.bay12.hotmail.com ([64.4.35.52] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BER7V-0003vn-00 for rohc@ietf.org; Fri, 16 Apr 2004 07:02:53 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Apr 2004 04:02:21 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Fri, 16 Apr 2004 11:02:21 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: jbhalla@hss.hns.com Cc: rohc@ietf.org, sauragupta@hss.hns.com, nsudarshan@hss.hns.com, schatterjee@hss.hns.com, amannan@hss.hns.com, rahammad@hss.hns.com, anagarajan@hss.hns.com Subject: RE: [rohc] Examples for Uni-Directional Compression Date: Fri, 16 Apr 2004 12:02:21 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2004 11:02:21.0546 (UTC) FILETIME=[4A8A2CA0:01C423A2] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Hi Jyoti, It's not the case that you can set the code_len field to 0 and rely on the UDVM to output the message as-is, because this behaviour isn't specified in RFC 3320. What you have to do instead is to send a (small) piece of bytecode that tells the UDVM to output the message unchanged (i.e. you need to upload a "null" decompression algorithm to the UDVM). Here's an example of how to do this. Prepend the following 13 bytes to the front of an uncompressed message, and the UDVM will output the data directly without modification: 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16, 0xf9, 0x23, The first three bytes are the SigComp header; the other ten correspond to the following bytecode: INPUT-BYTES(1, 64, 9) OUTPUT(64, 1) JUMP(-7) END-MESSAGE This bytecode just tells the UDVM to output the data unchanged. Moreover, because the uncompressed message is encapsulated in a SigComp message, you can send feedback using the SigComp feedback mechanism ;-) Hope this helps... Regards, Richard >From: jbhalla@hss.hns.com >To: "Richard Price" >CC: rohc@ietf.org, sauragupta@hss.hns.com, jbhalla@hss.hns.com, >nsudarshan@hss.hns.com, schatterjee@hss.hns.com, amannan@hss.hns.com, >sauragupta@hss.hns.com, jbhalla@hss.hns.com, rahammad@hss.hns.com, >anagarajan@hss.hns.com >Subject: RE: [rohc] Examples for Uni-Directional Compression >Date: Fri, 16 Apr 2004 15:54:56 +0530 > > > > > >Hi Richard, > From your mail I understand that in downlink direction (which does >not want to do compression),the sigcomp message can be formed with >following specifications to achieve higher compression ratio:- >1. Returned feedback data containing state information >2. The 12-bit code_len field which specifies the size of the uploaded UDVM >bytecode must be set to zero (to specify "null" decompression algorithm) > >So incase Decompressor dispatcher receives SigComp message which has >code_len field set to zero then it must return the message as it to the >application but it must process the feedback response. > >Please confirm if this understanding is correct. > >thanks and regards >Jyoti _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 16 08:01:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02903 for ; Fri, 16 Apr 2004 08:01:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BES00-0001Td-T5 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 07:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GBxCW8005673 for rohc-archive@odin.ietf.org; Fri, 16 Apr 2004 07:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERy2-0001A1-Qa for rohc-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 07:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02725 for ; Fri, 16 Apr 2004 07:57:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BERy1-0002dA-Sl for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 07:57:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BERx5-0002Wd-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 07:56:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BERwi-0002Q0-00 for rohc-web-archive@ietf.org; Fri, 16 Apr 2004 07:55:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERt5-0000AK-Sv; Fri, 16 Apr 2004 07:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERr9-00085N-9g for rohc@optimus.ietf.org; Fri, 16 Apr 2004 07:50:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02426 for ; Fri, 16 Apr 2004 07:50:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BERr8-0001l1-BH for rohc@ietf.org; Fri, 16 Apr 2004 07:50:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BERq9-0001e3-00 for rohc@ietf.org; Fri, 16 Apr 2004 07:49:02 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BERpA-0001R4-00 for rohc@ietf.org; Fri, 16 Apr 2004 07:48:01 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HW90091JI0R02@mta0.huawei.com> for rohc@ietf.org; Fri, 16 Apr 2004 19:46:05 +0800 (CST) Date: Fri, 16 Apr 2004 17:18:39 +0530 From: suman Subject: Re: [rohc] Examples for Uni-Directional Compression To: Richard Price , jbhalla@hss.hns.com Cc: rohc@ietf.org, sauragupta@hss.hns.com, nsudarshan@hss.hns.com, schatterjee@hss.hns.com, amannan@hss.hns.com, rahammad@hss.hns.com, anagarajan@hss.hns.com Message-id: <001901c423a8$c3726af0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, This solution works fine only if the application is willing to create a compartment even when he actually does not want to send compressed messages. If the application is adamant and not willing to create a compartment in case it does not want to send compressed messages, then there is no way to convey the feedback mechanism... thanks suman ----- Original Message ----- From: "Richard Price" To: Cc: ; ; ; ; ; ; Sent: Friday, April 16, 2004 4:32 PM Subject: RE: [rohc] Examples for Uni-Directional Compression > Hi Jyoti, > > It's not the case that you can set the code_len field to 0 and > rely on the UDVM to output the message as-is, because this > behaviour isn't specified in RFC 3320. What you have to do > instead is to send a (small) piece of bytecode that tells the > UDVM to output the message unchanged (i.e. you need to > upload a "null" decompression algorithm to the UDVM). > > Here's an example of how to do this. Prepend the following > 13 bytes to the front of an uncompressed message, and > the UDVM will output the data directly without modification: > > 0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, > 0x86, 0x01, 0x16, 0xf9, 0x23, > > The first three bytes are the SigComp header; the other > ten correspond to the following bytecode: > > INPUT-BYTES(1, 64, 9) > OUTPUT(64, 1) > JUMP(-7) > END-MESSAGE > > This bytecode just tells the UDVM to output the data > unchanged. Moreover, because the uncompressed > message is encapsulated in a SigComp message, you can > send feedback using the SigComp feedback mechanism ;-) > > Hope this helps... > > Regards, > > Richard > > >From: jbhalla@hss.hns.com > >To: "Richard Price" > >CC: rohc@ietf.org, sauragupta@hss.hns.com, jbhalla@hss.hns.com, > >nsudarshan@hss.hns.com, schatterjee@hss.hns.com, amannan@hss.hns.com, > >sauragupta@hss.hns.com, jbhalla@hss.hns.com, rahammad@hss.hns.com, > >anagarajan@hss.hns.com > >Subject: RE: [rohc] Examples for Uni-Directional Compression > >Date: Fri, 16 Apr 2004 15:54:56 +0530 > > > > > > > > > > > >Hi Richard, > > From your mail I understand that in downlink direction (which does > >not want to do compression),the sigcomp message can be formed with > >following specifications to achieve higher compression ratio:- > >1. Returned feedback data containing state information > >2. The 12-bit code_len field which specifies the size of the uploaded UDVM > >bytecode must be set to zero (to specify "null" decompression algorithm) > > > >So incase Decompressor dispatcher receives SigComp message which has > >code_len field set to zero then it must return the message as it to the > >application but it must process the feedback response. > > > >Please confirm if this understanding is correct. > > > >thanks and regards > >Jyoti > > _________________________________________________________________ > Use MSN Messenger to send music and pics to your friends > http://www.msn.co.uk/messenger > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Apr 19 06:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01334 for ; Mon, 19 Apr 2004 06:24:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVrh-0000r0-US for rohc-archive@odin.ietf.org; Mon, 19 Apr 2004 06:19:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JAJ11V003277 for rohc-archive@odin.ietf.org; Mon, 19 Apr 2004 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVqh-0000ea-8o for rohc-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 06:17:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01097 for ; Mon, 19 Apr 2004 06:17:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFVqd-0002R3-AU for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 06:17:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFVpg-0002EU-00 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 06:16:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFVp1-00021c-00 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 06:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVmr-0008Lz-0K; Mon, 19 Apr 2004 06:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEQZp-0001Sz-MJ for rohc@optimus.ietf.org; Fri, 16 Apr 2004 06:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28019 for ; Fri, 16 Apr 2004 06:28:01 -0400 (EDT) From: jbhalla@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEQZl-0007C2-KF for rohc@ietf.org; Fri, 16 Apr 2004 06:28:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEQYu-00076u-00 for rohc@ietf.org; Fri, 16 Apr 2004 06:27:09 -0400 Received: from 210-210-93-102.lan.sify.net ([210.210.93.102] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BEQYD-000719-00 for rohc@ietf.org; Fri, 16 Apr 2004 06:26:25 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3GAOBD23711; Fri, 16 Apr 2004 15:54:23 +0530 In-Reply-To: Subject: RE: [rohc] Examples for Uni-Directional Compression To: "Richard Price" Cc: rohc@ietf.org, sauragupta@hss.hns.com, jbhalla@hss.hns.com, nsudarshan@hss.hns.com, schatterjee@hss.hns.com, amannan@hss.hns.com, sauragupta@hss.hns.com, jbhalla@hss.hns.com, rahammad@hss.hns.com, anagarajan@hss.hns.com X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 16 Apr 2004 15:54:56 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/16/2004 03:55:38 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Hi Richard, From your mail I understand that in downlink direction (which does not want to do compression),the sigcomp message can be formed with following specifications to achieve higher compression ratio:- 1. Returned feedback data containing state information 2. The 12-bit code_len field which specifies the size of the uploaded UDVM bytecode must be set to zero (to specify "null" decompression algorithm) So incase Decompressor dispatcher receives SigComp message which has code_len field set to zero then it must return the message as it to the application but it must process the feedback response. Please confirm if this understanding is correct. thanks and regards Jyoti "Richard Price" To jbhalla@hss.hns.com 04/16/04 03:23 PM cc rohc@ietf.org, sauragupta@hss.hns.com Subject RE: [rohc] Examples for Uni-Directional Compression Hi Jyoti, If you want to use the SigComp feedback mechanism to improve the compression ratio in the uplink direction, but don't need to compress the messages in the downlink direction, then you can apply SigComp to the downlink messages with a "null" compression algorithm. In other words, you can use SigComp in both directions, with an efficient, CPU-intensive algorithm in the uplink direction where compression is useful, and a null algorithm that just attaches a SigComp header to the raw uncompressed message in the downlink direction where compression isn't needed. Regards, Richard >From: jbhalla@hss.hns.com >To: "Richard Price" >CC: rohc@ietf.org, rohc-admin@ietf.org, sauragupta@hss.hns.com >Subject: RE: [rohc] Examples for Uni-Directional Compression >Date: Fri, 16 Apr 2004 10:54:45 +0530 > >Hi Richard, > I have another doubt in this :- Incase application wants to >compress in one direction (say uplink) and not in other direction >(day downlink) then how can "feedback mechanism" be used >to establish the "state" (since the ack for the state established >is sent in sigcomp message and remote application is not sending >any sigcomp message). Further,that means in case the >compression is uni-directional and feedback mechanism can not >be used for establishing state ,So overall compression ratio will >be very less (because decompression bytecode will be sent >everytime). > >So, Doubt is that although in practical scenario, compression in >one direction is possible but which mechanism does SigComp >provide to achieve this feature so that compression ratio is less. > > >regards >Jyoti _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 19 06:29:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01598 for ; Mon, 19 Apr 2004 06:29:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVxE-0001d5-00 for rohc-archive@odin.ietf.org; Mon, 19 Apr 2004 06:24:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JAOhGE006242 for rohc-archive@odin.ietf.org; Mon, 19 Apr 2004 06:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVse-00010N-8J for rohc-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 06:20:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01152 for ; Mon, 19 Apr 2004 06:19:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFVsa-0002rg-99 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 06:19:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFVra-0002eJ-00 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 06:18:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFVqs-0002Rb-00 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 06:18:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVmr-0008M7-AY; Mon, 19 Apr 2004 06:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUR7-0000Or-EB for rohc@optimus.ietf.org; Fri, 16 Apr 2004 10:35:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12727 for ; Fri, 16 Apr 2004 10:35:17 -0400 (EDT) From: amannan@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEUR4-0001by-UW for rohc@ietf.org; Fri, 16 Apr 2004 10:35:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUQ3-0001aX-00 for rohc@ietf.org; Fri, 16 Apr 2004 10:34:16 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BEUPJ-0001YT-00 for rohc@ietf.org; Fri, 16 Apr 2004 10:33:29 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3GEUeD27951; Fri, 16 Apr 2004 20:00:51 +0530 To: "Richard Price" Cc: abigail.surtees@roke.co.uk, mark.a.west@roke.co.uk, rohc@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 16 Apr 2004 20:01:36 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/16/2004 08:02:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Regarding STATE-CREATE,STATE-FREE, 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME,SUBJ_FREE_CAP autolearn=no version=2.60 Hi Richard, I have a query regarding the STATE-CREATE,STATE-FREE instructions. Suppose i want to implement a compression algorithm, now when should i add the STATE-CREAT,STATE-FREE instructions in the algorithm. Say suppose i chose to call the STATE-CREATE instruction as the first one instruction in my algorithm , then under what circumstances could there be more than one STATE-CREATE requests. I would appreciate any information/feedback regarding this. Thanks Azim _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 19 09:27:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10010 for ; Mon, 19 Apr 2004 09:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYh2-0003HK-Py for rohc-archive@odin.ietf.org; Mon, 19 Apr 2004 09:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JDKCOY012596 for rohc-archive@odin.ietf.org; Mon, 19 Apr 2004 09:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYey-0002oI-ST for rohc-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 09:18:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09662 for ; Mon, 19 Apr 2004 09:18:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYex-0003rP-7X for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 09:18:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYdz-0003eR-00 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 09:17:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFYdb-0003RW-00 for rohc-web-archive@ietf.org; Mon, 19 Apr 2004 09:16:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYZ6-0001kj-Qn; Mon, 19 Apr 2004 09:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYUG-0000X4-Sh for rohc@optimus.ietf.org; Mon, 19 Apr 2004 09:07:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09166 for ; Mon, 19 Apr 2004 09:06:58 -0400 (EDT) From: amannan@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYUF-0001FT-6D for rohc@ietf.org; Mon, 19 Apr 2004 09:06:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYTQ-00012o-00 for rohc@ietf.org; Mon, 19 Apr 2004 09:06:08 -0400 Received: from 210-210-93-102.lan.sify.net ([210.210.93.102] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BFYSs-0000pZ-00 for rohc@ietf.org; Mon, 19 Apr 2004 09:05:34 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3JD4ID29695; Mon, 19 Apr 2004 18:34:18 +0530 Subject: [rohc] Regarding STATE-CREATE,STATE-FREE, To: "Richard Price" Cc: abigail.surtees@roke.co.uk, mark.a.west@roke.co.uk, rohc@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Mon, 19 Apr 2004 18:35:16 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/19/2004 06:35:17 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME,SUBJ_FREE_CAP autolearn=no version=2.60 Hi Richard, I have a query regarding the STATE-CREATE,STATE-FREE instructions. Suppose i want to implement a compression algorithm, now when should i add the STATE-CREAT,STATE-FREE instructions in the algorithm. Say suppose i chose to call the STATE-CREATE instruction as the first one instruction in my algorithm , then under what circumstances could there be more than one STATE-CREATE requests. I would appreciate any information/feedback regarding this. Thanks Azim _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 21 01:16:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24584 for ; Wed, 21 Apr 2004 01:16:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGA4h-0005Xn-A9 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 01:15:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L5F7g0021311 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 01:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9zH-0003LS-Cg for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 01:09:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24267 for ; Wed, 21 Apr 2004 01:09:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9zE-0003uV-IN for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 01:09:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9yI-0003pB-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 01:08:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG9xT-0003kY-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 01:07:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9t1-0000Re-57; Wed, 21 Apr 2004 01:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9nd-0006dn-Ai for rohc@optimus.ietf.org; Wed, 21 Apr 2004 00:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23839 for ; Wed, 21 Apr 2004 00:57:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9na-0002o7-G0 for rohc@ietf.org; Wed, 21 Apr 2004 00:57:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9ma-0002jS-00 for rohc@ietf.org; Wed, 21 Apr 2004 00:56:24 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BG9lb-0002Yh-00 for rohc@ietf.org; Wed, 21 Apr 2004 00:55:24 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWI00C5T898QD@mta0.huawei.com> for rohc@ietf.org; Wed, 21 Apr 2004 12:53:34 +0800 (CST) Date: Wed, 21 Apr 2004 10:26:07 +0530 From: suman Subject: Re: [rohc] Regarding STATE-CREATE,STATE-FREE, To: amannan@hss.hns.com, Richard Price Cc: abigail.surtees@roke.co.uk, mark.a.west@roke.co.uk, rohc@ietf.org Message-id: <001301c4275c$f6600960$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_FREE_CAP autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Azim, Comments inline !!! thanks suman ----- Original Message ----- From: To: "Richard Price" Cc: ; ; Sent: Monday, April 19, 2004 6:35 PM Subject: [rohc] Regarding STATE-CREATE,STATE-FREE, > > > > > Hi Richard, > > I have a query regarding the STATE-CREATE,STATE-FREE > instructions. Suppose i want to implement a compression algorithm, > now when should i add the STATE-CREAT,STATE-FREE instructions in the > algorithm. > [suman]: this depends on the implementation strategy and compression algorithm used. In any case, STATE_CREAT instruction will not be executed until the application has given a valid compartment id. > Say suppose i chose to call the STATE-CREATE instruction as the first one > instruction in my algorithm , then under what circumstances could there be > more > than one STATE-CREATE requests. > [suman]: One example wherein there could be more than one state-create instructions is when the remote endpoint wishes to ask the other endpoint to save the bytecode as well as the decompressed message as seperate states for future reference. > I would appreciate any information/feedback regarding this. > > > Thanks > Azim > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Apr 21 02:13:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11234 for ; Wed, 21 Apr 2004 02:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAwz-000078-IE for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 02:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L6BDEn000433 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 02:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAqc-0002cm-4b for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 02:04:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02893 for ; Wed, 21 Apr 2004 02:04:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGAqY-0002hq-0Y for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 02:04:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGApZ-0002cc-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 02:03:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGApB-0002XU-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 02:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAkE-0006XT-Hz; Wed, 21 Apr 2004 01:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAaz-000388-VC for rohc@optimus.ietf.org; Wed, 21 Apr 2004 01:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26925 for ; Wed, 21 Apr 2004 01:48:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGAaw-0000dp-Kp for rohc@ietf.org; Wed, 21 Apr 2004 01:48:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGAZy-0000Yq-00 for rohc@ietf.org; Wed, 21 Apr 2004 01:47:26 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BGAYx-0000Px-00 for rohc@ietf.org; Wed, 21 Apr 2004 01:46:24 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWI00FZYAMMFE@mta0.huawei.com> for rohc@ietf.org; Wed, 21 Apr 2004 13:44:48 +0800 (CST) Date: Wed, 21 Apr 2004 11:17:22 +0530 From: suman To: rohc@ietf.org Message-id: <000a01c42764$1e7b81c0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_lYL2Q8KZkXXM7/iUDNwfvw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] Regarding length of each state item 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_lYL2Q8KZkXXM7/iUDNwfvw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Section 6.2 of rfc 3320 states the following... " As well as storing the state items themselves, the state handler maintains a list of the state items created by a particular compartment and ensures that no compartment exceeds its allocated state_memory_size. For the purpose of calculation, each state item is considered to cost (state_length + 64) bytes." I am not able to get the significance of this magic number "64 bytes " ... what is the purpose of adding these 64 bytes to the state length ? could anybody throw light on this ? thanks suman --Boundary_(ID_lYL2Q8KZkXXM7/iUDNwfvw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Section 6.2 of rfc 3320 states the following...
 
"   As well as storing the state items themselves, the state handler
   maintains a list of the state items created by a particular
   compartment and ensures that no compartment exceeds its allocated
   state_memory_size.  For the purpose of calculation, each state item
   is considered to cost (state_length + 64) bytes."
 
I am not able to get the significance of this magic number "64 bytes " ...
 
what is the purpose of adding these 64 bytes to the state length ?
 
could anybody throw light on this ?
 
 
thanks
suman
--Boundary_(ID_lYL2Q8KZkXXM7/iUDNwfvw)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 21 03:32:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00617 for ; Wed, 21 Apr 2004 03:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGC9I-0001U0-Um for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 03:28:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L7S0fv005694 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 03:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGC0F-0006Br-QO for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00040 for ; Wed, 21 Apr 2004 03:18:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGC0D-0003Re-Ec for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 03:18:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBzL-0003M8-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 03:17:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGByw-0003GR-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 03:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBvl-00041w-0L; Wed, 21 Apr 2004 03:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBmh-0008EL-Ei for rohc@optimus.ietf.org; Wed, 21 Apr 2004 03:04:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29357 for ; Wed, 21 Apr 2004 03:04:36 -0400 (EDT) From: amannan@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBmd-0001w9-Jh for rohc@ietf.org; Wed, 21 Apr 2004 03:04:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBlj-0001qf-00 for rohc@ietf.org; Wed, 21 Apr 2004 03:03:39 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BGBl8-0001l7-00 for rohc@ietf.org; Wed, 21 Apr 2004 03:03:03 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3L705D13842; Wed, 21 Apr 2004 12:30:16 +0530 In-Reply-To: <001301c4275c$f6600960$6d05120a@sumanccl20088> Subject: Re: [rohc] Regarding STATE-CREATE,STATE-FREE, To: suman Cc: abigail.surtees@roke.co.uk, Richard Price , mark.a.west@roke.co.uk, rohc@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 21 Apr 2004 12:30:59 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/21/2004 12:31:48 PM 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME,SUBJ_FREE_CAP autolearn=no version=2.60 Hi Suman, As you mentioned that adding the STATE-CREATE,STATE-FREE depends on implementation strategy and compression algorithm used. My question is : 1>Is there any implementaion guideline for implementing the compression algorithm OR is it upto the discreation of the implementor of the algorithm to add these (STATE-CREATE /STATE-FREE) instruction anywhere. What i mean exactly is whether are there any logical points where these instructions have to be added. According to your second point : "One example wherein there could be more than one state-create instructionsis when the remote endpoint wishes to ask the other endpoint to save the bytecodeas well as the decompressed message as seperate states for future reference" I don't agree to this points, say for instance you are operating in a proxy mode, then would it be possible to save thousand of decompressed messages. Thanks Azim suman To Azimul Mannan/BLR/HSS@HSS, Richard 04/21/04 10:26 AM Price cc abigail.surtees@roke.co.uk, mark.a.west@roke.co.uk, rohc@ietf.org Subject Re: [rohc] Regarding STATE-CREATE,STATE-FREE, Hi Azim, Comments inline !!! thanks suman ----- Original Message ----- From: To: "Richard Price" Cc: ; ; Sent: Monday, April 19, 2004 6:35 PM Subject: [rohc] Regarding STATE-CREATE,STATE-FREE, > > > > > Hi Richard, > > I have a query regarding the STATE-CREATE,STATE-FREE > instructions. Suppose i want to implement a compression algorithm, > now when should i add the STATE-CREAT,STATE-FREE instructions in the > algorithm. > [suman]: this depends on the implementation strategy and compression algorithm used. In any case, STATE_CREAT instruction will not be executed until the application has given a valid compartment id. > Say suppose i chose to call the STATE-CREATE instruction as the first one > instruction in my algorithm , then under what circumstances could there be > more > than one STATE-CREATE requests. > [suman]: One example wherein there could be more than one state-create instructions is when the remote endpoint wishes to ask the other endpoint to save the bytecode as well as the decompressed message as seperate states for future reference. > I would appreciate any information/feedback regarding this. > > > Thanks > Azim > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Apr 21 04:12:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02765 for ; Wed, 21 Apr 2004 04:12:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCnX-0001Mb-Go for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 04:09:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L89ZFI005236 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 04:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCet-0005rT-Hj for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 04:00:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02209 for ; Wed, 21 Apr 2004 04:00:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCeq-0000Bm-UJ for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 04:00:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCdv-00005k-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 03:59:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGCdI-00000A-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 03:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCWa-0002Yk-Ev; Wed, 21 Apr 2004 03:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCQU-000059-MB for rohc@optimus.ietf.org; Wed, 21 Apr 2004 03:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01464 for ; Wed, 21 Apr 2004 03:45:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCQS-0006Lo-9i for rohc@ietf.org; Wed, 21 Apr 2004 03:45:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCPN-0006Gc-00 for rohc@ietf.org; Wed, 21 Apr 2004 03:44:37 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BGCP4-0006BY-00 for rohc@ietf.org; Wed, 21 Apr 2004 03:44:20 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWI00FNWFLQFE@mta0.huawei.com> for rohc@ietf.org; Wed, 21 Apr 2004 15:32:25 +0800 (CST) Date: Wed, 21 Apr 2004 13:04:49 +0530 From: suman Subject: Re: [rohc] Regarding STATE-CREATE,STATE-FREE, To: amannan@hss.hns.com Cc: abigail.surtees@roke.co.uk, Richard Price , mark.a.west@roke.co.uk, rohc@ietf.org Message-id: <001d01c42773$245ea040$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_FREE_CAP autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Azim, Regarding your first query, the answer is "it is upto the discreation of the implementor of the algorithm to add these (STATE-CREATE /STATE-FREE) instruction anywhere. " regarding your second query, while operating in proxy mode, a compartment could be created on a session basis. Only one decompressed message will be stored at any point of time in a compartment. When a new message is received from the peer endpoint, it will replace the old version of the decompressed message. If the proxy is handling thousands of sessions from various endpoints, and is not able to support the memory requirements, it can swtich to stateless compression. thanks suman ----- Original Message ----- From: To: "suman" Cc: ; "Richard Price" ; ; Sent: Wednesday, April 21, 2004 12:30 PM Subject: Re: [rohc] Regarding STATE-CREATE,STATE-FREE, > > > > > Hi Suman, > > As you mentioned that adding the STATE-CREATE,STATE-FREE > depends on implementation strategy and compression > algorithm used. > My question is : > 1>Is there any implementaion guideline for implementing the compression > algorithm OR is it upto the discreation of the implementor of the algorithm > to add these (STATE-CREATE /STATE-FREE) instruction anywhere. What i mean > exactly is whether are there any logical points where these instructions > have to be added. > > According to your second point : "One example wherein there could be more > than one state-create > instructionsis when the remote endpoint wishes to ask the other endpoint to > save the bytecodeas well as the decompressed message as seperate states for > future reference" > > I don't agree to this points, say for instance you are operating in a > proxy mode, then would it be possible to save thousand of decompressed > messages. > > Thanks > Azim > > > > > > > > > > > suman > m> To > Azimul Mannan/BLR/HSS@HSS, Richard > 04/21/04 10:26 AM Price > cc > abigail.surtees@roke.co.uk, > mark.a.west@roke.co.uk, > rohc@ietf.org > Subject > Re: [rohc] Regarding > STATE-CREATE,STATE-FREE, > > > > > > > > > > > Hi Azim, > > Comments inline !!! > > thanks > suman > > ----- Original Message ----- > From: > To: "Richard Price" > Cc: ; ; > Sent: Monday, April 19, 2004 6:35 PM > Subject: [rohc] Regarding STATE-CREATE,STATE-FREE, > > > > > > > > > > > > Hi Richard, > > > > I have a query regarding the STATE-CREATE,STATE-FREE > > instructions. Suppose i want to implement a compression algorithm, > > now when should i add the STATE-CREAT,STATE-FREE instructions in the > > algorithm. > > > [suman]: this depends on the implementation strategy and compression > algorithm used. > In any case, STATE_CREAT instruction will not be executed until the > application has > given a valid compartment id. > > > Say suppose i chose to call the STATE-CREATE instruction as the first one > > instruction in my algorithm , then under what circumstances could there > be > > more > > than one STATE-CREATE requests. > > > [suman]: One example wherein there could be more than one state-create > instructions > is when the remote endpoint wishes to ask the other endpoint to save the > bytecode > as well as the decompressed message as seperate states for future > reference. > > > I would appreciate any information/feedback regarding this. > > > > > > Thanks > > Azim > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Apr 21 08:45:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17430 for ; Wed, 21 Apr 2004 08:45:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH2q-0007be-K1 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 08:41:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LCfePR029233 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 08:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGz7-0006Dq-9j for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 08:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17155 for ; Wed, 21 Apr 2004 08:37:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGGz6-0005YI-3p for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 08:37:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGGy7-0005OZ-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 08:36:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGGxA-0005EO-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 08:35:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGrb-0003Hs-NY; Wed, 21 Apr 2004 08:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGmX-0001DL-8L for rohc@optimus.ietf.org; Wed, 21 Apr 2004 08:24:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16492 for ; Wed, 21 Apr 2004 08:24:47 -0400 (EDT) From: jbhalla@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGGmW-0003e3-40 for rohc@ietf.org; Wed, 21 Apr 2004 08:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGGlo-0003WU-00 for rohc@ietf.org; Wed, 21 Apr 2004 08:24:04 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BGGkz-0003Nz-00 for rohc@ietf.org; Wed, 21 Apr 2004 08:23:13 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3LCLED18714; Wed, 21 Apr 2004 17:51:24 +0530 To: rohc@ietf.org, ellyptic@hotmail.com, cabo@tzi.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 21 Apr 2004 17:52:11 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/21/2004 05:52:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Record-Marking Clarification 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi all, I request you to please confirm if the following understanding for "record-marking"and "record-unmarking" is correct or not :- Record-Marking as described in RFC 3320,section 4.2.2 says Occurs in data stream: Action: ---------------------------------------------------- 0xFF 00 one 0xFF byte in the data stream 0xFF 01 same, but the next byte is quoted (could be another 0xFF) : : 0xFF 7F same, but the next 127 bytes are quoted 0xFF 80 to 0xFF FE (reserved for future standardization) 0xFF FF end of SigComp message Suppose input is 0xFF 00 11 FF 01 22 FF 04 01 FF 03 04 FF FF Byte-# Value ===================== 01 FF 02 FF 03 11 04 FF 05 FF 06 FF 07 00 08 FF 09 FF 10 FF As per "Record-Marking" done at Compressor-end (refer to above input) :- 1> When Compressor is at byte-1,it sees FF FF but it is not end of message so it can replace it as : a> FF 00 FF 00 b> FF 01 FF 2> When Compressor is at byte 4, ,it sees FF FF but it is not end of message so it can replace it as : a> FF 00 FF 00 FF 00 FF 00 ( from byte-4 to byte-8) b> FF 04 FF FF FF 00 As per "Record-Unmarking" done at Decompressor-end, 1>When decompressor sees "FF 00" , the decompressor skips "0 byte" i.e goes to 3 byte [copies literally into output buffer] 2>When decompressor sees "FF 01" it skips "1 byte" i.e goes "1 byte" ahead [copies 1 byte literally into output buffer] 3>When decompressor sees "FF 04" it skips "4 bytes" i.e it goes "4 bytes" ahead [copies 4 bytes literally into output buf] 4> When decompressor sees "FF FF" , it means end of the sigcomp message. Conclusion: ----------------- The compressor can effectively "record-mark" the output sigcomp buffer using this scheme (look ahead the bytes and form the message) so that the work of decompressor is reduced. Please confirm if the above understanding is correct... thanks and regards Jyoti _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 21 08:51:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17705 for ; Wed, 21 Apr 2004 08:51:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH9r-0001Ws-0l for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 08:48:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LCmsGH005874 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 08:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH40-00088q-EK for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 08:42:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17339 for ; Wed, 21 Apr 2004 08:42:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGH3z-0006Ej-76 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 08:42:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGH2z-00066a-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 08:41:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGH2F-0005zF-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 08:41:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGuS-00045G-Fn; Wed, 21 Apr 2004 08:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGrV-0003Gs-9C for rohc@optimus.ietf.org; Wed, 21 Apr 2004 08:29:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16732 for ; Wed, 21 Apr 2004 08:29:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGGrU-0004Jp-3t for rohc@ietf.org; Wed, 21 Apr 2004 08:29:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGGqb-0004B7-00 for rohc@ietf.org; Wed, 21 Apr 2004 08:29:02 -0400 Received: from bay12-f53.bay12.hotmail.com ([64.4.35.53] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGGpj-0003vE-00 for rohc@ietf.org; Wed, 21 Apr 2004 08:28:07 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 05:27:36 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Wed, 21 Apr 2004 12:27:36 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: sumanc@huawei.com, rohc@ietf.org Subject: RE: [rohc] Regarding length of each state item Date: Wed, 21 Apr 2004 13:27:36 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2004 12:27:36.0535 (UTC) FILETIME=[07604E70:01C4279C] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Suman, The additional 64 bytes is to take into account the cost of storing the state_identifier, state_length, state_address, state_instruction and minimum_access_length which are also required as part of a state item, as well as the cost of storing some kind of hashing table to provide quick access to the states. 64 bytes is a generous estimate of the additional cost of storing each state item: efficient implementations may be able to get away with less than this. Regards, Richard >From: suman >To: rohc@ietf.org >Subject: [rohc] Regarding length of each state item >Date: Wed, 21 Apr 2004 11:17:22 +0530 > >Section 6.2 of rfc 3320 states the following... > >" As well as storing the state items themselves, the state handler > maintains a list of the state items created by a particular > compartment and ensures that no compartment exceeds its allocated > state_memory_size. For the purpose of calculation, each state item > is considered to cost (state_length + 64) bytes." > >I am not able to get the significance of this magic number "64 bytes " ... > >what is the purpose of adding these 64 bytes to the state length ? > >could anybody throw light on this ? > > >thanks >suman _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 21 09:37:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20368 for ; Wed, 21 Apr 2004 09:37:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHfS-0006fO-Dc for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 09:21:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LDLYXD025622 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 09:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHZv-0004xJ-8D for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 09:15:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19148 for ; Wed, 21 Apr 2004 09:15:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHZt-0003Vq-Q4 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 09:15:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHYt-0003Lg-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 09:14:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGHXs-00036T-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 09:13:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHPQ-0000yK-IT; Wed, 21 Apr 2004 09:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHNJ-0007qh-9s for rohc@optimus.ietf.org; Wed, 21 Apr 2004 09:02:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18425 for ; Wed, 21 Apr 2004 09:02:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHNH-0001Qk-Rb for rohc@ietf.org; Wed, 21 Apr 2004 09:02:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHMO-0001IP-00 for rohc@ietf.org; Wed, 21 Apr 2004 09:01:52 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BGHLW-00011O-00 for rohc@ietf.org; Wed, 21 Apr 2004 09:00:58 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWI00MYHUQSGM@mta0.huawei.com> for rohc@ietf.org; Wed, 21 Apr 2004 20:59:18 +0800 (CST) Date: Wed, 21 Apr 2004 18:31:51 +0530 From: suman Subject: Re: [rohc] Regarding length of each state item To: Richard Price , rohc@ietf.org Message-id: <001001c427a0$d1c92ed0$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Richard, As per your explanation, it is clear that the magic number 64 is implementation specific.( the way the state item is organized in the database.). so I think the rule stated in section 6.2 or rfc 3320 does not carry much weightage if the implementation has a different strategy. ( 64 could be different for different implementations..) " If the state creation request needs more state memory than the total state_memory_size for the compartment, the state handler deletes all but the first (state_memory_size - 64) bytes from the state_value. It sets the state_length to (state_memory_size - 64), and recalculates the state_identifier as defined in Section 9.4.9." any comments on this ? thanks suman ----- Original Message ----- From: "Richard Price" To: ; Sent: Wednesday, April 21, 2004 5:57 PM Subject: RE: [rohc] Regarding length of each state item > Suman, > > The additional 64 bytes is to take into account the cost > of storing the state_identifier, state_length, state_address, > state_instruction and minimum_access_length which are also > required as part of a state item, as well as the cost of > storing some kind of hashing table to provide quick access > to the states. > > 64 bytes is a generous estimate of the additional cost of > storing each state item: efficient implementations may be > able to get away with less than this. > > Regards, > > Richard > > > >From: suman > >To: rohc@ietf.org > >Subject: [rohc] Regarding length of each state item > >Date: Wed, 21 Apr 2004 11:17:22 +0530 > > > >Section 6.2 of rfc 3320 states the following... > > > >" As well as storing the state items themselves, the state handler > > maintains a list of the state items created by a particular > > compartment and ensures that no compartment exceeds its allocated > > state_memory_size. For the purpose of calculation, each state item > > is considered to cost (state_length + 64) bytes." > > > >I am not able to get the significance of this magic number "64 bytes " ... > > > >what is the purpose of adding these 64 bytes to the state length ? > > > >could anybody throw light on this ? > > > > > >thanks > >suman > > _________________________________________________________________ > Express yourself with cool emoticons - download MSN Messenger today! > http://www.msn.co.uk/messenger > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Apr 21 12:38:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01336 for ; Wed, 21 Apr 2004 12:38:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKbg-0003Gh-3A for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 12:30:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTp36012535 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKPM-0006H0-Gs for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00024 for ; Wed, 21 Apr 2004 12:17:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKPL-0002tv-61 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 12:17:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKOT-0002hj-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 12:16:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKNV-0002Uv-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 12:15:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzr-00037m-BI; Wed, 21 Apr 2004 11:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJoY-0007Tx-SW for rohc@optimus.ietf.org; Wed, 21 Apr 2004 11:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27843 for ; Wed, 21 Apr 2004 11:39:04 -0400 (EDT) From: amannan@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJoX-0003hB-Mw for rohc@ietf.org; Wed, 21 Apr 2004 11:39:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJne-0003WB-00 for rohc@ietf.org; Wed, 21 Apr 2004 11:38:10 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJmn-0003Lf-00 for rohc@ietf.org; Wed, 21 Apr 2004 11:37:18 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3LFYfD21087; Wed, 21 Apr 2004 21:04:52 +0530 To: rohc@ietf.org Cc: abigail.surtees@roke.co.uk, Richard Price , mark.a.west@roke.co.uk X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 21 Apr 2004 21:05:38 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/21/2004 09:06:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Query regarding the format of returned_feedback_field 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi, According to the section 9.4.9. (END-MESSAGE ) of RFC 3320 " The returned feedback data is itself subdivided into a returned feedback item and a list of returned SigComp parameters." The figure 13 of the RFC 3320 describes the format of the returned SigComp parameters, however the format of the returned feedback item is not clear. According to Section 7.1 of RFC 3320 (Returned feedback item), the format of the returned feedback item is shown in figure 4, (i have shown the figure in the mail for quick reference). My question is what is the format of the "returned_feedback_field" ?. This is needed since the other end would need to understand the format before processing. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 0 | returned_feedback_field | | 1 | returned_feedback_length | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | : returned_feedback_field : | | +---+---+---+---+---+---+---+---+ I would appreciate any information regarding this. Thanks Azim _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 21 18:22:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23292 for ; Wed, 21 Apr 2004 18:22:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPpJ-0002cW-Bl for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM4HEJ010067 for rohc-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOqT-0001WB-NL for rohc-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14111 for ; Wed, 21 Apr 2004 17:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOqR-0004iy-JD for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 17:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOpU-0004Xu-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 17:00:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOof-0004M0-00 for rohc-web-archive@ietf.org; Wed, 21 Apr 2004 16:59:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZo-0003Ta-2Q; Wed, 21 Apr 2004 16:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGL4r-0006Kd-Uy for rohc@optimus.ietf.org; Wed, 21 Apr 2004 13:00:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02153 for ; Wed, 21 Apr 2004 12:59:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGL4q-0002NF-7g for rohc@ietf.org; Wed, 21 Apr 2004 13:00:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGL3s-0002Dj-00 for rohc@ietf.org; Wed, 21 Apr 2004 12:59:01 -0400 Received: from bay12-f11.bay12.hotmail.com ([64.4.35.11] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGL2z-0001v7-00 for rohc@ietf.org; Wed, 21 Apr 2004 12:58:05 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 09:57:32 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Wed, 21 Apr 2004 16:57:32 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: sumanc@huawei.com, rohc@ietf.org Subject: Re: [rohc] Regarding length of each state item Date: Wed, 21 Apr 2004 17:57:32 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2004 16:57:32.0535 (UTC) FILETIME=[BCF1C870:01C427C1] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Suman, The "magic number" of 64 bytes is referring to the amount of state memory required to store each state item. This defines the behaviour of the UDVM as it appears to the outside world. For example, if the remote endpoint requests 4 state items of size 400 bytes to be stored in a compartment of 2048 bytes, then the amount of state memory remaining must be 2048 - 4 x 464 = 192 bytes. Since the UDVM is a *virtual* machine, there is no need to have a 1-1 mapping between state memory and physical memory. Each state item costs (state_length + 64) bytes of state memory to store, as perceived by the bytecode running on the UDVM; however, the actual amount of physical memory used to store the state may be different. The important point to make sure of is that the UDVM behaves as documented in RFC 3320. Regards, Richard >From: suman >To: Richard Price , rohc@ietf.org >Subject: Re: [rohc] Regarding length of each state item >Date: Wed, 21 Apr 2004 18:31:51 +0530 > >Hi Richard, > >As per your explanation, it is clear that the magic number 64 >is implementation specific.( the way the state item is organized >in the database.). > >so I think the rule stated in section 6.2 or rfc 3320 does not carry >much weightage if the implementation has a different strategy. >( 64 could be different for different implementations..) > >" If the state creation request needs more state memory than the > total state_memory_size for the compartment, the state handler > deletes all but the first (state_memory_size - 64) bytes from the > state_value. It sets the state_length to (state_memory_size - > 64), and recalculates the state_identifier as defined in Section > 9.4.9." > >any comments on this ? > >thanks >suman >----- Original Message ----- >From: "Richard Price" >To: ; >Sent: Wednesday, April 21, 2004 5:57 PM >Subject: RE: [rohc] Regarding length of each state item > > > > Suman, > > > > The additional 64 bytes is to take into account the cost > > of storing the state_identifier, state_length, state_address, > > state_instruction and minimum_access_length which are also > > required as part of a state item, as well as the cost of > > storing some kind of hashing table to provide quick access > > to the states. > > > > 64 bytes is a generous estimate of the additional cost of > > storing each state item: efficient implementations may be > > able to get away with less than this. > > > > Regards, > > > > Richard > > > > > > >From: suman > > >To: rohc@ietf.org > > >Subject: [rohc] Regarding length of each state item > > >Date: Wed, 21 Apr 2004 11:17:22 +0530 > > > > > >Section 6.2 of rfc 3320 states the following... > > > > > >" As well as storing the state items themselves, the state handler > > > maintains a list of the state items created by a particular > > > compartment and ensures that no compartment exceeds its allocated > > > state_memory_size. For the purpose of calculation, each state item > > > is considered to cost (state_length + 64) bytes." > > > > > >I am not able to get the significance of this magic number "64 bytes " >... > > > > > >what is the purpose of adding these 64 bytes to the state length ? > > > > > >could anybody throw light on this ? > > > > > > > > >thanks > > >suman > > > > _________________________________________________________________ > > Express yourself with cool emoticons - download MSN Messenger today! > > http://www.msn.co.uk/messenger > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Apr 22 01:50:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19507 for ; Thu, 22 Apr 2004 01:50:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGX4C-00020F-Ki for rohc-archive@odin.ietf.org; Thu, 22 Apr 2004 01:48:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M5m8C6007694 for rohc-archive@odin.ietf.org; Thu, 22 Apr 2004 01:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGX0s-0000NT-MP for rohc-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 01:44:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19026 for ; Thu, 22 Apr 2004 01:44:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGX0p-0004oV-HM for rohc-web-archive@ietf.org; Thu, 22 Apr 2004 01:44:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGWzV-0004Ii-00 for rohc-web-archive@ietf.org; Thu, 22 Apr 2004 01:43:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGWyM-0003xF-00 for rohc-web-archive@ietf.org; Thu, 22 Apr 2004 01:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGWsW-0004tU-HA; Thu, 22 Apr 2004 01:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGWlG-0001XR-OT for rohc@optimus.ietf.org; Thu, 22 Apr 2004 01:28:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17884 for ; Thu, 22 Apr 2004 01:28:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGWlC-00016p-Uv for rohc@ietf.org; Thu, 22 Apr 2004 01:28:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGWkF-0000vB-00 for rohc@ietf.org; Thu, 22 Apr 2004 01:27:32 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BGWjP-0000WG-00 for rohc@ietf.org; Thu, 22 Apr 2004 01:26:39 -0400 Received: from sumanccl20088 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWK003X547CAX@mta0.huawei.com> for rohc@ietf.org; Thu, 22 Apr 2004 13:21:14 +0800 (CST) Date: Thu, 22 Apr 2004 10:53:47 +0530 From: suman To: rohc@ietf.org Cc: mark.a.west@roke.co.uk, abigail.surtees@roke.co.uk, Richard Price Message-id: <001d01c42829$fe459640$6d05120a@sumanccl20088> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_N/3yfJyKVB0IR3RfgdJeOg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] Query regarding usage of states in SigComp 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_N/3yfJyKVB0IR3RfgdJeOg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi All, Consider a scenario wherein an Endpoint1 asks the Endpoint2 to create 3 states.(s1, s2, s3) one for storing the bytecode(s1), the second for storing the user specific dictionary(s2), and the third for implementing dynamic/shared compression(s3). All these states will be stored in a compartment. Now when the Endpoint2 wishes to send a compresed message how can it make a decision which of these states, s1, s2, and s3. should be used while compressing the application message ?? Actually the compressor is supposed to used only s2 and s3...s1 cannot be used for compression because it actually contains the bytecode for future reference. But the compressor cannot make an intelligent decision and identify which states to use and which not to use just by examining the state identifiers ??? Any comments on this would be appreciated, thanks suman --Boundary_(ID_N/3yfJyKVB0IR3RfgdJeOg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi All,
 
   Consider a scenario wherein an Endpoint1 asks the Endpoint2 to create 3 states.(s1, s2, s3)
one for storing the bytecode(s1), the second for storing the user specific dictionary(s2),
and the third for implementing dynamic/shared compression(s3).
 
All these states will be stored in a compartment.
 
Now when the Endpoint2 wishes to send a compresed message how can it make a decision
which of these states, s1, s2, and s3. should be used while compressing the application message ??
 
Actually the compressor is supposed to used only s2 and s3...s1 cannot be used for compression
because it actually contains the bytecode for future reference.
 
But the compressor cannot make an intelligent decision and identify which states to use and which not
to use just by examining the state identifiers ???
 
Any comments on this would be appreciated,
 
thanks
suman
--Boundary_(ID_N/3yfJyKVB0IR3RfgdJeOg)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 00:10:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25996 for ; Fri, 23 Apr 2004 00:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrzU-0008VU-46 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 00:08:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N48evJ032700 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 00:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrvW-0006YJ-Na for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 00:04:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25639 for ; Fri, 23 Apr 2004 00:04:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGrvS-0001jV-Di for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 00:04:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGruU-0001SE-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 00:03:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGrtW-0001BT-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 00:02:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGroD-0005TM-1v; Thu, 22 Apr 2004 23:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrg5-0002rh-EW for rohc@optimus.ietf.org; Thu, 22 Apr 2004 23:48:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25054 for ; Thu, 22 Apr 2004 23:48:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGrg1-0005Ll-5M for rohc@ietf.org; Thu, 22 Apr 2004 23:48:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGrf6-00055k-00 for rohc@ietf.org; Thu, 22 Apr 2004 23:47:37 -0400 Received: from [216.90.186.146] (helo=mail.ipnetfusion.com) by ietf-mx with esmtp (Exim 4.12) id 1BGreI-0004q6-00 for rohc@ietf.org; Thu, 22 Apr 2004 23:46:46 -0400 Received: from ipnetfusion.com (proxy.ipnetfusion.com [216.90.186.147]) (authenticated) by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i3N3kNG12457; Thu, 22 Apr 2004 22:46:23 -0500 Message-ID: <408891EF.9050900@ipnetfusion.com> Date: Thu, 22 Apr 2004 22:47:59 -0500 From: Simran Suri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jbhalla@hss.hns.com CC: rohc@ietf.org Subject: Re: [rohc] Record-Marking Clarification References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040405040407070603080600" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------040405040407070603080600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jyoti, Please refer to the following post by Carsten regarding this: http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02031.html Rgds, Simran jbhalla@hss.hns.com wrote: > > >Hi all, > I request you to please confirm if the following understanding >for "record-marking"and "record-unmarking" is correct or not :- > >Record-Marking as described in RFC 3320,section 4.2.2 says >Occurs in data stream: Action: >---------------------------------------------------- > 0xFF 00 one 0xFF byte in the data stream > 0xFF 01 same, but the next byte is quoted (could > be another 0xFF) > : : > 0xFF 7F same, but the next 127 bytes are quoted > 0xFF 80 to 0xFF FE (reserved for future standardization) > 0xFF FF end of SigComp message > > >Suppose input is 0xFF 00 11 FF 01 22 FF 04 01 FF 03 04 FF FF >Byte-# Value >===================== >01 FF >02 FF >03 11 >04 FF >05 FF >06 FF >07 00 >08 FF >09 FF >10 FF > >As per "Record-Marking" done at Compressor-end (refer to above input) :- >1> When Compressor is at byte-1,it sees FF FF but it is not end >of message so it can replace it as : > a> FF 00 FF 00 > b> FF 01 FF >2> When Compressor is at byte 4, ,it sees FF FF but it is not end > of message so it can replace it as : > a> FF 00 FF 00 FF 00 FF 00 ( from byte-4 to byte-8) > b> FF 04 FF FF FF 00 > > >As per "Record-Unmarking" done at Decompressor-end, >1>When decompressor sees "FF 00" , the decompressor skips > "0 byte" i.e goes to 3 byte [copies literally into output buffer] >2>When decompressor sees "FF 01" it skips "1 byte" i.e > goes "1 byte" ahead [copies 1 byte literally into output buffer] >3>When decompressor sees "FF 04" it skips "4 bytes" i.e > it goes "4 bytes" ahead [copies 4 bytes literally into output buf] >4> When decompressor sees "FF FF" , it means > end of the sigcomp message. > > >Conclusion: >----------------- >The compressor can effectively "record-mark" the output sigcomp >buffer using this scheme (look ahead the bytes and form the message) >so that the work of decompressor is reduced. > > >Please confirm if the above understanding is correct... > > >thanks and regards >Jyoti > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc > > > --------------040405040407070603080600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jyoti,
Please refer to the following post by Carsten regarding this:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02031.html
Rgds,
Simran

jbhalla@hss.hns.com wrote:


Hi all,
      I request you to please confirm if the following understanding
for "record-marking"and "record-unmarking" is correct or not :-

Record-Marking as described in RFC 3320,section 4.2.2  says
Occurs in data stream:     Action:
----------------------------------------------------
   0xFF 00                 one 0xFF byte in the data stream
   0xFF 01                 same, but the next byte is quoted (could
                                   be another 0xFF)
      :                           :
   0xFF 7F                 same, but the next 127 bytes are quoted
   0xFF 80 to 0xFF FE      (reserved for future standardization)
   0xFF FF                 end of SigComp message


Suppose input is  0xFF 00 11 FF 01 22 FF 04 01 FF 03 04 FF FF
Byte-#         Value
=====================
01                FF
02                FF
03                11
04                FF
05                FF
06                FF
07                00
08                FF
09                FF
10                FF

As per "Record-Marking" done at Compressor-end (refer to above input) :-
1> When Compressor is at byte-1,it sees FF FF but it is not end
of message so it can replace it as :
            a> FF 00 FF 00
            b> FF 01 FF
2> When Compressor is at byte 4, ,it sees FF FF but it is not end
   of message so it can replace it as :
            a> FF 00 FF 00 FF 00 FF 00 ( from byte-4 to byte-8)
            b> FF 04 FF FF FF 00


As per "Record-Unmarking" done at Decompressor-end,
1>When decompressor sees "FF 00" , the decompressor skips
  "0 byte" i.e goes to 3 byte [copies literally into output buffer]
2>When decompressor sees "FF 01" it skips "1 byte" i.e
  goes  "1 byte" ahead [copies 1 byte literally into output buffer]
3>When decompressor sees "FF 04" it skips "4 bytes" i.e
  it goes "4 bytes" ahead [copies 4 bytes literally into output buf]
4> When decompressor sees "FF FF" , it means
   end of the sigcomp message.


Conclusion:
-----------------
The compressor can effectively "record-mark" the output sigcomp
buffer using this scheme (look ahead the bytes and form the message)
so that the work of decompressor is reduced.


Please confirm if the above understanding is correct...


thanks and regards
Jyoti


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
--------------040405040407070603080600-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 01:23:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00671 for ; Fri, 23 Apr 2004 01:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsxw-0003Y7-Bt for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 01:11:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N5B8wq013638 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 01:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsv2-0002IN-1E for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 01:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29757 for ; Fri, 23 Apr 2004 01:08:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGsux-000485-5R for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 01:08:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGstm-0003n5-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 01:06:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGst2-0003US-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 01:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsoD-0008J1-6B; Fri, 23 Apr 2004 01:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGshL-0006AB-CY for rohc@optimus.ietf.org; Fri, 23 Apr 2004 00:53:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28650 for ; Fri, 23 Apr 2004 00:53:54 -0400 (EDT) From: jbhalla@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGshG-0007Wo-F6 for rohc@ietf.org; Fri, 23 Apr 2004 00:53:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsgC-0007F4-00 for rohc@ietf.org; Fri, 23 Apr 2004 00:52:48 -0400 Received: from 210-210-93-102.lan.sify.net ([210.210.93.102] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BGsf9-0006tH-00 for rohc@ietf.org; Fri, 23 Apr 2004 00:51:43 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3N4noD13054; Fri, 23 Apr 2004 10:20:00 +0530 To: rohc@ietf.org, ellyptic@hotmail.com, cabo@tzi.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 23 Apr 2004 10:20:29 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/23/2004 10:21:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [rohc] Compressor Requirement as per RFC 3320 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi all, I have a doubt in a requirement of compressor/compressor dispatcher as described in section-5 of RFC 3320. It says : "The compressor MUST ensure that the message can be decompressed using the resources available at the remote endpoint." Doubt : ------- RFC 3320 provides feedback mechanism to advertize endpoints's local capabilities/resources(sigcomp parmeters like decompression memory size) to remote end and it is sent as piggy-backed in the sigcomp message. How a compressor (sender end) will know the "remote end configuration/resources" [to ensure the successful decompression using the resources available at the remote endpoint] as it does not know other end's resource availability before sending a message incase it is the session initiating end point. Since feedback request is sent piggybacked with sigcomp message so how can endpoint advertize its local configuration/resources to remote end so that remote end can use this information effectively to take decision *to ensure successful decompression*. Please clarify my doubt on this requirement of compressor. thanks and regards Jyoti _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 05:47:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24956 for ; Fri, 23 Apr 2004 05:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGx5W-00048D-Lz for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 05:35:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N9ZEPJ015881 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 05:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGx2F-0003Pl-F3 for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 05:31:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24475 for ; Fri, 23 Apr 2004 05:31:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGx29-0005UL-TY for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 05:31:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGx1D-0005EP-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 05:30:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGx0G-0004yT-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 05:29:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwxa-0001xr-13; Fri, 23 Apr 2004 05:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwsY-0008A4-RG for rohc@optimus.ietf.org; Fri, 23 Apr 2004 05:21:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24149 for ; Fri, 23 Apr 2004 05:21:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGwsT-0002wb-9z for rohc@ietf.org; Fri, 23 Apr 2004 05:21:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwrV-0002gD-00 for rohc@ietf.org; Fri, 23 Apr 2004 05:20:46 -0400 Received: from bay12-f72.bay12.hotmail.com ([64.4.35.72] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGwqX-0002CT-00 for rohc@ietf.org; Fri, 23 Apr 2004 05:19:45 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Apr 2004 02:19:18 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Fri, 23 Apr 2004 09:19:18 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: jbhalla@hss.hns.com, rohc@ietf.org Date: Fri, 23 Apr 2004 10:19:18 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Apr 2004 09:19:18.0751 (UTC) FILETIME=[0E32C6F0:01C42914] Subject: [rohc] RE: Compressor Requirement as per RFC 3320 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jyoti, Since standalone feedback messages are normally banned for security reasons, the very first message in the exchange must be decompressible using only the minimum resources guaranteed to be available at the remote endpoint. For SIP/SigComp, the minimum resources that must be provided by every endpoint are in . Regards, Richard >From: jbhalla@hss.hns.com >To: rohc@ietf.org, ellyptic@hotmail.com, cabo@tzi.org >Subject: Compressor Requirement as per RFC 3320 >Date: Fri, 23 Apr 2004 10:20:29 +0530 > > > > > >Hi all, >I have a doubt in a requirement of compressor/compressor dispatcher >as described in section-5 of RFC 3320. It says : >"The compressor MUST ensure that the message can be decompressed > using the resources available at the remote endpoint." > > >Doubt : >------- >RFC 3320 provides feedback mechanism to advertize endpoints's >local capabilities/resources(sigcomp parmeters like decompression memory >size) >to remote end and it is sent as piggy-backed in the sigcomp message. > >How a compressor (sender end) will know the >"remote end configuration/resources" [to ensure the successful >decompression using the resources available at the remote >endpoint] as it does not know other end's resource availability before >sending >a message incase it is the session initiating end point. > >Since feedback request is sent piggybacked with sigcomp message >so how can endpoint advertize its local configuration/resources >to remote end so that remote end can use this information >effectively to take decision *to ensure successful decompression*. > >Please clarify my doubt on this requirement of compressor. > >thanks and regards >Jyoti > _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 06:42:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26816 for ; Fri, 23 Apr 2004 06:42:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGy60-0003r1-Ug for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 06:39:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NAdmsJ014811 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 06:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGxzN-00027y-00 for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 06:32:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26520 for ; Fri, 23 Apr 2004 06:32:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGxzH-0005zM-0d for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 06:32:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGxyH-0005jL-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 06:31:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGxxb-0005U1-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 06:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGxrg-0000FJ-Kj; Fri, 23 Apr 2004 06:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGxni-0007po-Kj for rohc@optimus.ietf.org; Fri, 23 Apr 2004 06:20:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26163 for ; Fri, 23 Apr 2004 06:20:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGxnc-0002s7-PH for rohc@ietf.org; Fri, 23 Apr 2004 06:20:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGxmd-0002bq-00 for rohc@ietf.org; Fri, 23 Apr 2004 06:19:47 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BGxlf-00027b-00 for rohc@ietf.org; Fri, 23 Apr 2004 06:18:51 -0400 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HWM00E6ZCOSHU@mta2.huawei.com> for rohc@ietf.org; Fri, 23 Apr 2004 18:19:41 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HWM00LPVCORID@mta2.huawei.com> for rohc@ietf.org; Fri, 23 Apr 2004 18:19:40 +0800 (CST) Received: from JAKKIS ([10.18.5.200]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HWMCUG00.C0U for ; Fri, 23 Apr 2004 18:23:04 +0800 Date: Fri, 23 Apr 2004 15:54:03 +0530 From: sasidhar To: rohc@ietf.org Reply-to: sasidhar Message-id: <004f01c4291d$19cafba0$c805120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_zwmey/XjEiPDfeZjMBGsug)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] state retention priority - SIGCOMP 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_zwmey/XjEiPDfeZjMBGsug) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, I have some doubt regarding state retention priority in SIGCOMP. Consider the following call flow.. Endpoint A Endpoint B S0* -----------------M1-----------------------> S0 S0,S1 <---------------M2--------------------------S1*,S0 S0,S1,S2* ----------------M3(S0)------------------->S2,S1,S0 S0,S1,S2,S3<---------------M4(S1)-------------------S3*,S2,S1.S0 * implies unacked. Doubts: 1. Endpoint A creates a state S0 locally and remotely. Do both the states have the same priority(priority doesn't effect state id)? 2. Suppose endpoint A has SMS equal to the size of two states (say 1kb each). If A gives constant priority 1 for its states and B gives a priority of 10, when A receives M3 it will be having states . And on receiving M4 it will be . Endpoint A will have no states to use for compressing the next message. So it has to go stateless. This will effect the compression ratio. Please clarify my doubts. Thanks, Sasidhar --Boundary_(ID_zwmey/XjEiPDfeZjMBGsug) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
    I have some doubt regarding state retention priority in SIGCOMP. Consider the following call flow..
 
 
    Endpoint A                                   Endpoint B
            S0* -----------------M1-----------------------> S0
   
       S0,S1  <---------------M2--------------------------S1*,S0
 
   S0,S1,S2* ----------------M3(S0)------------------->S2,S1,S0
   
S0,S1,S2,S3<---------------M4(S1)-------------------S3*,S2,S1.S0
 
    * implies unacked.
 
Doubts:
   1. Endpoint A creates a state S0 locally and remotely. Do both the states have the same priority(priority doesn't effect state id)?
   2. Suppose endpoint A has SMS equal to the size of two states (say 1kb each). If A gives constant priority 1 for its states and B gives a priority of 10, when A receives M3 it will be having states <S1,S2>. And on receiving M4 it will be <S1,S3>. Endpoint A will have no states to use for compressing the next message. So it has to go stateless. This will effect the compression ratio.
 
Please clarify my doubts.
 
Thanks,
Sasidhar
--Boundary_(ID_zwmey/XjEiPDfeZjMBGsug)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 09:36:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06848 for ; Fri, 23 Apr 2004 09:36:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0nu-0006qN-JM for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 09:33:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NDXIAq026301 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 09:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0hP-0004l6-Q8 for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:26:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06050 for ; Fri, 23 Apr 2004 09:26:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0hO-0005ES-4y for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 09:26:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0gH-0004sr-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 09:25:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH0fP-0004Zu-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 09:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0TP-0000Ic-BU; Fri, 23 Apr 2004 09:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0OW-0006nq-6g for rohc@optimus.ietf.org; Fri, 23 Apr 2004 09:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04513 for ; Fri, 23 Apr 2004 09:07:01 -0400 (EDT) From: amannan@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0OU-0007U6-Lh for rohc@ietf.org; Fri, 23 Apr 2004 09:07:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0Nh-0007Eo-00 for rohc@ietf.org; Fri, 23 Apr 2004 09:06:14 -0400 Received: from [61.16.168.135] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BH0Ml-0006uk-00; Fri, 23 Apr 2004 09:05:17 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3ND33D19267; Fri, 23 Apr 2004 18:33:15 +0530 In-Reply-To: <004f01c4291d$19cafba0$c805120a@in.huawei.com> Subject: Re: [rohc] state retention priority - SIGCOMP To: sasidhar Cc: rohc@ietf.org, rohc-admin@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 23 Apr 2004 18:34:10 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/23/2004 06:34:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Sasidhar, Refer to Section 6.2.( Memory Management) of RFC 3320. It states that " Note that locally available state items (as described in Section 3.3.3) need not be mapped to any particular compartment. However, i= f they are created on a per-compartment basis, then they must not interfere with the state created at the request of the remote endpoint. The special state_retention_priority of 65535 is reserved= for locally available state items to ensure that this is the case." 1) Locally created states have the least priority i.e 65535, if created= on a per compartment basis. The state_retention_priority of 65535 is reserved for locally available states; these states must always b= e freed first. This clearly states that the remotely created states hav= e a higher priority, since there priority would range from (0 - 65534) an= d locally created states whose priority is always 65535. 2) Regarding your second point you need not store the local states on a= per compartment basis, there could be stored globally (refer sec 5.3 of RFC 3321), hence the state would not be deleted whe= n a new state creation request comes from the remote. However if you still decide to go ahead with maintaining the local states on a per= compartment basis then they would be deleted if no states memory is available and a new request for state creation has come from the rem= ote. Thanks Azim The answer to your first question is = sasidhar = = To Sent by: rohc@ietf.org = rohc-admin@ietf.o = cc rg = Subj= ect [rohc] state retention priority = - 04/23/04 03:54 PM SIGCOMP = = = Please respond to = sasidhar = = = = Hi all, =A0=A0=A0 I have=A0some doubt regarding state retention priority in SI= GCOMP. Consider the following call flow.. =A0=A0=A0 Endpoint A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Endpoint B =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 S0*=A0-----------------M1---------------= --------> S0 =A0=A0=A0=A0=A0=A0=A0S0,S1=A0 <---------------M2----------------------= ----S1*,S0 =A0=A0 S0,S1,S2* ----------------M3(S0)------------------->S2,S1,S0 S0,S1,S2,S3<---------------M4(S1)-------------------S3*,S2,S1.S0 =A0=A0=A0 * implies unacked. Doubts: =A0=A0=A01. Endpoint A creates=A0a state S0 locally and remotely. Do b= oth the states have the same priority(priority doesn't effect state id)? =A0=A0 2.=A0Suppose=A0endpoint A has SMS equal to the size of two stat= es (say 1kb each). If A gives constant priority 1 for its=A0states and B gives a priority of 10, when=A0A receives M3 it will be having states .= And=A0on receiving M4 it will be .=A0Endpoint A will have no st= ates to use for compressing=A0the next message. So it has to go stateless. Thi= s will effect the compression ratio. Please clarify my doubts. Thanks, Sasidhar= _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 10:09:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09771 for ; Fri, 23 Apr 2004 10:09:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1DB-0005MV-Uh for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 09:59:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NDxPAc020607 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 09:59:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH16H-0003bm-LB for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:52:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08347 for ; Fri, 23 Apr 2004 09:52:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH16F-00052Q-M3 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 09:52:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH15R-0004la-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 09:51:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH14Y-0004Tn-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 09:50:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0wL-0001F7-DS; Fri, 23 Apr 2004 09:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0se-0008S9-P2 for rohc@optimus.ietf.org; Fri, 23 Apr 2004 09:38:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07091 for ; Fri, 23 Apr 2004 09:38:09 -0400 (EDT) From: anagarajan@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0sc-0000pi-Tg for rohc@ietf.org; Fri, 23 Apr 2004 09:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0rp-0000Yc-00 for rohc@ietf.org; Fri, 23 Apr 2004 09:37:22 -0400 Received: from 210-210-93-102.lan.sify.net ([210.210.93.102] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BH0qu-0000GN-00; Fri, 23 Apr 2004 09:36:24 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i3NDYuD19578; Fri, 23 Apr 2004 19:05:08 +0530 To: rohc@ietf.org, rohc-admin@ietf.org Cc: jbhalla@hss.hns.com, rahammad@hss.hns.com, amannan@hss.hns.com, sauragupta@hss.hns.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Fri, 23 Apr 2004 19:06:08 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 04/23/2004 07:06:21 PM, Serialize complete at 04/23/2004 07:06:21 PM Content-Type: multipart/alternative; boundary="=_alternative 004AC23B65256E7F_=" Subject: [rohc] Physical deletion of states 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004AC23B65256E7F_= Content-Type: text/plain; charset="US-ASCII" Hi All, I have a doubt about the physical deletion of states when all the compartments using these states are closed. In draft-ietf-rohc-sigcomp-sip-01 it says that : "A SigComp endpoint may offer to keep a state created upon request from its peer endpoint during a dialog beyond the duration of that dialog. This may improve compression efficiency of SIP messages generated by the same peer endpoint in subsequent dialogs. In that case, it can inform its peer SigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the dialog. That signals the state will be maintained until the associated timer times out. Since there is no mechanism in SigComp and SIP to convey the timeout value, a default value needs to be specified" Can you tell me in what scenario this retaining of states till the expiry of timer help in compression efficiency of SIP messages? Please clarify on this. Regards Anil N --=_alternative 004AC23B65256E7F_= Content-Type: text/html; charset="US-ASCII"
Hi All,
            I have a doubt about the physical deletion of states when all the compartments using these states are closed. In draft-ietf-rohc-sigcomp-sip-01
it says that :
   
"A SigComp endpoint may offer to keep a state created upon request from its peer endpoint during a dialog beyond the duration of that dialog. This may improve compression efficiency of SIP messages generated by the same peer endpoint in subsequent dialogs.  In that case, it can inform its peer SigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the dialog. That signals the state will be maintained until the associated timer times out. Since there is no mechanism in SigComp and SIP to convey the timeout value, a default value needs to be specified"

Can you tell me in what scenario this retaining of states till the expiry of timer help in compression efficiency of SIP messages?
Please clarify on this.

Regards
Anil N --=_alternative 004AC23B65256E7F_=-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 11:08:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13494 for ; Fri, 23 Apr 2004 11:08:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2DW-0002af-Mj for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 11:03:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NF3oj3009935 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 11:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH259-0000Z0-0s for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:55:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12976 for ; Fri, 23 Apr 2004 10:55:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH256-00069n-Ib for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 10:55:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH24H-0005u4-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 10:54:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH23L-0005e2-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 10:53:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1sS-0005nJ-Dm; Fri, 23 Apr 2004 10:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1og-0004dw-3r for rohc@optimus.ietf.org; Fri, 23 Apr 2004 10:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12137 for ; Fri, 23 Apr 2004 10:38:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1od-0001oo-Md for rohc@ietf.org; Fri, 23 Apr 2004 10:38:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1nl-0001Z2-00 for rohc@ietf.org; Fri, 23 Apr 2004 10:37:14 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BH1mn-00015b-00 for rohc@ietf.org; Fri, 23 Apr 2004 10:36:14 -0400 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HWM000QDOL3OF@mta2.huawei.com> for rohc@ietf.org; Fri, 23 Apr 2004 22:36:40 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HWM00LZGOL2ID@mta2.huawei.com> for rohc@ietf.org; Fri, 23 Apr 2004 22:36:39 +0800 (CST) Received: from JAKKIS ([10.18.5.200]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HWMOQR00.215; Fri, 23 Apr 2004 22:40:03 +0800 Date: Fri, 23 Apr 2004 20:11:02 +0530 From: sasidhar Subject: Re: [rohc] state retention priority - SIGCOMP To: amannan@hss.hns.com Cc: rohc@ietf.org Reply-to: sasidhar Message-id: <006901c42941$0055e9e0$c805120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Azim, Thanks for the explaination. Now let me reiterate the things which i understood. The locally available state items will include the states like static dictionary and also the states that have been saved by the compressor at the local endpoint after the successful compression of a message. These states need not be maintained in the STATE memory and should not reflect in the SMS advertised to the remote endpoint. Please let me know if my understanding is correct. And i have few more queries: 1. You have mentioned that the locally available states(specially the states created by compressor) can be maitained on a global basis. I cannot think of any good reason for this. Can you throw some more light on it? As per my understanding, states will be created by the compressor on a per message basis and each message will be specific to one compartment. So there is very little probability that these states will be same across all compartments. 2. what does SMS that is advertised in the returned sigcomp parameters imply? Does it mean the actual capability of the endpoint or is it the presently available free state memory size ? 3. How can the compressor decide about the minimum access length for a state to be stored on the remote side? Because it won't be having any idea about the number of states that are existing on the remote side. And in the decompression process for STATE-ACCESS instruction, the state has to be accessed without knowing the compartment in which it has been stored. Consider a scenario in which all the endpoints make the minimum access length as 6 for all the states and access the states using 6 bytes. Then, is this SHA-1 hash so efficient that it can avoid collisions among the states even for the FIRST 6 bytes? Thanks, Sasidhar ----- Original Message ----- From: To: "sasidhar" Cc: ; Sent: Friday, April 23, 2004 6:34 PM Subject: Re: [rohc] state retention priority - SIGCOMP Hi Sasidhar, Refer to Section 6.2.( Memory Management) of RFC 3320. It states that " Note that locally available state items (as described in Section 3.3.3) need not be mapped to any particular compartment. However, if they are created on a per-compartment basis, then they must not interfere with the state created at the request of the remote endpoint. The special state_retention_priority of 65535 is reserved for locally available state items to ensure that this is the case." 1) Locally created states have the least priority i.e 65535, if created on a per compartment basis. The state_retention_priority of 65535 is reserved for locally available states; these states must always be freed first. This clearly states that the remotely created states have a higher priority, since there priority would range from (0 - 65534) and locally created states whose priority is always 65535. 2) Regarding your second point you need not store the local states on a per compartment basis, there could be stored globally (refer sec 5.3 of RFC 3321), hence the state would not be deleted when a new state creation request comes from the remote. However if you still decide to go ahead with maintaining the local states on a per compartment basis then they would be deleted if no states memory is available and a new request for state creation has come from the remote. Thanks Azim The answer to your first question is sasidhar To Sent by: rohc@ietf.org rohc-admin@ietf.o cc rg Subject [rohc] state retention priority - 04/23/04 03:54 PM SIGCOMP Please respond to sasidhar Hi all, I have some doubt regarding state retention priority in SIGCOMP. Consider the following call flow.. Endpoint A Endpoint B S0* -----------------M1-----------------------> S0 S0,S1 <---------------M2--------------------------S1*,S0 S0,S1,S2* ----------------M3(S0)------------------->S2,S1,S0 S0,S1,S2,S3<---------------M4(S1)-------------------S3*,S2,S1.S0 * implies unacked. Doubts: 1. Endpoint A creates a state S0 locally and remotely. Do both the states have the same priority(priority doesn't effect state id)? 2. Suppose endpoint A has SMS equal to the size of two states (say 1kb each). If A gives constant priority 1 for its states and B gives a priority of 10, when A receives M3 it will be having states . And on receiving M4 it will be . Endpoint A will have no states to use for compressing the next message. So it has to go stateless. This will effect the compression ratio. Please clarify my doubts. Thanks, Sasidhar _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Apr 23 15:09:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00109 for ; Fri, 23 Apr 2004 15:09:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5mO-0006Y8-I1 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 14:52:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NIq4Qx025176 for rohc-archive@odin.ietf.org; Fri, 23 Apr 2004 14:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5M0-0002pR-25 for rohc-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:24:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25051 for ; Fri, 23 Apr 2004 14:24:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5Lx-0007GC-J6 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 14:24:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5Kv-0006yW-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 14:23:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5KF-0006gJ-00 for rohc-web-archive@ietf.org; Fri, 23 Apr 2004 14:22:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5DX-0000VF-Qc; Fri, 23 Apr 2004 14:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH526-0004ru-A4 for rohc@optimus.ietf.org; Fri, 23 Apr 2004 14:04:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23961 for ; Fri, 23 Apr 2004 14:04:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH523-0001yk-Ur for rohc@ietf.org; Fri, 23 Apr 2004 14:04:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH518-0001hU-00 for rohc@ietf.org; Fri, 23 Apr 2004 14:03:15 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH50F-0001PX-00; Fri, 23 Apr 2004 14:02:20 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NI1YN08060; Fri, 23 Apr 2004 11:01:34 -0700 (PDT) Message-Id: <200404231801.i3NI1YN08060@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, rohc@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 23 Apr 2004 11:01:33 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [rohc] RFC 3759 on RObust Header Compression (ROHC): Terminology and Channel Mapping Examples 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3759 Title: RObust Header Compression (ROHC): Terminology and Channel Mapping Examples Author(s): L-E. Jonsson Status: Informational Date: April 2004 Mailbox: lars-erik.jonsson@ericsson.com Pages: 20 Characters: 50168 Updates: 3095 I-D Tag: draft-ietf-rohc-terminology-and-examples-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3759.txt This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This document is a product of the Robust Header Compression Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040423110006.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3759 --OtherAccess Content-Type: Message/External-body; name="rfc3759.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040423110006.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 26 03:37:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29574 for ; Mon, 26 Apr 2004 03:37:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0eQ-0005jS-TG for rohc-archive@odin.ietf.org; Mon, 26 Apr 2004 03:35:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q7Zcpe022025 for rohc-archive@odin.ietf.org; Mon, 26 Apr 2004 03:35:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0ah-0004rl-4T for rohc-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 03:31:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28780 for ; Mon, 26 Apr 2004 03:31:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0ae-0007IK-TE for rohc-web-archive@ietf.org; Mon, 26 Apr 2004 03:31:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0Zn-00074y-00 for rohc-web-archive@ietf.org; Mon, 26 Apr 2004 03:30:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Yx-0006so-00 for rohc-web-archive@ietf.org; Mon, 26 Apr 2004 03:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0TD-0002fl-Lw; Mon, 26 Apr 2004 03:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0Qv-0001vl-FB for rohc@optimus.ietf.org; Mon, 26 Apr 2004 03:21:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28221 for ; Mon, 26 Apr 2004 03:21:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0Qt-0005E7-0T for rohc@ietf.org; Mon, 26 Apr 2004 03:21:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0Pt-00050a-00 for rohc@ietf.org; Mon, 26 Apr 2004 03:20:38 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Or-0004cQ-00 for rohc@ietf.org; Mon, 26 Apr 2004 03:19:38 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWR00A2BOAAYN@mailout2.samsung.com> for rohc@ietf.org; Mon, 26 Apr 2004 16:18:10 +0900 (KST) Received: from ep_ms13_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWR003BTO5G5A@mailout2.samsung.com> for rohc@ietf.org; Mon, 26 Apr 2004 16:15:16 +0900 (KST) Received: from ep_spt04 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWR002ILO5GDP@ms13.samsung.com> for rohc@ietf.org; Mon, 26 Apr 2004 16:15:16 +0900 (KST) Content-return: prohibited Date: Mon, 26 Apr 2004 07:15:17 +0000 (GMT) From: shilong zhao X-Sender: =?gb2312?B?Pz8/P6H7Pz8/Pz8oVE4/Pymh+0VuZ2luZWVy?= To: rohc@ietf.org Reply-to: shilong.zhao@samsung.com Message-id: <7542893.1082963714179.JavaMail.weblogic@ep_app11> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040426071514176@shilong.zhao X-MTR: 20040426071514176@shilong.zhao X-EPLocale: zh_CN.gb2312 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Subject: [rohc] How to determine the structure of static chain of IR packet 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT hi, Dear all ROHC experts: There is a basic question when I will implement RFC3095. In RFC3095 5.7.7 RTP IR and IR-DYN packets The subheaders which are compressible are split into a STATIC part and a DYNAMIC part. These parts are defined in sections 5.7.7.3 through 5.7.7.7. The structure of a chain of subheaders is determined by each header having a Next Header, or Protocol, field. This field identifies the type of the following header. Each Static part below that is followed by another Static part contains the Next Header/Protocol field and allows parsing of the Static chain; the Dynamic chain, if present, is structured analogously. For RTP/UDP/IPv4. we know that we can know what is the next static chain from IPV4 static part: +---+---+---+---+---+---+---+---+ | Version = 4 | 0 | +---+---+---+---+---+---+---+---+ | Protocol | +---+---+---+---+---+---+---+---+ / Source Address / 4 octets +---+---+---+---+---+---+---+---+ / Destination Address / 4 octets +---+---+---+---+---+---+---+---+ through protocol field, we know the next static should be UDP static part. However, How we know what is next static part(It should be RTP static part) from UDP static part? UDP Static part as following: +---+---+---+---+---+---+---+---+ / Source Port / 2 octets +---+---+---+---+---+---+---+---+ / Destination Port / 2 octets +---+---+---+---+---+---+---+---+ Who can point out for me. Thankx in advance. Shilong Zhao CHINA SAMSUNG Telecom R&D Center 4/F Science and Technology Tower No.9 Zhongguancun Nandajie, Haidian District Beijing, China 100081 TEL: (010) 6842-7711 - 2411 FAX: (010) 6848-1891 Mobile: 13621193636 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Apr 26 03:56:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00895 for ; Mon, 26 Apr 2004 03:56:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0vK-00035J-9c for rohc-archive@odin.ietf.org; Mon, 26 Apr 2004 03:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q7r6Rd011853 for rohc-archive@odin.ietf.org; Mon, 26 Apr 2004 03:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0s8-00024W-6J for rohc-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 03:49:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00484 for ; Mon, 26 Apr 2004 03:49:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0s5-0003s2-M0 for rohc-web-archive@ietf.org; Mon, 26 Apr 2004 03:49:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0rF-0003fl-00 for rohc-web-archive@ietf.org; Mon, 26 Apr 2004 03:48:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI0qf-0003Ta-00 for rohc-web-archive@ietf.org; Mon, 26 Apr 2004 03:48:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0lZ-0008Hp-PI; Mon, 26 Apr 2004 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0iT-0006wq-5C for rohc@optimus.ietf.org; Mon, 26 Apr 2004 03:39:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29836 for ; Mon, 26 Apr 2004 03:39:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0iQ-0001X0-OI for rohc@ietf.org; Mon, 26 Apr 2004 03:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0hT-0001LI-00 for rohc@ietf.org; Mon, 26 Apr 2004 03:38:47 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BI0gp-00019b-00 for rohc@ietf.org; Mon, 26 Apr 2004 03:38:07 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3Q7c7PA022823 for ; Mon, 26 Apr 2004 09:38:07 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Apr 2004 09:38:07 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 09:38:06 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'shilong.zhao@samsung.com'" , rohc@ietf.org Subject: RE: [rohc] How to determine the structure of static chain of IR p acket Date: Mon, 26 Apr 2004 09:37:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="GB2312" X-OriginalArrivalTime: 26 Apr 2004 07:38:07.0034 (UTC) FILETIME=[6A6989A0:01C42B61] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 By initiating compression with the RTP profile, one can implicitly know that UDP will be followed by RTP, at least this is how the compressor will operate if it uses the RTP profile. One can never know that it is RTP, but one can guess. As has previously been explained on this list, the compressor will use heuristics to find out if it is RTP or not. It can initiate compression for all UDP flows as if they were RTP, and then switch back to only-UDP if it turns out to be an invalid guess. The RTP compression is transparent, independent of actual data, so this approach will never fail. /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On > Behalf Of shilong zhao > Sent: den 26 april 2004 09:15 > To: rohc@ietf.org > Subject: [rohc] How to determine the structure of static > chain of IR packet > > > hi, Dear all ROHC experts: > > There is a basic question when I will implement RFC3095. > > In RFC3095 > > 5.7.7 RTP IR and IR-DYN packets > The subheaders which are compressible are split into a STATIC > part and a DYNAMIC part. These parts are defined in sections > 5.7.7.3 through 5.7.7.7. > > The structure of a chain of subheaders is determined by each > header having a Next Header, or Protocol, field. This field > identifies the type of the following header. Each Static part > below that is followed by another Static part contains the > Next Header/Protocol field and allows parsing of the Static > chain; the Dynamic chain, if present, is structured analogously. > > For RTP/UDP/IPv4. > we know that we can know what is the next static chain from > IPV4 static part: > > > +---+---+---+---+---+---+---+---+ > | Version = 4 | 0 | > +---+---+---+---+---+---+---+---+ > | Protocol | > +---+---+---+---+---+---+---+---+ > / Source Address / 4 octets > +---+---+---+---+---+---+---+---+ > / Destination Address / 4 octets > +---+---+---+---+---+---+---+---+ > > through protocol field, we know the next static should be > UDP static part. > > However, How we know what is next static part(It should be > RTP static part) from UDP static part? > > UDP Static part as following: > > > +---+---+---+---+---+---+---+---+ > / Source Port / 2 octets > +---+---+---+---+---+---+---+---+ > / Destination Port / 2 octets > +---+---+---+---+---+---+---+---+ > > > > Who can point out for me. > Thankx in advance. > > > Shilong Zhao > > > > CHINA SAMSUNG Telecom R&D Center > 4/F Science and Technology Tower > No.9 Zhongguancun Nandajie, Haidian District > Beijing, China 100081 > > TEL: (010) 6842-7711 - 2411 > FAX: (010) 6848-1891 > Mobile: 13621193636 > > _______________________________________________ > 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 exim@www1.ietf.org Wed Apr 28 08:16:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10855 for ; Wed, 28 Apr 2004 08:16:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInur-0007UG-34 for rohc-archive@odin.ietf.org; Wed, 28 Apr 2004 08:11:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCBrtA028780 for rohc-archive@odin.ietf.org; Wed, 28 Apr 2004 08:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInQD-0000Pr-Lx for rohc-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:40:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07632 for ; Wed, 28 Apr 2004 07:40:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInQD-0004AE-2d for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 07:40:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInP5-0003tW-00 for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 07:39:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInOG-0003d8-00 for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 07:38:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInLD-0007Ok-46; Wed, 28 Apr 2004 07:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIn6t-0006Bo-NZ for rohc@optimus.ietf.org; Wed, 28 Apr 2004 07:20:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07020 for ; Wed, 28 Apr 2004 07:20:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIn6t-0006mY-4W for rohc@ietf.org; Wed, 28 Apr 2004 07:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIn5v-0006TQ-00 for rohc@ietf.org; Wed, 28 Apr 2004 07:19:16 -0400 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BIn54-00065V-00 for rohc@ietf.org; Wed, 28 Apr 2004 07:18:22 -0400 Received: from effnet.com (c-307871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.48]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i3SAHYU2000958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Apr 2004 12:17:36 +0200 Message-ID: <408F92E3.7080702@effnet.com> Date: Wed, 28 Apr 2004 13:17:55 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] Feedback & Updating context 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all. I have a couple of questions on feeback updating properties that I would like to have clarified. Question 1 - R-mode feedback and CRCs --- Section 4.6 says: c) Feedback information can also be subject to residual errors, both when feedback is piggybacked and when it is sent in separate ROHC packets. ROHC uses sanity checks and adds CRCs to vital feedback information to allow detection of some damaged feedback. One "vital feedback" described in 3095 that I can see is the mode transition feedback, but I guess there can be others too. Since ACK feedback in R-mode is supposed to update the context of the compressor (by updating the reference), must all ACK feedback also carry a CRC option in this mode? If not, isn't it against the secure reference principle as context gets updated by a packet without a CRC? Section 5.5.1.2. says that * It is possible, although unlikely, that residual errors on the reverse channel could cause a packet to mimic a valid ACK feedback. But if the CRC is not mandatory, then I'd say it is not "unlikely". Having some kind of bit error on the feedback link could easily distort the SN to another "legal" value, even if the local clock algorithm of 5.5.1.2 is used. Or? Question 2 - Discarding old references (R-mode) ---- Section 4.5.2 says: 3) When the compressor is sufficiently confident that a certain value v and all values older than v will not be used as reference by the decompressor, the window is advanced by removing those values (including v). Since "v" is supposed to be the field value (for example RTP SN), removing "all values older than v" _can_ be interpreted as all packets with "an older SN". If the spec is read this way, then R-mode can cause havoc if we had pre-link packet reordering (reordering BEFORE the compressor). I assume that "older value" should be based on packet arrival time instead of SN value, which probably should remove the risk of context getting out of synch. If so, I think a clarification in the implementers guide could be in order. Best regards, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Apr 28 08:21:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11686 for ; Wed, 28 Apr 2004 08:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInwk-0008OV-Hi for rohc-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDoZp032258 for rohc-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInfz-0003M4-2t for rohc-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:56:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08811 for ; Wed, 28 Apr 2004 07:56:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInfy-0001I2-8y for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 07:56:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInet-0000w0-00 for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 07:55:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIndv-0000bo-00 for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 07:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMc-0007jK-Qh; Wed, 28 Apr 2004 07:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIjP5-0007TM-69 for rohc@optimus.ietf.org; Wed, 28 Apr 2004 03:22:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28697 for ; Wed, 28 Apr 2004 03:22:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIjP0-0004lj-Q3 for rohc@ietf.org; Wed, 28 Apr 2004 03:22:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIjO5-0004YW-00 for rohc@ietf.org; Wed, 28 Apr 2004 03:21:46 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BIjNj-0004LR-00 for rohc@ietf.org; Wed, 28 Apr 2004 03:21:23 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3S7LQPA027858 for ; Wed, 28 Apr 2004 09:21:26 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Apr 2004 09:21:26 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Apr 2004 09:21:23 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Wed, 28 Apr 2004 09:21:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Apr 2004 07:21:26.0011 (UTC) FILETIME=[6A950CB0:01C42CF1] Subject: [rohc] The SigComp NACK draft 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 SigComp'ers, The NACK draft has not been modified for a long time, and we should ship it if we think it is ready. Since there have been no actual discussion about it since last year, we would like to hear your opinions, whether we should consider it ready and issue WG last-call, or if more work is needed. You'll find the draft at: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-nack-00.txt Please speak up and let us know what you think about it! /L-E -------------------------------------- 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 exim@www1.ietf.org Wed Apr 28 14:22:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05501 for ; Wed, 28 Apr 2004 14:22:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItcv-0001hp-An for rohc-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIHjS0006558 for rohc-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItWw-0000Wn-Un for rohc-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04912 for ; Wed, 28 Apr 2004 14:11:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItWt-0004XR-8J for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 14:11:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItVx-0004Pj-00 for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 14:10:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BItUx-0004It-00 for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 14:09:32 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BItUz-0005GG-Rd for rohc-web-archive@ietf.org; Wed, 28 Apr 2004 14:09:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItIu-0005WC-OY; Wed, 28 Apr 2004 13:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt8s-0003Kw-Ul for rohc@optimus.ietf.org; Wed, 28 Apr 2004 13:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02860 for ; Wed, 28 Apr 2004 13:46:40 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt8p-0002j1-Dz for rohc@ietf.org; Wed, 28 Apr 2004 13:46:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt7w-0002eM-00 for rohc@ietf.org; Wed, 28 Apr 2004 13:45:45 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BIt7C-0002a1-00 for rohc@ietf.org; Wed, 28 Apr 2004 13:44:58 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SHiwH22745; Wed, 28 Apr 2004 20:44:58 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 20:44:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3SHiLKN019711; Wed, 28 Apr 2004 20:44:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00wZKJXj; Wed, 28 Apr 2004 20:44:18 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SHiHH12659; Wed, 28 Apr 2004 20:44:17 +0300 (EET DST) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 12:44:13 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Feedback & Updating context x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 28 Apr 2004 13:44:11 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B815378A@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Feedback & Updating context Thread-Index: AcQtFjzugVV7WoRbRKqlf46ln+I4EQAKUiXw To: , X-OriginalArrivalTime: 28 Apr 2004 17:44:13.0540 (UTC) FILETIME=[6B5D7A40:01C42D48] Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kristofer, Please see my answers in line. BR, Zhigang > Since ACK feedback in R-mode is supposed to update the context > of the compressor (by updating the reference),=20 > must all ACK feedback also carry a CRC option in this mode?=20 IMHO, must is a too strong requirement. It should be left to=20 implementation to make the decision, since it depends on many=20 factors. Some of them are: - frequency of ACKs, which in turn depends on characteristics of the packet stream being header compressed; - the residual error rate on the reverse channel, which not only depends on radio technology, but also dynamic radio conditions; - bytes available on the reverse channel to carry ACK. If there are more space, the decompressor may just send ACK with CRC all the time, instead of wasting the space by padding. - CPU cost to calculate CRC. This is probably less a concern in most cases. > If not, isn't it=20 > against the secure reference principle as context gets=20 > updated by a packet without a CRC? No. Secure reference principle, as described in section 5.5.1.2 (text below), is more for the direction from compressor to decompressor. = However, we did realize and discussed the possible corruption of ACKs.=20 We considered it as a low probability event in general (see next answer) = and introduced a few mechanisms (those you've mentioned) in RFC 3095 to=20 address it in case the probability is high or considered high in = implementation.=20 The secure reference principle is enforced in both compression and decompression logic. The principle means that only a packet carrying a 7- or 8-bit CRC can update the decompression context and be used as a reference for subsequent decompression. Consequently, only field values of update packets need to be added to the encoding sliding windows (see 4.5) maintained by the compressor. >=20 > Section 5.5.1.2. says that > * It is possible, although unlikely, that residual errors > on the reverse channel could cause a packet to mimic a > valid ACK feedback. >=20 > But if the CRC is not mandatory, then I'd say it is not=20 > "unlikely". Having some kind of bit error on the feedback=20 > link could easily distort the SN to another=20 > "legal" value, even if the local clock algorithm of 5.5.1.2=20 > is used. Or? If I remember correctly, we (authors of RFC 3095) have discussed the issue before the above text was accepted. I cannot recall the details but here are some high-level reasons why it is "unlikely". When you multiply all these factors, it can be seen that the probability for a corrupted ACK to cause desync between compressor and decompressor is very low. 1) ACK is expected to be infrequent 2) Size of ACK is small =3D=3D> the chance it gets hit is small. 3) When an ACK is hit by errors, it takes some good luck to mimic a different "legal" ACK. The set of "legal" SN is small. 4) Even if the damaged ACK is legal, it has to correspond to an update=20 packet that was actually lost on the forward diction (C->D). 5) Even if above is the case, it does not necessary lead to loss of context sync (i.e. the decompression can be still correct even if the compressor and decompressor use different reference). =20 >=20 > Question 2 - Discarding old references (R-mode) > ---- > Section 4.5.2 says: > 3) When the compressor is sufficiently confident that a > certain value v and all values older than v will not > be used as reference by the decompressor, the window > is advanced by removing those values (including v). =20 > I assume that "older value" should be based on packet arrival=20 > time instead of SN value,=20 Right. That is why we specifically used word "older" instead of = "smaller". _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc