From exim@www1.ietf.org Sun May 2 16:27:58 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 QAA01906 for ; Sun, 2 May 2004 16:27:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKNXs-0000PF-Lh for rohc-archive@odin.ietf.org; Sun, 02 May 2004 16:26:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42KQetT001561 for rohc-archive@odin.ietf.org; Sun, 2 May 2004 16:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKNRd-00071e-Qu for rohc-web-archive@optimus.ietf.org; Sun, 02 May 2004 16:20: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 QAA01557 for ; Sun, 2 May 2004 16:20: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 1BKNRc-0002vU-4e for rohc-web-archive@ietf.org; Sun, 02 May 2004 16:20:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKNQg-0002gi-00 for rohc-web-archive@ietf.org; Sun, 02 May 2004 16:19:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKNQR-0002Sq-00 for rohc-web-archive@ietf.org; Sun, 02 May 2004 16:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKNLi-00040c-IH; Sun, 02 May 2004 16:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKNB7-0008Ot-T6 for rohc@optimus.ietf.org; Sun, 02 May 2004 16:03: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 QAA00958 for ; Sun, 2 May 2004 16:03:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKNB6-0006YY-Aj for rohc@ietf.org; Sun, 02 May 2004 16:03:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKNAA-0006LI-00 for rohc@ietf.org; Sun, 02 May 2004 16:02:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BKN9Z-0005yl-00 for rohc@ietf.org; Sun, 02 May 2004 16:01:33 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i42K12U9025973 for ; Sun, 2 May 2004 13:01:02 -0700 (PDT) Received: from san.rr.com (vpn-10-50-0-74.qualcomm.com [10.50.0.74]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i42K103O004741 for ; Sun, 2 May 2004 13:01:00 -0700 (PDT) Message-ID: <4095535C.8080508@san.rr.com> Date: Sun, 02 May 2004 13:00:28 -0700 From: Ramin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC channel reordering 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 Given that ROHC header includes a sequence number, why is it required that the channel between the compressor and decompressor preserve the ordering? Same question about duplication. Shouldn't The decompressor be able to re-order compressed packets based on the ROHC sequence number? Thank you, -Ramin RFC 3095 says: "Reordering The channel between compressor and decompressor is required to maintain packet ordering, i.e., the decompressor must receive packets in the same order as the compressor sent them." "Duplication The channel between compressor and decompressor is required to not duplicate packets. " _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon May 3 03:09: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 DAA10894 for ; Mon, 3 May 2004 03:09: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 1BKXN9-0004Y3-7w for rohc-archive@odin.ietf.org; Mon, 03 May 2004 02:56:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i436uEsp017437 for rohc-archive@odin.ietf.org; Mon, 3 May 2004 02:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXHL-0000t1-86 for rohc-web-archive@optimus.ietf.org; Mon, 03 May 2004 02:50: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 CAA09976 for ; Mon, 3 May 2004 02:50: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 1BKXHH-0002TI-6Z for rohc-web-archive@ietf.org; Mon, 03 May 2004 02:50:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXEP-0001ww-00 for rohc-web-archive@ietf.org; Mon, 03 May 2004 02:47:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKXBG-0001PA-00 for rohc-web-archive@ietf.org; Mon, 03 May 2004 02:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKX1g-0003cc-KD; Mon, 03 May 2004 02:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKWpm-000621-U5 for rohc@optimus.ietf.org; Mon, 03 May 2004 02:21: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 CAA08354 for ; Mon, 3 May 2004 02:21:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKWpj-0005P8-AH for rohc@ietf.org; Mon, 03 May 2004 02:21:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKWmm-0004rC-00 for rohc@ietf.org; Mon, 03 May 2004 02:18:41 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BKWk6-0004Mn-00 for rohc@ietf.org; Mon, 03 May 2004 02:15:54 -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 i436FsAh029119 for ; Mon, 3 May 2004 08:15:54 +0200 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, 3 May 2004 08:15:54 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 08:15:54 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Ramin'" , rohc@ietf.org Subject: RE: [rohc] ROHC channel reordering Date: Mon, 3 May 2004 08:15:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 May 2004 06:15:54.0367 (UTC) FILETIME=[173488F0:01C430D6] 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 SN in compressed packets is very small, only a few bits. Considering that packets can be lossed, it is a non-trivial task to put packets back in order. Further, to be able to reorder packets, a decompressor would have to buffer in case of "early arrival", which would add delay and maybe the missing packet(s) will never arrive, due to losses. By making the in-order assumption, we were able to make the scheme more efficient and robust to losses (which were our main requirements). /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On > Behalf Of Ramin > Sent: den 2 maj 2004 22:00 > To: rohc@ietf.org > Subject: [rohc] ROHC channel reordering > > > > Given that ROHC header includes a sequence number, why is it required > that the channel between the compressor and decompressor preserve the > ordering? Same question about duplication. Shouldn't The > decompressor > be able to re-order compressed packets based on the ROHC > sequence number? > > Thank you, > > -Ramin > > RFC 3095 says: > "Reordering > The channel between compressor and decompressor is required to > maintain packet ordering, i.e., the decompressor must receive > packets in the same order as the compressor sent them." > > "Duplication > The channel between compressor and decompressor is required to not > duplicate packets. " > > _______________________________________________ > 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 May 3 11:13:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07397 for ; Mon, 3 May 2004 11:13:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKf5C-0006PL-I5 for rohc-archive@odin.ietf.org; Mon, 03 May 2004 11:10:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43FAEYY024617 for rohc-archive@odin.ietf.org; Mon, 3 May 2004 11:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKf3f-00061R-Lj for rohc-web-archive@optimus.ietf.org; Mon, 03 May 2004 11:08: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 LAA07156 for ; Mon, 3 May 2004 11:08:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKf3d-0007O0-3K for rohc-web-archive@ietf.org; Mon, 03 May 2004 11:08:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKf2d-0007KE-00 for rohc-web-archive@ietf.org; Mon, 03 May 2004 11:07:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKf1j-0007Hd-00 for rohc-web-archive@ietf.org; Mon, 03 May 2004 11:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeuK-0003En-K2; Mon, 03 May 2004 10:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKd6w-0007Uv-6s for rohc@optimus.ietf.org; Mon, 03 May 2004 09:03: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 JAA26732 for ; Mon, 3 May 2004 09:03:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKd6u-0000Rf-Kp for rohc@ietf.org; Mon, 03 May 2004 09:03:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKd2w-0007bc-00 for rohc@ietf.org; Mon, 03 May 2004 08:59:47 -0400 Received: from ozone.nc3a.nato.int ([195.169.116.7] helo=nc3a.nato.int) by ietf-mx with esmtp (Exim 4.12) id 1BKcxh-0006jw-00 for rohc@ietf.org; Mon, 03 May 2004 08:54:21 -0400 Received: from nc3a-interscan ([195.169.116.119]) by nc3a.nato.int (8.12.10/8.9.0) with SMTP id i43CroC7022109 for ; Mon, 3 May 2004 14:53:50 +0200 (MEST) Received: from neo (radio.nc3a.nato.int [195.169.112.101]) by exchangeth3.nc3a.nato.int with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JYD1TM2B; Mon, 3 May 2004 14:53:01 +0200 From: "Maarten Gerbrands \(NC3A\)" To: Date: Mon, 3 May 2004 14:53:49 +0200 Message-ID: <000001c4310d$ae40ba70$4440a8c0@neo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [rohc] Possible using ROHC on a multinode subnet? 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 Dear ROHC experts, I am currently researching ways to improve TCP/IP networking using NATO STANAG 5066 HF packet radio as a data link layer. HF packet radio is a wireless network which can operate over very long distances. The link speeds are slow (max 9600 bits per sec.), and delays are high (RTT something like 4 to 5 seconds). I believe ROHC is the most promising header compression scheme for TCP/IP over HF, however I don't know if it can operate in a data link layer (subnet) with multiple nodes. I understand it less efficient as a link with just two end points. Note that HF subnets are normally operating with just a few nodes in one subnet. So I would like to know if a single instance of a compressor/decompressor can handle different layer-2 endpoints. If it is designed to do so, are there made any plans to register an Ether Type assignment for use ROHC over Ethernet like the registered VJHC(RFC 1144)? The reason I am interested in the Ether Type is because we have plans to include the Ether Type field in the link layer protocol (STANAG 5066). Regards, Maarten Gerbrands Architecture, Security and Interoperability Branch, Communications and Information Systems Division NATO C3 Agency _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri May 7 06:02:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12078 for ; Fri, 7 May 2004 06:02:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM25f-0005QM-Ho for rohc-archive@odin.ietf.org; Fri, 07 May 2004 05:56:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i479uNsj020850 for rohc-archive@odin.ietf.org; Fri, 7 May 2004 05:56:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1zj-0003OV-Tr for rohc-web-archive@optimus.ietf.org; Fri, 07 May 2004 05:50:16 -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 FAA11307 for ; Fri, 7 May 2004 05:50: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 1BM1zg-0003RA-CH for rohc-web-archive@ietf.org; Fri, 07 May 2004 05:50:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM1yh-0002wj-00 for rohc-web-archive@ietf.org; Fri, 07 May 2004 05:49:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM1xd-0002Qs-00 for rohc-web-archive@ietf.org; Fri, 07 May 2004 05:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1gS-0004QC-IB; Fri, 07 May 2004 05:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1MK-0006nR-On for rohc@optimus.ietf.org; Fri, 07 May 2004 05:09: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 FAA09657 for ; Fri, 7 May 2004 05: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 1BM1MH-0002UD-GO for rohc@ietf.org; Fri, 07 May 2004 05:09:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM1LJ-000251-00 for rohc@ietf.org; Fri, 07 May 2004 05:08:29 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BM1KB-0001Mj-00 for rohc@ietf.org; Fri, 07 May 2004 05:07:20 -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 i4797KPA029228 for ; Fri, 7 May 2004 11:07:20 +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); Fri, 7 May 2004 11:07:20 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 7 May 2004 11:07:20 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'rohc@ietf.org'" , "Kristofer Sandlund (E-mail)" , "Mark West (E-mail)" Date: Fri, 7 May 2004 11:06:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 May 2004 09:07:20.0467 (UTC) FILETIME=[B3D9D630:01C43412] Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC Profiles for UDP-Lite 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 RoHCers, I am currently updating draft-ietf-rohc-udp-lite. My hopes are to see this updated version go to wglc. Therefore I'd appreciate review comments from the group, with the objectives of completing the work. I suggest the following changes:=20 * Harmonization with the IP-Only profile. Suggestion are to add: - support for Constant IP-ID behavior (see section 3.3 of IP-only-05) - support for the mode reject option (see section 3.4 of IP-only-05) draft-ietf-rohc-udp-lite-02 already include some of the fixes that IP-only introduced, such as the Context_Memory feedback option and support arbitrary number of IP headers. It seems normal to include the two above modifications as well. I propose to insert the normative part of section 3.3 and 3.4 of IP-only-05 to=20 draft-ietf-rohc-udp-lite-03, along with a pointer IP-Only=20 for the rest of the informative part. Anything else missing to make the draft complete? Other comments on the current draft? Your feedback would be greatly appreciated. I'd like to move that one forward asap, it's been hanging around long enough I think. /Ghyslain 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.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri May 7 11:06:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29484 for ; Fri, 7 May 2004 11:06:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6aV-0004tz-P3 for rohc-archive@odin.ietf.org; Fri, 07 May 2004 10:44:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47EiVIJ018843 for rohc-archive@odin.ietf.org; Fri, 7 May 2004 10:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Jk-0006RP-JX for rohc-web-archive@optimus.ietf.org; Fri, 07 May 2004 10: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 KAA25614 for ; Fri, 7 May 2004 10:27:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6Ji-0004b2-90 for rohc-web-archive@ietf.org; Fri, 07 May 2004 10:27:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6Il-00047q-00 for rohc-web-archive@ietf.org; Fri, 07 May 2004 10:26:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6Hs-0003ea-00 for rohc-web-archive@ietf.org; Fri, 07 May 2004 10:25:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5vR-0000lk-LC; Fri, 07 May 2004 10:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM360-0001pw-4S for rohc@optimus.ietf.org; Fri, 07 May 2004 07:00: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 HAA15342 for ; Fri, 7 May 2004 07:00:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM35v-0001wZ-PT for rohc@ietf.org; Fri, 07 May 2004 07:00:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM34n-0001Wo-00 for rohc@ietf.org; Fri, 07 May 2004 06:59:34 -0400 Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 1BM33p-0000k4-00 for rohc@ietf.org; Fri, 07 May 2004 06:58:34 -0400 Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i47Av6gX017485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 May 2004 11:57:07 +0100 (BST) Message-ID: <409B6B83.8070909@erg.abdn.ac.uk> Date: Fri, 07 May 2004 11:57:07 +0100 From: gorry fairhurst Reply-To: gf@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Subject: [rohc] Possible using ROHC on a multinode subnet? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner-Information: See www.mailscanner.info for information X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-ERG-MailScanner-To: rohc@ietf.org 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 When you say: > "So I would like to know if a single instance of a > compressor/decompressor can handle different layer-2 endpoints." Do you mean point-to-multipoint boadcast/multicast (or are these sperate link layer unicast communications to several different end points?) best wishes, Gorry Fairhurst Maarten Gerbrands (NC3A) wrote: > Dear ROHC experts, > > I am currently researching ways to improve TCP/IP networking using NATO > STANAG 5066 HF packet radio as a data link layer. > HF packet radio is a wireless network which can operate over very long > distances. > The link speeds are slow (max 9600 bits per sec.), and delays are high > (RTT something like 4 to 5 seconds). > > I believe ROHC is the most promising header compression scheme for > TCP/IP over HF, however I don't know if it can operate in a data link layer (subnet) > with multiple nodes. > I understand it less efficient as a link with just two end points. > Note that HF subnets are normally operating with just a few nodes in one > subnet. > > So I would like to know if a single instance of a > compressor/decompressor can handle different layer-2 endpoints. > > If it is designed to do so, are there made any plans to register an > Ether Type assignment for use ROHC over Ethernet > like the registered VJHC(RFC 1144)? The reason I am interested in the Ether Type is because we have plans to > include the Ether Type field in the link layer protocol (STANAG 5066). > > Regards, > > Maarten Gerbrands > Architecture, Security and Interoperability Branch, > Communications and Information Systems Division > NATO C3 Agency > > > > > > _______________________________________________ > 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 May 10 11:28:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11176 for ; Mon, 10 May 2004 11:28: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 1BNCfg-0003sE-C1 for rohc-archive@odin.ietf.org; Mon, 10 May 2004 11:26:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AFQOl6014891 for rohc-archive@odin.ietf.org; Mon, 10 May 2004 11:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCUY-0001Z9-SC for rohc-web-archive@optimus.ietf.org; Mon, 10 May 2004 11:14: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 LAA10403 for ; Mon, 10 May 2004 11:14:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCUX-0007Gw-WB for rohc-web-archive@ietf.org; Mon, 10 May 2004 11:14:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCTc-0006vd-00 for rohc-web-archive@ietf.org; Mon, 10 May 2004 11:13:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNCSp-0006bm-00 for rohc-web-archive@ietf.org; Mon, 10 May 2004 11:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCI8-0007Mb-9n; Mon, 10 May 2004 11:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCCO-0005rS-G7 for rohc@optimus.ietf.org; Mon, 10 May 2004 10:56: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 KAA09248 for ; Mon, 10 May 2004 10:56: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 1BNCCL-0000Vk-VG for rohc@ietf.org; Mon, 10 May 2004 10:56:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCBF-0000At-00 for rohc@ietf.org; Mon, 10 May 2004 10:54:58 -0400 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BNCAt-0007dW-00 for rohc@ietf.org; Mon, 10 May 2004 10:54:35 -0400 Received: from effnet.com (c-707871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.112]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i4ADrmU2027829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 May 2004 15:53:49 +0200 Message-ID: <409F9794.9020900@effnet.com> Date: Mon, 10 May 2004 16:54:12 +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] Limiting the number of IP header in IP-only profile 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 know I'm a bit late here since the IP profile has passed last call, but there's one feature that I think could be quite useful to add. Section 3.1 in ip-only-05.txt says: Instead, the static chain is terminated if the "Next Header / Protocol" field of a static IP header part indicates anything but IP (IPinIP or IPv6). It would be useful for the compressor to decide to only compress a few of the IP headers instead of having to compress "all or none". To do this, the compressor would somehow have to indicate in the static chain that an IP header is the last compressed IP header, even if the protocol field indicates the prescence of more IP headers. Since only the IPv4 header has "reserved bits" (the 4 bits right after version), there are no free bits that work for both IPv4 and IPv4. But, since we're sending all 4 of the IP version bits, while we anyway only handle them to be "4" and "6", the IP only could be extended to work with some extra bit patterns. The only of these four bits that actually needs to be read from the static chain is the third one (4=0100 and 6=0110) so any of the other three bits could be used to mark the end of the static chain. So, let's say that we use the top bit to indicate the end of the static chain, the version field would be: 0100= IPv4 non-final header 0110= IPv6 non-final header 1100= IPv4 final header (end of static chain) 1110= IPv6 final header (end of static chain). Obviously, these changes would only need to apply to the IP profile since that is the only one that can terminate in an IP header, so this would not have any impact on any other profiles. If it can be added to the current IP-only profile that would be great but otherwise it might be something for the next revision of the profile. Rgds, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon May 10 20:51:34 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19606 for ; Mon, 10 May 2004 20:51:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLNu-0007nX-CC for rohc-archive@odin.ietf.org; Mon, 10 May 2004 20:44:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B0icRG029975 for rohc-archive@odin.ietf.org; Mon, 10 May 2004 20:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLF3-0006A7-50 for rohc-web-archive@optimus.ietf.org; Mon, 10 May 2004 20:35: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 UAA18895 for ; Mon, 10 May 2004 20:35:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNLF1-0000zV-2g for rohc-web-archive@ietf.org; Mon, 10 May 2004 20:35:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLE4-0000eA-00 for rohc-web-archive@ietf.org; Mon, 10 May 2004 20:34:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNLDX-0000Ii-00 for rohc-web-archive@ietf.org; Mon, 10 May 2004 20:33:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNL40-0003di-2G; Mon, 10 May 2004 20:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNKzI-0002MD-Vp for rohc@optimus.ietf.org; Mon, 10 May 2004 20:19: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 UAA18018 for ; Mon, 10 May 2004 20:19:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNKzG-0003In-QA for rohc@ietf.org; Mon, 10 May 2004 20:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNKyR-0002z2-00 for rohc@ietf.org; Mon, 10 May 2004 20:18:20 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BNKxu-0002bx-00 for rohc@ietf.org; Mon, 10 May 2004 20:17:46 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 01:17:10 +0100 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHDWYLTN; Tue, 11 May 2004 01:17:02 +0100 From: "West, Mark" To: rohc@ietf.org Date: Tue, 11 May 2004 01:17:01 +0100 (GMT Daylight Time) Message-ID: X-X-Sender: maw1@maw-laptop.comm.ad.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Comments on UDP-lite 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, Here are my comments on the UDP-lite compression draft. I think that there's only one of any real significance; the others are minor typos / grammar tweaks (which you can feel free to ignore if you wish!) Cheers, Mark. Non-NiTS - If CE(OFF) is sent, the decompressor is supposed to infer the setting of the CFI flag. However, what about the case where CC == packet length == context(CC) (e.g. CC is used to protect the RTP header and there is a 'null length' RTP payload? I'm not sure that this is ambiguous (i.e. the packet length has precedence over matching the context when setting CFI)? However, it would be good to ensure that the text for this really is unambiguous... NiTS - I assume that the RFC numbers will be filled in for [UDP-lite] and [IPonly] as part of the RFC Ed process? - S1. 'guaranteed to an extremely high extent even when' -> 'guaranteed to an extremely high extent, even when' - S3.1. 'and allow applications' -> 'and allows applications' - S3.1. '16-bit checksum and it is applied' -> '16-bit checksum, which is applied' - S3.1. 'share protocol identifier' -> 'share a protocol identifier' - S3.2. 'inferred from the IP module' -> 'inferred from the IP header' - S3.3. 'found in the Appendix A' -> 'found in Appendix A' - S5.1. 'infomration relevant to previous' -> 'information about previous' - S5.1. 'describing the packet stream, or parameters' -> 'describing the packet stream or compression parameters' - S5.3.1. [figure] '(includes no SN)' -> '(does not include SN)' - S5.3.2. Is the acronym 'CE' confusable (easily) with Congestion Experienced in ECN? Probably not, but I'd thought that I'd mention it..! (CCE == Checksum Coverage Extension has been proposed as an alternative; this sounds good to me!) - S5.3.2. 'while the field could previously' -> 'where the field could previously' - S5.3.2. 'of such deviations are seldom' -> 'of such deviations is rare' - S5.6. 'context of the packet stream, as the stream is currently compressed' -> 'context of the packet stream required by the current compressed structure' -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 11 05:38:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14858 for ; Tue, 11 May 2004 05:38: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 1BNTW2-0008EK-0R for rohc-archive@odin.ietf.org; Tue, 11 May 2004 05:25:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B9PXTK031637 for rohc-archive@odin.ietf.org; Tue, 11 May 2004 05:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTTD-0007ny-P2 for rohc-web-archive@optimus.ietf.org; Tue, 11 May 2004 05:22: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 FAA14189 for ; Tue, 11 May 2004 05:22:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNTTA-0003X5-EE for rohc-web-archive@ietf.org; Tue, 11 May 2004 05:22:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNTS9-00038w-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 05:21:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNTR5-0002Xl-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 05:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTG3-0004WD-N7; Tue, 11 May 2004 05:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNT1M-0000dV-NW for rohc@optimus.ietf.org; Tue, 11 May 2004 04:53:53 -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 EAA12859 for ; Tue, 11 May 2004 04:53:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNT1J-0000NU-Ik for rohc@ietf.org; Tue, 11 May 2004 04:53:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNT0L-0007li-00 for rohc@ietf.org; Tue, 11 May 2004 04:52:50 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BNSzV-0007OK-00 for rohc@ietf.org; Tue, 11 May 2004 04:51:57 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4B8ptWR024042 for ; Tue, 11 May 2004 10:51:55 +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); Tue, 11 May 2004 10:51:55 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 10:51:55 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] Limiting the number of IP header in IP-only profile Date: Tue, 11 May 2004 10:50:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 May 2004 08:51:55.0295 (UTC) FILETIME=[360ECAF0:01C43735] 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 Kristofer, I understand your concern and agree with your point. I also find your proposal reasonable. The question is, what should we do at this point? We could argue for making this change to the IP profile before publication, as it is a new problem that is unique for the IP profile, and it would be bad to not have that resolved. I am not sure this is a sufficiently significant problem in practice, but it might be tricky to implement it without the ability to limit the compressed chain length. So, while we are anyway waiting for the IANA action, let's figure out what text should had been in the document. If we can agree on that, we can consider whether we should bother the AD's with it at this point. /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Kristofer Sandlund > Sent: den 10 maj 2004 16:54 > To: rohc@ietf.org > Subject: [rohc] Limiting the number of IP header in IP-only profile > > > Hi all! > > I know I'm a bit late here since the IP profile has passed > last call, but > there's one feature that I think could be quite useful to add. > > Section 3.1 in ip-only-05.txt says: > Instead, the static chain is terminated if the "Next Header / > Protocol" field of a static IP header part indicates > anything but IP > (IPinIP or IPv6). > > It would be useful for the compressor to decide to only > compress a few of the IP > headers instead of having to compress "all or none". > > To do this, the compressor would somehow have to indicate in > the static chain > that an IP header is the last compressed IP header, even if > the protocol field > indicates the prescence of more IP headers. > > Since only the IPv4 header has "reserved bits" (the 4 bits > right after version), > there are no free bits that work for both IPv4 and IPv4. But, > since we're > sending all 4 of the IP version bits, while we anyway only > handle them to be "4" > and "6", the IP only could be extended to work with some > extra bit patterns. > > The only of these four bits that actually needs to be read > from the static chain > is the third one (4=0100 and 6=0110) so any of the other > three bits could be > used to mark the end of the static chain. So, let's say that > we use the top bit > to indicate the end of the static chain, the version field would be: > > 0100= IPv4 non-final header > 0110= IPv6 non-final header > 1100= IPv4 final header (end of static chain) > 1110= IPv6 final header (end of static chain). > > Obviously, these changes would only need to apply to the IP > profile since that > is the only one that can terminate in an IP header, so this > would not have any > impact on any other profiles. If it can be added to the > current IP-only profile > that would be great but otherwise it might be something for > the next revision of > the profile. > > Rgds, > Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 11 08:38: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 IAA22939 for ; Tue, 11 May 2004 08:38: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 1BNWRI-0001ez-4b for rohc-archive@odin.ietf.org; Tue, 11 May 2004 08:32:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BCWq7p006381 for rohc-archive@odin.ietf.org; Tue, 11 May 2004 08:32:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWKZ-0000r5-9H for rohc-web-archive@optimus.ietf.org; Tue, 11 May 2004 08:25: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 IAA22321 for ; Tue, 11 May 2004 08:25: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 1BNWKY-0002nQ-4j for rohc-web-archive@ietf.org; Tue, 11 May 2004 08:25:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNWJk-0002PQ-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 08:25:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNWJ9-00020x-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 08:24:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWEr-0008P2-Rx; Tue, 11 May 2004 08:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNW7w-000763-At for rohc@optimus.ietf.org; Tue, 11 May 2004 08:12: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 IAA21856 for ; Tue, 11 May 2004 08:12: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 1BNW7v-0005VI-Cb for rohc@ietf.org; Tue, 11 May 2004 08:12:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNW76-00057y-00 for rohc@ietf.org; Tue, 11 May 2004 08:12:01 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BNW69-0004js-00 for rohc@ietf.org; Tue, 11 May 2004 08:11:01 -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 i4BCAxAh024654 for ; Tue, 11 May 2004 14:10:59 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 14:10:59 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 14:10:59 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'West, Mark'" , rohc@ietf.org Subject: RE: [rohc] Comments on UDP-lite compression Date: Tue, 11 May 2004 14:10:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 May 2004 12:10:59.0687 (UTC) FILETIME=[05785F70:01C43751] 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 Mark, Thanks for your review and comments. Non-NiTS: --------- Matching the packet length is what has precedence. Is this also your opinion? Or do you feel that this might be wrong? Having a null size payload is not the case that is normally expected. However, when this occurs, i.e. size(payload) == null and if field(CC) == length(packet) if the compressor then uses CE(OFF), the compressor knows that the CC field will be inferred at the decompressor, and that the length of the packet will be used. So I don't think that there is any ambiguity based on the text. However, if the compressor would rather use a fixed value for the CC and avoid the decompressor to infer the CC after the length of the packet, then the compressor should use: CE(OFF) for packets with field(CC) == constant != length(packet), and CE() for packets with field(CC) == constant == length(packet). Recall that CE() does not update the context, so the compressor can avoid any ambiguity. I don't think that there is any contradiction regarding this in the text, however I will have a closer look to see where I can make a clarification. NiTS: ----- I'll change the text according to your suggestions. I can change the acronym 'CE' to 'CCE', after "Checksum Coverage Extension". I assume that you are fine with the changes mentionned in my previous mail to the list? Thanks again, /Ghyslain -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of West, Mark Sent: den 11 maj 2004 02:17 To: rohc@ietf.org Subject: [rohc] Comments on UDP-lite compression Hi all, Here are my comments on the UDP-lite compression draft. I think that there's only one of any real significance; the others are minor typos / grammar tweaks (which you can feel free to ignore if you wish!) Cheers, Mark. Non-NiTS - If CE(OFF) is sent, the decompressor is supposed to infer the setting of the CFI flag. However, what about the case where CC == packet length == context(CC) (e.g. CC is used to protect the RTP header and there is a 'null length' RTP payload? I'm not sure that this is ambiguous (i.e. the packet length has precedence over matching the context when setting CFI)? However, it would be good to ensure that the text for this really is unambiguous... NiTS - I assume that the RFC numbers will be filled in for [UDP-lite] and [IPonly] as part of the RFC Ed process? - S1. 'guaranteed to an extremely high extent even when' -> 'guaranteed to an extremely high extent, even when' - S3.1. 'and allow applications' -> 'and allows applications' - S3.1. '16-bit checksum and it is applied' -> '16-bit checksum, which is applied' - S3.1. 'share protocol identifier' -> 'share a protocol identifier' - S3.2. 'inferred from the IP module' -> 'inferred from the IP header' - S3.3. 'found in the Appendix A' -> 'found in Appendix A' - S5.1. 'infomration relevant to previous' -> 'information about previous' - S5.1. 'describing the packet stream, or parameters' -> 'describing the packet stream or compression parameters' - S5.3.1. [figure] '(includes no SN)' -> '(does not include SN)' - S5.3.2. Is the acronym 'CE' confusable (easily) with Congestion Experienced in ECN? Probably not, but I'd thought that I'd mention it..! (CCE == Checksum Coverage Extension has been proposed as an alternative; this sounds good to me!) - S5.3.2. 'while the field could previously' -> 'where the field could previously' - S5.3.2. 'of such deviations are seldom' -> 'of such deviations is rare' - S5.6. 'context of the packet stream, as the stream is currently compressed' -> 'context of the packet stream required by the current compressed structure' -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 11 09:20:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24795 for ; Tue, 11 May 2004 09:20: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 1BNX7w-0001iQ-6D for rohc-archive@odin.ietf.org; Tue, 11 May 2004 09:16:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BDGutv006595 for rohc-archive@odin.ietf.org; Tue, 11 May 2004 09:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWxB-00087d-7z for rohc-web-archive@optimus.ietf.org; Tue, 11 May 2004 09:05: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 JAA24120 for ; Tue, 11 May 2004 09:05: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 1BNWx9-0002yG-PQ for rohc-web-archive@ietf.org; Tue, 11 May 2004 09:05:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNWw8-0002Xw-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 09:04:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNWv1-0001p0-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 09:03:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWll-0005no-B3; Tue, 11 May 2004 08:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWhh-00056g-7n for rohc@optimus.ietf.org; Tue, 11 May 2004 08:49: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 IAA23296 for ; Tue, 11 May 2004 08:49: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 1BNWhf-0004F3-Sr for rohc@ietf.org; Tue, 11 May 2004 08:49:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNWgl-0003sa-00 for rohc@ietf.org; Tue, 11 May 2004 08:48:52 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BNWgN-0003Vb-00 for rohc@ietf.org; Tue, 11 May 2004 08:48:27 -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 i4BCmQPA009842 for ; Tue, 11 May 2004 14:48:26 +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); Tue, 11 May 2004 14:48:26 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 14:48:26 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] Limiting the number of IP header in IP-only profile Date: Tue, 11 May 2004 14:47:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 May 2004 12:48:26.0624 (UTC) FILETIME=[40BFC000:01C43756] 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 Me and Kristofer have discussed this issue further and come up with a change proposal. Please let us know what you think, both about the technical issue/resolution as well as how we should move on with it. Kristofer has convinced me that this is important for real-world implementations, so our take on it is that we should try to get this into the IP profile before publication, if at all possible. BR /L-E ***** CHANGE PROPOSAL FOR THE IP PROFILE ***** OLD: 3.1. Static Chain Termination One difference for IP-only compression, compared to IP/UDP compression, is related to the termination of the static chain in IR headers. For the UDP profile, the chain always ends with a UDP header part, which per definition provides the boundaries for the chain. The UDP header is also the last header in the uncompressed packet (except for a potential application header). For the IP-only profile, there is no single last header that per profile definition terminates the chain. Instead, the static chain is terminated if the "Next Header / Protocol" field of a static IP header part indicates anything but IP (IPinIP or IPv6). NEW: 3.1. Static Chain Termination One difference for IP-only compression, compared to IP/UDP compression, is related to the termination of the static chain in IR headers. For the UDP profile, the chain always ends with a UDP header part, which per definition provides the boundaries for the chain. The UDP header is also the last header in the uncompressed packet (except for a potential application header). For the IP-only profile, there is no single last header that per profile definition terminates the chain. Instead, the static chain is terminated if the "Next Header / Protocol" field of a static IP header part indicates anything but IP (IPinIP or IPv6). Alternatively, the compressor can choose to end the static chain at any IP header, and indicate this by setting the MSB of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The decompressor must store this indication in the context for correct decompression of subsequent headers. Note that the IP version field in decompressed headers must be restored to its original value. OLD (part of 3.2): As explained above, the static chain within IR packets can be of arbitrary length, and the chain is terminated by the presence of a non-IP header (not IPinIP nor IPv6). The dynamic chain is structured analogously. NEW (part of 3.2): As explained above, the static chain within IR packets can be of arbitrary length, and the chain is terminated by the presence of a non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be explicitly terminated with a special IP version number, as described in section 3.1. The dynamic chain is structured analogously. OLD (part of 3.5): 1) By using an IR packet as in ROHC UDP, where the profile is 0x0004, and the static chain ends with the static part of an IP header, where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is initialized to a random value when the first IR packet is sent. 2) By reusing an existing context. This is done with an IR-DYN packet, identifying profile 0x0004, where the dynamic chain corresponds to the prefix of the existing static chain, ending with an IP header where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is initialized to a random value when the first IR-DYN packet is sent. NEW (part of 3.5): 1) By using an IR packet as in ROHC UDP, where the profile is 0x0004, and the static chain ends with the static part of an IP header, where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field indicates termination (see section 3.1). At the compressor, SN is initialized to a random value when the first IR packet is sent. 2) By reusing an existing context. This is done with an IR-DYN packet, identifying profile 0x0004, where the dynamic chain corresponds to the prefix of the existing static chain, ending with an IP header where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field indicates termination (see section 3.1). At the compressor, SN is initialized to a random value when the first IR-DYN packet is sent. > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Lars-Erik Jonsson (LU/EAB) > Sent: den 11 maj 2004 10:51 > To: 'Kristofer Sandlund'; rohc@ietf.org > Subject: RE: [rohc] Limiting the number of IP header in > IP-only profile > > > Kristofer, > > I understand your concern and agree with your point. I also find > your proposal reasonable. The question is, what should we do at > this point? We could argue for making this change to the IP > profile before publication, as it is a new problem that is > unique for the IP profile, and it would be bad to not have > that resolved. I am not sure this is a sufficiently significant > problem in practice, but it might be tricky to implement it > without the ability to limit the compressed chain length. > > So, while we are anyway waiting for the IANA action, let's figure > out what text should had been in the document. If we can agree on > that, we can consider whether we should bother the AD's with it > at this point. > > /L-E > > > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > > Kristofer Sandlund > > Sent: den 10 maj 2004 16:54 > > To: rohc@ietf.org > > Subject: [rohc] Limiting the number of IP header in IP-only profile > > > > > > Hi all! > > > > I know I'm a bit late here since the IP profile has passed > > last call, but > > there's one feature that I think could be quite useful to add. > > > > Section 3.1 in ip-only-05.txt says: > > Instead, the static chain is terminated if the "Next Header / > > Protocol" field of a static IP header part indicates > > anything but IP > > (IPinIP or IPv6). > > > > It would be useful for the compressor to decide to only > > compress a few of the IP > > headers instead of having to compress "all or none". > > > > To do this, the compressor would somehow have to indicate in > > the static chain > > that an IP header is the last compressed IP header, even if > > the protocol field > > indicates the prescence of more IP headers. > > > > Since only the IPv4 header has "reserved bits" (the 4 bits > > right after version), > > there are no free bits that work for both IPv4 and IPv4. But, > > since we're > > sending all 4 of the IP version bits, while we anyway only > > handle them to be "4" > > and "6", the IP only could be extended to work with some > > extra bit patterns. > > > > The only of these four bits that actually needs to be read > > from the static chain > > is the third one (4=0100 and 6=0110) so any of the other > > three bits could be > > used to mark the end of the static chain. So, let's say that > > we use the top bit > > to indicate the end of the static chain, the version field would be: > > > > 0100= IPv4 non-final header > > 0110= IPv6 non-final header > > 1100= IPv4 final header (end of static chain) > > 1110= IPv6 final header (end of static chain). > > > > Obviously, these changes would only need to apply to the IP > > profile since that > > is the only one that can terminate in an IP header, so this > > would not have any > > impact on any other profiles. If it can be added to the > > current IP-only profile > > that would be great but otherwise it might be something for > > the next revision of > > the profile. > > > > Rgds, > > Kristofer Sandlund, Effnet AB > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 11 10:23:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29071 for ; Tue, 11 May 2004 10:23:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY7A-0004Pv-VT for rohc-archive@odin.ietf.org; Tue, 11 May 2004 10:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BEKCRF016975 for rohc-archive@odin.ietf.org; Tue, 11 May 2004 10: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 1BNXsQ-00050q-7H for rohc-web-archive@optimus.ietf.org; Tue, 11 May 2004 10:04: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 KAA27066 for ; Tue, 11 May 2004 10:04:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXsO-00034R-4p for rohc-web-archive@ietf.org; Tue, 11 May 2004 10:04:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXrS-0002gc-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 10:03:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNXqr-0002Id-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 10:03:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXho-0000ak-Q6; Tue, 11 May 2004 09:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXfr-0000AA-D6 for rohc@optimus.ietf.org; Tue, 11 May 2004 09:51: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 JAA26265 for ; Tue, 11 May 2004 09:51: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 1BNXfp-0005ib-D5 for rohc@ietf.org; Tue, 11 May 2004 09:51:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXez-0005KW-00 for rohc@ietf.org; Tue, 11 May 2004 09:51:06 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BNXe8-0004vr-00 for rohc@ietf.org; Tue, 11 May 2004 09:50:12 -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 i4BDoBPA025902 for ; Tue, 11 May 2004 15:50:11 +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); Tue, 11 May 2004 15:50:11 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 11 May 2004 15:50:11 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] Limiting the number of IP header in IP-only profile Date: Tue, 11 May 2004 15:49:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 May 2004 13:50:11.0477 (UTC) FILETIME=[E1037450:01C4375E] 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 NEW (part of 3.2): As explained above, the static chain within IR packets can be of arbitrary length, and the chain is terminated by the presence of a non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be explicitly terminated with a special IP version number, as described in section 3.1. The dynamic chain is structured analogously. [Ghyslain] s/with a special IP version number/with a special code value in the IP version field/ ? _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 11 20:22: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 UAA09069 for ; Tue, 11 May 2004 20:22: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 1BNhKU-0007ns-AN for rohc-archive@odin.ietf.org; Tue, 11 May 2004 20:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C0AYBa029991 for rohc-archive@odin.ietf.org; Tue, 11 May 2004 20:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhCe-0005eW-71 for rohc-web-archive@optimus.ietf.org; Tue, 11 May 2004 20:02: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 UAA07997 for ; Tue, 11 May 2004 20:02:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhCc-0006Qz-BT for rohc-web-archive@ietf.org; Tue, 11 May 2004 20:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhBe-0005xp-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 20:01:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNhAc-0005TR-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 20:00:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh1c-00037V-MQ; Tue, 11 May 2004 19:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgrF-00019F-Ll for rohc@optimus.ietf.org; Tue, 11 May 2004 19:40: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 TAA06795 for ; Tue, 11 May 2004 19:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgrD-0004Ui-QK for rohc@ietf.org; Tue, 11 May 2004 19:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgqL-00044x-00 for rohc@ietf.org; Tue, 11 May 2004 19:39:26 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BNgpY-0003DR-00 for rohc@ietf.org; Tue, 11 May 2004 19:38:36 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 00:37:57 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHDWYMZN; Wed, 12 May 2004 00:37:53 +0100 From: "West, Mark" To: "Ghyslain Pelletier (LU/EAB)" Cc: rohc@ietf.org Date: Tue, 11 May 2004 23:37:53 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: RE: [rohc] Comments on UDP-lite compression In-Reply-To: Message-ID: 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi Ghyslain, > Non-NiTS: > --------- > Matching the packet length is what has precedence. Is this also your opinion? > Or do you feel that this might be wrong? > That sounds fine to me. > Having a null size payload is not the case that is normally expected. I agree that it's a pretty rare occurence; but then those are always the ones that bite you when you least expect it! > However, when this occurs, i.e. > > size(payload) == null and if > field(CC) == length(packet) > > if the compressor then uses CE(OFF), the compressor knows that the CC > field will be inferred at the decompressor, and that the length of the > packet will be used. So I don't think that there is any ambiguity based > on the text. > Agree. > However, if the compressor would rather use a fixed value for the CC and > avoid the decompressor to infer the CC after the length of the packet, > then the compressor should use: > > CE(OFF) for packets with field(CC) == constant != length(packet), and > CE() for packets with field(CC) == constant == length(packet). > > Recall that CE() does not update the context, so the compressor can avoid any ambiguity. That's a good point. > > I don't think that there is any contradiction regarding this in the > text, however I will have a closer look to see where I can make a > clarification. Sounds good to me. To be honest, when this occured to me, I re-read the text briefly and decided that it was sufficiently interesting to bring up as a review comment. However, your explanation makes sense. If it is possible to make it less likely that it will be read in the way that I did, then that would be great! > > NiTS: > ----- > I'll change the text according to your suggestions. > I can change the acronym 'CE' to 'CCE', after "Checksum Coverage Extension". > Great... > I assume that you are fine with the changes mentionned in my previous mail to the list? > Yes -- no problem with any of those. Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 11 20:32: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 UAA09434 for ; Tue, 11 May 2004 20:32: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 1BNhWK-00025i-Oe for rohc-archive@odin.ietf.org; Tue, 11 May 2004 20:22:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C0MmTN007887 for rohc-archive@odin.ietf.org; Tue, 11 May 2004 20:22:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhMS-000874-2h for rohc-web-archive@optimus.ietf.org; Tue, 11 May 2004 20:12: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 UAA08571 for ; Tue, 11 May 2004 20:12: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 1BNhMQ-00036v-3v for rohc-web-archive@ietf.org; Tue, 11 May 2004 20:12:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhLY-0002dX-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 20:11:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNhJW-0001nG-00 for rohc-web-archive@ietf.org; Tue, 11 May 2004 20: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 1BNh9J-0004w3-Ry; Tue, 11 May 2004 19:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh0w-0002xD-Ok for rohc@optimus.ietf.org; Tue, 11 May 2004 19:50: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 TAA07183 for ; Tue, 11 May 2004 19:50:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNh0u-0000ym-Su for rohc@ietf.org; Tue, 11 May 2004 19:50:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgzz-0000Y5-00 for rohc@ietf.org; Tue, 11 May 2004 19:49:24 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BNgz0-0007UV-00 for rohc@ietf.org; Tue, 11 May 2004 19:48:22 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 00:47:52 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHDWYMZS; Wed, 12 May 2004 00:47:49 +0100 From: "West, Mark" To: "Lars-Erik Jonsson (LU/EAB)" Cc: "'Kristofer Sandlund'" , rohc@ietf.org Date: Tue, 11 May 2004 23:47:49 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: RE: [rohc] Limiting the number of IP header in IP-only profile In-Reply-To: Message-ID: 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, Looks like a reasonable proposal to me... I'm not *completely* convinced that manipulating the version field in this way doesn't come under the heading of 'hack', but it strikes me as a pretty rational hack! :-) My only observation would be that this allows a compressor to limit the number of headers that it has to store in its contexts, but the decompressor can only REJECT the flow (if it has insufficient storage). That is, there's no 'reason code' for the decompressor to be able to say 'I can't handle that many headers' or for the decompressor to be able to advertise, 'I can handle up to n IP headers'... Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Tue, 11 May 2004, Lars-Erik Jonsson (LU/EAB) wrote: > Date: Tue, 11 May 2004 14:47:21 +0200 > From: "Lars-Erik Jonsson (LU/EAB)" > To: "Lars-Erik Jonsson (LU/EAB)" , > 'Kristofer Sandlund' , rohc@ietf.org > Subject: RE: [rohc] Limiting the number of IP header in IP-only profile > > Me and Kristofer have discussed this issue further and come up with > a change proposal. Please let us know what you think, both about the > technical issue/resolution as well as how we should move on with it. > Kristofer has convinced me that this is important for real-world > implementations, so our take on it is that we should try to get this > into the IP profile before publication, if at all possible. > > BR > /L-E > > > ***** CHANGE PROPOSAL FOR THE IP PROFILE ***** > > > OLD: > 3.1. Static Chain Termination > One difference for IP-only compression, compared to IP/UDP > compression, is related to the termination of the static chain in IR > headers. For the UDP profile, the chain always ends with a UDP header > part, which per definition provides the boundaries for the chain. The > UDP header is also the last header in the uncompressed packet (except > for a potential application header). For the IP-only profile, there > is no single last header that per profile definition terminates the > chain. Instead, the static chain is terminated if the "Next Header / > Protocol" field of a static IP header part indicates anything but IP > (IPinIP or IPv6). > > NEW: > 3.1. Static Chain Termination > One difference for IP-only compression, compared to IP/UDP > compression, is related to the termination of the static chain in IR > headers. For the UDP profile, the chain always ends with a UDP header > part, which per definition provides the boundaries for the chain. The > UDP header is also the last header in the uncompressed packet (except > for a potential application header). For the IP-only profile, there > is no single last header that per profile definition terminates the > chain. Instead, the static chain is terminated if the "Next Header / > Protocol" field of a static IP header part indicates anything but IP > (IPinIP or IPv6). Alternatively, the compressor can choose to end the > static chain at any IP header, and indicate this by setting the MSB > of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The > decompressor must store this indication in the context for correct > decompression of subsequent headers. Note that the IP version field > in decompressed headers must be restored to its original value. > > > OLD (part of 3.2): > As explained above, the static chain within IR packets can be of > arbitrary length, and the chain is terminated by the presence of a > non-IP header (not IPinIP nor IPv6). The dynamic chain is structured > analogously. > > NEW (part of 3.2): > As explained above, the static chain within IR packets can be of > arbitrary length, and the chain is terminated by the presence of a > non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be > explicitly terminated with a special IP version number, as described > in section 3.1. The dynamic chain is structured analogously. > > > OLD (part of 3.5): > 1) By using an IR packet as in ROHC UDP, where the profile is > 0x0004, and the static chain ends with the static part of an > IP header, where the Next Header/Protocol field has any value but > IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is > initialized to a random value when the first IR packet is sent. > > 2) By reusing an existing context. This is done with an IR-DYN > packet, identifying profile 0x0004, where the dynamic chain > corresponds to the prefix of the existing static chain, ending > with an IP header where the Next Header/Protocol field has any > value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, > SN is initialized to a random value when the first IR-DYN packet > is sent. > > NEW (part of 3.5): > 1) By using an IR packet as in ROHC UDP, where the profile is > 0x0004, and the static chain ends with the static part of an > IP header, where the Next Header/Protocol field has any value but > IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field > indicates termination (see section 3.1). At the compressor, SN > is initialized to a random value when the first IR packet is sent. > > 2) By reusing an existing context. This is done with an IR-DYN > packet, identifying profile 0x0004, where the dynamic chain > corresponds to the prefix of the existing static chain, ending > with an IP header where the Next Header/Protocol field has any > value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP > version field indicates termination (see section 3.1). At the > compressor, SN is initialized to a random value when the first > IR-DYN packet is sent. > > > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > > Lars-Erik Jonsson (LU/EAB) > > Sent: den 11 maj 2004 10:51 > > To: 'Kristofer Sandlund'; rohc@ietf.org > > Subject: RE: [rohc] Limiting the number of IP header in > > IP-only profile > > > > > > Kristofer, > > > > I understand your concern and agree with your point. I also find > > your proposal reasonable. The question is, what should we do at > > this point? We could argue for making this change to the IP > > profile before publication, as it is a new problem that is > > unique for the IP profile, and it would be bad to not have > > that resolved. I am not sure this is a sufficiently significant > > problem in practice, but it might be tricky to implement it > > without the ability to limit the compressed chain length. > > > > So, while we are anyway waiting for the IANA action, let's figure > > out what text should had been in the document. If we can agree on > > that, we can consider whether we should bother the AD's with it > > at this point. > > > > /L-E > > > > > > > -----Original Message----- > > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > > > Kristofer Sandlund > > > Sent: den 10 maj 2004 16:54 > > > To: rohc@ietf.org > > > Subject: [rohc] Limiting the number of IP header in IP-only profile > > > > > > > > > Hi all! > > > > > > I know I'm a bit late here since the IP profile has passed > > > last call, but > > > there's one feature that I think could be quite useful to add. > > > > > > Section 3.1 in ip-only-05.txt says: > > > Instead, the static chain is terminated if the "Next Header / > > > Protocol" field of a static IP header part indicates > > > anything but IP > > > (IPinIP or IPv6). > > > > > > It would be useful for the compressor to decide to only > > > compress a few of the IP > > > headers instead of having to compress "all or none". > > > > > > To do this, the compressor would somehow have to indicate in > > > the static chain > > > that an IP header is the last compressed IP header, even if > > > the protocol field > > > indicates the prescence of more IP headers. > > > > > > Since only the IPv4 header has "reserved bits" (the 4 bits > > > right after version), > > > there are no free bits that work for both IPv4 and IPv4. But, > > > since we're > > > sending all 4 of the IP version bits, while we anyway only > > > handle them to be "4" > > > and "6", the IP only could be extended to work with some > > > extra bit patterns. > > > > > > The only of these four bits that actually needs to be read > > > from the static chain > > > is the third one (4=0100 and 6=0110) so any of the other > > > three bits could be > > > used to mark the end of the static chain. So, let's say that > > > we use the top bit > > > to indicate the end of the static chain, the version field would be: > > > > > > 0100= IPv4 non-final header > > > 0110= IPv6 non-final header > > > 1100= IPv4 final header (end of static chain) > > > 1110= IPv6 final header (end of static chain). > > > > > > Obviously, these changes would only need to apply to the IP > > > profile since that > > > is the only one that can terminate in an IP header, so this > > > would not have any > > > impact on any other profiles. If it can be added to the > > > current IP-only profile > > > that would be great but otherwise it might be something for > > > the next revision of > > > the profile. > > > > > > Rgds, > > > Kristofer Sandlund, Effnet AB > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 01:30:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22192 for ; Wed, 12 May 2004 01:30: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 1BNmAu-0007Oj-5i for rohc-archive@odin.ietf.org; Wed, 12 May 2004 01:21:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C5L0rD028435 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 01:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNm9W-000728-DW for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 01:19: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 BAA21581 for ; Wed, 12 May 2004 01:19: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 1BNm9T-0004Nx-J9 for rohc-web-archive@ietf.org; Wed, 12 May 2004 01:19:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNm8V-0003wQ-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 01:18:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNm7T-0003UR-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 01:17:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNlok-0002IC-69; Wed, 12 May 2004 00:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNliU-0000sk-AC for rohc@optimus.ietf.org; Wed, 12 May 2004 00:51: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 AAA20280 for ; Wed, 12 May 2004 00:51:34 -0400 (EDT) From: rseth@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 1BNliR-0007ah-G9 for rohc@ietf.org; Wed, 12 May 2004 00:51:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNlhP-00079H-00 for rohc@ietf.org; Wed, 12 May 2004 00:50:31 -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 1BNlgO-0006hz-00 for rohc@ietf.org; Wed, 12 May 2004 00:49:29 -0400 Received: from pragati.blr.hss.hns.com ([172.17.33.22]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i4C4mKD01138 for ; Wed, 12 May 2004 10:18:20 +0530 To: rohc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 12 May 2004 10:19:24 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 05/12/2004 10:19:25 AM, Serialize complete at 05/12/2004 10:19:25 AM Content-Type: multipart/alternative; boundary="=_alternative 001A823E65256E92_=" Subject: [rohc] Partial_State_ID calculation at compressor End 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=HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 001A823E65256E92_= Content-Type: text/plain; charset="US-ASCII" RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. --=_alternative 001A823E65256E92_= Content-Type: text/html; charset="US-ASCII"
RFC 3321 says

"The compressor must only use states   that are established at the remote decompressor, otherwise a decompression failure will occur.  For this reason,  acknowledgements are necessary, at least for unreliable transport."

My case is as follows :

1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2.
2. EP2 saves state EP2_S1.
2. EP2 sends compressed 100 Trying  message with decompression  BYTECODE to EP1.
3. EP1 saves state EP1_S1.
4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1.

My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing.

If so how the partial_state_id will be calculated at EP2 compressor End.


--=_alternative 001A823E65256E92_=-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 03:02:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11638 for ; Wed, 12 May 2004 03:02: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 1BNngv-0000rc-Tr for rohc-archive@odin.ietf.org; Wed, 12 May 2004 02:58:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6w9PG003316 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 02:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnN1-00041h-Nb for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 02:37: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 CAA09268 for ; Wed, 12 May 2004 02:37: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 1BNnMx-0000qn-QE for rohc-web-archive@ietf.org; Wed, 12 May 2004 02:37:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnLn-0007lN-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 02:36:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNnK9-0006rH-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 02:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNn8y-0007ga-FS; Wed, 12 May 2004 02:23:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNn5a-0006N7-DX for rohc@optimus.ietf.org; Wed, 12 May 2004 02:19: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 CAA14912 for ; Wed, 12 May 2004 02:19: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 1BNn5W-0007iB-Cl for rohc@ietf.org; Wed, 12 May 2004 02:19:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNn4X-0007I9-00 for rohc@ietf.org; Wed, 12 May 2004 02:18:30 -0400 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BNn3P-0006T1-00 for rohc@ietf.org; Wed, 12 May 2004 02:17:19 -0400 Received: from effnet.com (c-177871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.23]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i4C5GVU2003086 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 May 2004 07:16:32 +0200 Message-ID: <40A1C152.8070403@effnet.com> Date: Wed, 12 May 2004 08:16:50 +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: "West, Mark" CC: "Lars-Erik Jonsson (LU/EAB)" , rohc@ietf.org Subject: Re: [rohc] Limiting the number of IP header in IP-only profile References: In-Reply-To: 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 Hi Mark. Since we added the CONTEXT_MEMORY feedback to the IP profile, the decompressor has a way of saying that "this specific flow should be compressed less agressively" instead of just REJECT. At reception of a CONTEXT_MEMORY, the compressor can choose to reduce the number of IP headers compressed instead of performing a profile downgrade to uncompressed. I agree that is it not an _exact_ reason, but with this, the "toolbox" for the compressor is improved. Rgds, Kristofer Sandlund, Effnet AB West, Mark wrote: > Hi all, > > Looks like a reasonable proposal to me... I'm not *completely* convinced > that manipulating the version field in this way doesn't come under the > heading of 'hack', but it strikes me as a pretty rational hack! :-) > > My only observation would be that this allows a compressor to limit the > number of headers that it has to store in its contexts, but the > decompressor can only REJECT the flow (if it has insufficient storage). > That is, there's no 'reason code' for the decompressor to be able to say > 'I can't handle that many headers' or for the decompressor to be able to > advertise, 'I can handle up to n IP headers'... > > Cheers, > > Mark. > > -- > Mark A. West, Senior Consultant Engineer > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > On Tue, 11 May 2004, Lars-Erik Jonsson (LU/EAB) wrote: > > >>Date: Tue, 11 May 2004 14:47:21 +0200 >>From: "Lars-Erik Jonsson (LU/EAB)" >>To: "Lars-Erik Jonsson (LU/EAB)" , >> 'Kristofer Sandlund' , rohc@ietf.org >>Subject: RE: [rohc] Limiting the number of IP header in IP-only profile >> >>Me and Kristofer have discussed this issue further and come up with >>a change proposal. Please let us know what you think, both about the >>technical issue/resolution as well as how we should move on with it. >>Kristofer has convinced me that this is important for real-world >>implementations, so our take on it is that we should try to get this >>into the IP profile before publication, if at all possible. >> >>BR >>/L-E >> >> >>***** CHANGE PROPOSAL FOR THE IP PROFILE ***** >> >> >>OLD: >>3.1. Static Chain Termination >> One difference for IP-only compression, compared to IP/UDP >> compression, is related to the termination of the static chain in IR >> headers. For the UDP profile, the chain always ends with a UDP header >> part, which per definition provides the boundaries for the chain. The >> UDP header is also the last header in the uncompressed packet (except >> for a potential application header). For the IP-only profile, there >> is no single last header that per profile definition terminates the >> chain. Instead, the static chain is terminated if the "Next Header / >> Protocol" field of a static IP header part indicates anything but IP >> (IPinIP or IPv6). >> >>NEW: >>3.1. Static Chain Termination >> One difference for IP-only compression, compared to IP/UDP >> compression, is related to the termination of the static chain in IR >> headers. For the UDP profile, the chain always ends with a UDP header >> part, which per definition provides the boundaries for the chain. The >> UDP header is also the last header in the uncompressed packet (except >> for a potential application header). For the IP-only profile, there >> is no single last header that per profile definition terminates the >> chain. Instead, the static chain is terminated if the "Next Header / >> Protocol" field of a static IP header part indicates anything but IP >> (IPinIP or IPv6). Alternatively, the compressor can choose to end the >> static chain at any IP header, and indicate this by setting the MSB >> of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The >> decompressor must store this indication in the context for correct >> decompression of subsequent headers. Note that the IP version field >> in decompressed headers must be restored to its original value. >> >> >>OLD (part of 3.2): >> As explained above, the static chain within IR packets can be of >> arbitrary length, and the chain is terminated by the presence of a >> non-IP header (not IPinIP nor IPv6). The dynamic chain is structured >> analogously. >> >>NEW (part of 3.2): >> As explained above, the static chain within IR packets can be of >> arbitrary length, and the chain is terminated by the presence of a >> non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be >> explicitly terminated with a special IP version number, as described >> in section 3.1. The dynamic chain is structured analogously. >> >> >>OLD (part of 3.5): >> 1) By using an IR packet as in ROHC UDP, where the profile is >> 0x0004, and the static chain ends with the static part of an >> IP header, where the Next Header/Protocol field has any value but >> IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is >> initialized to a random value when the first IR packet is sent. >> >> 2) By reusing an existing context. This is done with an IR-DYN >> packet, identifying profile 0x0004, where the dynamic chain >> corresponds to the prefix of the existing static chain, ending >> with an IP header where the Next Header/Protocol field has any >> value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, >> SN is initialized to a random value when the first IR-DYN packet >> is sent. >> >>NEW (part of 3.5): >> 1) By using an IR packet as in ROHC UDP, where the profile is >> 0x0004, and the static chain ends with the static part of an >> IP header, where the Next Header/Protocol field has any value but >> IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field >> indicates termination (see section 3.1). At the compressor, SN >> is initialized to a random value when the first IR packet is sent. >> >> 2) By reusing an existing context. This is done with an IR-DYN >> packet, identifying profile 0x0004, where the dynamic chain >> corresponds to the prefix of the existing static chain, ending >> with an IP header where the Next Header/Protocol field has any >> value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP >> version field indicates termination (see section 3.1). At the >> compressor, SN is initialized to a random value when the first >> IR-DYN packet is sent. >> >> >> >>>-----Original Message----- >>>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of >>>Lars-Erik Jonsson (LU/EAB) >>>Sent: den 11 maj 2004 10:51 >>>To: 'Kristofer Sandlund'; rohc@ietf.org >>>Subject: RE: [rohc] Limiting the number of IP header in >>>IP-only profile >>> >>> >>>Kristofer, >>> >>>I understand your concern and agree with your point. I also find >>>your proposal reasonable. The question is, what should we do at >>>this point? We could argue for making this change to the IP >>>profile before publication, as it is a new problem that is >>>unique for the IP profile, and it would be bad to not have >>>that resolved. I am not sure this is a sufficiently significant >>>problem in practice, but it might be tricky to implement it >>>without the ability to limit the compressed chain length. >>> >>>So, while we are anyway waiting for the IANA action, let's figure >>>out what text should had been in the document. If we can agree on >>>that, we can consider whether we should bother the AD's with it >>>at this point. >>> >>>/L-E >>> >>> >>> >>>>-----Original Message----- >>>>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of >>>>Kristofer Sandlund >>>>Sent: den 10 maj 2004 16:54 >>>>To: rohc@ietf.org >>>>Subject: [rohc] Limiting the number of IP header in IP-only profile >>>> >>>> >>>>Hi all! >>>> >>>>I know I'm a bit late here since the IP profile has passed >>>>last call, but >>>>there's one feature that I think could be quite useful to add. >>>> >>>>Section 3.1 in ip-only-05.txt says: >>>> Instead, the static chain is terminated if the "Next Header / >>>> Protocol" field of a static IP header part indicates >>>>anything but IP >>>> (IPinIP or IPv6). >>>> >>>>It would be useful for the compressor to decide to only >>>>compress a few of the IP >>>>headers instead of having to compress "all or none". >>>> >>>>To do this, the compressor would somehow have to indicate in >>>>the static chain >>>>that an IP header is the last compressed IP header, even if >>>>the protocol field >>>>indicates the prescence of more IP headers. >>>> >>>>Since only the IPv4 header has "reserved bits" (the 4 bits >>>>right after version), >>>>there are no free bits that work for both IPv4 and IPv4. But, >>>>since we're >>>>sending all 4 of the IP version bits, while we anyway only >>>>handle them to be "4" >>>>and "6", the IP only could be extended to work with some >>>>extra bit patterns. >>>> >>>>The only of these four bits that actually needs to be read >>>>from the static chain >>>>is the third one (4=0100 and 6=0110) so any of the other >>>>three bits could be >>>>used to mark the end of the static chain. So, let's say that >>>>we use the top bit >>>>to indicate the end of the static chain, the version field would be: >>>> >>>>0100= IPv4 non-final header >>>>0110= IPv6 non-final header >>>>1100= IPv4 final header (end of static chain) >>>>1110= IPv6 final header (end of static chain). >>>> >>>>Obviously, these changes would only need to apply to the IP >>>>profile since that >>>>is the only one that can terminate in an IP header, so this >>>>would not have any >>>>impact on any other profiles. If it can be added to the >>>>current IP-only profile >>>>that would be great but otherwise it might be something for >>>>the next revision of >>>>the profile. >>>> >>>>Rgds, >>>> Kristofer Sandlund, Effnet AB >>> >>>_______________________________________________ >>>Rohc mailing list >>>Rohc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rohc >>> >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 03:29:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13170 for ; Wed, 12 May 2004 03:29: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 1BNo3W-0007qy-UC for rohc-archive@odin.ietf.org; Wed, 12 May 2004 03:21:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C7LU2J030174 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 03:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnwz-0006Us-VV for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 03:14: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 DAA12475 for ; Wed, 12 May 2004 03:14: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 1BNnwx-0002lw-SK for rohc-web-archive@ietf.org; Wed, 12 May 2004 03:14:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnw2-0002Jo-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 03:13:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNnvM-0001rc-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 03:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnjA-00021j-S7; Wed, 12 May 2004 03:00:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnch-0007y9-G9 for rohc@optimus.ietf.org; Wed, 12 May 2004 02:53: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 CAA11167 for ; Wed, 12 May 2004 02:53: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 1BNncd-0000LL-Og for rohc@ietf.org; Wed, 12 May 2004 02:53:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnbq-0007gW-00 for rohc@ietf.org; Wed, 12 May 2004 02:52:54 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BNnar-0006kw-00 for rohc@ietf.org; Wed, 12 May 2004 02:51: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 <0HXL00JXT97EE4@mta1.huawei.com> for rohc@ietf.org; Wed, 12 May 2004 14:40:28 +0800 (CST) Date: Wed, 12 May 2004 12:22:10 +0530 From: suman Subject: Re: [rohc] Partial_State_ID calculation at compressor End To: rseth@hss.hns.com, rohc@ietf.org Message-id: <001b01c437ed$a6ee2be0$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_s6Fc5qM8DPfbmnTtavEaqw)" X-Priority: 3 X-MSMail-priority: Normal References: 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,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_s6Fc5qM8DPfbmnTtavEaqw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP. This is because the other endpoint could be stateless with sms = 0. Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved. thanks suman ----- Original Message ----- From: rseth@hss.hns.com To: rohc@ietf.org Sent: Wednesday, May 12, 2004 10:19 AM Subject: [rohc] Partial_State_ID calculation at compressor End RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. --Boundary_(ID_s6Fc5qM8DPfbmnTtavEaqw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP.
This is because the other endpoint could be stateless with sms = 0.
Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved.
 
thanks
suman
----- Original Message -----
Sent: Wednesday, May 12, 2004 10:19 AM
Subject: [rohc] Partial_State_ID calculation at compressor End


RFC 3321 says

"The compressor must only use states   that are established at the remote decompressor, otherwise a decompression failure will occur.  For this reason,  acknowledgements are necessary, at least for unreliable transport."

My case is as follows :

1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2.
2. EP2 saves state EP2_S1.
2. EP2 sends compressed 100 Trying  message with decompression  BYTECODE to EP1.
3. EP1 saves state EP1_S1.
4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1.

My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing.

If so how the partial_state_id will be calculated at EP2 compressor End.


--Boundary_(ID_s6Fc5qM8DPfbmnTtavEaqw)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 04:20:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16301 for ; Wed, 12 May 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 1BNosy-00044L-1Q for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:14:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C8Edxb015641 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNokE-0001qx-O8 for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 04:05: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 EAA15345 for ; Wed, 12 May 2004 04:05:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNokC-0004OC-5O for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:05:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNojD-0003tU-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:04:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNoi3-0002wD-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:03:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNoem-0000Wv-RE; Wed, 12 May 2004 04:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNoXg-0007On-OE for rohc@optimus.ietf.org; Wed, 12 May 2004 03: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 DAA14428 for ; Wed, 12 May 2004 03:52: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 1BNoXe-0005c4-7Y for rohc@ietf.org; Wed, 12 May 2004 03:52:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNoWc-00057j-00 for rohc@ietf.org; Wed, 12 May 2004 03:51:35 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BNoVY-0004C2-00 for rohc@ietf.org; Wed, 12 May 2004 03:50:29 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 08:49:58 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHDWYM0Q; Wed, 12 May 2004 08:49:55 +0100 From: "West, Mark" To: Kristofer Sandlund Cc: "West, Mark" , "Lars-Erik Jonsson (LU/EAB)" , rohc@ietf.org Date: Wed, 12 May 2004 07:49:55 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: Re: [rohc] Limiting the number of IP header in IP-only profile In-Reply-To: <40A1C152.8070403@effnet.com> Message-ID: 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.0 required=5.0 tests=none autolearn=no version=2.60 Hi Kristofer, I must be getting old..! I'd forgotten about the CONTEXT_MEMORY feedback (as you could probably tell!) Of course that will do the job just fine. In which case, the proposed changes look good to me. Cheers, Mark. -- Mark A. West, Senior Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Wed, 12 May 2004, Kristofer Sandlund wrote: > Date: Wed, 12 May 2004 08:16:50 +0200 > From: Kristofer Sandlund > To: "West, Mark" > Cc: "Lars-Erik Jonsson (LU/EAB)" , > rohc@ietf.org > Subject: Re: [rohc] Limiting the number of IP header in IP-only profile > > Hi Mark. > > Since we added the CONTEXT_MEMORY feedback to the IP profile, the decompressor > has a way of saying that "this specific flow should be compressed less > agressively" instead of just REJECT. At reception of a CONTEXT_MEMORY, the > compressor can choose to reduce the number of IP headers compressed instead of > performing a profile downgrade to uncompressed. I agree that is it not an > _exact_ reason, but with this, the "toolbox" for the compressor is improved. > > Rgds, > Kristofer Sandlund, Effnet AB > > West, Mark wrote: > > Hi all, > > > > Looks like a reasonable proposal to me... I'm not *completely* convinced > > that manipulating the version field in this way doesn't come under the > > heading of 'hack', but it strikes me as a pretty rational hack! :-) > > > > My only observation would be that this allows a compressor to limit the > > number of headers that it has to store in its contexts, but the > > decompressor can only REJECT the flow (if it has insufficient storage). > > That is, there's no 'reason code' for the decompressor to be able to say > > 'I can't handle that many headers' or for the decompressor to be able to > > advertise, 'I can handle up to n IP headers'... > > > > Cheers, > > > > Mark. > > > > -- > > Mark A. West, Senior Consultant Engineer > > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > > On Tue, 11 May 2004, Lars-Erik Jonsson (LU/EAB) wrote: > > > > > >>Date: Tue, 11 May 2004 14:47:21 +0200 > >>From: "Lars-Erik Jonsson (LU/EAB)" > >>To: "Lars-Erik Jonsson (LU/EAB)" , > >> 'Kristofer Sandlund' , rohc@ietf.org > >>Subject: RE: [rohc] Limiting the number of IP header in IP-only profile > >> > >>Me and Kristofer have discussed this issue further and come up with > >>a change proposal. Please let us know what you think, both about the > >>technical issue/resolution as well as how we should move on with it. > >>Kristofer has convinced me that this is important for real-world > >>implementations, so our take on it is that we should try to get this > >>into the IP profile before publication, if at all possible. > >> > >>BR > >>/L-E > >> > >> > >>***** CHANGE PROPOSAL FOR THE IP PROFILE ***** > >> > >> > >>OLD: > >>3.1. Static Chain Termination > >> One difference for IP-only compression, compared to IP/UDP > >> compression, is related to the termination of the static chain in IR > >> headers. For the UDP profile, the chain always ends with a UDP header > >> part, which per definition provides the boundaries for the chain. The > >> UDP header is also the last header in the uncompressed packet (except > >> for a potential application header). For the IP-only profile, there > >> is no single last header that per profile definition terminates the > >> chain. Instead, the static chain is terminated if the "Next Header / > >> Protocol" field of a static IP header part indicates anything but IP > >> (IPinIP or IPv6). > >> > >>NEW: > >>3.1. Static Chain Termination > >> One difference for IP-only compression, compared to IP/UDP > >> compression, is related to the termination of the static chain in IR > >> headers. For the UDP profile, the chain always ends with a UDP header > >> part, which per definition provides the boundaries for the chain. The > >> UDP header is also the last header in the uncompressed packet (except > >> for a potential application header). For the IP-only profile, there > >> is no single last header that per profile definition terminates the > >> chain. Instead, the static chain is terminated if the "Next Header / > >> Protocol" field of a static IP header part indicates anything but IP > >> (IPinIP or IPv6). Alternatively, the compressor can choose to end the > >> static chain at any IP header, and indicate this by setting the MSB > >> of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The > >> decompressor must store this indication in the context for correct > >> decompression of subsequent headers. Note that the IP version field > >> in decompressed headers must be restored to its original value. > >> > >> > >>OLD (part of 3.2): > >> As explained above, the static chain within IR packets can be of > >> arbitrary length, and the chain is terminated by the presence of a > >> non-IP header (not IPinIP nor IPv6). The dynamic chain is structured > >> analogously. > >> > >>NEW (part of 3.2): > >> As explained above, the static chain within IR packets can be of > >> arbitrary length, and the chain is terminated by the presence of a > >> non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be > >> explicitly terminated with a special IP version number, as described > >> in section 3.1. The dynamic chain is structured analogously. > >> > >> > >>OLD (part of 3.5): > >> 1) By using an IR packet as in ROHC UDP, where the profile is > >> 0x0004, and the static chain ends with the static part of an > >> IP header, where the Next Header/Protocol field has any value but > >> IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is > >> initialized to a random value when the first IR packet is sent. > >> > >> 2) By reusing an existing context. This is done with an IR-DYN > >> packet, identifying profile 0x0004, where the dynamic chain > >> corresponds to the prefix of the existing static chain, ending > >> with an IP header where the Next Header/Protocol field has any > >> value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, > >> SN is initialized to a random value when the first IR-DYN packet > >> is sent. > >> > >>NEW (part of 3.5): > >> 1) By using an IR packet as in ROHC UDP, where the profile is > >> 0x0004, and the static chain ends with the static part of an > >> IP header, where the Next Header/Protocol field has any value but > >> IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field > >> indicates termination (see section 3.1). At the compressor, SN > >> is initialized to a random value when the first IR packet is sent. > >> > >> 2) By reusing an existing context. This is done with an IR-DYN > >> packet, identifying profile 0x0004, where the dynamic chain > >> corresponds to the prefix of the existing static chain, ending > >> with an IP header where the Next Header/Protocol field has any > >> value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP > >> version field indicates termination (see section 3.1). At the > >> compressor, SN is initialized to a random value when the first > >> IR-DYN packet is sent. > >> > >> > >> > >>>-----Original Message----- > >>>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > >>>Lars-Erik Jonsson (LU/EAB) > >>>Sent: den 11 maj 2004 10:51 > >>>To: 'Kristofer Sandlund'; rohc@ietf.org > >>>Subject: RE: [rohc] Limiting the number of IP header in > >>>IP-only profile > >>> > >>> > >>>Kristofer, > >>> > >>>I understand your concern and agree with your point. I also find > >>>your proposal reasonable. The question is, what should we do at > >>>this point? We could argue for making this change to the IP > >>>profile before publication, as it is a new problem that is > >>>unique for the IP profile, and it would be bad to not have > >>>that resolved. I am not sure this is a sufficiently significant > >>>problem in practice, but it might be tricky to implement it > >>>without the ability to limit the compressed chain length. > >>> > >>>So, while we are anyway waiting for the IANA action, let's figure > >>>out what text should had been in the document. If we can agree on > >>>that, we can consider whether we should bother the AD's with it > >>>at this point. > >>> > >>>/L-E > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > >>>>Kristofer Sandlund > >>>>Sent: den 10 maj 2004 16:54 > >>>>To: rohc@ietf.org > >>>>Subject: [rohc] Limiting the number of IP header in IP-only profile > >>>> > >>>> > >>>>Hi all! > >>>> > >>>>I know I'm a bit late here since the IP profile has passed > >>>>last call, but > >>>>there's one feature that I think could be quite useful to add. > >>>> > >>>>Section 3.1 in ip-only-05.txt says: > >>>> Instead, the static chain is terminated if the "Next Header / > >>>> Protocol" field of a static IP header part indicates > >>>>anything but IP > >>>> (IPinIP or IPv6). > >>>> > >>>>It would be useful for the compressor to decide to only > >>>>compress a few of the IP > >>>>headers instead of having to compress "all or none". > >>>> > >>>>To do this, the compressor would somehow have to indicate in > >>>>the static chain > >>>>that an IP header is the last compressed IP header, even if > >>>>the protocol field > >>>>indicates the prescence of more IP headers. > >>>> > >>>>Since only the IPv4 header has "reserved bits" (the 4 bits > >>>>right after version), > >>>>there are no free bits that work for both IPv4 and IPv4. But, > >>>>since we're > >>>>sending all 4 of the IP version bits, while we anyway only > >>>>handle them to be "4" > >>>>and "6", the IP only could be extended to work with some > >>>>extra bit patterns. > >>>> > >>>>The only of these four bits that actually needs to be read > >>>>from the static chain > >>>>is the third one (4=0100 and 6=0110) so any of the other > >>>>three bits could be > >>>>used to mark the end of the static chain. So, let's say that > >>>>we use the top bit > >>>>to indicate the end of the static chain, the version field would be: > >>>> > >>>>0100= IPv4 non-final header > >>>>0110= IPv6 non-final header > >>>>1100= IPv4 final header (end of static chain) > >>>>1110= IPv6 final header (end of static chain). > >>>> > >>>>Obviously, these changes would only need to apply to the IP > >>>>profile since that > >>>>is the only one that can terminate in an IP header, so this > >>>>would not have any > >>>>impact on any other profiles. If it can be added to the > >>>>current IP-only profile > >>>>that would be great but otherwise it might be something for > >>>>the next revision of > >>>>the profile. > >>>> > >>>>Rgds, > >>>> Kristofer Sandlund, Effnet AB > >>> > >>>_______________________________________________ > >>>Rohc mailing list > >>>Rohc@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/rohc > >>> > >> > >>_______________________________________________ > >>Rohc mailing list > >>Rohc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rohc > >> > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 04:24:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16532 for ; Wed, 12 May 2004 04:24: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 1BNouh-0004Ke-Vt for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:16:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C8GRTl016634 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNomD-0002ZH-Az for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 04:07: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 EAA15457 for ; Wed, 12 May 2004 04:07: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 1BNomA-0005NB-Nr for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:07:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNolB-0004sb-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:06:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNokE-0004Og-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:05:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNoen-0000Xn-LM; Wed, 12 May 2004 04: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 1BNoXm-0007Os-ND for rohc@optimus.ietf.org; Wed, 12 May 2004 03:52: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 DAA14449 for ; Wed, 12 May 2004 03:52: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 1BNoXk-0005cm-3z for rohc@ietf.org; Wed, 12 May 2004 03:52:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNoWr-00059e-00 for rohc@ietf.org; Wed, 12 May 2004 03:51:50 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BNoVx-0004ge-00 for rohc@ietf.org; Wed, 12 May 2004 03:50:53 -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 i4C7osPA010043 for ; Wed, 12 May 2004 09:50:54 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 May 2004 09:50:54 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 09:50:58 +0200 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'suman'" , rseth@hss.hns.com, rohc@ietf.org Subject: RE: [rohc] Partial_State_ID calculation at compressor End Date: Wed, 12 May 2004 09:50:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C437F5.C7DE818A" X-OriginalArrivalTime: 12 May 2004 07:50:54.0350 (UTC) FILETIME=[DA60AAE0:01C437F5] 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,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C437F5.C7DE818A Content-Type: text/plain; charset="ISO-8859-1" Hi, As far as I know, using a reliable transport makes feedbacks unnecessary. In such a case, it is not the feedback you need to decide if the requested save state operation has been performed but the advertisement of SMS > 0 (as Suman mentioned it might be 0). In the example, the first message might advertise SMS > 0, which I believe is enough to think that the BYTECODE was successfully saved, so there is no need to repeat it in the 180 Ringing. Note that the feedback in itself is not enough to know if the save state was indeed all right, because there might be some kind of state database error or lack of memory in state handler, while the requested feedback is still sent back (indicating only that the application accepted the decompressed message). BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: Wednesday, May 12, 2004 8:52 AM To: rseth@hss.hns.com; rohc@ietf.org Subject: Re: [rohc] Partial_State_ID calculation at compressor End In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP. This is because the other endpoint could be stateless with sms = 0. Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved. thanks suman ----- Original Message ----- From: rseth@hss.hns.com To: rohc@ietf.org Sent: Wednesday, May 12, 2004 10:19 AM Subject: [rohc] Partial_State_ID calculation at compressor End RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. ------_=_NextPart_001_01C437F5.C7DE818A Content-Type: text/html; charset="ISO-8859-1"
Hi,
 
As far as I know, using a reliable transport makes feedbacks unnecessary. In such a case, it is not the feedback you need to decide if the requested save state operation has been performed but the advertisement of SMS > 0 (as Suman mentioned it might be 0).
In the example, the first message might advertise SMS > 0, which I believe is enough to think that the BYTECODE was successfully saved, so there is no need to repeat it in the 180 Ringing.
Note that the feedback in itself is not enough to know if the save state was indeed all right, because there might be some kind of state database error or lack of memory in state handler, while the requested feedback is still sent back (indicating only that the application accepted the decompressed message).
 
BR/Zacco
-----Original Message-----
From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman
Sent: Wednesday, May 12, 2004 8:52 AM
To: rseth@hss.hns.com; rohc@ietf.org
Subject: Re: [rohc] Partial_State_ID calculation at compressor End

In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP.
This is because the other endpoint could be stateless with sms = 0.
Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved.
 
thanks
suman
----- Original Message -----
Sent: Wednesday, May 12, 2004 10:19 AM
Subject: [rohc] Partial_State_ID calculation at compressor End


RFC 3321 says

"The compressor must only use states   that are established at the remote decompressor, otherwise a decompression failure will occur.  For this reason,  acknowledgements are necessary, at least for unreliable transport."

My case is as follows :

1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2.
2. EP2 saves state EP2_S1.
2. EP2 sends compressed 100 Trying  message with decompression  BYTECODE to EP1.
3. EP1 saves state EP1_S1.
4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1.

My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing.

If so how the partial_state_id will be calculated at EP2 compressor End.


------_=_NextPart_001_01C437F5.C7DE818A-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 04:46:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17882 for ; Wed, 12 May 2004 04:46: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 1BNpL9-0002IG-I3 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:43:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C8hlu4008811 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpII-0001CD-Bt for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 04:40: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 EAA17439 for ; Wed, 12 May 2004 04:40: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 1BNpIF-0006yA-98 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:40:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpHJ-0006RY-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:39:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNpGQ-0005wL-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:38:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNp3D-0006Gu-Vs; Wed, 12 May 2004 04:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNowb-0004kF-3f for rohc@optimus.ietf.org; Wed, 12 May 2004 04:18: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 EAA16110 for ; Wed, 12 May 2004 04:18:23 -0400 (EDT) From: schatterjee@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 1BNowY-00031X-DP for rohc@ietf.org; Wed, 12 May 2004 04:18:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNov0-00025k-00 for rohc@ietf.org; Wed, 12 May 2004 04:16:46 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BNotA-0000zf-00 for rohc@ietf.org; Wed, 12 May 2004 04:14:52 -0400 Received: from pragati.blr.hss.hns.com ([172.17.33.22]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i4C8CoD06441; Wed, 12 May 2004 13:43:00 +0530 In-Reply-To: Subject: RE: [rohc] Partial_State_ID calculation at compressor End To: "Lajos Zaccomer (IJ/ETH)" Cc: rohc@ietf.org, rseth@hss.hns.com, "'suman'" X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 12 May 2004 13:43:49 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 05/12/2004 01:44:16 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, A couple of points 1. If you don't send the feedback in the case of TCP , how do you know the partial state id of the saved state so that u can send it in the next message you send ? the partial state id is calculated when the UDVM executes at the remote end. 2. I believe, if the state save fails due to some reason, the requested feedback should not be sent back at all by the receiving endpoint. regds, suprabhat "Lajos Zaccomer (IJ/ETH)" "'suman'" , Sent by: rseth@hss.hns.com, rohc@ietf.org rohc-admin@ietf.o cc rg Subject RE: [rohc] Partial_State_ID 05/12/04 01:20 PM calculation at compressor End Hi, As far as I know, using a reliable transport makes feedbacks unnecessary. In such a case, it is not the feedback you need to decide if the requested save state operation has been performed but the advertisement of SMS > 0 (as Suman mentioned it might be 0). In the example, the first message might advertise SMS > 0, which I believe is enough to think that the BYTECODE was successfully saved, so there is no need to repeat it in the 180 Ringing. Note that the feedback in itself is not enough to know if the save state was indeed all right, because there might be some kind of state database error or lack of memory in state handler, while the requested feedback is still sent back (indicating only that the application accepted the decompressed message). BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: Wednesday, May 12, 2004 8:52 AM To: rseth@hss.hns.com; rohc@ietf.org Subject: Re: [rohc] Partial_State_ID calculation at compressor End In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP. This is because the other endpoint could be stateless with sms = 0. Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved. thanks suman ----- Original Message ----- From: rseth@hss.hns.com To: rohc@ietf.org Sent: Wednesday, May 12, 2004 10:19 AM Subject: [rohc] Partial_State_ID calculation at compressor End RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 05:08:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18925 for ; Wed, 12 May 2004 05:08: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 1BNpZq-0007OA-1g for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:58:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C8wv3v028385 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 04:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpUp-0004Zv-Pj for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 04:53: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 EAA18210 for ; Wed, 12 May 2004 04:53: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 1BNpUm-0005oL-PU for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpTp-0005Ke-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:52:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNpSx-0004pe-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 04:51:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpLZ-0002VB-Uc; Wed, 12 May 2004 04:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpHF-0000te-Ky for rohc@optimus.ietf.org; Wed, 12 May 2004 04:39: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 EAA17377 for ; Wed, 12 May 2004 04:39:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNpHC-0006QW-D3 for rohc@ietf.org; Wed, 12 May 2004 04:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpGD-0005uR-00 for rohc@ietf.org; Wed, 12 May 2004 04:38:42 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BNpFC-0005Pn-00 for rohc@ietf.org; Wed, 12 May 2004 04:37:38 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4C8bcWR012343 for ; Wed, 12 May 2004 10:37:38 +0200 (MEST) 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, 12 May 2004 10:37:38 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 10:37:42 +0200 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'schatterjee@hss.hns.com'" Cc: rohc@ietf.org, rseth@hss.hns.com, "'suman'" Subject: RE: [rohc] Partial_State_ID calculation at compressor End Date: Wed, 12 May 2004 10:37:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 12 May 2004 08:37:38.0781 (UTC) FILETIME=[61F2E0D0:01C437FC] 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 Hi, 1. The compressor must be aware of what the state ID is, so no need to send it back. 2. This question is not discussed in implementation details in the RFC 3320 that says in 4.3 (remember the note in my previous message): Upon receiving a decompressed message the application may supply the dispatcher with a compartment identifier. Supplying this identifier grants permission for the following: 1. Items of state accompanying the decompressed message can be saved using the state memory reserved for the specified compartment. 2. The feedback data accompanying the decompressed message can be trusted sufficiently that it can be used when sending SigComp messages that relate to the compressor's equivalent for the compartment. BR/Zacco -----Original Message----- From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] Sent: Wednesday, May 12, 2004 10:14 AM To: Lajos Zaccomer (IJ/ETH) Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' Subject: RE: [rohc] Partial_State_ID calculation at compressor End Hi, A couple of points 1. If you don't send the feedback in the case of TCP , how do you know the partial state id of the saved state so that u can send it in the next message you send ? the partial state id is calculated when the UDVM executes at the remote end. 2. I believe, if the state save fails due to some reason, the requested feedback should not be sent back at all by the receiving endpoint. regds, suprabhat "Lajos Zaccomer (IJ/ETH)" "'suman'" , Sent by: rseth@hss.hns.com, rohc@ietf.org rohc-admin@ietf.o cc rg Subject RE: [rohc] Partial_State_ID 05/12/04 01:20 PM calculation at compressor End Hi, As far as I know, using a reliable transport makes feedbacks unnecessary. In such a case, it is not the feedback you need to decide if the requested save state operation has been performed but the advertisement of SMS > 0 (as Suman mentioned it might be 0). In the example, the first message might advertise SMS > 0, which I believe is enough to think that the BYTECODE was successfully saved, so there is no need to repeat it in the 180 Ringing. Note that the feedback in itself is not enough to know if the save state was indeed all right, because there might be some kind of state database error or lack of memory in state handler, while the requested feedback is still sent back (indicating only that the application accepted the decompressed message). BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: Wednesday, May 12, 2004 8:52 AM To: rseth@hss.hns.com; rohc@ietf.org Subject: Re: [rohc] Partial_State_ID calculation at compressor End In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP. This is because the other endpoint could be stateless with sms = 0. Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved. thanks suman ----- Original Message ----- From: rseth@hss.hns.com To: rohc@ietf.org Sent: Wednesday, May 12, 2004 10:19 AM Subject: [rohc] Partial_State_ID calculation at compressor End RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 05:20:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19386 for ; Wed, 12 May 2004 05:20: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 1BNpof-0002N1-6l for rohc-archive@odin.ietf.org; Wed, 12 May 2004 05:14:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C9EHeT009111 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 05:14:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpjH-0001Ao-GG for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 05:08: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 FAA18965 for ; Wed, 12 May 2004 05:08: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 1BNpjE-0005YF-E8 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:08:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpiF-00052w-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:07:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNph8-0004I9-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:06:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpYy-0007Gn-L2; Wed, 12 May 2004 04:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpTq-00048p-LP for rohc@optimus.ietf.org; Wed, 12 May 2004 04:52: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 EAA18176 for ; Wed, 12 May 2004 04:52: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 1BNpTn-0005KG-J2 for rohc@ietf.org; Wed, 12 May 2004 04:52:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpSl-0004oK-00 for rohc@ietf.org; Wed, 12 May 2004 04:51:40 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BNpRn-0004HJ-00 for rohc@ietf.org; Wed, 12 May 2004 04:50:39 -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 i4C8oePA026957 for ; Wed, 12 May 2004 10:50: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, 12 May 2004 10:50:40 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 10:50:40 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Vicknesan Ayadurai (KI/EAB)" Cc: "Karl Norrman (KI/EAB)" , "'rohc@ietf.org'" Date: Wed, 12 May 2004 10:49: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: 12 May 2004 08:50:40.0072 (UTC) FILETIME=[33A26C80:01C437FE] Subject: [rohc] RE: Outer IP-ID 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Vick (and others), See page 75, "IP-ID": "IP-ID fields in compressed base headers carry the compressed IP-ID of the innermost IPv4 header whose corresponding RND flag is not 1." This means for two IP headers (IP-ID field means the field in compressed headers): IPv6/IPv6/UDP/RTP : No IP-ID field in compressed headers. IPv6/IPv4(RND=1)/UDP/RTP : No IP-ID field in compressed headers. IPv6/IPv4(RND=0)/UDP/RTP : The IP-ID field corresponds to the inner header. IPv4(RND=1)/IPv6/UDP/RTP : No IP-ID field in compressed headers. IPv4(RND=0)/IPv6/UDP/RTP : The IP-ID field corresponds to the outer header. IPv4(RND=1)/IPv4(RND=1)/UDP/RTP: No IP-ID field in compressed headers. IPv4(RND=1)/IPv4(RND=0)/UDP/RTP: The IP-ID field corresponds to the inner header. IPv4(RND=0)/IPv4(RND=0)/UDP/RTP: The IP-ID field corresponds to the inner header. This last case would only work if the outer IP-ID is totally sequential N, N+1, N+2...etc. (previous config should be used instead) Crystal clear from RFC3095...=) /L-E > -----Original Message----- > From: Vicknesan Ayadurai (KI/EAB) > Sent: den 4 maj 2004 17:38 > To: Lars-Erik Jonsson (LU/EAB) > Subject: Outer IP-ID field > > > Hi L-E, > > Regarding our brief chat regarding the outer IP-ID field, there > doesn't seem to be too much detail in the RFC regarding this. Page 75 > describes the compressed IP-ID field, but mainly focus on how IP-ID is > encoded, and not what happens with the outer IP-ID. It says: > > "... The rules below assume that the IP-ID is for the innermost IP > header. If it is for an outer IP header, the RND2 and NBO2 flags are > used instead of RND and NBO." > > which doesn't really clarify things up (to me anyway). > > The simplest thing I think, as we talked, would be to send the > complete outer IP-ID in full all the time. This means that RND2 is > always set whenever there's an outer IP-ID, but I didn't find any > clear text saying this. > > Would this be the correct interpretation of how to handle the outer > IP-ID field? > > Regards, > vick > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 05:43:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20276 for ; Wed, 12 May 2004 05:43: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 1BNqBl-0006ze-R1 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 05:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C9c9fP026878 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 05:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNq9a-0006NW-VQ for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 05:35: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 FAA19917 for ; Wed, 12 May 2004 05:35:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNq9X-0003H4-ID for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:35:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNq8X-0002n0-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:34:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNq7u-0002JK-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:34:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNq10-0004lK-VK; Wed, 12 May 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 1BNpw4-0003pr-0P for rohc@optimus.ietf.org; Wed, 12 May 2004 05:21: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 FAA19518 for ; Wed, 12 May 2004 05:21: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 1BNpw0-0004CJ-Hk for rohc@ietf.org; Wed, 12 May 2004 05:21:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpv7-0003hl-00 for rohc@ietf.org; Wed, 12 May 2004 05:20:57 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BNpuM-0003AY-00 for rohc@ietf.org; Wed, 12 May 2004 05:20:10 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 10:19:41 +0100 Message-ID: From: "Surtees, Abigail" To: "'rohc@ietf.org'" Date: Wed, 12 May 2004 10:19:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [rohc] SigComp clarifications 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 Folks, A couple of minor ambiguities in SigComp have come to light. If we can agree on the outcome, then I'll write some text for the implementer's guide. I believe it was also agreed that the DAP specification used for SIPit should be put as an annex to the implementer's guide. I'll do this in the same update. Byte copying rules: Section 8.4 of 3320 does not list CRC but 9.3.5 does say byte-copying rules apply. Presumably byte copying rules do apply? The SHA-1 instruction uses byte-copying rules to write the computed hash to UDVM memory. Should byte copying rules be used for reading a partial state identifier provided by a STATE-FREE instruction? The STATE-FREE instruction doesn't say so, nor is it listed in section 8.4. However, if the byte-copying rules don't apply, then if you were do a SHA-1 instruction and write the identifier into the circular buffer, (though I can't currently see any reason for wanting to do so) and then free some state using STATE-FREE and that identifier, the identifier would be read incorrectly. A similar question applies to the feedback items and whether they should obey byte-copying rules - the requested feedback could be the result of a SHA-1 instruction which obeys byte-copying rules. The END-MESSAGE description uses the term 'byte-copy' when referring to the partial state id but does not explicitly reference 8.4 (though it is mentioned there). Any thoughts welcome. Best regards, Abbie Abbie Surtees Senior Engineer Networks Roke Manor Research Ltd Old Salisbury Lane Romsey, SO51 0ZN Tel: +44 (0) 1794 833131 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed May 12 06:04:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20978 for ; Wed, 12 May 2004 06:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqW9-0002Ij-5D for rohc-archive@odin.ietf.org; Wed, 12 May 2004 05:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C9xDKb008845 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 05:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqRy-0001Z9-Ur for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 05:54: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 FAA20694 for ; Wed, 12 May 2004 05:54:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNqRv-0004xu-C7 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:54:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqRA-0004Sv-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:54:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNqQ5-0003ye-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:52:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqHR-0007wX-22; Wed, 12 May 2004 05: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 1BNqCZ-0007Ff-Tp for rohc@optimus.ietf.org; Wed, 12 May 2004 05:38: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 FAA20039 for ; Wed, 12 May 2004 05:38: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 1BNqCW-0004ma-A5 for rohc@ietf.org; Wed, 12 May 2004 05:38:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqBY-0004HF-00 for rohc@ietf.org; Wed, 12 May 2004 05:37:57 -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 1BNqAY-0003m3-00; Wed, 12 May 2004 05:36:54 -0400 Received: from pragati.blr.hss.hns.com ([172.17.33.22]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i4C9YhD08405; Wed, 12 May 2004 15:04:53 +0530 In-Reply-To: Subject: RE: [rohc] Partial_State_ID calculation at compressor End To: "Lajos Zaccomer (IJ/ETH)" Cc: rohc@ietf.org, rohc-admin@ietf.org, rseth@hss.hns.com, "'schatterjee@hss.hns.com'" , "'suman'" X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 12 May 2004 15:05:44 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 05/12/2004 03:06:13 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 Lajos, This mail is regarding the pt-1 as stated by you in previous mail. As per my understanding of RFC 3320, the sigcomp does not mandate any "compression algorithm & decompression bytecode" because the decompression intelligence is built in the UDVM. The sender sends the compressed message along with the decompression bytecode in the sigcomp message. That clearly means that decompression algorithm/bytecode writing is outside the scope of the sigcomp and it is entirely in scope of application written over top of the sigcomp. Pls note that State-Id calculation requires following parameters : 1> State Length 2> State address 3> State Instruction 4> Min access length 5> State Retention Priority Also, note that state create request can be made through two instructions : a. STATE_CREATE b. END_MESSAGE The sigcomp can not know the above parameters at the time of sending message (which will contain the bytecode as chosen by the application) so how can State-Id be calculated at sender side. That is, how can compressor at local end know the state-id as the parameters [required for state id calcuation] are embedded inside the bytecode [which can be interpreted at the remote end only] ? Waiting for your input on this point. thanks and regards Jyoti "Lajos Zaccomer (IJ/ETH)" "'schatterjee@hss.hns.com'" Sent by: rohc-admin@ietf.o cc rg rohc@ietf.org, rseth@hss.hns.com, "'suman'" Subject 05/12/04 02:07 PM RE: [rohc] Partial_State_ID calculation at compressor End Hi, 1. The compressor must be aware of what the state ID is, so no need to send it back. 2. This question is not discussed in implementation details in the RFC 3320 that says in 4.3 (remember the note in my previous message): Upon receiving a decompressed message the application may supply the dispatcher with a compartment identifier. Supplying this identifier grants permission for the following: 1. Items of state accompanying the decompressed message can be saved using the state memory reserved for the specified compartment. 2. The feedback data accompanying the decompressed message can be trusted sufficiently that it can be used when sending SigComp messages that relate to the compressor's equivalent for the compartment. BR/Zacco -----Original Message----- From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] Sent: Wednesday, May 12, 2004 10:14 AM To: Lajos Zaccomer (IJ/ETH) Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' Subject: RE: [rohc] Partial_State_ID calculation at compressor End Hi, A couple of points 1. If you don't send the feedback in the case of TCP , how do you know the partial state id of the saved state so that u can send it in the next message you send ? the partial state id is calculated when the UDVM executes at the remote end. 2. I believe, if the state save fails due to some reason, the requested feedback should not be sent back at all by the receiving endpoint. regds, suprabhat "Lajos Zaccomer (IJ/ETH)" "'suman'" , Sent by: rseth@hss.hns.com, rohc@ietf.org rohc-admin@ietf.o cc rg Subject RE: [rohc] Partial_State_ID 05/12/04 01:20 PM calculation at compressor End Hi, As far as I know, using a reliable transport makes feedbacks unnecessary. In such a case, it is not the feedback you need to decide if the requested save state operation has been performed but the advertisement of SMS > 0 (as Suman mentioned it might be 0). In the example, the first message might advertise SMS > 0, which I believe is enough to think that the BYTECODE was successfully saved, so there is no need to repeat it in the 180 Ringing. Note that the feedback in itself is not enough to know if the save state was indeed all right, because there might be some kind of state database error or lack of memory in state handler, while the requested feedback is still sent back (indicating only that the application accepted the decompressed message). BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: Wednesday, May 12, 2004 8:52 AM To: rseth@hss.hns.com; rohc@ietf.org Subject: Re: [rohc] Partial_State_ID calculation at compressor End In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP. This is because the other endpoint could be stateless with sms = 0. Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved. thanks suman ----- Original Message ----- From: rseth@hss.hns.com To: rohc@ietf.org Sent: Wednesday, May 12, 2004 10:19 AM Subject: [rohc] Partial_State_ID calculation at compressor End RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. _______________________________________________ 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 May 12 06:05:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21033 for ; Wed, 12 May 2004 06:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqbF-0002lh-Ey for rohc-archive@odin.ietf.org; Wed, 12 May 2004 06:04:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CA4TKn010636 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 06:04:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqWp-0002KN-AA for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 05:59: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 FAA20834 for ; Wed, 12 May 2004 05:59: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 1BNqWl-0007Q8-Q1 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:59:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqVl-0006vQ-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:58:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNqV3-0006RG-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 05:58:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqQ9-0001Gj-MM; Wed, 12 May 2004 05:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqEP-0007eP-CZ for rohc@optimus.ietf.org; Wed, 12 May 2004 05:40:53 -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 FAA20151 for ; Wed, 12 May 2004 05:40:50 -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 1BNqEL-0005ng-TV for rohc@ietf.org; Wed, 12 May 2004 05:40:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqDQ-0005Ir-00 for rohc@ietf.org; Wed, 12 May 2004 05:39:53 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BNqCc-0004n8-00; Wed, 12 May 2004 05:39:02 -0400 Received: from pragati.blr.hss.hns.com ([172.17.33.22]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i4C9aFD08469; Wed, 12 May 2004 15:06:36 +0530 In-Reply-To: Subject: RE: [rohc] Partial_State_ID calculation at compressor End To: rohc@ietf.org, rohc-admin@ietf.org Cc: "Lajos Zaccomer (IJ/ETH)" , ellyptic@hotmail.com, cabo@tzi.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 12 May 2004 15:07:16 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 05/12/2004 03:08:30 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 Lajos, This mail is regarding the pt-1 as stated by you in previous mail. As per my understanding of RFC 3320, the sigcomp does not mandate any "compression algorithm & decompression bytecode" because the decompression intelligence is built in the UDVM. The sender sends the compressed message along with the decompression bytecode in the sigcomp message. That clearly means that decompression algorithm/bytecode writing is outside the scope of the sigcomp and it is entirely in scope of application written over top of the sigcomp. Pls note that State-Id calculation requires following parameters : 1> State Length 2> State address 3> State Instruction 4> Min access length 5> State Retention Priority Also, note that state create request can be made through two instructions : a. STATE_CREATE b. END_MESSAGE The sigcomp can not know the above parameters at the time of sending message (which will contain the bytecode as chosen by the application) so how can State-Id be calculated at sender side. That is, how can compressor at local end know the state-id as the parameters [required for state id calcuation] are embedded inside the bytecode [which can be interpreted at the remote end only] ? Waiting for your input on this point. thanks and regards Jyoti "Lajos Zaccomer (IJ/ETH)" "'schatterjee@hss.hns.com'" Sent by: rohc-admin@ietf.o cc rg rohc@ietf.org, rseth@hss.hns.com, "'suman'" Subject 05/12/04 02:07 PM RE: [rohc] Partial_State_ID calculation at compressor End Hi, 1. The compressor must be aware of what the state ID is, so no need to send it back. 2. This question is not discussed in implementation details in the RFC 3320 that says in 4.3 (remember the note in my previous message): Upon receiving a decompressed message the application may supply the dispatcher with a compartment identifier. Supplying this identifier grants permission for the following: 1. Items of state accompanying the decompressed message can be saved using the state memory reserved for the specified compartment. 2. The feedback data accompanying the decompressed message can be trusted sufficiently that it can be used when sending SigComp messages that relate to the compressor's equivalent for the compartment. BR/Zacco -----Original Message----- From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] Sent: Wednesday, May 12, 2004 10:14 AM To: Lajos Zaccomer (IJ/ETH) Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' Subject: RE: [rohc] Partial_State_ID calculation at compressor End Hi, A couple of points 1. If you don't send the feedback in the case of TCP , how do you know the partial state id of the saved state so that u can send it in the next message you send ? the partial state id is calculated when the UDVM executes at the remote end. 2. I believe, if the state save fails due to some reason, the requested feedback should not be sent back at all by the receiving endpoint. regds, suprabhat "Lajos Zaccomer (IJ/ETH)" "'suman'" , Sent by: rseth@hss.hns.com, rohc@ietf.org rohc-admin@ietf.o cc rg Subject RE: [rohc] Partial_State_ID 05/12/04 01:20 PM calculation at compressor End Hi, As far as I know, using a reliable transport makes feedbacks unnecessary. In such a case, it is not the feedback you need to decide if the requested save state operation has been performed but the advertisement of SMS > 0 (as Suman mentioned it might be 0). In the example, the first message might advertise SMS > 0, which I believe is enough to think that the BYTECODE was successfully saved, so there is no need to repeat it in the 180 Ringing. Note that the feedback in itself is not enough to know if the save state was indeed all right, because there might be some kind of state database error or lack of memory in state handler, while the requested feedback is still sent back (indicating only that the application accepted the decompressed message). BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: Wednesday, May 12, 2004 8:52 AM To: rseth@hss.hns.com; rohc@ietf.org Subject: Re: [rohc] Partial_State_ID calculation at compressor End In your example, the 180 ringing will always carry the bytecode in case of both UDP and TCP. This is because the other endpoint could be stateless with sms = 0. Without receiving feedback from the peer endpoint, it cannot be assumed that the states are saved. thanks suman ----- Original Message ----- From: rseth@hss.hns.com To: rohc@ietf.org Sent: Wednesday, May 12, 2004 10:19 AM Subject: [rohc] Partial_State_ID calculation at compressor End RFC 3321 says "The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport." My case is as follows : 1. EP1 sends compressed INVITE message with decompression BYTECODE to EP2. 2. EP2 saves state EP2_S1. 2. EP2 sends compressed 100 Trying message with decompression BYTECODE to EP1. 3. EP1 saves state EP1_S1. 4. Now when EP2 wants to send 180 ringing and it has not go the ack for state EP1_S1. My question is in case of TCP, can the EP2 send the partial_state_Id instead of uploading BYTECODE again when it sends 180 Ringing. If so how the partial_state_id will be calculated at EP2 compressor End. _______________________________________________ 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 May 12 08:09:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27134 for ; Wed, 12 May 2004 08:09:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsUt-0001h9-6Z for rohc-archive@odin.ietf.org; Wed, 12 May 2004 08:06:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CC63nd006516 for rohc-archive@odin.ietf.org; Wed, 12 May 2004 08:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsSl-0001AD-QC for rohc-web-archive@optimus.ietf.org; Wed, 12 May 2004 08:03: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 IAA26833 for ; Wed, 12 May 2004 08:03: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 1BNsSk-0001dl-TT for rohc-web-archive@ietf.org; Wed, 12 May 2004 08:03:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNsRk-00017M-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 08:02:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNsQe-0000JZ-00 for rohc-web-archive@ietf.org; Wed, 12 May 2004 08:01:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsM9-0008CX-Ca; Wed, 12 May 2004 07: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 1BNsGM-0007Vc-4D for rohc@optimus.ietf.org; Wed, 12 May 2004 07:51:02 -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 HAA25681 for ; Wed, 12 May 2004 07:51: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 1BNsGL-0002fL-Ag for rohc@ietf.org; Wed, 12 May 2004 07:51:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNsFL-0002A1-00 for rohc@ietf.org; Wed, 12 May 2004 07:50:00 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BNsEt-0001Tj-00 for rohc@ietf.org; Wed, 12 May 2004 07:49:32 -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 <0HXL0085PNF55H@mta0.huawei.com> for rohc@ietf.org; Wed, 12 May 2004 19:47:31 +0800 (CST) Date: Wed, 12 May 2004 17:19:55 +0530 From: suman Subject: Re: [rohc] Partial_State_ID calculation at compressor End To: jbhalla@hss.hns.com, rohc@ietf.org Cc: "Lajos Zaccomer (IJ/ETH)" , ellyptic@hotmail.com, cabo@tzi.org Message-id: <002601c43817$3f7ee2e0$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 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) 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 Jyoti, Please note that the State-Id calculation requires State Value and not State retention priority. Sigcomp will be aware of all the states that will be created at remote endpoint even before the sigcomp message is sent to the remote endpoint. This is because the bytecode being transferred to the remote endpoint will have a direct one to one relationship with the way the compression algorithm behaves. Before sending the compressed message with the bytecode, the compressor has to save the state it has generated during process of compression. And this state id will be the same as that computed at remote end using STATE-CREATE or END-MESSAGE instructions. thanks suman ----- Original Message ----- From: To: ; Cc: "Lajos Zaccomer (IJ/ETH)" ; ; Sent: Wednesday, May 12, 2004 3:07 PM Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > Hi Lajos, > > This mail is regarding the pt-1 as stated by you in previous mail. > > As per my understanding of RFC 3320, the sigcomp does not mandate > any "compression algorithm & decompression bytecode" because > the decompression intelligence is built in the UDVM. > > The sender sends the compressed message along with the decompression > bytecode in the sigcomp message. That clearly means that decompression > algorithm/bytecode writing is outside the scope of the sigcomp and > it is entirely in scope of application written over top of the sigcomp. > > Pls note that State-Id calculation requires following parameters : > 1> State Length > 2> State address > 3> State Instruction > 4> Min access length > 5> State Retention Priority > > Also, note that state create request can be made through two > instructions : > a. STATE_CREATE > b. END_MESSAGE > > The sigcomp can not know the above parameters at the time of > sending message (which will contain the bytecode as chosen > by the application) so how can State-Id be calculated at sender > side. That is, how can compressor at local end know the state-id > as the parameters [required for state id calcuation] > are embedded inside the bytecode [which can be interpreted at the > remote end only] ? > > Waiting for your input on this point. > > thanks and regards > Jyoti > > > > > "Lajos Zaccomer > (IJ/ETH)" > ricsson.com> "'schatterjee@hss.hns.com'" > Sent by: > rohc-admin@ietf.o cc > rg rohc@ietf.org, rseth@hss.hns.com, > "'suman'" > Subject > 05/12/04 02:07 PM RE: [rohc] Partial_State_ID > calculation at compressor End > > > > > > > > > > > Hi, > > 1. The compressor must be aware of what the state ID is, so no need to send > it back. > 2. This question is not discussed in implementation details in the RFC 3320 > that says in 4.3 (remember the note in my previous message): > > Upon receiving a decompressed message the application may supply the > dispatcher with a compartment identifier. Supplying this identifier > grants permission for the following: > > 1. Items of state accompanying the decompressed message can be saved > using the state memory reserved for the specified compartment. > > 2. The feedback data accompanying the decompressed message can be > trusted sufficiently that it can be used when sending SigComp > messages that relate to the compressor's equivalent for the > compartment. > > BR/Zacco > > > -----Original Message----- > From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] > Sent: Wednesday, May 12, 2004 10:14 AM > To: Lajos Zaccomer (IJ/ETH) > Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' > Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > > Hi, > > A couple of points > > 1. If you don't send the feedback in the case of TCP , how do you know the > partial state id of the saved state so that u can send it in the next > message you send ? the partial state id is calculated when the UDVM > executes at the remote end. > > 2. I believe, if the state save fails due to some reason, the requested > feedback should not be sent back at all by the receiving endpoint. > > regds, > suprabhat > > > > > > "Lajos Zaccomer > (IJ/ETH)" > ricsson.com> "'suman'" , > Sent by: rseth@hss.hns.com, rohc@ietf.org > rohc-admin@ietf.o cc > rg > Subject > RE: [rohc] Partial_State_ID > 05/12/04 01:20 PM calculation at compressor End > > > > > > > > > > > Hi, > > As far as I know, using a reliable transport makes feedbacks unnecessary. > In such a case, it is not the feedback you need to decide if the requested > save state operation has been performed but the advertisement of SMS > 0 > (as Suman mentioned it might be 0). > In the example, the first message might advertise SMS > 0, which I believe > is enough to think that the BYTECODE was successfully saved, so there is no > need to repeat it in the 180 Ringing. > Note that the feedback in itself is not enough to know if the save state > was indeed all right, because there might be some kind of state database > error or lack of memory in state handler, while the requested feedback is > still sent back (indicating only that the application accepted the > decompressed message). > > BR/Zacco > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > suman > Sent: Wednesday, May 12, 2004 8:52 AM > To: rseth@hss.hns.com; rohc@ietf.org > Subject: Re: [rohc] Partial_State_ID calculation at compressor End > > In your example, the 180 ringing will always carry the bytecode in > case of both UDP and TCP. > This is because the other endpoint could be stateless with sms = 0. > Without receiving feedback from the peer endpoint, it cannot be > assumed that the states are saved. > > thanks > suman > ----- Original Message ----- > From: rseth@hss.hns.com > To: rohc@ietf.org > Sent: Wednesday, May 12, 2004 10:19 AM > Subject: [rohc] Partial_State_ID calculation at compressor End > > > RFC 3321 says > > "The compressor must only use states that are established at the > remote decompressor, otherwise a decompression failure will occur. > For this reason, acknowledgements are necessary, at least for > unreliable transport." > > My case is as follows : > > 1. EP1 sends compressed INVITE message with decompression BYTECODE > to EP2. > 2. EP2 saves state EP2_S1. > 2. EP2 sends compressed 100 Trying message with decompression > BYTECODE to EP1. > 3. EP1 saves state EP1_S1. > 4. Now when EP2 wants to send 180 ringing and it has not go the ack > for state EP1_S1. > > My question is in case of TCP, can the EP2 send the partial_state_Id > instead of uploading BYTECODE again when it sends 180 Ringing. > > If so how the partial_state_id will be calculated at EP2 compressor > End. > > > > _______________________________________________ > 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 May 13 03:50:55 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 DAA26148 for ; Thu, 13 May 2004 03:50:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAwQ-0004H7-JG for rohc-archive@odin.ietf.org; Thu, 13 May 2004 03:47:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D7lg8h016426 for rohc-archive@odin.ietf.org; Thu, 13 May 2004 03:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAsd-0003b9-Vc for rohc-web-archive@optimus.ietf.org; Thu, 13 May 2004 03:43: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 DAA25936 for ; Thu, 13 May 2004 03:43: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 1BOAsb-0005Vo-Gk for rohc-web-archive@ietf.org; Thu, 13 May 2004 03:43:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOArm-0004yV-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 03:42:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOAqT-000426-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 03:41:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAn3-000280-Lw; Thu, 13 May 2004 03:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsgW-00048s-R3 for rohc@optimus.ietf.org; Wed, 12 May 2004 08:18: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 IAA27503 for ; Wed, 12 May 2004 08:18:03 -0400 (EDT) From: schatterjee@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 1BNsgV-0001Kc-Ml for rohc@ietf.org; Wed, 12 May 2004 08:18:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNsfY-0000p7-00 for rohc@ietf.org; Wed, 12 May 2004 08:17:05 -0400 Received: from [61.16.168.135] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1BNsez-0000Iw-00; Wed, 12 May 2004 08:16:30 -0400 Received: from pragati.blr.hss.hns.com ([172.17.33.22]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id i4CCArD12394; Wed, 12 May 2004 17:41:15 +0530 In-Reply-To: <002601c43817$3f7ee2e0$6d05120a@sumanccl20088> Subject: Re: [rohc] Partial_State_ID calculation at compressor End To: suman Cc: cabo@tzi.org, ellyptic@hotmail.com, jbhalla@hss.hns.com, "Lajos Zaccomer (IJ/ETH)" , rohc@ietf.org, rohc-admin@ietf.org, anagarajan@hss.hns.com, amannan@hss.hns.com, jbhalla@hss.hns.com, rahammad@hss.hns.com, sauragupta@hss.hns.com, nsudarshan@hss.hns.com, schatterjee@hss.hns.com, rseth@hss.hns.com X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Wed, 12 May 2004 17:41:52 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 05/12/2004 05:43:14 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 suman, Going by your statement you are assuming that the bytecode generation is in the scope of Sigcomp(the compressor). But then you r restricting the application on top of Sigcomp to use any compression algorithm it wishes. regds, suprabhat suman To Sent by: jbhalla@hss.hns.com, rohc@ietf.org rohc-admin@ietf.o cc rg "Lajos Zaccomer (IJ/ETH)" , ellyptic@hotmail.com, cabo@tzi.org 05/12/04 05:19 PM Subject Re: [rohc] Partial_State_ID calculation at compressor End Hi Jyoti, Please note that the State-Id calculation requires State Value and not State retention priority. Sigcomp will be aware of all the states that will be created at remote endpoint even before the sigcomp message is sent to the remote endpoint. This is because the bytecode being transferred to the remote endpoint will have a direct one to one relationship with the way the compression algorithm behaves. Before sending the compressed message with the bytecode, the compressor has to save the state it has generated during process of compression. And this state id will be the same as that computed at remote end using STATE-CREATE or END-MESSAGE instructions. thanks suman ----- Original Message ----- From: To: ; Cc: "Lajos Zaccomer (IJ/ETH)" ; ; Sent: Wednesday, May 12, 2004 3:07 PM Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > Hi Lajos, > > This mail is regarding the pt-1 as stated by you in previous mail. > > As per my understanding of RFC 3320, the sigcomp does not mandate > any "compression algorithm & decompression bytecode" because > the decompression intelligence is built in the UDVM. > > The sender sends the compressed message along with the decompression > bytecode in the sigcomp message. That clearly means that decompression > algorithm/bytecode writing is outside the scope of the sigcomp and > it is entirely in scope of application written over top of the sigcomp. > > Pls note that State-Id calculation requires following parameters : > 1> State Length > 2> State address > 3> State Instruction > 4> Min access length > 5> State Retention Priority > > Also, note that state create request can be made through two > instructions : > a. STATE_CREATE > b. END_MESSAGE > > The sigcomp can not know the above parameters at the time of > sending message (which will contain the bytecode as chosen > by the application) so how can State-Id be calculated at sender > side. That is, how can compressor at local end know the state-id > as the parameters [required for state id calcuation] > are embedded inside the bytecode [which can be interpreted at the > remote end only] ? > > Waiting for your input on this point. > > thanks and regards > Jyoti > > > > > "Lajos Zaccomer > (IJ/ETH)" > ricsson.com> "'schatterjee@hss.hns.com'" > Sent by: > rohc-admin@ietf.o cc > rg rohc@ietf.org, rseth@hss.hns.com, > "'suman'" > Subject > 05/12/04 02:07 PM RE: [rohc] Partial_State_ID > calculation at compressor End > > > > > > > > > > > Hi, > > 1. The compressor must be aware of what the state ID is, so no need to send > it back. > 2. This question is not discussed in implementation details in the RFC 3320 > that says in 4.3 (remember the note in my previous message): > > Upon receiving a decompressed message the application may supply the > dispatcher with a compartment identifier. Supplying this identifier > grants permission for the following: > > 1. Items of state accompanying the decompressed message can be saved > using the state memory reserved for the specified compartment. > > 2. The feedback data accompanying the decompressed message can be > trusted sufficiently that it can be used when sending SigComp > messages that relate to the compressor's equivalent for the > compartment. > > BR/Zacco > > > -----Original Message----- > From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] > Sent: Wednesday, May 12, 2004 10:14 AM > To: Lajos Zaccomer (IJ/ETH) > Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' > Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > > Hi, > > A couple of points > > 1. If you don't send the feedback in the case of TCP , how do you know the > partial state id of the saved state so that u can send it in the next > message you send ? the partial state id is calculated when the UDVM > executes at the remote end. > > 2. I believe, if the state save fails due to some reason, the requested > feedback should not be sent back at all by the receiving endpoint. > > regds, > suprabhat > > > > > > "Lajos Zaccomer > (IJ/ETH)" > ricsson.com> "'suman'" , > Sent by: rseth@hss.hns.com, rohc@ietf.org > rohc-admin@ietf.o cc > rg > Subject > RE: [rohc] Partial_State_ID > 05/12/04 01:20 PM calculation at compressor End > > > > > > > > > > > Hi, > > As far as I know, using a reliable transport makes feedbacks unnecessary. > In such a case, it is not the feedback you need to decide if the requested > save state operation has been performed but the advertisement of SMS > 0 > (as Suman mentioned it might be 0). > In the example, the first message might advertise SMS > 0, which I believe > is enough to think that the BYTECODE was successfully saved, so there is no > need to repeat it in the 180 Ringing. > Note that the feedback in itself is not enough to know if the save state > was indeed all right, because there might be some kind of state database > error or lack of memory in state handler, while the requested feedback is > still sent back (indicating only that the application accepted the > decompressed message). > > BR/Zacco > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > suman > Sent: Wednesday, May 12, 2004 8:52 AM > To: rseth@hss.hns.com; rohc@ietf.org > Subject: Re: [rohc] Partial_State_ID calculation at compressor End > > In your example, the 180 ringing will always carry the bytecode in > case of both UDP and TCP. > This is because the other endpoint could be stateless with sms = 0. > Without receiving feedback from the peer endpoint, it cannot be > assumed that the states are saved. > > thanks > suman > ----- Original Message ----- > From: rseth@hss.hns.com > To: rohc@ietf.org > Sent: Wednesday, May 12, 2004 10:19 AM > Subject: [rohc] Partial_State_ID calculation at compressor End > > > RFC 3321 says > > "The compressor must only use states that are established at the > remote decompressor, otherwise a decompression failure will occur. > For this reason, acknowledgements are necessary, at least for > unreliable transport." > > My case is as follows : > > 1. EP1 sends compressed INVITE message with decompression BYTECODE > to EP2. > 2. EP2 saves state EP2_S1. > 2. EP2 sends compressed 100 Trying message with decompression > BYTECODE to EP1. > 3. EP1 saves state EP1_S1. > 4. Now when EP2 wants to send 180 ringing and it has not go the ack > for state EP1_S1. > > My question is in case of TCP, can the EP2 send the partial_state_Id > instead of uploading BYTECODE again when it sends 180 Ringing. > > If so how the partial_state_id will be calculated at EP2 compressor > End. > > > > _______________________________________________ > 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 May 13 03:51: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 DAA26165 for ; Thu, 13 May 2004 03:51: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 1BOAwS-0004Hz-2D for rohc-archive@odin.ietf.org; Thu, 13 May 2004 03:47:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D7liLD016483 for rohc-archive@odin.ietf.org; Thu, 13 May 2004 03:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAua-0003jj-5H for rohc-web-archive@optimus.ietf.org; Thu, 13 May 2004 03:45: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 DAA25976 for ; Thu, 13 May 2004 03:45: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 1BOAuX-0006YA-OP for rohc-web-archive@ietf.org; Thu, 13 May 2004 03:45:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOAtc-000623-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 03:44:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOAsi-0005Wf-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 03:43:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOAn4-00028A-7o; Thu, 13 May 2004 03:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO7d6-00052z-M7 for rohc@optimus.ietf.org; Thu, 13 May 2004 00:15:32 -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 AAA01403 for ; Thu, 13 May 2004 00:15: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 1BO7d4-0001Xw-4Z for rohc@ietf.org; Thu, 13 May 2004 00:15:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO7c5-00011g-00 for rohc@ietf.org; Thu, 13 May 2004 00:14:30 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BO7ap-000014-00 for rohc@ietf.org; Thu, 13 May 2004 00:13:12 -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 <0HXM006DAWJFUZ@mta1.huawei.com> for rohc@ietf.org; Thu, 13 May 2004 12:02:06 +0800 (CST) Date: Thu, 13 May 2004 09:43:47 +0530 From: suman Subject: Re: [rohc] Partial_State_ID calculation at compressor End To: schatterjee@hss.hns.com Cc: cabo@tzi.org, ellyptic@hotmail.com, jbhalla@hss.hns.com, "Lajos Zaccomer (IJ/ETH)" , rohc@ietf.org, anagarajan@hss.hns.com, amannan@hss.hns.com, rahammad@hss.hns.com, sauragupta@hss.hns.com, nsudarshan@hss.hns.com, schatterjee@hss.hns.com, rseth@hss.hns.com Message-id: <000801c438a0$b1c1afc0$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 suprabat, The application is flexible to choose any of the compression algorithms, but there will be a unique bytecode for each of the compression algorithm(each of which is available within the SigComp framework). SigComp layer should send the corresponding bytecode depending on the compression algorithm chosen by application. The state management policy could be different for each of the compression algorithms. It should be handled in the same way by the compression algorithm and the corresponding bytecode. If the application on the top of SigComp wishes to use a new compression algorithm, it has to bind the corresponding bytecode to the SigComp layer. But as you say, this architecture has some limitations. Introducing a new compression algorithm on the fly by application means, the compressor should be made aware of the states that will be created by this algorithm, and the corresponding bytecode. thanks suman ----- Original Message ----- From: To: "suman" Cc: ; ; ; "Lajos Zaccomer (IJ/ETH)" ; ; ; ; ; ; ; ; ; ; Sent: Wednesday, May 12, 2004 5:41 PM Subject: Re: [rohc] Partial_State_ID calculation at compressor End > > > > > Hi suman, > > Going by your statement you are assuming that the bytecode generation is in > the scope of Sigcomp(the compressor). But then you r restricting the > application on top of Sigcomp to use any compression algorithm it wishes. > > > regds, > suprabhat > > > > suman > m> To > Sent by: jbhalla@hss.hns.com, rohc@ietf.org > rohc-admin@ietf.o cc > rg "Lajos Zaccomer (IJ/ETH)" > , > ellyptic@hotmail.com, cabo@tzi.org > 05/12/04 05:19 PM Subject > Re: [rohc] Partial_State_ID > calculation at compressor End > > > > > > > > > > > Hi Jyoti, > > Please note that the State-Id calculation requires State Value and not > State retention priority. > > Sigcomp will be aware of all the states that will be created at remote > endpoint > even before the sigcomp message is sent to the remote endpoint. > > This is because the bytecode being transferred to the remote endpoint will > have > a direct one to one relationship with the way the compression algorithm > behaves. > Before sending the compressed message with the bytecode, the compressor has > to save the state it has generated during process of compression. And this > state id > will be the same as that computed at remote end using STATE-CREATE > or END-MESSAGE instructions. > > thanks > suman > > ----- Original Message ----- > From: > To: ; > Cc: "Lajos Zaccomer (IJ/ETH)" ; > ; > Sent: Wednesday, May 12, 2004 3:07 PM > Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > > > > > > > > > Hi Lajos, > > > > This mail is regarding the pt-1 as stated by you in previous mail. > > > > As per my understanding of RFC 3320, the sigcomp does not mandate > > any "compression algorithm & decompression bytecode" because > > the decompression intelligence is built in the UDVM. > > > > The sender sends the compressed message along with the decompression > > bytecode in the sigcomp message. That clearly means that decompression > > algorithm/bytecode writing is outside the scope of the sigcomp and > > it is entirely in scope of application written over top of the sigcomp. > > > > Pls note that State-Id calculation requires following parameters : > > 1> State Length > > 2> State address > > 3> State Instruction > > 4> Min access length > > 5> State Retention Priority > > > > Also, note that state create request can be made through two > > instructions : > > a. STATE_CREATE > > b. END_MESSAGE > > > > The sigcomp can not know the above parameters at the time of > > sending message (which will contain the bytecode as chosen > > by the application) so how can State-Id be calculated at sender > > side. That is, how can compressor at local end know the state-id > > as the parameters [required for state id calcuation] > > are embedded inside the bytecode [which can be interpreted at the > > remote end only] ? > > > > Waiting for your input on this point. > > > > thanks and regards > > Jyoti > > > > > > > > > > "Lajos Zaccomer > > (IJ/ETH)" > > To > > ricsson.com> "'schatterjee@hss.hns.com'" > > Sent by: > > rohc-admin@ietf.o > cc > > rg rohc@ietf.org, rseth@hss.hns.com, > > "'suman'" > > > Subject > > 05/12/04 02:07 PM RE: [rohc] Partial_State_ID > > calculation at compressor End > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > 1. The compressor must be aware of what the state ID is, so no need to > send > > it back. > > 2. This question is not discussed in implementation details in the RFC > 3320 > > that says in 4.3 (remember the note in my previous message): > > > > Upon receiving a decompressed message the application may supply the > > dispatcher with a compartment identifier. Supplying this identifier > > grants permission for the following: > > > > 1. Items of state accompanying the decompressed message can be saved > > using the state memory reserved for the specified compartment. > > > > 2. The feedback data accompanying the decompressed message can be > > trusted sufficiently that it can be used when sending SigComp > > messages that relate to the compressor's equivalent for the > > compartment. > > > > BR/Zacco > > > > > > -----Original Message----- > > From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] > > Sent: Wednesday, May 12, 2004 10:14 AM > > To: Lajos Zaccomer (IJ/ETH) > > Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' > > Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > > > > > > > > > Hi, > > > > A couple of points > > > > 1. If you don't send the feedback in the case of TCP , how do you know > the > > partial state id of the saved state so that u can send it in the next > > message you send ? the partial state id is calculated when the UDVM > > executes at the remote end. > > > > 2. I believe, if the state save fails due to some reason, the requested > > feedback should not be sent back at all by the receiving endpoint. > > > > regds, > > suprabhat > > > > > > > > > > > > "Lajos Zaccomer > > (IJ/ETH)" > > To > > ricsson.com> "'suman'" , > > Sent by: rseth@hss.hns.com, rohc@ietf.org > > rohc-admin@ietf.o > cc > > rg > > > Subject > > RE: [rohc] Partial_State_ID > > 05/12/04 01:20 PM calculation at compressor End > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > As far as I know, using a reliable transport makes feedbacks unnecessary. > > In such a case, it is not the feedback you need to decide if the > requested > > save state operation has been performed but the advertisement of SMS > 0 > > (as Suman mentioned it might be 0). > > In the example, the first message might advertise SMS > 0, which I > believe > > is enough to think that the BYTECODE was successfully saved, so there is > no > > need to repeat it in the 180 Ringing. > > Note that the feedback in itself is not enough to know if the save state > > was indeed all right, because there might be some kind of state database > > error or lack of memory in state handler, while the requested feedback is > > still sent back (indicating only that the application accepted the > > decompressed message). > > > > BR/Zacco > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > > suman > > Sent: Wednesday, May 12, 2004 8:52 AM > > To: rseth@hss.hns.com; rohc@ietf.org > > Subject: Re: [rohc] Partial_State_ID calculation at compressor End > > > > In your example, the 180 ringing will always carry the bytecode in > > case of both UDP and TCP. > > This is because the other endpoint could be stateless with sms = 0. > > Without receiving feedback from the peer endpoint, it cannot be > > assumed that the states are saved. > > > > thanks > > suman > > ----- Original Message ----- > > From: rseth@hss.hns.com > > To: rohc@ietf.org > > Sent: Wednesday, May 12, 2004 10:19 AM > > Subject: [rohc] Partial_State_ID calculation at compressor End > > > > > > RFC 3321 says > > > > "The compressor must only use states that are established at the > > remote decompressor, otherwise a decompression failure will occur. > > For this reason, acknowledgements are necessary, at least for > > unreliable transport." > > > > My case is as follows : > > > > 1. EP1 sends compressed INVITE message with decompression BYTECODE > > to EP2. > > 2. EP2 saves state EP2_S1. > > 2. EP2 sends compressed 100 Trying message with decompression > > BYTECODE to EP1. > > 3. EP1 saves state EP1_S1. > > 4. Now when EP2 wants to send 180 ringing and it has not go the > ack > > for state EP1_S1. > > > > My question is in case of TCP, can the EP2 send the > partial_state_Id > > instead of uploading BYTECODE again when it sends 180 Ringing. > > > > If so how the partial_state_id will be calculated at EP2 > compressor > > End. > > > > > > > > _______________________________________________ > > 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 May 13 05:51:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01068 for ; Thu, 13 May 2004 05:50: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 1BOCi9-0000BP-Lo for rohc-archive@odin.ietf.org; Thu, 13 May 2004 05:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D9f5G0000703 for rohc-archive@odin.ietf.org; Thu, 13 May 2004 05:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOCc6-0007FA-94 for rohc-web-archive@optimus.ietf.org; Thu, 13 May 2004 05:34: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 FAA00286 for ; Thu, 13 May 2004 05:34: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 1BOCc2-00012U-SV for rohc-web-archive@ietf.org; Thu, 13 May 2004 05:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOCb4-0000V2-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 05:33:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOCZw-0007Xn-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 05:32:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOCTm-0005uY-KO; Thu, 13 May 2004 05:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOCI0-0003uO-Bd for rohc@optimus.ietf.org; Thu, 13 May 2004 05:14: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 FAA29609 for ; Thu, 13 May 2004 05:14: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 1BOCHx-0005pA-1k for rohc@ietf.org; Thu, 13 May 2004 05:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOCHE-0005Ir-00 for rohc@ietf.org; Thu, 13 May 2004 05:13:17 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BOCGI-0004bo-00 for rohc@ietf.org; Thu, 13 May 2004 05:12:19 -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 <0HXN0033AATLTM@mta0.huawei.com> for rohc@ietf.org; Thu, 13 May 2004 17:10:34 +0800 (CST) Date: Thu, 13 May 2004 14:42:51 +0530 From: suman Subject: Re: [rohc] Partial_State_ID calculation at compressor End To: rohc@ietf.org Cc: schatterjee@hss.hns.com Message-id: <001501c438ca$7cfed040$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 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) 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 suprabat, The application is flexible to choose any of the compression algorithms, but there will be a unique bytecode for each of the compression algorithm(each of which is available within the SigComp framework). SigComp layer should send the corresponding bytecode depending on the compression algorithm chosen by application. The state management policy could be different for each of the compression algorithms. It should be handled in the same way by the compression algorithm and the corresponding bytecode. If the application on the top of SigComp wishes to use a new compression algorithm, it has to bind the corresponding bytecode to the SigComp layer. But as you say, this architecture has some limitations. Introducing a new compression algorithm on the fly by application means, the compressor should be made aware of the states that will be created by this algorithm, and the corresponding bytecode. thanks suman ----- Original Message ----- From: To: "suman" Cc: ; ; ; "Lajos Zaccomer (IJ/ETH)" ; ; ; ; ; ; ; ; ; ; Sent: Wednesday, May 12, 2004 5:41 PM Subject: Re: [rohc] Partial_State_ID calculation at compressor End > > > > > Hi suman, > > Going by your statement you are assuming that the bytecode generation is in > the scope of Sigcomp(the compressor). But then you r restricting the > application on top of Sigcomp to use any compression algorithm it wishes. > > > regds, > suprabhat > > > > suman > m> To > Sent by: jbhalla@hss.hns.com, rohc@ietf.org > rohc-admin@ietf.o cc > rg "Lajos Zaccomer (IJ/ETH)" > , > ellyptic@hotmail.com, cabo@tzi.org > 05/12/04 05:19 PM Subject > Re: [rohc] Partial_State_ID > calculation at compressor End > > > > > > > > > > > Hi Jyoti, > > Please note that the State-Id calculation requires State Value and not > State retention priority. > > Sigcomp will be aware of all the states that will be created at remote > endpoint > even before the sigcomp message is sent to the remote endpoint. > > This is because the bytecode being transferred to the remote endpoint will > have > a direct one to one relationship with the way the compression algorithm > behaves. > Before sending the compressed message with the bytecode, the compressor has > to save the state it has generated during process of compression. And this > state id > will be the same as that computed at remote end using STATE-CREATE > or END-MESSAGE instructions. > > thanks > suman > > ----- Original Message ----- > From: > To: ; > Cc: "Lajos Zaccomer (IJ/ETH)" ; > ; > Sent: Wednesday, May 12, 2004 3:07 PM > Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > > > > > > > > > Hi Lajos, > > > > This mail is regarding the pt-1 as stated by you in previous mail. > > > > As per my understanding of RFC 3320, the sigcomp does not mandate > > any "compression algorithm & decompression bytecode" because > > the decompression intelligence is built in the UDVM. > > > > The sender sends the compressed message along with the decompression > > bytecode in the sigcomp message. That clearly means that decompression > > algorithm/bytecode writing is outside the scope of the sigcomp and > > it is entirely in scope of application written over top of the sigcomp. > > > > Pls note that State-Id calculation requires following parameters : > > 1> State Length > > 2> State address > > 3> State Instruction > > 4> Min access length > > 5> State Retention Priority > > > > Also, note that state create request can be made through two > > instructions : > > a. STATE_CREATE > > b. END_MESSAGE > > > > The sigcomp can not know the above parameters at the time of > > sending message (which will contain the bytecode as chosen > > by the application) so how can State-Id be calculated at sender > > side. That is, how can compressor at local end know the state-id > > as the parameters [required for state id calcuation] > > are embedded inside the bytecode [which can be interpreted at the > > remote end only] ? > > > > Waiting for your input on this point. > > > > thanks and regards > > Jyoti > > > > > > > > > > "Lajos Zaccomer > > (IJ/ETH)" > > To > > ricsson.com> "'schatterjee@hss.hns.com'" > > Sent by: > > rohc-admin@ietf.o > cc > > rg rohc@ietf.org, rseth@hss.hns.com, > > "'suman'" > > > Subject > > 05/12/04 02:07 PM RE: [rohc] Partial_State_ID > > calculation at compressor End > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > 1. The compressor must be aware of what the state ID is, so no need to > send > > it back. > > 2. This question is not discussed in implementation details in the RFC > 3320 > > that says in 4.3 (remember the note in my previous message): > > > > Upon receiving a decompressed message the application may supply the > > dispatcher with a compartment identifier. Supplying this identifier > > grants permission for the following: > > > > 1. Items of state accompanying the decompressed message can be saved > > using the state memory reserved for the specified compartment. > > > > 2. The feedback data accompanying the decompressed message can be > > trusted sufficiently that it can be used when sending SigComp > > messages that relate to the compressor's equivalent for the > > compartment. > > > > BR/Zacco > > > > > > -----Original Message----- > > From: schatterjee@hss.hns.com [mailto:schatterjee@hss.hns.com] > > Sent: Wednesday, May 12, 2004 10:14 AM > > To: Lajos Zaccomer (IJ/ETH) > > Cc: rohc@ietf.org; rseth@hss.hns.com; 'suman' > > Subject: RE: [rohc] Partial_State_ID calculation at compressor End > > > > > > > > > > > > > > Hi, > > > > A couple of points > > > > 1. If you don't send the feedback in the case of TCP , how do you know > the > > partial state id of the saved state so that u can send it in the next > > message you send ? the partial state id is calculated when the UDVM > > executes at the remote end. > > > > 2. I believe, if the state save fails due to some reason, the requested > > feedback should not be sent back at all by the receiving endpoint. > > > > regds, > > suprabhat > > > > > > > > > > > > "Lajos Zaccomer > > (IJ/ETH)" > > To > > ricsson.com> "'suman'" , > > Sent by: rseth@hss.hns.com, rohc@ietf.org > > rohc-admin@ietf.o > cc > > rg > > > Subject > > RE: [rohc] Partial_State_ID > > 05/12/04 01:20 PM calculation at compressor End > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > As far as I know, using a reliable transport makes feedbacks unnecessary. > > In such a case, it is not the feedback you need to decide if the > requested > > save state operation has been performed but the advertisement of SMS > 0 > > (as Suman mentioned it might be 0). > > In the example, the first message might advertise SMS > 0, which I > believe > > is enough to think that the BYTECODE was successfully saved, so there is > no > > need to repeat it in the 180 Ringing. > > Note that the feedback in itself is not enough to know if the save state > > was indeed all right, because there might be some kind of state database > > error or lack of memory in state handler, while the requested feedback is > > still sent back (indicating only that the application accepted the > > decompressed message). > > > > BR/Zacco > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > > suman > > Sent: Wednesday, May 12, 2004 8:52 AM > > To: rseth@hss.hns.com; rohc@ietf.org > > Subject: Re: [rohc] Partial_State_ID calculation at compressor End > > > > In your example, the 180 ringing will always carry the bytecode in > > case of both UDP and TCP. > > This is because the other endpoint could be stateless with sms = 0. > > Without receiving feedback from the peer endpoint, it cannot be > > assumed that the states are saved. > > > > thanks > > suman > > ----- Original Message ----- > > From: rseth@hss.hns.com > > To: rohc@ietf.org > > Sent: Wednesday, May 12, 2004 10:19 AM > > Subject: [rohc] Partial_State_ID calculation at compressor End > > > > > > RFC 3321 says > > > > "The compressor must only use states that are established at the > > remote decompressor, otherwise a decompression failure will occur. > > For this reason, acknowledgements are necessary, at least for > > unreliable transport." > > > > My case is as follows : > > > > 1. EP1 sends compressed INVITE message with decompression BYTECODE > > to EP2. > > 2. EP2 saves state EP2_S1. > > 2. EP2 sends compressed 100 Trying message with decompression > > BYTECODE to EP1. > > 3. EP1 saves state EP1_S1. > > 4. Now when EP2 wants to send 180 ringing and it has not go the > ack > > for state EP1_S1. > > > > My question is in case of TCP, can the EP2 send the > partial_state_Id > > instead of uploading BYTECODE again when it sends 180 Ringing. > > > > If so how the partial_state_id will be calculated at EP2 > compressor > > End. > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu May 13 07:19: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 HAA05316 for ; Thu, 13 May 2004 07:19: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 1BOEEC-0002XH-EY for rohc-archive@odin.ietf.org; Thu, 13 May 2004 07:18:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DBIGXX009743 for rohc-archive@odin.ietf.org; Thu, 13 May 2004 07:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOEAz-0001ai-DE for rohc-web-archive@optimus.ietf.org; Thu, 13 May 2004 07:14: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 HAA05165 for ; Thu, 13 May 2004 07:14: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 1BOEAy-0000t7-Uw for rohc-web-archive@ietf.org; Thu, 13 May 2004 07:14:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOEA7-0000Mu-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 07:14:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOE9J-0007dw-00 for rohc-web-archive@ietf.org; Thu, 13 May 2004 07:13:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOE2L-0008PY-MS; Thu, 13 May 2004 07:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOD82-0004kN-42 for rohc@optimus.ietf.org; Thu, 13 May 2004 06:07: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 GAA01986 for ; Thu, 13 May 2004 06:07: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 1BOD7y-0003RU-CD for rohc@ietf.org; Thu, 13 May 2004 06:07:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOD6z-0002un-00 for rohc@ietf.org; Thu, 13 May 2004 06:06:46 -0400 Received: from ozone.nc3a.nato.int ([195.169.116.7] helo=nc3a.nato.int) by ietf-mx with esmtp (Exim 4.12) id 1BOD5u-0001sP-00 for rohc@ietf.org; Thu, 13 May 2004 06:05:38 -0400 Received: from nc3a-interscan ([195.169.116.119]) by nc3a.nato.int (8.12.10/8.9.0) with SMTP id i4DA50C7003473; Thu, 13 May 2004 12:05:02 +0200 (MEST) Received: from neo (radio.nc3a.nato.int [195.169.112.101]) by exchangeth3.nc3a.nato.int with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JYD1T98Y; Thu, 13 May 2004 12:04:03 +0200 From: "Maarten Gerbrands \(NC3A\)" To: , Date: Thu, 13 May 2004 12:04:59 +0200 Message-ID: <000001c438d1$c0514b50$4440a8c0@neo> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-de8a2fef-87b4-4031-b296-ffc1a12b6d0d" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [rohc] Possible using ROHC on a multinode subnet? 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,HTML_60_70,HTML_MESSAGE, MIME_BOUND_NEXTPART autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-de8a2fef-87b4-4031-b296-ffc1a12b6d0d Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C438E2.83DA1B50" ------=_NextPart_000_0001_01C438E2.83DA1B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Gorry, Thanks for responding to my question: "Possible using ROHC on a multinode subnet?" What I mean is unicast communication to several different end points. Will ROHC work on a single Ethernet LAN, where all nodes connected to it are equipped with a single ROHC decompressor/compressor used for all incoming and outgoing unicast? rohc-enabled-node-1 rohc-enabled-node-3 | | |----------------------------------------------------------------------- --------------| Ether | rohc-enabled-node-2 An Ethernet LAN behaves similar to a STANAG 5066 HF subnet. Is the ROHC scheme designed so, that it is possible node 1 and 2 exchange compressed IP frames while node 1 exchanges compressed IP frames with node 3 as well. regards, Maarten Gerbrands Communication Network Branch, Communication and Information Systems Division NATO C3 Agency ------=_NextPart_000_0001_01C438E2.83DA1B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gorry,

 

Thanks for responding to my question: =  “Possible using ROHC on a multinode subnet?”

 

What I mean is unicast communication to several = different end points.

Will ROHC work on a single Ethernet LAN, where all = nodes connected to it are equipped with a single ROHC decompressor/compressor used = for

all incoming and outgoing unicast?

 

  = rohc-enabled-node-1         =                         &= nbsp;      rohc-enabled-node-3

    =        |     =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   |

|---------------------------------------------------= ----------------------------------| Ether

        &nbs= p;                      |=

        &nbs= p;             rohc-enabled-node-2=

 

 

An Ethernet LAN behaves similar to a STANAG 5066 HF = subnet.

 

 

Is the ROHC scheme designed so, that it is possible = node 1 and 2 exchange compressed IP frames

while node 1 exchanges compressed IP frames with node = 3 as well.

 

regards,

 

Maarten Gerbrands
Communication Network Branch,
Communication and Information Systems Division
NATO C3 Agency
 

 

------=_NextPart_000_0001_01C438E2.83DA1B50-- ------=_NextPartTM-000-de8a2fef-87b4-4031-b296-ffc1a12b6d0d-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri May 14 03:29:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03205 for ; Fri, 14 May 2004 03:29: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 1BOX6L-0007Fl-Qt for rohc-archive@odin.ietf.org; Fri, 14 May 2004 03:27:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7RPQL027874 for rohc-archive@odin.ietf.org; Fri, 14 May 2004 03:27:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX3c-0006dJ-8G for rohc-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:24: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 DAA02740 for ; Fri, 14 May 2004 03:24: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 1BOX3a-0005Lt-4M for rohc-web-archive@ietf.org; Fri, 14 May 2004 03:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX1m-0004de-00 for rohc-web-archive@ietf.org; Fri, 14 May 2004 03:22:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOWzi-0003WN-00 for rohc-web-archive@ietf.org; Fri, 14 May 2004 03:20:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWvM-0004Iq-Sh; Fri, 14 May 2004 03:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOWrO-0003VM-JY for rohc@optimus.ietf.org; Fri, 14 May 2004 03:11: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 DAA01231 for ; Fri, 14 May 2004 03:11:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOWrK-0006li-Ja for rohc@ietf.org; Fri, 14 May 2004 03:11:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOWqG-0006Cb-00 for rohc@ietf.org; Fri, 14 May 2004 03:10:49 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BOWpE-0005dq-00 for rohc@ietf.org; Fri, 14 May 2004 03:09:44 -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 i4E79iAh010202 for ; Fri, 14 May 2004 09:09:44 +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, 14 May 2004 09:09:43 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 14 May 2004 09:09:44 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Fri, 14 May 2004 09:08:27 +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 May 2004 07:09:43.0487 (UTC) FILETIME=[6E7464F0:01C43982] Subject: [rohc] FW: Outer IP-ID 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.0 required=5.0 tests=AWL autolearn=no version=2.60 The discussion continued offline, see below, but the conclusion is that IP-ID is always sent offset-IPID-encoded if it is not RND (sent at the end of the compressed base header), and this applies to both inner and outer IP-ID bits. /L-E -----Original Message----- From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] Sent: den 14 maj 2004 08:25 To: Vicknesan Ayadurai (KI/EAB) Cc: Lars-Erik Jonsson (LU/EAB); Karl Norrman; Karl Norrman (KI/EAB) Subject: Re: Outer IP-ID field Hi, comments inlined. Vicknesan Ayadurai wrote: > Hi LE, > > I vaguely recall having a discussion during one of the interops where > the meaning of "Identity" and "IP-ID" was clarified, and documented in > the implementers guide (which I now can't find on the ROHC IETF page). > > I think "Identity" was meant to be the entire (verbatim) 16-bits of IP > ID field, as transmitted in an IRDYN for e.g., while "IP-ID" is meant > to be the bits of an *encoded* IP-ID field (IP-ID - SN). > > Hence, my question below was what happens when a UO-1-ID packet is > generated for the situation where: > > >>IPv4(RND=0)/IPv6/UDP/RTP : The IP-ID field corresponds to the outer >>header. > > > i.e., what are the IP-ID bits in the UO-1-ID packets? > > More generally, I understand the ID-bits in a UO-1-ID packet to always > be the *encoded* IP-ID bits. What is the encoding process when the > tunnel header has an IP-ID field, but the inner IP header has no IP-ID > field (IPv6 or RND IP-ID for e.g.)? > Isn't it simply so that if we don't send the IP-ID uncompressed (all 16 bits), then we always send it offset-IPID-encoded, even if it is the outer header. Sure, we might not have AS strong a correlation to SN, so we'll have to send more bits, but we'll probably still be sending less than 16 bits. And there's always the choice for the compressor to set RND2 in this case, if the offset encoding isn't good enough. With ROHC, everything and then some is possible, even the most silly things, like sending ext3 on a UO-1-ID packet ;) /Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon May 17 17:50:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04530 for ; Mon, 17 May 2004 17:50:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpmH-00052G-Kk for rohc-archive@odin.ietf.org; Mon, 17 May 2004 17:36:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLa52D019350 for rohc-archive@odin.ietf.org; Mon, 17 May 2004 17:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpRG-0001BK-00 for rohc-web-archive@optimus.ietf.org; Mon, 17 May 2004 17:14: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 RAA28854 for ; Mon, 17 May 2004 17:14:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPpRD-00060c-PH for rohc-web-archive@ietf.org; Mon, 17 May 2004 17:14:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPpMx-0004kd-00 for rohc-web-archive@ietf.org; Mon, 17 May 2004 17:09:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPpIK-0003Oc-00 for rohc-web-archive@ietf.org; Mon, 17 May 2004 17:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoFY-0002rY-LG; Mon, 17 May 2004 15:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo48-00063T-Qv for rohc@optimus.ietf.org; Mon, 17 May 2004 15:46:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19340; Mon, 17 May 2004 15:46:22 -0400 (EDT) Message-Id: <200405171946.PAA19340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 17 May 2004 15:46:22 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-udp-lite-03.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC):Profiles for UDP-Lite Author(s) : G. Pelletier Filename : draft-ietf-rohc-udp-lite-03.txt Pages : 22 Date : 2004-5-17 This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in RFC 3095 [2] for UDP [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-udp-lite-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-udp-lite-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-17155956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-udp-lite-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-udp-lite-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155956.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 18 07:34:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06198 for ; Tue, 18 May 2004 07:34: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 1BQ2pv-0005rf-Ub for rohc-archive@odin.ietf.org; Tue, 18 May 2004 07:32:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBWh7G022544 for rohc-archive@odin.ietf.org; Tue, 18 May 2004 07:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2l5-0004YR-R6 for rohc-web-archive@optimus.ietf.org; Tue, 18 May 2004 07:27: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 HAA05482 for ; Tue, 18 May 2004 07:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ2l5-0001Lr-6H for rohc-web-archive@ietf.org; Tue, 18 May 2004 07:27:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2j6-0000U6-00 for rohc-web-archive@ietf.org; Tue, 18 May 2004 07:25:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2hs-0007m7-00 for rohc-web-archive@ietf.org; Tue, 18 May 2004 07:24:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2Wp-0008Hq-Ff; Tue, 18 May 2004 07:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2JJ-0004mI-Lz for rohc@optimus.ietf.org; Tue, 18 May 2004 06:59: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 GAA03116 for ; Tue, 18 May 2004 06:58: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 1BQ2JF-0004vT-Do for rohc@ietf.org; Tue, 18 May 2004 06:58:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2IQ-0004XI-00 for rohc@ietf.org; Tue, 18 May 2004 06:58:07 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2Hf-00049L-00 for rohc@ietf.org; Tue, 18 May 2004 06:57:19 -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 i4IAvDPA003155 for ; Tue, 18 May 2004 12:57:14 +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); Tue, 18 May 2004 12:57:13 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 May 2004 12:57:12 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: rohc@ietf.org Date: Tue, 18 May 2004 12:55: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: 18 May 2004 10:57:13.0571 (UTC) FILETIME=[E030EB30:01C43CC6] Subject: [rohc] RE: I-D ACTION:draft-ietf-rohc-udp-lite-03.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , 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 RoHCers, An updated version of the draft describing the ROHC profiles for UDP-Lite, , has been submitted. The draft is now available at: http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-03.txt Changes based on previous discussions are included. In particular, the following has been updated: - Shorter abstract - "Coverage Extension" (CE) changed to "Checksum Coverage Extension" (CCE) - Clarification on precedence of field(CC) matching packet length over matching context(CC) see http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02212.html - Harmonization with the IP-only profile: - Additional mode transition logic (section 5.6) - Constant IP-ID see http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02202.html - Updated IANA Considerations section - The draft follows the updated template for IETF drafts - Other editorial changes (NiTS, updated references, etc.) see http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02207.html Please comment on these changes and the updated version in general. Regards, /Ghyslain -----Original Message----- From: i-d-announce-admin@ietf.org [mailto:i-d-announce-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: den 17 maj 2004 21:46 To: i-d-announce@ietf.org Cc: rohc@ietf.org Subject: I-D ACTION:draft-ietf-rohc-udp-lite-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC):Profiles for UDP-Lite Author(s) : G. Pelletier Filename : draft-ietf-rohc-udp-lite-03.txt Pages : 22 Date : 2004-5-17 This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in RFC 3095 [2] for UDP [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-udp-lite-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-udp-lite-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue May 18 07:34:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06309 for ; Tue, 18 May 2004 07:34: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 1BQ2py-0005uL-UX for rohc-archive@odin.ietf.org; Tue, 18 May 2004 07:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBWkk1022701 for rohc-archive@odin.ietf.org; Tue, 18 May 2004 07:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2ly-0004c0-WD for rohc-web-archive@optimus.ietf.org; Tue, 18 May 2004 07:28: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 HAA05613 for ; Tue, 18 May 2004 07:28: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 1BQ2ly-0001YD-EG for rohc-web-archive@ietf.org; Tue, 18 May 2004 07:28:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2k1-0000wy-00 for rohc-web-archive@ietf.org; Tue, 18 May 2004 07:26:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2iR-0000Jn-00 for rohc-web-archive@ietf.org; Tue, 18 May 2004 07:24:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2Wt-0008Ik-0h; Tue, 18 May 2004 07:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ2NB-0005W4-9w for rohc@optimus.ietf.org; Tue, 18 May 2004 07:03: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 HAA03404 for ; Tue, 18 May 2004 07:02: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 1BQ2N7-0006ai-1v for rohc@ietf.org; Tue, 18 May 2004 07:02:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ2MF-0006BR-00 for rohc@ietf.org; Tue, 18 May 2004 07:02:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2LU-0005ln-00 for rohc@ietf.org; Tue, 18 May 2004 07:01:16 -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 i4IB1HWR009749 for ; Tue, 18 May 2004 13:01:17 +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); Tue, 18 May 2004 13:01:17 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 18 May 2004 13:01:16 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "Carsten Bormann (E-mail)" Cc: "'rohc@ietf.org'" Date: Tue, 18 May 2004 12:59:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 18 May 2004 11:01:17.0098 (UTC) FILETIME=[715830A0:01C43CC7] Content-Transfer-Encoding: quoted-printable Subject: [rohc] WG Last-Call for the profiles for UDP-Lite? 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 Carsten, Lars-Erik, An updated version of the draft describing the ROHC profiles for = UDP-Lite, is now available at: http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-03.txt Since this draft has been around and stable for quite a long time now, = I'd like to make the request to the wg chairs to issue a working group = last call on this version. Thanks. 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.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu May 20 12:13:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28612 for ; Thu, 20 May 2004 12:13:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpv1-00048k-1e for rohc-archive@odin.ietf.org; Thu, 20 May 2004 11:57:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KFvFUD015914 for rohc-archive@odin.ietf.org; Thu, 20 May 2004 11:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpeC-0006fN-DY for rohc-web-archive@optimus.ietf.org; Thu, 20 May 2004 11:39: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 LAA25008 for ; Thu, 20 May 2004 11:39:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpeB-0005aW-CZ for rohc-web-archive@ietf.org; Thu, 20 May 2004 11:39:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpdA-0005Tc-00 for rohc-web-archive@ietf.org; Thu, 20 May 2004 11:38:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQpcJ-0005NZ-00 for rohc-web-archive@ietf.org; Thu, 20 May 2004 11:37:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp6e-0004TB-JL; Thu, 20 May 2004 11:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQnRe-0006D9-Gv for rohc@optimus.ietf.org; Thu, 20 May 2004 09:18: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 JAA15986 for ; Thu, 20 May 2004 09:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQnRc-0006iW-Dx for rohc@ietf.org; Thu, 20 May 2004 09:18:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQnQY-0006TJ-00 for rohc@ietf.org; Thu, 20 May 2004 09:17:39 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BQnPW-00065q-00 for rohc@ietf.org; Thu, 20 May 2004 09:16:34 -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 <0HY0006HQKSUB2@mta0.huawei.com> for rohc@ietf.org; Thu, 20 May 2004 21:14:55 +0800 (CST) Date: Thu, 20 May 2004 18:47:20 +0530 From: suman To: rohc@ietf.org Cc: "Lajos Zaccomer (IJ/ETH)" Message-id: <000e01c43e6c$c8626c20$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 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:51.88000 C:22 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) References: Content-Transfer-Encoding: 7BIT Subject: [rohc] Use of UDVM registers 6 to 9 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 Section 7.2 of rfc 3320 describes the format of the first 32 bytes in UDVM memory. " Addresses 6 to 9 are initialized to the length of the partial state identifier, followed by the state_length from the retrieved state item. " Does it mean that the state_length will be updated with the state_length of the state item for which a STATE-ACCESS/STATE-CREATE instruction is executed ? Just rephrasing the above statement with an example.. if a STATE-CREATE instruction is executed for a state-item whose state-length is 300 bytes, will the value of registers, 8-9 in UDVM be loaded with 300. Will this be done by state handler ?? Please confirm, thanks suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu May 20 13:19:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03801 for ; Thu, 20 May 2004 13:19: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 1BQr7L-0006sW-9b for rohc-archive@odin.ietf.org; Thu, 20 May 2004 13:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KHE3wM026438 for rohc-archive@odin.ietf.org; Thu, 20 May 2004 13:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqq3-0001yv-Qp for rohc-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:56: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 MAA01884 for ; Thu, 20 May 2004 12:56:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqq2-0005zB-2n for rohc-web-archive@ietf.org; Thu, 20 May 2004 12:56:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqp8-0005sb-00 for rohc-web-archive@ietf.org; Thu, 20 May 2004 12:55:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqoG-0005mH-00 for rohc-web-archive@ietf.org; Thu, 20 May 2004 12:54:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqZS-0003Qe-Lj; Thu, 20 May 2004 12: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 1BQqQf-0007pC-G0 for rohc@optimus.ietf.org; Thu, 20 May 2004 12: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 MAA29580 for ; Thu, 20 May 2004 12:29:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqQd-0003Nh-SE for rohc@ietf.org; Thu, 20 May 2004 12:29:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqPm-0003KP-00 for rohc@ietf.org; Thu, 20 May 2004 12:29:03 -0400 Received: from bay12-f3.bay12.hotmail.com ([64.4.35.3] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BQqPD-0003F0-00 for rohc@ietf.org; Thu, 20 May 2004 12:28:27 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 May 2004 09:27:56 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Thu, 20 May 2004 16:27:55 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 Cc: lajos.zaccomer@ericsson.com Subject: RE: [rohc] Use of UDVM registers 6 to 9 Date: Thu, 20 May 2004 17:27:55 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 May 2004 16:27:56.0146 (UTC) FILETIME=[681D1520:01C43E87] 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, The first 32 bytes are only set at UDVM startup; there is no special significance to this memory area afterwards. This means that the UDVM bytecode is free to use these locations for any other purpose a memory location might be used for; it just has to be aware they are not necessarily initialized to zero. Regards, Richard >From: suman >To: rohc@ietf.org >CC: "Lajos Zaccomer (IJ/ETH)" >Subject: [rohc] Use of UDVM registers 6 to 9 >Date: Thu, 20 May 2004 18:47:20 +0530 > >Section 7.2 of rfc 3320 describes the format of the first 32 bytes in UDVM >memory. > >" Addresses 6 to 9 are initialized to the length of the partial state > identifier, followed by the state_length from the retrieved state > item. " > >Does it mean that the state_length will be updated with the state_length of >the >state item for which a STATE-ACCESS/STATE-CREATE instruction is executed ? > >Just rephrasing the above statement with an example.. > >if a STATE-CREATE instruction is executed for a state-item whose >state-length is 300 bytes, >will the value of registers, 8-9 in UDVM be loaded with 300. Will this be >done by state handler ?? > >Please confirm, > >thanks >suman > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu May 20 13:20:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03848 for ; Thu, 20 May 2004 13: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 1BQr7T-0006wB-AH for rohc-archive@odin.ietf.org; Thu, 20 May 2004 13:14:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KHEBBc026663 for rohc-archive@odin.ietf.org; Thu, 20 May 2004 13:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqrn-0002Ia-F2 for rohc-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:57: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 MAA02046 for ; Thu, 20 May 2004 12:57: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 1BQqrl-0006BH-Po for rohc-web-archive@ietf.org; Thu, 20 May 2004 12:57:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqqs-000667-00 for rohc-web-archive@ietf.org; Thu, 20 May 2004 12:57:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqq4-0005zg-00 for rohc-web-archive@ietf.org; Thu, 20 May 2004 12:56:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqmz-0006iV-3K; Thu, 20 May 2004 12:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqXQ-0002dW-G2 for rohc@optimus.ietf.org; Thu, 20 May 2004 12:36: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 MAA00169 for ; Thu, 20 May 2004 12:36:52 -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 1BQqXO-00043D-SO for rohc@ietf.org; Thu, 20 May 2004 12:36:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqWQ-0003xI-00 for rohc@ietf.org; Thu, 20 May 2004 12:35:55 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BQqVl-0003ta-00 for rohc@ietf.org; Thu, 20 May 2004 12:35:13 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4KGZ7F01042 for ; Thu, 20 May 2004 19:35:07 +0300 (EET DST) X-Scanned: Thu, 20 May 2004 19:34:57 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4KGYvHl013545 for ; Thu, 20 May 2004 19:34:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001a6bFr; Thu, 20 May 2004 19:34:55 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 i4KGYsH14101 for ; Thu, 20 May 2004 19:34:55 +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, 20 May 2004 11:34:25 -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] Re: multiplexing SigComp and non-SigComp messages on the same TCP connection Date: Thu, 20 May 2004 12:34:24 -0400 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B81537BC@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcP1jQkqHIE4zJgnT7iq5OAueLWdxwBs1r+wEdCEAnA= To: X-OriginalArrivalTime: 20 May 2004 16:34:25.0070 (UTC) FILETIME=[4FEE2CE0:01C43E88] 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 Hello, The discussions on this topic have been idle for a while (I myself have been busy with other things). Let's see if we can progress to a=20 conclusion.=20 Below summarizes a few key points in my mind. Comments are welcome. With the "SigComp encapsulation with NULL compression" (I coded this term for convenience) described by Carsten and Mark, loss of state synchronization can be handled already without multiplexing. So, to me this doesn't look a strong argument for multiplexing. The multiplexing seems to be needed in the following case: - An endpoint A starts SIP message exchange with another endpoint B=20 over a TCP connection. Since A does not know if B supports SigComp,=20 it sends "plain" (i.e. non-SigComp) SIP messages. - B indicates its support of SigComp following RFC 3486. - If multiplexing is supported, A can start sending SigComp messages on the same TCP connection right away. Without multiplexing, A has to open a new TCP connection, which means extra delay due to 3-way TCP handshake and probably delay due to IPsec as well. Another argument that has been raised to have multiplexing is the 64KB size limit on SigComp messages. However, the counter argument could be that a large SIP message can be encapsulated into multiple SigComp messages, each of which is smaller than 64KB. RFC 3320 does not specify 1:1 mapping from SIP message to SigComp message for stream based transport. So, this should be possible. However, the=20 fragmentation might have security implications. I.e., under the=20 security assumption in RFC 3320, can the SIP receiver authenticate=20 fragments of a SIP message? BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri May 21 01:38:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22981 for ; Fri, 21 May 2004 01:38: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 1BR2g7-0002EN-4v for rohc-archive@odin.ietf.org; Fri, 21 May 2004 01:34:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L5YhJa008575 for rohc-archive@odin.ietf.org; Fri, 21 May 2004 01:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2bk-0001RE-Hy for rohc-web-archive@optimus.ietf.org; Fri, 21 May 2004 01:30: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 BAA22726 for ; Fri, 21 May 2004 01:30:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR2bh-0005Fq-JI for rohc-web-archive@ietf.org; Fri, 21 May 2004 01:30:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR2aj-00058L-00 for rohc-web-archive@ietf.org; Fri, 21 May 2004 01:29:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR2Za-0004wA-00 for rohc-web-archive@ietf.org; Fri, 21 May 2004 01:27:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2Tr-0008Kr-5c; Fri, 21 May 2004 01:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR2QA-0007dT-0x for rohc@optimus.ietf.org; Fri, 21 May 2004 01:18: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 BAA22386 for ; Fri, 21 May 2004 01:18: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 1BR2Q6-00040w-Uy for rohc@ietf.org; Fri, 21 May 2004 01:18:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR2PA-0003uy-00 for rohc@ietf.org; Fri, 21 May 2004 01:17:13 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BR2OL-0003kD-00 for rohc@ietf.org; Fri, 21 May 2004 01:16:21 -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 <0HY100MTBTCFCJ@mta2.huawei.com> for rohc@ietf.org; Fri, 21 May 2004 13:17:03 +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 <0HY100LJUTCE56@mta2.huawei.com> for rohc@ietf.org; Fri, 21 May 2004 13:17:03 +0800 (CST) Received: from JAKKIS ([10.18.5.200]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HY1TI900.I0L; Fri, 21 May 2004 13:20:33 +0800 Date: Fri, 21 May 2004 10:51:27 +0530 From: sasidhar Subject: Re: [rohc] Use of UDVM registers 6 to 9 To: Richard Price Cc: rohc@ietf.org Reply-to: sasidhar Message-id: <013101c43ef3$77d9e440$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_/vBIjFDZJaT/mhIaXt1NZQ)" X-Priority: 3 X-MSMail-priority: Normal References: 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,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_/vBIjFDZJaT/mhIaXt1NZQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, If these first 32 bytes of the UDVM are set only at the startup, do they correspond to the bytecode which will be loaded at the UDVM startup? And then what is the use of the partial_state_ID_length and state_length. Please clarify this. with regards, Sasidhar ----- Original Message ----- From: "Richard Price" To: ; Cc: Sent: Thursday, May 20, 2004 9:57 PM Subject: RE: [rohc] Use of UDVM registers 6 to 9 > Hi, > > The first 32 bytes are only set at UDVM startup; there is no > special significance to this memory area afterwards. This > means that the UDVM bytecode is free to use these locations > for any other purpose a memory location might be used for; it > just has to be aware they are not necessarily initialized to zero. > > Regards, > > Richard > > > >From: suman > >To: rohc@ietf.org > >CC: "Lajos Zaccomer (IJ/ETH)" > >Subject: [rohc] Use of UDVM registers 6 to 9 > >Date: Thu, 20 May 2004 18:47:20 +0530 > > > >Section 7.2 of rfc 3320 describes the format of the first 32 bytes in UDVM > >memory. > > > >" Addresses 6 to 9 are initialized to the length of the partial state > > identifier, followed by the state_length from the retrieved state > > item. " > > > >Does it mean that the state_length will be updated with the state_length of > >the > >state item for which a STATE-ACCESS/STATE-CREATE instruction is executed ? > > > >Just rephrasing the above statement with an example.. > > > >if a STATE-CREATE instruction is executed for a state-item whose > >state-length is 300 bytes, > >will the value of registers, 8-9 in UDVM be loaded with 300. Will this be > >done by state handler ?? > > > >Please confirm, > > > >thanks > >suman > > > > > >_______________________________________________ > >Rohc mailing list > >Rohc@ietf.org > >https://www1.ietf.org/mailman/listinfo/rohc > > _________________________________________________________________ > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > http://toolbar.msn.co.uk/ > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc --Boundary_(ID_/vBIjFDZJaT/mhIaXt1NZQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
    If these first 32 bytes of the UDVM are set only at the startup, do they correspond to the bytecode which will be loaded at the UDVM startup? And then what is the use of the partial_state_ID_length and state_length. 
    Please clarify this.
 
with regards,
Sasidhar
 
----- Original Message -----
From: "Richard Price" <ellyptic@hotmail.com>
Sent: Thursday, May 20, 2004 9:57 PM
Subject: RE: [rohc] Use of UDVM registers 6 to 9

> Hi,
>
> The first 32 bytes are only set at UDVM startup; there is no
> special significance to this memory area afterwards.  This
> means that the UDVM bytecode is free to use these locations
> for any other purpose a memory location might be used for; it
> just has to be aware they are not necessarily initialized to zero.
>
> Regards,
>
> Richard
>
>
> >From: suman <sumanc@huawei.com>
> >To: rohc@ietf.org
> >CC: "Lajos Zaccomer (IJ/ETH)" <lajos.zaccomer@ericsson.com>
> >Subject: [rohc] Use of UDVM registers 6 to 9
> >Date: Thu, 20 May 2004 18:47:20 +0530
> >
> >Section 7.2 of rfc 3320 describes the format of the first 32 bytes in UDVM
> >memory.
> >
> >"  Addresses 6 to 9 are initialized to the length of the partial state
> >    identifier, followed by the state_length from the retrieved state
> >    item. "
> >
> >Does it mean that the state_length will be updated with the state_length of
> >the
> >state item for which a STATE-ACCESS/STATE-CREATE instruction is executed ?
> >
> >Just rephrasing the above statement with an example..
> >
> >if a STATE-CREATE instruction is executed for a state-item whose
> >state-length is 300 bytes,
> >will the value of registers, 8-9 in UDVM be loaded with 300. Will this be
> >done by state handler ??
> >
> >Please confirm,
> >
> >thanks
> >suman
> >
> >
> >_______________________________________________
> >Rohc mailing list
> >Rohc@ietf.org
> >https://www1.ietf.org/mailman/listinfo/rohc
>
> _________________________________________________________________
> Want to block unwanted pop-ups? Download the free MSN Toolbar now! 
> http://toolbar.msn.co.uk/
>
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc --Boundary_(ID_/vBIjFDZJaT/mhIaXt1NZQ)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri May 21 08:54: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 IAA28623 for ; Fri, 21 May 2004 08:54: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 1BR9Pm-0004iX-Oj for rohc-archive@odin.ietf.org; Fri, 21 May 2004 08:46:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LCkINM018133 for rohc-archive@odin.ietf.org; Fri, 21 May 2004 08:46:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9LL-0002zB-Gx for rohc-web-archive@optimus.ietf.org; Fri, 21 May 2004 08:41: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 IAA27535 for ; Fri, 21 May 2004 08:41: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 1BR9LK-0001pr-35 for rohc-web-archive@ietf.org; Fri, 21 May 2004 08:41:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9KU-0001dn-00 for rohc-web-archive@ietf.org; Fri, 21 May 2004 08:40:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR9Jj-0001Rf-00 for rohc-web-archive@ietf.org; Fri, 21 May 2004 08:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR94H-0007VZ-4d; Fri, 21 May 2004 08:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7xF-0001Hz-9v for rohc@optimus.ietf.org; Fri, 21 May 2004 07:12: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 HAA24271 for ; Fri, 21 May 2004 07:12: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 1BR7xE-0001NS-Pf for rohc@ietf.org; Fri, 21 May 2004 07:12:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7wJ-0001AG-00 for rohc@ietf.org; Fri, 21 May 2004 07:11:48 -0400 Received: from bay12-f12.bay12.hotmail.com ([64.4.35.12] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BR7vS-0000w6-00 for rohc@ietf.org; Fri, 21 May 2004 07:10:54 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 May 2004 04:10:25 -0700 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Fri, 21 May 2004 11:10:25 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: jakkis@huawei.com Cc: rohc@ietf.org Subject: Re: [rohc] Use of UDVM registers 6 to 9 Date: Fri, 21 May 2004 12:10:25 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 May 2004 11:10:25.0447 (UTC) FILETIME=[376CDB70:01C43F24] 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, Yes, the first 32 bytes of the UDVM memory correspond to the bytecode which will be loaded at the UDVM startup. The partial_state_id_length and the state_length are used in the case where the bytecode is loaded from a state: they are set to the length of the state ID used to access the state, and to the length of the state which is accessed respectively. When the bytecode is uploaded as part of the SigComp message, the partial_state_id_length and the state_length are both initialised to 0. Regards, Richard >From: sasidhar >Reply-To: sasidhar >To: Richard Price >CC: rohc@ietf.org >Subject: Re: [rohc] Use of UDVM registers 6 to 9 >Date: Fri, 21 May 2004 10:51:27 +0530 > >Hi, > If these first 32 bytes of the UDVM are set only at the startup, do >they correspond to the bytecode which will be loaded at the UDVM startup? >And then what is the use of the partial_state_ID_length and state_length. > Please clarify this. > >with regards, >Sasidhar > >----- Original Message ----- >From: "Richard Price" >To: ; >Cc: >Sent: Thursday, May 20, 2004 9:57 PM >Subject: RE: [rohc] Use of UDVM registers 6 to 9 > > > > Hi, > > > > The first 32 bytes are only set at UDVM startup; there is no > > special significance to this memory area afterwards. This > > means that the UDVM bytecode is free to use these locations > > for any other purpose a memory location might be used for; it > > just has to be aware they are not necessarily initialized to zero. > > > > Regards, > > > > Richard > > > > > > >From: suman > > >To: rohc@ietf.org > > >CC: "Lajos Zaccomer (IJ/ETH)" > > >Subject: [rohc] Use of UDVM registers 6 to 9 > > >Date: Thu, 20 May 2004 18:47:20 +0530 > > > > > >Section 7.2 of rfc 3320 describes the format of the first 32 bytes in >UDVM > > >memory. > > > > > >" Addresses 6 to 9 are initialized to the length of the partial state > > > identifier, followed by the state_length from the retrieved state > > > item. " > > > > > >Does it mean that the state_length will be updated with the >state_length of > > >the > > >state item for which a STATE-ACCESS/STATE-CREATE instruction is >executed ? > > > > > >Just rephrasing the above statement with an example.. > > > > > >if a STATE-CREATE instruction is executed for a state-item whose > > >state-length is 300 bytes, > > >will the value of registers, 8-9 in UDVM be loaded with 300. Will this >be > > >done by state handler ?? > > > > > >Please confirm, > > > > > >thanks > > >suman > > > > > > > > >_______________________________________________ > > >Rohc mailing list > > >Rohc@ietf.org > > >https://www1.ietf.org/mailman/listinfo/rohc > > > > _________________________________________________________________ > > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > > http://toolbar.msn.co.uk/ > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri May 21 09:10: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 JAA29422 for ; Fri, 21 May 2004 09:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9ke-0001s0-Sk for rohc-archive@odin.ietf.org; Fri, 21 May 2004 09:07:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LD7qBV007185 for rohc-archive@odin.ietf.org; Fri, 21 May 2004 09:07:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9ba-0007T5-UR for rohc-web-archive@optimus.ietf.org; Fri, 21 May 2004 08:58: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 IAA28855 for ; Fri, 21 May 2004 08:58:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9bZ-0005et-GE for rohc-web-archive@ietf.org; Fri, 21 May 2004 08:58:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9aa-0005SY-00 for rohc-web-archive@ietf.org; Fri, 21 May 2004 08:57:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR9ZY-00058s-00 for rohc-web-archive@ietf.org; Fri, 21 May 2004 08:56:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9QT-00056t-Su; Fri, 21 May 2004 08: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 1BR9DX-00014V-7Y for rohc@optimus.ietf.org; Fri, 21 May 2004 08:33: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 IAA27259 for ; Fri, 21 May 2004 08:33:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9DV-0000LN-S9 for rohc@ietf.org; Fri, 21 May 2004 08:33:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9CW-00009d-00 for rohc@ietf.org; Fri, 21 May 2004 08:32:37 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BR9Bo-0007am-00 for rohc@ietf.org; Fri, 21 May 2004 08:31:53 -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 <0HY2006D5DIE26@mta2.huawei.com> for rohc@ietf.org; Fri, 21 May 2004 20:32:38 +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 <0HY2004YMDID5S@mta2.huawei.com> for rohc@ietf.org; Fri, 21 May 2004 20:32:37 +0800 (CST) Received: from JAKKIS ([10.18.5.200]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HY2DO800.P1I; Fri, 21 May 2004 20:36:08 +0800 Date: Fri, 21 May 2004 18:07:02 +0530 From: sasidhar Subject: Re: [rohc] Use of UDVM registers 6 to 9 To: Richard Price Cc: rohc@ietf.org Reply-to: sasidhar Message-id: <014f01c43f30$51434640$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, As per my understanding, this state_length is to effectively use the UDVM memory, instead of fixing some part of it for the bytecode. So we can start loading the states from the position at which the bytecode ends. This is also useful to decide whether to save the bytecode or not. But as Suman said, it would have been very useful, if the state-length of the accessed state is written at some reserved space in the UDVM. This will avoid the burden of carrying the state-length in every compressed message. with regards, Sasidhar ----- Original Message ----- From: "Richard Price" To: Cc: Sent: Friday, May 21, 2004 4:40 PM Subject: Re: [rohc] Use of UDVM registers 6 to 9 > Hi, > > Yes, the first 32 bytes of the UDVM memory correspond to the bytecode > which will be loaded at the UDVM startup. The partial_state_id_length > and the state_length are used in the case where the bytecode is > loaded from a state: they are set to the length of the state ID used > to access the state, and to the length of the state which is accessed > respectively. > > When the bytecode is uploaded as part of the SigComp message, > the partial_state_id_length and the state_length are both initialised > to 0. > > Regards, > > Richard > > > >From: sasidhar > >Reply-To: sasidhar > >To: Richard Price > >CC: rohc@ietf.org > >Subject: Re: [rohc] Use of UDVM registers 6 to 9 > >Date: Fri, 21 May 2004 10:51:27 +0530 > > > >Hi, > > If these first 32 bytes of the UDVM are set only at the startup, do > >they correspond to the bytecode which will be loaded at the UDVM startup? > >And then what is the use of the partial_state_ID_length and state_length. > > Please clarify this. > > > >with regards, > >Sasidhar > > > >----- Original Message ----- > >From: "Richard Price" > >To: ; > >Cc: > >Sent: Thursday, May 20, 2004 9:57 PM > >Subject: RE: [rohc] Use of UDVM registers 6 to 9 > > > > > > > Hi, > > > > > > The first 32 bytes are only set at UDVM startup; there is no > > > special significance to this memory area afterwards. This > > > means that the UDVM bytecode is free to use these locations > > > for any other purpose a memory location might be used for; it > > > just has to be aware they are not necessarily initialized to zero. > > > > > > Regards, > > > > > > Richard > > > > > > > > > >From: suman > > > >To: rohc@ietf.org > > > >CC: "Lajos Zaccomer (IJ/ETH)" > > > >Subject: [rohc] Use of UDVM registers 6 to 9 > > > >Date: Thu, 20 May 2004 18:47:20 +0530 > > > > > > > >Section 7.2 of rfc 3320 describes the format of the first 32 bytes in > >UDVM > > > >memory. > > > > > > > >" Addresses 6 to 9 are initialized to the length of the partial state > > > > identifier, followed by the state_length from the retrieved state > > > > item. " > > > > > > > >Does it mean that the state_length will be updated with the > >state_length of > > > >the > > > >state item for which a STATE-ACCESS/STATE-CREATE instruction is > >executed ? > > > > > > > >Just rephrasing the above statement with an example.. > > > > > > > >if a STATE-CREATE instruction is executed for a state-item whose > > > >state-length is 300 bytes, > > > >will the value of registers, 8-9 in UDVM be loaded with 300. Will this > >be > > > >done by state handler ?? > > > > > > > >Please confirm, > > > > > > > >thanks > > > >suman > > > > > > > > > > > >_______________________________________________ > > > >Rohc mailing list > > > >Rohc@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/rohc > > > > > > _________________________________________________________________ > > > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > > > http://toolbar.msn.co.uk/ > > > > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > _________________________________________________________________ > Get a FREE connection, FREE modem and one month's FREE line rental, plus a > US or European flight when you sign up for BT Broadband! > http://www.msn.co.uk/specials/btbroadband > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun May 23 04:19:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04850 for ; Sun, 23 May 2004 04:19: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 1BRoAw-00027b-Jc for rohc-archive@odin.ietf.org; Sun, 23 May 2004 04:17:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4N8HgQ6008156 for rohc-archive@odin.ietf.org; Sun, 23 May 2004 04:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRo8W-0001gz-4n for rohc-web-archive@optimus.ietf.org; Sun, 23 May 2004 04:15: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 EAA04787 for ; Sun, 23 May 2004 04:15: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 1BRo8T-0006fr-B8 for rohc-web-archive@ietf.org; Sun, 23 May 2004 04:15:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRo7X-0006RL-00 for rohc-web-archive@ietf.org; Sun, 23 May 2004 04:14:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRo6y-0006Cd-00 for rohc-web-archive@ietf.org; Sun, 23 May 2004 04:13:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRo4U-0000tX-5v; Sun, 23 May 2004 04:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRo3f-0000i9-Qi for rohc@optimus.ietf.org; Sun, 23 May 2004 04:10: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 EAA04496 for ; Sun, 23 May 2004 04:10: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 1BRo3d-0005OA-5e for rohc@ietf.org; Sun, 23 May 2004 04:10:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRo2j-00058k-00 for rohc@ietf.org; Sun, 23 May 2004 04:09:14 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BRo21-0004ew-00 for rohc@ietf.org; Sun, 23 May 2004 04:08:30 -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 <0HY5002JAQJI2L@mta0.huawei.com> for rohc@ietf.org; Sun, 23 May 2004 16:06:56 +0800 (CST) Date: Sun, 23 May 2004 13:39:19 +0530 From: suman To: rohc@ietf.org Message-id: <000501c4409d$4054d100$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 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:30.79987 C:22 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) References: <014f01c43f30$51434640$c805120a@in.huawei.com> Content-Transfer-Encoding: 7BIT Subject: [rohc] Memory management in state handle 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, the rules specified in 3320 for memory management in state handler seems a bit confusing to me.. Consider a scenario where a compartment has an allocated sms of 2048 bytes. Currently there are 3 states with the following sizes. state 1: (length -256 bytes), (state retention priority 65535) state 2: (length -512 bytes), (state retention priority 1) state 3: (length -512 bytes), (state retention priority 4) Now if a new state create request is received whose length is 1536 bytes, and its state retention priority is 3, what is the expected result ?? case1: Delete the states with priority 65535, 1, 2, and 4 to accomodate the new state. case 2: Delete only the states with priority 65535, 1 and 2 and check if the memory accomodates the new state creation request. if so, accept the STATE-CREATE request, else reject it. which of the above two is the correct answer ?? please confirm, thanks suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun May 23 07:13: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 HAA11319 for ; Sun, 23 May 2004 07:13: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 1BRqs4-0002az-3C for rohc-archive@odin.ietf.org; Sun, 23 May 2004 07:10:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4NBAOQq009977 for rohc-archive@odin.ietf.org; Sun, 23 May 2004 07:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRqq2-00029B-HF for rohc-web-archive@optimus.ietf.org; Sun, 23 May 2004 07:08: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 HAA10964 for ; Sun, 23 May 2004 07:08:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRqpy-0004Pe-7Y for rohc-web-archive@ietf.org; Sun, 23 May 2004 07:08:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRqp0-0004A3-00 for rohc-web-archive@ietf.org; Sun, 23 May 2004 07:07:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRqoQ-0003uf-00 for rohc-web-archive@ietf.org; Sun, 23 May 2004 07:06:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRqjy-0000ky-F4; Sun, 23 May 2004 07:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRqhY-0000N2-8P for rohc@optimus.ietf.org; Sun, 23 May 2004 06:59:32 -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 GAA10474 for ; Sun, 23 May 2004 06:59: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 1BRqhU-0001vb-2Z for rohc@ietf.org; Sun, 23 May 2004 06:59:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRqfL-0001RQ-00 for rohc@ietf.org; Sun, 23 May 2004 06:57:15 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BRqf5-0001Cf-00 for rohc@ietf.org; Sun, 23 May 2004 06:56:59 -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 <0HY500493YC3YJ@mta0.huawei.com> for rohc@ietf.org; Sun, 23 May 2004 18:55:16 +0800 (CST) Date: Sun, 23 May 2004 16:27:40 +0530 From: suman To: rohc@ietf.org Message-id: <009501c440b4$c4e995b0$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 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:62.48376 C:22 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) References: <014f01c43f30$51434640$c805120a@in.huawei.com> <000501c4409d$4054d100$6d05120a@sumanccl20088> Content-Transfer-Encoding: 7BIT Subject: [rohc] Memory management in state handle 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, There was some documentation error in my previous mail. I am sending it again ... the rules specified in 3320 for memory management in state handler seems a bit confusing to me.. Consider a scenario where a compartment has an allocated sms of 2048 bytes. Currently there are 3 states created by remote endpoint with the following sizes. state 1: (length -256 bytes), (state retention priority 65535) state 2: (length -512 bytes), (state retention priority 1) state 3: (length -512 bytes), (state retention priority 4) Now if a new state create request is received whose length is 1536 bytes, and its state retention priority is 3, what is the expected result ?? case1: Delete the states with priority 65535, 1 and 4 to accomodate the new state with retention priority 3. case 2: Delete only the states with priority 65535 and 1 and check if the remaining memory accomodates the new state creation request. if so, accept the STATE-CREATE request, else reject it. which of the above two is the correct answer ?? if case 1, is the correct answer, does it mean that a new state creation request with higher statelength can replace all existing states although its retention priority is less than those of the existing states. if case 2, is the correct answer, does it mean that a new state creation request will be accomodated only by replacing only the states of lower retention priority ...the existing states with higher retention priority will be left untouched.. please confirm, thanks suman _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon May 24 01:57:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29601 for ; Mon, 24 May 2004 01:57:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8HH-0003Od-35 for rohc-archive@odin.ietf.org; Mon, 24 May 2004 01:45:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O5jZ3t013055 for rohc-archive@odin.ietf.org; Mon, 24 May 2004 01:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8B0-0002be-FA for rohc-web-archive@optimus.ietf.org; Mon, 24 May 2004 01:39: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 BAA28920 for ; Mon, 24 May 2004 01:39: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 1BS8Ax-00042X-8w for rohc-web-archive@ietf.org; Mon, 24 May 2004 01:39:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8A2-0003m8-00 for rohc-web-archive@ietf.org; Mon, 24 May 2004 01:38:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS898-0003Vs-00 for rohc-web-archive@ietf.org; Mon, 24 May 2004 01:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS857-0001MF-Cd; Mon, 24 May 2004 01: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 1BS7sZ-0008L2-SH for rohc@optimus.ietf.org; Mon, 24 May 2004 01:20: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 BAA28160 for ; Mon, 24 May 2004 01:20: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 1BS7sW-0006WF-Ta for rohc@ietf.org; Mon, 24 May 2004 01:20:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS7rd-0006FX-00 for rohc@ietf.org; Mon, 24 May 2004 01:19:05 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BS7qJ-0005i8-00 for rohc@ietf.org; Mon, 24 May 2004 01:17:55 -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 <0HY700H2LDF1JX@mta2.huawei.com> for rohc@ietf.org; Mon, 24 May 2004 13:18:37 +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 <0HY700BXQDEZW6@mta2.huawei.com> for rohc@ietf.org; Mon, 24 May 2004 13:18:37 +0800 (CST) Received: from JAKKIS ([10.18.5.200]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HY7DKU01.90H for ; Mon, 24 May 2004 13:22:06 +0800 Date: Mon, 24 May 2004 10:53:02 +0530 From: sasidhar To: rohc@ietf.org Reply-to: sasidhar Message-id: <001601c4414f$2f5d9320$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_DYCKKRDA83MnI1gLzBeuSg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] Shared 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.4 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_DYCKKRDA83MnI1gLzBeuSg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, The following statement is from RFC 3321. "Note that new shared state items must not be created unless the compressor has made enough state memory available (as decompression failure could occur if the shared state pushed existing state out of the state memory buffer)." Does it mean that an endpoint cannot even delete an existing shared state which has already been used once by the peer endpoint? Please clarify this. with regards, Sasidhar --Boundary_(ID_DYCKKRDA83MnI1gLzBeuSg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
    The following statement is from RFC 3321.
 
"Note that new shared state items must not be created unless the compressor has made enough state memory available (as decompression failure could occur if the shared state pushed existing state out of the state memory buffer)."
 
Does it mean that an endpoint cannot even delete an existing shared state which has already been used once by the peer endpoint?
 
Please clarify this.
 
with regards,
Sasidhar
--Boundary_(ID_DYCKKRDA83MnI1gLzBeuSg)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon May 24 02:28:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14516 for ; Mon, 24 May 2004 02:27: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 1BS8rp-0001CV-4d for rohc-archive@odin.ietf.org; Mon, 24 May 2004 02:23:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O6NLEd004616 for rohc-archive@odin.ietf.org; Mon, 24 May 2004 02:23:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8qd-0000vv-8d for rohc-web-archive@optimus.ietf.org; Mon, 24 May 2004 02:22:07 -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 CAA14025 for ; Mon, 24 May 2004 02:22: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 1BS8qZ-0000I9-BQ for rohc-web-archive@ietf.org; Mon, 24 May 2004 02:22:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8pc-0007nj-00 for rohc-web-archive@ietf.org; Mon, 24 May 2004 02:21:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS8p7-0007Xk-00 for rohc-web-archive@ietf.org; Mon, 24 May 2004 02:20:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8gw-0007IK-Kb; Mon, 24 May 2004 02:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8aA-0005Rz-T2 for rohc@optimus.ietf.org; Mon, 24 May 2004 02:05: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 CAA05121 for ; Mon, 24 May 2004 02:05: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 1BS8a7-0003Vv-D2 for rohc@ietf.org; Mon, 24 May 2004 02:05:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8ZA-0003Cz-00 for rohc@ietf.org; Mon, 24 May 2004 02:04:05 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BS8YB-0002uA-00 for rohc@ietf.org; Mon, 24 May 2004 02:03:04 -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 i4O634PA023745 for ; Mon, 24 May 2004 08:03:04 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 08:03:04 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 08:03:04 +0200 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'suman'" Cc: rohc@ietf.org Subject: RE: [rohc] Memory management in state handle Date: Mon, 24 May 2004 08:02:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 24 May 2004 06:03:04.0273 (UTC) FILETIME=[C6DE4410:01C44154] 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 Hi Suman, This is what should happen: states in the order of automatic removal: state 1: 256 + 64 = 320 state 2: 512 + 64 = 576 state 3: 512 + 64 = 576 total (1472, free mem: 576) save: 1536 + 64 = 1600 not enough memory, free state 1 -> free mem = 576 + 320 = 896 not enough memory, free state 2 -> free mem = 896 + 576 = 1472 not enough memory, free state 3 (empty SM) -> free mem = 2048 enough memory, save new state In brief, case 1 is right. BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of suman Sent: Sunday, May 23, 2004 10:09 AM To: rohc@ietf.org Subject: [rohc] Memory management in state handle Hi, the rules specified in 3320 for memory management in state handler seems a bit confusing to me.. Consider a scenario where a compartment has an allocated sms of 2048 bytes. Currently there are 3 states with the following sizes. state 1: (length -256 bytes), (state retention priority 65535) state 2: (length -512 bytes), (state retention priority 1) state 3: (length -512 bytes), (state retention priority 4) Now if a new state create request is received whose length is 1536 bytes, and its state retention priority is 3, what is the expected result ?? case1: Delete the states with priority 65535, 1, 2, and 4 to accomodate the new state. case 2: Delete only the states with priority 65535, 1 and 2 and check if the memory accomodates the new state creation request. if so, accept the STATE-CREATE request, else reject it. which of the above two is the correct answer ?? please confirm, 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 May 24 02:39:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15035 for ; Mon, 24 May 2004 02:39: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 1BS8yl-0002IW-UN for rohc-archive@odin.ietf.org; Mon, 24 May 2004 02:30:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O6UVV2008826 for rohc-archive@odin.ietf.org; Mon, 24 May 2004 02:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8vX-0001qP-PL for rohc-web-archive@optimus.ietf.org; Mon, 24 May 2004 02:27: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 CAA14469 for ; Mon, 24 May 2004 02:27:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS8vT-0001nN-II for rohc-web-archive@ietf.org; Mon, 24 May 2004 02:27:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8uS-0001Ur-00 for rohc-web-archive@ietf.org; Mon, 24 May 2004 02:26:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS8tV-0001Cg-00 for rohc-web-archive@ietf.org; Mon, 24 May 2004 02:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8rZ-00015p-OL; Mon, 24 May 2004 02:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8lC-0008GB-67 for rohc@optimus.ietf.org; Mon, 24 May 2004 02:16: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 CAA13494 for ; Mon, 24 May 2004 02:16: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 1BS8l8-0006TW-NQ for rohc@ietf.org; Mon, 24 May 2004 02:16:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8k5-0006Bb-00 for rohc@ietf.org; Mon, 24 May 2004 02:15:22 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BS8i7-0005sq-00 for rohc@ietf.org; Mon, 24 May 2004 02:13:19 -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 i4O6DKPA025436 for ; Mon, 24 May 2004 08:13:20 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 08:13:20 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 08:13:20 +0200 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'sasidhar'" Cc: rohc@ietf.org Subject: RE: [rohc] Shared compression Date: Mon, 24 May 2004 08:13:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44156.33CBB14E" X-OriginalArrivalTime: 24 May 2004 06:13:20.0140 (UTC) FILETIME=[35F41CC0:01C44156] 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,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44156.33CBB14E Content-Type: text/plain; charset="ISO-8859-1" Hi Sasidhar, No, it does not. The statement below means, the compressor may save a shared state only if there is enough memory to store it, without deleting any other (shared or regular) states in the state memory. Thus, you are right only when there is not enough free state memory to save a new shared state. The other compressor is responsible for deleting the useless states. BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of sasidhar Sent: Monday, May 24, 2004 7:23 AM To: rohc@ietf.org Subject: [rohc] Shared compression Hi, The following statement is from RFC 3321. "Note that new shared state items must not be created unless the compressor has made enough state memory available (as decompression failure could occur if the shared state pushed existing state out of the state memory buffer)." Does it mean that an endpoint cannot even delete an existing shared state which has already been used once by the peer endpoint? Please clarify this. with regards, Sasidhar ------_=_NextPart_001_01C44156.33CBB14E Content-Type: text/html; charset="ISO-8859-1"
Hi Sasidhar,
 
No, it does not. The statement below means, the compressor may save a shared state only if there is enough memory to store it, without deleting any other (shared or regular) states in the state memory. Thus, you are right only when there is not enough free state memory to save a new shared state. The other compressor is responsible for deleting the useless states.
 
BR/Zacco
-----Original Message-----
From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of sasidhar
Sent: Monday, May 24, 2004 7:23 AM
To: rohc@ietf.org
Subject: [rohc] Shared compression

Hi,
    The following statement is from RFC 3321.
 
"Note that new shared state items must not be created unless the compressor has made enough state memory available (as decompression failure could occur if the shared state pushed existing state out of the state memory buffer)."
 
Does it mean that an endpoint cannot even delete an existing shared state which has already been used once by the peer endpoint?
 
Please clarify this.
 
with regards,
Sasidhar
------_=_NextPart_001_01C44156.33CBB14E-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc