From exim@www1.ietf.org Fri Feb 6 03:07:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16017 for ; Fri, 6 Feb 2004 03:07:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap10U-0007IW-HZ for rohc-archive@odin.ietf.org; Fri, 06 Feb 2004 03:06:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1686Y0j028046 for rohc-archive@odin.ietf.org; Fri, 6 Feb 2004 03:06:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap10U-0007IG-82 for rohc-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 03:06:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16012 for ; Fri, 6 Feb 2004 03:06:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap10Q-0003Fx-00 for rohc-web-archive@ietf.org; Fri, 06 Feb 2004 03:06:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0zV-0003E7-00 for rohc-web-archive@ietf.org; Fri, 06 Feb 2004 03:05:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0z0-0003C9-00 for rohc-web-archive@ietf.org; Fri, 06 Feb 2004 03:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0z2-0007AJ-9N; Fri, 06 Feb 2004 03:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0yX-00075s-MN for rohc@optimus.ietf.org; Fri, 06 Feb 2004 03:04:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15980 for ; Fri, 6 Feb 2004 03:04:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0yT-0003BP-00 for rohc@ietf.org; Fri, 06 Feb 2004 03:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0xX-00039i-00 for rohc@ietf.org; Fri, 06 Feb 2004 03:03:32 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap0xK-00037w-00 for rohc@ietf.org; Fri, 06 Feb 2004 03:03:18 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i1672bqf001413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Feb 2004 08:02:37 +0100 Message-ID: <40234A2C.9060906@effnet.com> Date: Fri, 06 Feb 2004 09:02:52 +0100 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] ROHC context reuse & mode 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 think I have found an ambiguity in RFC3095 that I would like to have clarified. I will explain the situation with examples. Example 1: A ROHC compressor is running in O-mode on context #1 (say for example IPv4/UDP/RTP, profile 1), when it decides to reuse this this context for a completely different flow (say IPv6/UDP/RTP, profile 1). The compressor will of course have to send an IR packet to the decompressor, but what mode must it set in the IR packet? Do I inherit the mode of the old flow or do I go back to U-mode? RFC3095 Section 4.4.1. "Unidirectional mode -- U-mode" says: Compression with ROHC MUST start in the Unidirectional mode. Does this mean that the compressor starts in U-mode "when the channel is set-up" or "whenever the compressor re-initializes a context"? If I interpret it as the latter, then the decompressor will see an IR with U-mode while being in O-mode, i.e. a mode change occurs without the 3-way handshake. Example 2: The compressor has received the CONTEXT_REINITIALIZATION signal (section 6.3.1), but the channel is kept up and running. Then it seems most likely that compression must start in U-mode since you are supposed to re-establish everything (true?). The decompressor is in O-mode in this example as well. So it seems we cannot completely avoid a situation where the compressor could be forced to send U-mode IRs to an O-mode decompressor. "Bonus questions": * How does this work in profiles 2 & 3 where there is no mode parameter to send in the IR packets? Do I inherit "current mode" or do I inherit "initial mode"? * If I reuse a profile 1 context in R-mode and make it a profile 0 or TCP profile context (these do not have R-mode), what does my compressor send? I cannot inherit "current mode" (R-mode), since it does not exist, and it seems like inheriting "initial mode" for the selected profile would be the only choice here. So, this might seem like a pure implementation choice at first, but I think this needs to be clarified, since the questions posed above seem pretty unclear to me. Regards, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Feb 6 05:12: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 FAA18841 for ; Fri, 6 Feb 2004 05:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2xX-0006Jx-UM for rohc-archive@odin.ietf.org; Fri, 06 Feb 2004 05:11:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16ABdlN024291 for rohc-archive@odin.ietf.org; Fri, 6 Feb 2004 05:11:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2xX-0006Ji-C4 for rohc-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 05:11:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18831 for ; Fri, 6 Feb 2004 05:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2xU-0000wo-00 for rohc-web-archive@ietf.org; Fri, 06 Feb 2004 05:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2wm-0000u9-00 for rohc-web-archive@ietf.org; Fri, 06 Feb 2004 05:10:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2vw-0000r0-00 for rohc-web-archive@ietf.org; Fri, 06 Feb 2004 05:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2vy-0005z1-1R; Fri, 06 Feb 2004 05:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2vd-0005th-41 for rohc@optimus.ietf.org; Fri, 06 Feb 2004 05:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18756 for ; Fri, 6 Feb 2004 05:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2vZ-0000pr-00 for rohc@ietf.org; Fri, 06 Feb 2004 05:09:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2ub-0000n0-00 for rohc@ietf.org; Fri, 06 Feb 2004 05:08:37 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2uN-0000kf-00 for rohc@ietf.org; Fri, 06 Feb 2004 05:08:23 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i16A8NAH001864 for ; Fri, 6 Feb 2004 03:08:24 -0700 (MST) Received: from motorola.com ([163.14.20.17]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i16A44WJ001702; Fri, 6 Feb 2004 04:04:19 -0600 Message-ID: <40236738.8010101@motorola.com> Date: Fri, 06 Feb 2004 18:06:48 +0800 From: Qiaobing Xie 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 WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] LLA-ROHC question Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I wonder how friendly is LLA-ROHC towards RTP packets with a customer defined header extension (i.e., X flag =1). How is this handled? regards, -Qiaobing _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 9 04:05:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07658 for ; Mon, 9 Feb 2004 04:05:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq7Lc-00020u-LB for rohc-archive@odin.ietf.org; Mon, 09 Feb 2004 04:04:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1994uHs007731 for rohc-archive@odin.ietf.org; Mon, 9 Feb 2004 04:04:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq7Lb-00020V-6b for rohc-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 04:04:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07628 for ; Mon, 9 Feb 2004 04:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq7LY-00036L-00 for rohc-web-archive@ietf.org; Mon, 09 Feb 2004 04:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq7Kb-00031M-00 for rohc-web-archive@ietf.org; Mon, 09 Feb 2004 04:03:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq7Jl-0002x7-00 for rohc-web-archive@ietf.org; Mon, 09 Feb 2004 04:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq7Jl-0001qK-Nz; Mon, 09 Feb 2004 04:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq7Jf-0001pv-1j for rohc@optimus.ietf.org; Mon, 09 Feb 2004 04:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07595 for ; Mon, 9 Feb 2004 04:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq7Jc-0002wh-00 for rohc@ietf.org; Mon, 09 Feb 2004 04:02:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq7Ii-0002t2-00 for rohc@ietf.org; Mon, 09 Feb 2004 04:01:57 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Aq7IT-0002oj-00 for rohc@ietf.org; Mon, 09 Feb 2004 04:01:41 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1991eYG007642 for ; Mon, 9 Feb 2004 10:01:41 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 10:01:39 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJPY05B>; Mon, 9 Feb 2004 10:01:40 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Qiaobing Xie'" , ROHC WG Subject: RE: [rohc] LLA-ROHC question Date: Mon, 9 Feb 2004 10:00:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Feb 2004 09:01:39.0567 (UTC) FILETIME=[544E9FF0:01C3EEEB] 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 Qiaobing, I do not know exactly what you mean with friendly, using a non-standard extension is in my opinion not what I would call friendly...=) Anyway, LLA [profile 5] handles Xtensions as ROHC RTP [profile 1], i.e. its presence is indicated in IR's (or extensions to CO) and the X-bit is thus transparently decompressed (as all fields). The extension itself is seen as just another part of the payload data. Rgds, /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Qiaobing Xie > Sent: den 6 februari 2004 11:07 > To: ROHC WG > Subject: [rohc] LLA-ROHC question > > > Hi, > > I wonder how friendly is LLA-ROHC towards RTP packets with a customer > defined header extension (i.e., X flag =1). How is this handled? > > regards, > -Qiaobing > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 10 00:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17270 for ; Tue, 10 Feb 2004 00:27:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQPw-0003hG-Qg for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 00:26:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A5QeGr014204 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 00:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQPw-0003h1-L5 for rohc-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 00:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17259 for ; Tue, 10 Feb 2004 00:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqQPu-00075t-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 00:26:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqQP8-00070B-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 00:25:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqQOL-0006tu-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 00:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQOL-0003W2-OI; Tue, 10 Feb 2004 00:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqQNz-0003VE-RC for rohc@optimus.ietf.org; Tue, 10 Feb 2004 00:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17216 for ; Tue, 10 Feb 2004 00:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqQNx-0006qm-00 for rohc@ietf.org; Tue, 10 Feb 2004 00:24:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqQN4-0006lS-00 for rohc@ietf.org; Tue, 10 Feb 2004 00:23:43 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AqQMN-0006fs-00 for rohc@ietf.org; Tue, 10 Feb 2004 00:22:59 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i1A5MIOq027566; Mon, 9 Feb 2004 22:22:18 -0700 (MST) Received: from motorola.com ([163.14.20.5]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i1A5JqWJ005755; Mon, 9 Feb 2004 23:19:53 -0600 Message-ID: <40286AA1.2090901@motorola.com> Date: Tue, 10 Feb 2004 13:22:41 +0800 From: Qiaobing Xie 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: "Lars-Erik Jonsson (LU/EAB)" CC: ROHC WG Subject: Re: [rohc] LLA-ROHC question References: In-Reply-To: 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Lars-Erik, Thanks. As far as the user-defined RTP extension headers are preserved or restored after the compression-decompression cycle, I consider it's friendly :-) By the way, is the same true for RTCP packets (including app-defined RTCP packets)? regards, -Qiaobing Lars-Erik Jonsson (LU/EAB) wrote: > Qiaobing, > > I do not know exactly what you mean with friendly, using a non-standard > extension is in my opinion not what I would call friendly...=) > > Anyway, LLA [profile 5] handles Xtensions as ROHC RTP [profile 1], i.e. > its presence is indicated in IR's (or extensions to CO) and the X-bit > is thus transparently decompressed (as all fields). The extension > itself is seen as just another part of the payload data. > > Rgds, > /L-E > > > >>-----Original Message----- >>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of >>Qiaobing Xie >>Sent: den 6 februari 2004 11:07 >>To: ROHC WG >>Subject: [rohc] LLA-ROHC question >> >> >>Hi, >> >>I wonder how friendly is LLA-ROHC towards RTP packets with a customer >>defined header extension (i.e., X flag =1). How is this handled? >> >>regards, >>-Qiaobing >> >> >> >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 10 03:20:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05521 for ; Tue, 10 Feb 2004 03:20:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT7M-00066Y-Im for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 03:19:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A8JeDQ023466 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 03:19:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT7L-00066P-UZ for rohc-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 03:19:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05492 for ; Tue, 10 Feb 2004 03:19:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqT7J-0007FV-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 03:19:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqT6M-0007AQ-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 03:18:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqT5l-00075u-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 03:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT5m-00062C-MG; Tue, 10 Feb 2004 03:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT5Q-0005zz-56 for rohc@optimus.ietf.org; Tue, 10 Feb 2004 03:17:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05409 for ; Tue, 10 Feb 2004 03:17:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqT5N-00075J-00 for rohc@ietf.org; Tue, 10 Feb 2004 03:17:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqT4Q-000718-00 for rohc@ietf.org; Tue, 10 Feb 2004 03:16:39 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AqT49-0006ws-00 for rohc@ietf.org; Tue, 10 Feb 2004 03:16:22 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1A8GLqY018448 for ; Tue, 10 Feb 2004 09:16:22 +0100 (MET) 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, 10 Feb 2004 09:16:21 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQD5WX>; Tue, 10 Feb 2004 09:16:21 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Qiaobing Xie'" Cc: ROHC WG Subject: RE: [rohc] LLA-ROHC question Date: Tue, 10 Feb 2004 09:15:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Feb 2004 08:16:21.0718 (UTC) FILETIME=[2AC18760:01C3EFAE] 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 RTCP packet headers can, at most, be compressed up to the UDP header, i.e. with ROHC profile 2. /L-E > By the way, is the same true for RTCP packets (including > app-defined RTCP packets)? > > regards, > -Qiaobing > > Lars-Erik Jonsson (LU/EAB) wrote: > > > Qiaobing, > > > > I do not know exactly what you mean with friendly, using a > non-standard > > extension is in my opinion not what I would call friendly...=) > > > > Anyway, LLA [profile 5] handles Xtensions as ROHC RTP > [profile 1], i.e. > > its presence is indicated in IR's (or extensions to CO) and > the X-bit > > is thus transparently decompressed (as all fields). The extension > > itself is seen as just another part of the payload data. > > > > Rgds, > > /L-E > > > > > > > >>-----Original Message----- > >>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > >>Qiaobing Xie > >>Sent: den 6 februari 2004 11:07 > >>To: ROHC WG > >>Subject: [rohc] LLA-ROHC question > >> > >> > >>Hi, > >> > >>I wonder how friendly is LLA-ROHC towards RTP packets with > a customer > >>defined header extension (i.e., X flag =1). How is this handled? > >> > >>regards, > >>-Qiaobing > >> > >> > >> > >> > >>_______________________________________________ > >>Rohc mailing list > >>Rohc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rohc > >> > > > > > > This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 10 03:22:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05576 for ; Tue, 10 Feb 2004 03:22:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT9I-0006Eb-Uw for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 03:21:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A8LeLF023959 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 03:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT9I-0006EM-N4 for rohc-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 03:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05570 for ; Tue, 10 Feb 2004 03:21:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqT9G-0007PX-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 03:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqT8L-0007LF-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 03:20:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqT7h-0007Ge-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 03:20:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT7i-00067s-Pb; Tue, 10 Feb 2004 03:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT7O-00066s-FF for rohc@optimus.ietf.org; Tue, 10 Feb 2004 03:19:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05509 for ; Tue, 10 Feb 2004 03:19:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqT7M-0007Fp-00 for rohc@ietf.org; Tue, 10 Feb 2004 03:19:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqT6P-0007Aq-00 for rohc@ietf.org; Tue, 10 Feb 2004 03:18:42 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AqT60-000762-00 for rohc@ietf.org; Tue, 10 Feb 2004 03:18:17 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1A8IGYG013602 for ; Tue, 10 Feb 2004 09:18:17 +0100 (MET) 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, 10 Feb 2004 09:18:16 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQD6KX>; Tue, 10 Feb 2004 09:18:16 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Qiaobing Xie'" , "'ROHC WG'" Subject: RE: [rohc] LLA-ROHC question Date: Tue, 10 Feb 2004 09:17:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Feb 2004 08:18:16.0718 (UTC) FILETIME=[6F4D22E0:01C3EFAE] 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 Qiaobing, I do not know exactly what you mean with friendly, using a non-standard extension is in my opinion not what I would call friendly...=) Anyway, LLA [profile 5] handles Xtensions as ROHC RTP [profile 1], i.e. its presence is indicated in IR's (or extensions to CO) and the X-bit is thus transparently decompressed (as all fields). The extension itself is seen as just another part of the payload data. Rgds, /L-E > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of > Qiaobing Xie > Sent: den 6 februari 2004 11:07 > To: ROHC WG > Subject: [rohc] LLA-ROHC question > > > Hi, > > I wonder how friendly is LLA-ROHC towards RTP packets with a customer > defined header extension (i.e., X flag =1). How is this handled? > > regards, > -Qiaobing > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 10 05:39:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10808 for ; Tue, 10 Feb 2004 05:39:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVI0-0008FX-4s for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 05:38:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AAcmiD031707 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 05:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVHz-0008FK-UF for rohc-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 05:38:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10785 for ; Tue, 10 Feb 2004 05:38:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVHw-0006he-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 05:38:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVH6-0006bq-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 05:37:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqVGH-0006VR-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 05:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVGI-0007rw-QQ; Tue, 10 Feb 2004 05:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVGA-0007qz-GL for rohc@optimus.ietf.org; Tue, 10 Feb 2004 05:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10726 for ; Tue, 10 Feb 2004 05:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVG7-0006Tp-00 for rohc@ietf.org; Tue, 10 Feb 2004 05:36:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVFE-0006Nn-00 for rohc@ietf.org; Tue, 10 Feb 2004 05:35:57 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AqVEX-0006HS-00 for rohc@ietf.org; Tue, 10 Feb 2004 05:35:13 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1AAZEAh025897 for ; Tue, 10 Feb 2004 11:35:14 +0100 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, 10 Feb 2004 11:35:14 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQFNMC>; Tue, 10 Feb 2004 11:35:14 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] ROHC context reuse & mode Date: Tue, 10 Feb 2004 11:34:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Feb 2004 10:35:14.0510 (UTC) FILETIME=[917CAEE0:01C3EFC1] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Kristofer, These are good questions, let's see if we can figure out=20 answers to them, it might be necessary to clarify some of these in the implementer's guide. > Example 1: > A ROHC compressor is running in O-mode on context #1 (say for > example IPv4/UDP/RTP, profile 1), when it decides to reuse > this this context for a completely different flow (say > IPv6/UDP/RTP, profile 1). The compressor will of course have > to send an IR packet to the decompressor, but what mode must > it set in the IR packet? Do I inherit the mode of the old > flow or do I go back to U-mode? My spontaneous answer would be, "it's a new stream, and a new context, you must start in U-mode". Does this answer fly? Let's see... > RFC3095 Section 4.4.1. "Unidirectional mode -- U-mode" says: > Compression with ROHC MUST start in the Unidirectional mode. >=20 > Does this mean that the compressor starts in U-mode "when the=20 > channel is set-up" or "whenever the compressor re-initializes > a context"? > If I interpret it as the latter, then the decompressor will=20 > see an IR with U-mode while being in O-mode, i.e. a mode > change occurs without the 3-way handshake. Yes, but this should work when it is initiated by the compressor, right? The 3-way handshake is there in **->U-mode because one must ensure that the compressor will not continue to rely on feedback. =20 > Example 2: > The compressor has received the CONTEXT_REINITIALIZATION=20 > signal (section 6.3.1), but the channel is kept up and > running. Then it seems most likely that compression must > start in U-mode since you are supposed to re-establish=20 > everything (true?). The decompressor is in O-mode in this=20 > example as well. So it seems we cannot completely avoid > a situation where the compressor could be forced to send > U-mode IRs to an O-mode decompressor. True, but that should not be risky, as long as it is done on initiative by the compressor (i.e. the compressor knows it is operating in U-mode), as all U-mode packets have a CRC, errors can thus be avoided and would be resolved. > "Bonus questions": > * How does this work in profiles 2 & 3 where there is > no mode parameter to send in the IR packets? Do I > inherit "current mode" or do I inherit "initial mode"? In the same way, I think it should be "initial mode", but a compressor implementation that does this must of course be very careful ensuring the decompressor will interpret the packets correctly. > * If I reuse a profile 1 context in R-mode and make it a=20 > profile 0 or TCP profile context (these do not have R-mode), > what does my compressor send? I cannot inherit > "current mode" (R-mode), since it does not exist, and it > seems like inheriting "initial mode" for the selected > profile would be the only choice here. Yes! /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 10 07:38:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14075 for ; Tue, 10 Feb 2004 07:38:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX9B-0007Pa-F0 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 07:37:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACbnIY028476 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 07:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX9A-0007PD-TY for rohc-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14061 for ; Tue, 10 Feb 2004 07:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX9A-0001Ie-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 07:37:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqX8D-0001D5-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 07:36:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqX7S-00018e-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 07:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX7R-00074s-J2; Tue, 10 Feb 2004 07:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX7E-00074V-8N for rohc@optimus.ietf.org; Tue, 10 Feb 2004 07:35:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14027 for ; Tue, 10 Feb 2004 07:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX7D-000181-00 for rohc@ietf.org; Tue, 10 Feb 2004 07:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqX6J-00013q-00 for rohc@ietf.org; Tue, 10 Feb 2004 07:34:52 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AqX5t-0000xx-00 for rohc@ietf.org; Tue, 10 Feb 2004 07:34:25 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i1ABXeqf020663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Feb 2004 12:33:40 +0100 Message-ID: <4028CFB6.8050807@effnet.com> Date: Tue, 10 Feb 2004 13:33:58 +0100 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: "Lars-Erik Jonsson (LU/EAB)" CC: rohc@ietf.org Subject: Re: [rohc] ROHC context reuse & mode References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by effnet.com id i1ABXeqf020663 Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi L-E, Thank you for your reply. I agree with you that "initial mode" (U-mode) seems like the best solutio= n. That=20 should probably go into the implementer's guide. >>* How does this work in profiles 2 & 3 where there is >>no mode parameter to send in the IR packets? Do I >>inherit "current mode" or do I inherit "initial mode"? > > > In the same way, I think it should be "initial mode", but > a compressor implementation that does this must of course > be very careful ensuring the decompressor will interpret > the packets correctly. CAN the compressor "ensure that the decompressor will interpret the packe= ts=20 correctly"? As it is currently specified, the decompressor is not forced = to have=20 any kind of detection that this is a new flow. To me it seems like it sho= uld be=20 the responsibility of the decompressor to be able to detect when the flow= has=20 changed. I think we should say in the implementer's guide something like: "The decompressor must be able to detect when an IR packet is used to=20 reinitialize a context with a different flow than the current flow in tha= t=20 context. When such an IR packet is received, the decompressor should star= t in=20 its initial mode if no mode parameter was included in the IR packet. At t= his=20 time, the decompressor may also discard all information stored in the old= context." Exactly how decompressor detects that it is a new flow can be an implemen= tation=20 detail, but it could for example "diff" all the STATIC-DEF fields of the = new IR=20 with the old context to see if it is a new flow. Rgds, Kristofer Sandlund, Effnet AB Lars-Erik Jonsson (LU/EAB) wrote: > Kristofer, >=20 > These are good questions, let's see if we can figure out=20 > answers to them, it might be necessary to clarify some of > these in the implementer's guide. >=20 >=20 >>Example 1: >>A ROHC compressor is running in O-mode on context #1 (say for >>example IPv4/UDP/RTP, profile 1), when it decides to reuse >>this this context for a completely different flow (say >>IPv6/UDP/RTP, profile 1). The compressor will of course have >>to send an IR packet to the decompressor, but what mode must >>it set in the IR packet? Do I inherit the mode of the old >>flow or do I go back to U-mode? >=20 >=20 > My spontaneous answer would be, "it's a new stream, and a new > context, you must start in U-mode". Does this answer fly? > Let's see... >=20 >=20 >>RFC3095 Section 4.4.1. "Unidirectional mode -- U-mode" says: >> Compression with ROHC MUST start in the Unidirectional mode. >> >>Does this mean that the compressor starts in U-mode "when the=20 >>channel is set-up" or "whenever the compressor re-initializes >>a context"? >>If I interpret it as the latter, then the decompressor will=20 >>see an IR with U-mode while being in O-mode, i.e. a mode >>change occurs without the 3-way handshake. >=20 >=20 > Yes, but this should work when it is initiated by the compressor, > right? The 3-way handshake is there in **->U-mode because one > must ensure that the compressor will not continue to rely on > feedback. > =20 >=20 >>Example 2: >>The compressor has received the CONTEXT_REINITIALIZATION=20 >>signal (section 6.3.1), but the channel is kept up and >>running. Then it seems most likely that compression must >>start in U-mode since you are supposed to re-establish=20 >>everything (true?). The decompressor is in O-mode in this=20 >>example as well. So it seems we cannot completely avoid >>a situation where the compressor could be forced to send >>U-mode IRs to an O-mode decompressor. >=20 >=20 > True, but that should not be risky, as long as it is done > on initiative by the compressor (i.e. the compressor knows > it is operating in U-mode), as all U-mode packets have a > CRC, errors can thus be avoided and would be resolved. >=20 >=20 >>"Bonus questions": >>* How does this work in profiles 2 & 3 where there is >>no mode parameter to send in the IR packets? Do I >>inherit "current mode" or do I inherit "initial mode"? >=20 >=20 > In the same way, I think it should be "initial mode", but > a compressor implementation that does this must of course > be very careful ensuring the decompressor will interpret > the packets correctly. >=20 >=20 >>* If I reuse a profile 1 context in R-mode and make it a=20 >>profile 0 or TCP profile context (these do not have R-mode), >>what does my compressor send? I cannot inherit >>"current mode" (R-mode), since it does not exist, and it >>seems like inheriting "initial mode" for the selected >>profile would be the only choice here. >=20 >=20 > Yes! > /L-E >=20 >=20 > ----------------------------------- > Lars-Erik Jonsson, M.Sc > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > Ericsson AB > Box 920, S-971 28 Lule=E5, Sweden > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 920 20 21 07 > Fax: +46 920 20 20 99 > Home: +46 920 999 57 >=20 > My opinions are my personal opinions and should not be considered > as the opinions of my employer, if not explicitly stated. At the > end of this message, my employer might have automatically inserted > a stupid disclaimer. This nonsense is out of my control and should > simply be ignored. >=20 > This communication is confidential and intended solely for the addresse= e(s). Any unauthorized review, use, disclosure or distribution is prohibi= ted. If you believe this message has been sent to you in error, please no= tify the sender by replying to this transmission and delete the message w= ithout disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data corruption, interru= ption, unauthorized amendment, tampering and viruses, and we only send an= d receive e-mails on the basis that we are not liable for any such corrup= tion, interception, amendment, tampering or viruses or any consequences t= hereof. >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 10 15:20:44 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 PAA08488 for ; Tue, 10 Feb 2004 15:20:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeMc-0008LO-5C for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 15:20:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKK9xO032063 for rohc-archive@odin.ietf.org; Tue, 10 Feb 2004 15:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeMb-0008Kf-0a for rohc-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:20:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08393 for ; Tue, 10 Feb 2004 15:20:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeMZ-0003uS-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 15:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeLe-0003lp-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 15:19:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqeKX-0003cK-00 for rohc-web-archive@ietf.org; Tue, 10 Feb 2004 15:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeKX-0007kz-41; Tue, 10 Feb 2004 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeJr-0007YX-QO for rohc@optimus.ietf.org; Tue, 10 Feb 2004 15:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07925 for ; Tue, 10 Feb 2004 15:17:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeJq-0003Tx-00 for rohc@ietf.org; Tue, 10 Feb 2004 15:17:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeIw-0003Ji-00 for rohc@ietf.org; Tue, 10 Feb 2004 15:16:23 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AqeI7-0003Cb-00 for rohc@ietf.org; Tue, 10 Feb 2004 15:15:31 -0500 Received: from [IPv6:::1] (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id i1AKF9lR021450; Tue, 10 Feb 2004 21:15:12 +0100 (MET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Lars-Erik Jonsson (LU/EAB) , Carsten Bormann , "'Kristofer Sandlund'" From: Carsten Bormann Subject: Re: [rohc] ROHC context reuse & mode Date: Tue, 10 Feb 2004 21:15:10 +0100 To: rohc@ietf.org X-Mailer: Apple Mail (2.612) 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 >> RFC3095 Section 4.4.1. "Unidirectional mode -- U-mode" says: >> Compression with ROHC MUST start in the Unidirectional mode. >> >> Does this mean that the compressor starts in U-mode "when the >> channel is set-up" or "whenever the compressor re-initializes >> a context"? I believe the intention has been all the time that initializing a context using an IR packet would start with a clean slate, as if the channel was just created. I.e., this is a new context, even when a CID is being reused. I'm too busy to do the analysis (read: dusting off brain cells) right now: Do we have any case where we need to maintain previous state beyond an IR packet? Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 11 02:40: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 CAA20839 for ; Wed, 11 Feb 2004 02:40:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqoy7-0004fP-DK for rohc-archive@odin.ietf.org; Wed, 11 Feb 2004 02:39:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B7dZxo017938 for rohc-archive@odin.ietf.org; Wed, 11 Feb 2004 02:39:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqoy6-0004fE-Ie for rohc-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 02:39:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20775 for ; Wed, 11 Feb 2004 02:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqoy2-0001vR-00 for rohc-web-archive@ietf.org; Wed, 11 Feb 2004 02:39:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqox5-0001q3-00 for rohc-web-archive@ietf.org; Wed, 11 Feb 2004 02:38:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqowc-0001kj-00 for rohc-web-archive@ietf.org; Wed, 11 Feb 2004 02:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqowe-0004Q1-RG; Wed, 11 Feb 2004 02:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqowB-0004Jv-47 for rohc@optimus.ietf.org; Wed, 11 Feb 2004 02:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20696 for ; Wed, 11 Feb 2004 02:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqow7-0001jY-00 for rohc@ietf.org; Wed, 11 Feb 2004 02:37:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqovE-0001dh-00 for rohc@ietf.org; Wed, 11 Feb 2004 02:36:36 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqoum-0001XK-00 for rohc@ietf.org; Wed, 11 Feb 2004 02:36:08 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i1B6ZKqf023990 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Feb 2004 07:35:26 +0100 Message-ID: <4029DB46.4050603@effnet.com> Date: Wed, 11 Feb 2004 08:35:34 +0100 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: Carsten Bormann CC: rohc@ietf.org, "Lars-Erik Jonsson (LU/EAB)" Subject: Re: [rohc] ROHC context reuse & mode 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 Carsten, Are you saying that every IR packet (regardless of it being for a new flow or not) should flush the ENTIRE decompressor context? One case where some state probably should be kept is for the list compression. Just because an extension header (or CSRC identifier) is not present in the current IR packet does not mean that it's not present in the context and could reappear in a later packet. If I flush the list compression tables every time I get an IR packet, I will have to re-establish every item once again. This does not seem to be very efficient, especially in U-mode where I should periodically refresh the context with IRs. Also, if every IR would mean the same as establishing a new context, wouldn't that mean that all IR:s would need to carry U-mode? (since all compression should start in U-mode). Why then a mode parameter in the profile 1 IR packet? Rgds, Kristofer Sandlund, Effnet AB Carsten Bormann wrote: >>> RFC3095 Section 4.4.1. "Unidirectional mode -- U-mode" says: >>> Compression with ROHC MUST start in the Unidirectional mode. >>> >>> Does this mean that the compressor starts in U-mode "when the >>> channel is set-up" or "whenever the compressor re-initializes >>> a context"? > > > I believe the intention has been all the time that initializing a > context using an IR packet would start with a clean slate, as if the > channel was just created. I.e., this is a new context, even when a CID > is being reused. > > I'm too busy to do the analysis (read: dusting off brain cells) right now: > Do we have any case where we need to maintain previous state beyond an > IR packet? > > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 11 03:56:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22857 for ; Wed, 11 Feb 2004 03:56:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqq9p-0000vc-Ji for rohc-archive@odin.ietf.org; Wed, 11 Feb 2004 03:55:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B8tjpL003566 for rohc-archive@odin.ietf.org; Wed, 11 Feb 2004 03:55:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqq9p-0000vR-1Q for rohc-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 03:55:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22839 for ; Wed, 11 Feb 2004 03:55:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqq9m-00016f-00 for rohc-web-archive@ietf.org; Wed, 11 Feb 2004 03:55:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqq8k-0000yQ-00 for rohc-web-archive@ietf.org; Wed, 11 Feb 2004 03:54:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqq89-0000ri-00 for rohc-web-archive@ietf.org; Wed, 11 Feb 2004 03:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqq89-0000pR-6I; Wed, 11 Feb 2004 03:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqq7g-0000mN-BQ for rohc@optimus.ietf.org; Wed, 11 Feb 2004 03:53:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22760 for ; Wed, 11 Feb 2004 03:53:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqq7d-0000qh-00 for rohc@ietf.org; Wed, 11 Feb 2004 03:53:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqq6p-0000m2-00 for rohc@ietf.org; Wed, 11 Feb 2004 03:52:39 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aqq6U-0000gW-00 for rohc@ietf.org; Wed, 11 Feb 2004 03:52:18 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1B8qIqY008250 for ; Wed, 11 Feb 2004 09:52:18 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Feb 2004 09:52:18 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQSYMB>; Wed, 11 Feb 2004 09:52:18 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kristofer Sandlund'" Cc: rohc@ietf.org Subject: RE: [rohc] ROHC context reuse & mode Date: Wed, 11 Feb 2004 09:51:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 11 Feb 2004 08:52:18.0391 (UTC) FILETIME=[5AA57670:01C3F07C] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Kristofer, > I think we should say in the implementer's guide > something like: > "The decompressor must be able to detect when an > IR packet is used to reinitialize a context with > a different flow than the current flow in that > context. When such an IR packet is received, the > decompressor should start in its initial mode if > no mode parameter was included in the IR packet. > At this time, the decompressor may also discard > all information stored in the old context." This looks ok, I'll add a new section on aspects of "context re-use" and include this text. I think we should also say something about the compressor, like: "When a ROHC compressor runs out of available=20 context identifiers or context memory resources, it can re-use an already established context and re-initialize it with IR for the new packet stream. The context must then be handled as a new context, which means compression must be carried out according to the initial mode of operation (U-mode)." It is probably also useful to spell out what you said in your previous mail.=20 "Exactly how a decompressor detects that a context is being re-initialized for a new flow is an implementation detail, but one possible approach could be to make a "diff" between all the STATIC-DEF fields of the new IR and the old context." /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibite= d. If you believe this message has been sent to you in error, please noti= fy the sender by replying to this transmission and delete the message wit= hout disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and = receive e-mails on the basis that we are not liable for any such corrupti= on, interception, amendment, tampering or viruses or any consequences the= reof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 12 02:41:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12700 for ; Thu, 12 Feb 2004 02:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBT4-0005DU-6x for rohc-archive@odin.ietf.org; Thu, 12 Feb 2004 02:41:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C7f1fI020043 for rohc-archive@odin.ietf.org; Thu, 12 Feb 2004 02:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBT1-0005D8-NS for rohc-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 02:40:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12634 for ; Thu, 12 Feb 2004 02:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBSx-0001RA-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 02:40:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBRz-0001LK-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 02:39:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArBR8-0001FM-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 02:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBR8-0004gw-Lj; Thu, 12 Feb 2004 02:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBQ8-0004Tq-IA for rohc@optimus.ietf.org; Thu, 12 Feb 2004 02:38:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12439 for ; Thu, 12 Feb 2004 02:37:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBQ4-00018J-00 for rohc@ietf.org; Thu, 12 Feb 2004 02:37:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBPA-000127-00 for rohc@ietf.org; Thu, 12 Feb 2004 02:37:01 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1ArBOX-0000wS-00 for rohc@ietf.org; Thu, 12 Feb 2004 02:36:21 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1C7aMAH006541 for ; Thu, 12 Feb 2004 00:36:22 -0700 (MST) Received: from zhk08exr01.mot.com ([10.196.51.11]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i1C7aEsa024195 for ; Thu, 12 Feb 2004 01:36:19 -0600 Received: from motorola.com (she144.cig.mcel.mot.com [200.30.6.144]) by zhk08exr01.mot.com (Motorola/8.11.6) with ESMTP id i1C6Ilv24853; Thu, 12 Feb 2004 00:18:47 -0600 Message-ID: <402B2CF1.8070003@motorola.com> Date: Thu, 12 Feb 2004 15:36:17 +0800 From: Qiaobing Xie 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: "Lars-Erik Jonsson (LU/EAB)" CC: ROHC WG Subject: Re: [rohc] LLA-ROHC question References: In-Reply-To: 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 Lars-Erik, So, in other words, when a RTCP/UDP/IP packet is presented to the compressor, the RTCP portion will be treated as just a general UDP payload and will not be compressed by ROHC or LLA-ROHC? regards, -Qiaobing Lars-Erik Jonsson (LU/EAB) wrote: > RTCP packet headers can, at most, be compressed up to the UDP > header, i.e. with ROHC profile 2. > > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 12 05:27:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17879 for ; Thu, 12 Feb 2004 05:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE3k-000078-Le for rohc-archive@odin.ietf.org; Thu, 12 Feb 2004 05:27:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CAR46b000432 for rohc-archive@odin.ietf.org; Thu, 12 Feb 2004 05:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE3k-00006t-Eu for rohc-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 05:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17850 for ; Thu, 12 Feb 2004 05:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArE3g-0002Dg-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 05:27:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArE2i-00026o-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 05:26:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArE1j-00020f-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 05:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE1l-0008Tq-BS; Thu, 12 Feb 2004 05:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE0r-0008Sb-Qm for rohc@optimus.ietf.org; Thu, 12 Feb 2004 05:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17792 for ; Thu, 12 Feb 2004 05:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArE0o-0001ua-00 for rohc@ietf.org; Thu, 12 Feb 2004 05:24:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArDzo-0001ov-00 for rohc@ietf.org; Thu, 12 Feb 2004 05:23:01 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ArDyp-0001hS-00 for rohc@ietf.org; Thu, 12 Feb 2004 05:21:59 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1CALxqY003976 for ; Thu, 12 Feb 2004 11:21:59 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 11:21:58 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQ9DNL>; Thu, 12 Feb 2004 11:21:57 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Qiaobing Xie'" Cc: ROHC WG Subject: RE: [rohc] LLA-ROHC question Date: Thu, 12 Feb 2004 11:21:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 12 Feb 2004 10:21:58.0109 (UTC) FILETIME=[0B9F08D0:01C3F152] 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 > So, in other words, when a RTCP/UDP/IP packet is presented > to the compressor, the RTCP portion will be treated as just > a general UDP payload and will not be compressed by ROHC > or LLA-ROHC? That is correct. To my knowledge, compression of RTCP has never been seriously considered. /L-E This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 12 06:40:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19611 for ; Thu, 12 Feb 2004 06:40:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFCa-0007qC-S6 for rohc-archive@odin.ietf.org; Thu, 12 Feb 2004 06:40:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CBeGqC030136 for rohc-archive@odin.ietf.org; Thu, 12 Feb 2004 06:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFCa-0007pz-Jx for rohc-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 06:40:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19605 for ; Thu, 12 Feb 2004 06:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArFCW-0000jH-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 06:40:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArFBc-0000dp-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 06:39:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArFBK-0000Xp-00 for rohc-web-archive@ietf.org; Thu, 12 Feb 2004 06:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFBN-0007ky-C2; Thu, 12 Feb 2004 06:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFAX-0007kG-FF for rohc@optimus.ietf.org; Thu, 12 Feb 2004 06:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19554 for ; Thu, 12 Feb 2004 06:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArFAT-0000Vz-00 for rohc@ietf.org; Thu, 12 Feb 2004 06:38:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArF9W-0000R5-00 for rohc@ietf.org; Thu, 12 Feb 2004 06:37:07 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ArF9D-0000MZ-00 for rohc@ietf.org; Thu, 12 Feb 2004 06:36:47 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1CBalqY018074 for ; Thu, 12 Feb 2004 12:36:47 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 12:36:47 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1LJQ9QRH>; Thu, 12 Feb 2004 12:36:47 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Thu, 12 Feb 2004 11:42:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 12 Feb 2004 11:36:47.0419 (UTC) FILETIME=[7F7560B0:01C3F15C] Subject: [rohc] An apology 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 Dear ROHCers, Now the world of lawyers has also taken control over the old Swedish telecom industry, and as a Ericsson employers we will have to live with all the depressing stupidity this brings. The disclaimer inserted at the end of this message is one example, it's out of my control, it's nonsense, and I am sorry for this. Unfortunately, I can not do more than that, for the moment. Please simply ignore it! Cheers, /L-E -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Feb 13 02:11:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24535 for ; Fri, 13 Feb 2004 02:11:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXTY-0002oH-A3 for rohc-archive@odin.ietf.org; Fri, 13 Feb 2004 02:11:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7B0vL010758 for rohc-archive@odin.ietf.org; Fri, 13 Feb 2004 02:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXTX-0002nF-1I for rohc-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 02:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24133 for ; Fri, 13 Feb 2004 02:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXTP-0000Pj-00 for rohc-web-archive@ietf.org; Fri, 13 Feb 2004 02:10:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXSV-0000IY-00 for rohc-web-archive@ietf.org; Fri, 13 Feb 2004 02:09:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArXRX-0000Bv-00 for rohc-web-archive@ietf.org; Fri, 13 Feb 2004 02:08:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXRd-00026N-Uw; Fri, 13 Feb 2004 02:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXRX-00022v-Se for rohc@optimus.ietf.org; Fri, 13 Feb 2004 02:08:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21896 for ; Fri, 13 Feb 2004 02:08:51 -0500 (EST) From: stucyc2@i2r.a-star.edu.sg Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXRQ-0000Aq-00 for rohc@ietf.org; Fri, 13 Feb 2004 02:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXQV-00004n-00 for rohc@ietf.org; Fri, 13 Feb 2004 02:07:52 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1ArXPm-0007nA-00 for rohc@ietf.org; Fri, 13 Feb 2004 02:07:06 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id i1D76q7o013639 for ; Fri, 13 Feb 2004 15:06:52 +0800 (SGT) Received: from i2r.a-star.edu.sg (localhost [127.0.0.1]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HT000KV4H3UBQ@mailhost.lit.org.sg> for rohc@ietf.org; Fri, 13 Feb 2004 15:07:06 +0800 (SGT) Received: from [192.168.152.203] by mailhost.lit.org.sg (mshttpd); Fri, 13 Feb 2004 15:07:06 +0800 Date: Fri, 13 Feb 2004 15:07:06 +0800 To: ROHC WG Message-id: <3d11223cbc05.3cbc053d1122@i2r.a-star.edu.sg> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7BIT Subject: [rohc] Statistical Inter-flow Field Behaviour 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: 7BIT Content-Transfer-Encoding: 7BIT Hi ROHCers, We have submitted a draft which (we hope!) may be of help to context replication in the ROHC-TCP profile. This draft presents the redundancy of TCP/IP fields between flows. Based on the inter-flow behaviour, we recommend suitable packet format specifications. In some cases, these are different from that in current proposals. We show the extent of behavioural asymmetry between flows, and discuss ways of handling it. We also note that the the current combination of encoding methods does not work well to encode TCP Window for context replication. This draft also aims to address some 'open issues' in which may still be unresolved. It can be found in: http://www.ietf.org/internet-drafts/draft-cho-rohc-tcp-interflow-behaviour-00.txt All comments are welcome. Thank you. Chia Yuan Cho Institute for Infocomm Research Singapore _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Feb 13 17:30:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11570 for ; Fri, 13 Feb 2004 17:30:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlpC-0003SE-Rh for rohc-archive@odin.ietf.org; Fri, 13 Feb 2004 17:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DMUIfj013278 for rohc-archive@odin.ietf.org; Fri, 13 Feb 2004 17:30:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlpC-0003S5-FS for rohc-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 17:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11557 for ; Fri, 13 Feb 2004 17:30:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arlp9-0004LL-00 for rohc-web-archive@ietf.org; Fri, 13 Feb 2004 17:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArloH-0004Hx-00 for rohc-web-archive@ietf.org; Fri, 13 Feb 2004 17:29:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arlnw-0004EA-00 for rohc-web-archive@ietf.org; Fri, 13 Feb 2004 17:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arlnx-00038z-7V; Fri, 13 Feb 2004 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlnH-00037Y-CC for rohc@optimus.ietf.org; Fri, 13 Feb 2004 17:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11477 for ; Fri, 13 Feb 2004 17:28:15 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlnE-0004Cq-00 for rohc@ietf.org; Fri, 13 Feb 2004 17:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlmM-00048q-00 for rohc@ietf.org; Fri, 13 Feb 2004 17:27:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArllM-00045F-00 for rohc@ietf.org; Fri, 13 Feb 2004 17:26:20 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DMQJv01664 for ; Sat, 14 Feb 2004 00:26:19 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 14 Feb 2004 00:26:19 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 14:26:15 -0800 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] ROHC context reuse & mode Date: Fri, 13 Feb 2004 17:26:12 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B815367E@ajebe001.americas.nokia.com> Thread-Topic: [rohc] ROHC context reuse & mode Thread-Index: AcPxRqGN0L9p/TjXTXOMBqpSzVrS7gBLEL9Q To: , Cc: , X-OriginalArrivalTime: 13 Feb 2004 22:26:15.0092 (UTC) FILETIME=[646A2740:01C3F280] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Just throw in some of my thoughts.=20 For U-mode, I have the same view with Carsten. It's not going to be=20 efficient anyway due to the reason we have it in the first place. RE O- and R-mode, there are three cases when the compressor sends an IR. Case 1: same flow but received STATIC-NACK from the decompressor. In=20 this case, each STATIC-NACK (as any feedback) carries the current=20 mode as seen by the decompressor. So, there is no ambiguity to the=20 compressor. If the mode in STATIC-NACK is the same as that of the=20 compressor, the compressor will (as it should) stay in the same mode=20 and send IR packets carrying the mode value as in the STATIC-NACK.=20 If it is different, the compressor will treat it as a mode transition and act accordingly. In either case, the IR packets must carry all the context information that is needed by the decompressor to re-establish context (since the decompressor may have lost them in the worst case). (I think this also answers the question from Kristofer why we have mode field in IR packets. In other words, the mode is handled specially in RFC 3095 so that the synchronization of mode can run in parallel with ROHC states.) Case 2: start a new flow with a CID that hasn't been used. Simple. Start in U-mode as it should be. Case 3: start a new flow but reuse CID. This is the sticky case. Two subcases.=20 3a) If the new flow belongs to a different profile, the compressor should start in U-mode as discussed.=20 3b) If same profile, this is actually similar to Case 1 (if you think=20 hard about it). The only difference is that the decompressor didn't send STATIC-NACK. The compressor can stay in the same mode for the=20 CID (before the new flow), and send all context info in IR (see Case 1=20 above). There may be other details to check, e.g., whether we have race = condition caused by decompressor sending STATIC-NACK while compressor starts a new flow? But later ... BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Carsten Bormann > Sent: 12 February, 2004 02:56 AM > To: Kristofer Sandlund > Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > Subject: Re: [rohc] ROHC context reuse & mode >=20 >=20 > On Feb 11 2004, at 08:35 Uhr, Kristofer Sandlund wrote: >=20 > > Hi Carsten, > > > > Are you saying that every IR packet (regardless of it being=20 > for a new=20 > > flow or not) should flush the ENTIRE decompressor context? >=20 > Not quite (but see below). > What I was trying to say is that a compressor must be=20 > prepared to deal=20 > with a decompressor that does exactly this. >=20 > > One case where some state probably should be kept is for the list=20 > > compression. Just because an extension header (or CSRC=20 > identifier) is=20 > > not present in the current IR packet does not mean that it's not=20 > > present in the context and could reappear in a later packet. If I=20 > > flush the list compression tables every time I get an IR packet, I=20 > > will have to re-establish every item once again. This does=20 > not seem to=20 > > be very efficient, especially in U-mode where I should periodically=20 > > refresh the context with IRs. >=20 > Well, U-mode is the simple example: We are sending IR-packets because=20 > we don't know whether the decompressor got enough of the previous=20 > packets to have set up state yet. So the compressor must be prepared=20 > to deal with a decompressor that has a clean slate immediately after=20 > the IR. >=20 > > Also, if every IR would mean the same as establishing a new=20 > context,=20 > > wouldn't that mean that all IR:s would need to carry U-mode? (since=20 > > all compression should start in U-mode). Why then a mode=20 > parameter in=20 > > the profile 1 IR packet? >=20 > That is the interesting part. Given that the compressor=20 > knows (R-mode)=20 > or is likely to be correct (O-mode) about the state at the=20 > decompressor, the U-mode argument above does not apply. But then, we=20 > are sending an IR packet because something isn't right, so the=20 > assumptions that can be made about the state are probably=20 > limited. It=20 > seems to me some serious analysis is required, which I can't=20 > do at the=20 > moment. >=20 > The questions I have in my mind: >=20 > 1) Can it be dangerous for a decompressor to retain state=20 > beyond an IR? >=20 > 2) Do we have an interoperability problem? > 2a) Would your compressor have problems with a decompressor=20 > that starts=20 > with a clean slate after each IR packet? > 2b) Would your decompressor have problems with a compressor that=20 > assumes this? (Related to 1 above.) >=20 > Gruesse, Carsten >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Feb 15 05:50:53 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 FAA04276 for ; Sun, 15 Feb 2004 05:50:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsJqz-0007pm-BL for rohc-archive@odin.ietf.org; Sun, 15 Feb 2004 05:50:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FAoPnr030110 for rohc-archive@odin.ietf.org; Sun, 15 Feb 2004 05:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsJqz-0007pZ-4F for rohc-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 05:50:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04273 for ; Sun, 15 Feb 2004 05:50:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsJqv-0002ho-00 for rohc-web-archive@ietf.org; Sun, 15 Feb 2004 05:50:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsJpy-0002fZ-00 for rohc-web-archive@ietf.org; Sun, 15 Feb 2004 05:49:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsJpb-0002dJ-00 for rohc-web-archive@ietf.org; Sun, 15 Feb 2004 05:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsJpc-0007mn-Iu; Sun, 15 Feb 2004 05:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsJp3-0007mU-C0 for rohc@optimus.ietf.org; Sun, 15 Feb 2004 05:48:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04247 for ; Sun, 15 Feb 2004 05:48:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsJoz-0002cz-00 for rohc@ietf.org; Sun, 15 Feb 2004 05:48:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsJo4-0002aJ-00 for rohc@ietf.org; Sun, 15 Feb 2004 05:47:25 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AsJnC-0002Uo-00 for rohc@ietf.org; Sun, 15 Feb 2004 05:46:30 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i1F9jgqf011285 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 15 Feb 2004 10:45:48 +0100 Message-ID: <402F4DE7.1000504@effnet.com> Date: Sun, 15 Feb 2004 11:45:59 +0100 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhigang.c.liu@nokia.com CC: cabo@tzi.org, lars-erik.jonsson@ericsson.com, rohc@ietf.org Subject: Re: [rohc] ROHC context reuse & mode References: <7B5AF06E216CB74DA8A5960A3181B5B815367E@ajebe001.americas.nokia.com> In-Reply-To: <7B5AF06E216CB74DA8A5960A3181B5B815367E@ajebe001.americas.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Zhigang, Thanks for your analysis. My comments inlined. zhigang.c.liu@nokia.com wrote: > Hi, > > Just throw in some of my thoughts. > > For U-mode, I have the same view with Carsten. It's not going to be > efficient anyway due to the reason we have it in the first place. > So what are you saying should happen here? Should every periodic refresh flush the entire context every time? Including list compression tables? It seems like we're throwing away a bit more than we'd need to, but I can agree to that as long as it is clarified if the compressor is allowed to use any "old information" after sending a periodic refresh > RE O- and R-mode, there are three cases when the compressor sends an IR. > > Case 1: same flow but received STATIC-NACK from the decompressor. In > this case, each STATIC-NACK (as any feedback) carries the current > mode as seen by the decompressor. So, there is no ambiguity to the > compressor. If the mode in STATIC-NACK is the same as that of the > compressor, the compressor will (as it should) stay in the same mode > and send IR packets carrying the mode value as in the STATIC-NACK. > If it is different, the compressor will treat it as a mode transition > and act accordingly. In either case, the IR packets must carry all the > context information that is needed by the decompressor to re-establish > context (since the decompressor may have lost them in the worst case). > One ambiguity is profiles 2 & 3 which do not have mode information in the IR packets, so the IR cannot say which mode it is meant for. So the decompressor probably must stay in its current mode when this happens? Can this cause any problems? I agree that the IR must carry everything needed to re-establish context, but what assumptions can be made regarding things that are not present in the current packet (e.g. List compression items that are known, are currently not present in the list, but might re-appear). If the compressor has confidence that these were "accepted" last time they were present in the packet (could have been ACKed), then most likely they are still ok in the decompresor context. It of course depends on exactly how to interpret the static-nack. What do you guys think? > (I think this also answers the question from Kristofer why we have > mode field in IR packets. In other words, the mode is handled > specially in RFC 3095 so that the synchronization of mode can run > in parallel with ROHC states.) > > Case 2: start a new flow with a CID that hasn't been used. Simple. > Start in U-mode as it should be. Agreed. > > Case 3: start a new flow but reuse CID. This is the sticky case. > Two subcases. > > 3a) If the new flow belongs to a different profile, the compressor > should start in U-mode as discussed. > Agreed. > 3b) If same profile, this is actually similar to Case 1 (if you think > hard about it). The only difference is that the decompressor didn't > send STATIC-NACK. The compressor can stay in the same mode for the > CID (before the new flow), and send all context info in IR (see Case 1 > above). Sure, works for me. > > There may be other details to check, e.g., whether we have race condition > caused by decompressor sending STATIC-NACK while compressor starts a > new flow? But later ... I agree that there might be some pitfalls here that are hard to predict, so we probably need to think about it for a bit. Whatever we decide, I think there needs to be some text to go into the implementer's guide. This discussion proves that it is not fully clear from 3095. Rgds, Kristofer Sandlund, Effnet AB > > BR, > Zhigang > > > >>-----Original Message----- >>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext >>Carsten Bormann >>Sent: 12 February, 2004 02:56 AM >>To: Kristofer Sandlund >>Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); rohc@ietf.org >>Subject: Re: [rohc] ROHC context reuse & mode >> >> >>On Feb 11 2004, at 08:35 Uhr, Kristofer Sandlund wrote: >> >> >>>Hi Carsten, >>> >>>Are you saying that every IR packet (regardless of it being >> >>for a new >> >>>flow or not) should flush the ENTIRE decompressor context? >> >>Not quite (but see below). >>What I was trying to say is that a compressor must be >>prepared to deal >>with a decompressor that does exactly this. >> >> >>>One case where some state probably should be kept is for the list >>>compression. Just because an extension header (or CSRC >> >>identifier) is >> >>>not present in the current IR packet does not mean that it's not >>>present in the context and could reappear in a later packet. If I >>>flush the list compression tables every time I get an IR packet, I >>>will have to re-establish every item once again. This does >> >>not seem to >> >>>be very efficient, especially in U-mode where I should periodically >>>refresh the context with IRs. >> >>Well, U-mode is the simple example: We are sending IR-packets because >>we don't know whether the decompressor got enough of the previous >>packets to have set up state yet. So the compressor must be prepared >>to deal with a decompressor that has a clean slate immediately after >>the IR. >> >> >>>Also, if every IR would mean the same as establishing a new >> >>context, >> >>>wouldn't that mean that all IR:s would need to carry U-mode? (since >>>all compression should start in U-mode). Why then a mode >> >>parameter in >> >>>the profile 1 IR packet? >> >>That is the interesting part. Given that the compressor >>knows (R-mode) >>or is likely to be correct (O-mode) about the state at the >>decompressor, the U-mode argument above does not apply. But then, we >>are sending an IR packet because something isn't right, so the >>assumptions that can be made about the state are probably >>limited. It >>seems to me some serious analysis is required, which I can't >>do at the >>moment. >> >>The questions I have in my mind: >> >>1) Can it be dangerous for a decompressor to retain state >>beyond an IR? >> >>2) Do we have an interoperability problem? >>2a) Would your compressor have problems with a decompressor >>that starts >>with a clean slate after each IR packet? >>2b) Would your decompressor have problems with a compressor that >>assumes this? (Related to 1 above.) >> >>Gruesse, Carsten >> >> >>_______________________________________________ >>Rohc mailing list >>Rohc@ietf.org >>https://www1.ietf.org/mailman/listinfo/rohc >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 16 04:08:44 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 EAA07004 for ; Mon, 16 Feb 2004 04:08:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asejf-0006Jh-1m for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 04:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G98Ek8024239 for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 04:08:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asejc-0006Ic-NE for rohc-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 04:08:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06998 for ; Mon, 16 Feb 2004 04:08:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsejZ-0004EH-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 04:08:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aseid-0004BI-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 04:07:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AseiS-00047w-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 04:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AseiT-000649-Nk; Mon, 16 Feb 2004 04:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asehe-00060d-H5 for rohc@optimus.ietf.org; Mon, 16 Feb 2004 04:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06957 for ; Mon, 16 Feb 2004 04:06:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asehb-00047J-00 for rohc@ietf.org; Mon, 16 Feb 2004 04:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asege-00044b-00 for rohc@ietf.org; Mon, 16 Feb 2004 04:05:09 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AsegC-00041d-00 for rohc@ietf.org; Mon, 16 Feb 2004 04:04:40 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1G94fqY007169 for ; Mon, 16 Feb 2004 10:04:41 +0100 (MET) 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, 16 Feb 2004 10:04:41 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Feb 2004 10:04:41 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: kristofer.sandlund@effnet.com Cc: rohc@ietf.org Subject: RE: [rohc] ROHC context reuse & mode Date: Mon, 16 Feb 2004 10:04:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Feb 2004 09:04:41.0552 (UTC) FILETIME=[E9AB9500:01C3F46B] 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 > Case 2: start a new flow with a CID that hasn't been used. Simple. > Start in U-mode as it should be. > > Case 3: start a new flow but reuse CID. This is the sticky case. > Two subcases. > > 3a) If the new flow belongs to a different profile, the compressor > should start in U-mode as discussed. > > 3b) If same profile, this is actually similar to Case 1 (if you think > hard about it). The only difference is that the decompressor didn't > send STATIC-NACK. The compressor can stay in the same mode for the > CID (before the new flow), and send all context info in IR > (see Case 1 above). One question is whether this is ok according to 3095? Personally, I agree with Carsten that when a new context is initialized, it must start in U-mode, and that would also apply to the CID reuse case. /L-E This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 16 11:35:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03093 for ; Mon, 16 Feb 2004 11:35:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsliM-0003U9-U6 for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 11:35:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGZM96013391 for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 11:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsliM-0003Tu-Or for rohc-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:35:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03018 for ; Mon, 16 Feb 2004 11:35:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsliL-00062G-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 11:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslgY-0005fM-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 11:33:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsleE-00057B-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 11:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asle9-0003Cy-Jz; Mon, 16 Feb 2004 11:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsldR-00038q-2p for rohc@optimus.ietf.org; Mon, 16 Feb 2004 11:30:17 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01989 for ; Mon, 16 Feb 2004 11:30:14 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1Aslcw-00037T-Dm; Mon, 16 Feb 2004 11:29:46 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 16 Feb 2004 11:29:46 -0500 Subject: [rohc] Protocol Action: 'Definitions of Managed Objects for Robust Header Compression' to Proposed Standard 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 The IESG has approved following documents: - 'Definitions of Managed Objects for Robust Header Compression ' as a Proposed Standard - 'RObust Header Compression (ROHC):Terminology and Channel Mapping Examples' as an Informational RFC These documents are products of the Robust Header Compression Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. The Informational document "ROHC Terminology and Channel Mapping Overview" discusses terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms such as network elements and IP interfaces, commonly used for example when addressing MIB issues. Working Group Summary The working group strongly supported advancement of these documents. Protocol Quality The ROHC MIB received extensive review on behalf of the MIB Doctors by C.M. Heard. It was additionally reviewed for the IESG by Bert Wijnen. The documents were also reviewed for the IESG by Allison Mankin. RFC Editor Note Replace the Informational document's title: Old: ROHC: Terminology and Channel Mapping Examples New: RObust Header Compression (ROHC): Terminology and Channel Mapping Overview Replace the entire Security Considerations of "ROHC: Terminology and Channel Mapping Examples" (the Informational document) : Old: Security Considerations This document is of an informative nature, and does not have any security aspects to address. New: Security Considerations The clear understanding of ROHC channels and their relations to IP interfaces and the physical medium plays a critical role in ensuring secure usage of ROHC. This document is therefore a valuable adjunct to the Security Considerations found in RFC 3095 and other ROHC specifications, however, as it just reviews information and definitions, it does not add new security issues to the ROHC protocol specifications _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 16 15:43:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20596 for ; Mon, 16 Feb 2004 15:43:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZn-0003N0-Gu for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKgl8I012948 for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZn-0003Ml-Bq for rohc-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:42:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20501 for ; Mon, 16 Feb 2004 15:42:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspZl-0002fh-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 15:42:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspYt-0002Xq-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspY5-0002Rn-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspY6-0002WB-Pv; Mon, 16 Feb 2004 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspXj-0002Hp-30 for rohc@optimus.ietf.org; Mon, 16 Feb 2004 15:40:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20016; Mon, 16 Feb 2004 15:40:36 -0500 (EST) Message-Id: <200402162040.PAA20016@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Feb 2004 15:40:36 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-sip-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , 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,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 : Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) Author(s) : Z. Liu, R. Price Filename : draft-ietf-rohc-sigcomp-sip-01.txt Pages : 9 Date : 2004-2-16 This document describes some specifics when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-sip-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-sip-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16123222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-sip-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-sip-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16123222.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 16 18:09:22 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 SAA07709 for ; Mon, 16 Feb 2004 18:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrrC-0002EO-I4 for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 18:08:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GN8s6d008570 for rohc-archive@odin.ietf.org; Mon, 16 Feb 2004 18:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrrC-0002E9-Ad for rohc-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 18:08:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07630 for ; Mon, 16 Feb 2004 18:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asrr8-0007gA-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 18:08:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asrpg-0007Nb-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 18:07:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsroO-0007Ch-00 for rohc-web-archive@ietf.org; Mon, 16 Feb 2004 18:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsroP-0001DY-L8; Mon, 16 Feb 2004 18:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrnX-0000zp-8A for rohc@optimus.ietf.org; Mon, 16 Feb 2004 18:05:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07062 for ; Mon, 16 Feb 2004 18:05:02 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrnT-00074V-00 for rohc@ietf.org; Mon, 16 Feb 2004 18:05:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsrmZ-0006wB-00 for rohc@ietf.org; Mon, 16 Feb 2004 18:04:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Asrle-0006nd-00 for rohc@ietf.org; Mon, 16 Feb 2004 18:03:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1GN39v18317 for ; Tue, 17 Feb 2004 01:03:09 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Feb 2004 01:03:09 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 17:02:37 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rohc] ROHC context reuse & mode Date: Mon, 16 Feb 2004 18:02:35 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153681@ajebe001.americas.nokia.com> Thread-Topic: [rohc] ROHC context reuse & mode Thread-Index: AcPzsQGa1tD/NIW4TuSjEzmal7u7/QBJ/e8A To: Cc: , , X-OriginalArrivalTime: 16 Feb 2004 23:02:37.0343 (UTC) FILETIME=[F8607AF0:01C3F4E0] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kristofer, > So what are you saying should happen here? Should every=20 > periodic refresh flush the entire context every time? Including=20 > list compression tables? Yes. This is simply a risk management in U-mode. You never know if the decompressor has received a particular packet. However,=20 the compressor can choose the frequency of IRs, and IR-DYNAMIC and other context update packets for that matter. > It seems like we're throwing away a bit more than we'd need=20 > to, but I can agree to that as long as it is clarified if the=20 > compressor is allowed to use any "old information" after sending > a periodic refresh Sorry, I'm not sure I follow you. Anyway, the reason that the compressor sends an IR packet is that it fears the decompressor may not has a=20 certain context (see above). And the decompressor will assume the IR=20 packet means to re-establish context from clean slate. For partial context refresh, other packets (e.g. IR-DYNAMIC) can be used. > One ambiguity is profiles 2 & 3 which do not have mode=20 > information in the IR packets, so the IR cannot say which=20 > mode it is meant for.=20 This is true. It would be cleaner if we had put the mode outside of=20 RTP dynamic chain ... > So the decompressor probably must stay in its current mode=20 > when this happens? Can this cause any problems? If the previous profile for this CID is different from what is=20 received in an IR packet, the decompressor should start in=20 U-mode since this clearly indicates a new packet flow. Else, the decompressor cannot tell if it is a context refresh=20 of the same packet flow or initialization of a new flow. Staying in its current mode seems OK to me, because: - if it is the former case, the compressor should not have switched mode (it's always the decompressor that controls mode). - if it is the latter case, the compressor is in U-mode and=20 decompressor is in same or "higher" mode (in terms of expectation=20 of feedback). For the "higher" case, the feedback from decompressor will trigger the compressor to switch mode to the current mode of the decompressor. I don't have time to think all the details, but it seems to be harmless though the decompressor is unaware it=20 actually triggered a mode transition. > If the compressor has confidence that these were "accepted" last=20 > time they were present in the packet (could have been ACKed),=20 > then most likely they are still ok in the decompresor context.=20 Then, the compressor should not send IR. > It of course depends on exactly how to interpret the static-nack.=20 > What do you guys think? STATIC-NACK means the decompressor believes its static context has=20 been corrupted. Since there is no way to indicate "partial" context corruption, the compressor has to assume the worst. Anyway, STATIC-NACK should be a rare condition after the first ACK, so the effect on efficiency should be quite small. > I agree that there might be some pitfalls here that are hard=20 > to predict, so we probably need to think about it for a bit. > Whatever we decide, I think there needs to be some text to go=20 > into the implementer's guide. This discussion proves that it is not=20 > fully clear from 3095. Agree. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 17 13:40:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25606 for ; Tue, 17 Feb 2004 13:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA8V-000745-2V for rohc-archive@odin.ietf.org; Tue, 17 Feb 2004 13:39:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIdxrE027151 for rohc-archive@odin.ietf.org; Tue, 17 Feb 2004 13:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA8U-00073q-SQ for rohc-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25470 for ; Tue, 17 Feb 2004 13:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA8S-00018S-00 for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 13:39:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA6y-0000tM-00 for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 13:38:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtA6L-0000o4-00 for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 13:37:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtA1p-0006LN-Ud for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 13:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA1l-0006W1-HW; Tue, 17 Feb 2004 13:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA1D-0006Uo-Gr for rohc@optimus.ietf.org; Tue, 17 Feb 2004 13:32:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25020 for ; Tue, 17 Feb 2004 13:32:25 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA1B-0000Lq-00 for rohc@ietf.org; Tue, 17 Feb 2004 13:32:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA0H-0000Gl-00 for rohc@ietf.org; Tue, 17 Feb 2004 13:31:30 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1At9zd-0000Bx-00 for rohc@ietf.org; Tue, 17 Feb 2004 13:30:49 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HIUmK08419 for ; Tue, 17 Feb 2004 20:30:48 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Feb 2004 20:30:48 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 10:30:46 -0800 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] ROHC context reuse & mode Date: Tue, 17 Feb 2004 13:30:44 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B8153686@ajebe001.americas.nokia.com> Thread-Topic: [rohc] ROHC context reuse & mode Thread-Index: AcP0bNPIyRmnVVwoQUG0CtWr5jPQBgBFl4bw To: , Cc: X-OriginalArrivalTime: 17 Feb 2004 18:30:46.0193 (UTC) FILETIME=[28964210:01C3F584] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lars-Erik, Technically, I don't seen any interoperability problem for the compressor to stay in current mode (see my email to Kristofer).=20 Do you? BTW, could you please copy me in the To or CC list when commenting on my emails? That makes it easier for me to know you have comments. Thanks. Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Lars-Erik Jonsson (LU/EAB) > Sent: 16 February, 2004 03:05 AM > To: kristofer.sandlund@effnet.com > Cc: rohc@ietf.org > Subject: RE: [rohc] ROHC context reuse & mode >=20 >=20 > > Case 2: start a new flow with a CID that hasn't been used. Simple. > > Start in U-mode as it should be. > >=20 > > Case 3: start a new flow but reuse CID. This is the sticky case. > > Two subcases.=20 > >=20 > > 3a) If the new flow belongs to a different profile, the compressor > > should start in U-mode as discussed.=20 > >=20 > > 3b) If same profile, this is actually similar to Case 1 (if=20 > you think=20 > > hard about it). The only difference is that the decompressor didn't > > send STATIC-NACK. The compressor can stay in the same mode for the=20 > > CID (before the new flow), and send all context info in IR=20 > > (see Case 1 above). >=20 > One question is whether this is ok according to 3095? Personally, I > agree with Carsten that when a new context is initialized, it must > start in U-mode, and that would also apply to the CID reuse case. >=20 > /L-E >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure or=20 > distribution is prohibited. If you believe this message has=20 > been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 17 14:37:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29150 for ; Tue, 17 Feb 2004 14:37:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB2B-0005gK-K2 for rohc-archive@odin.ietf.org; Tue, 17 Feb 2004 14:37:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJbVgt021833 for rohc-archive@odin.ietf.org; Tue, 17 Feb 2004 14:37:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB2B-0005fw-3u for rohc-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29144 for ; Tue, 17 Feb 2004 14:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtB28-0005dH-00 for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 14:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtB1B-0005ZD-00 for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 14:36:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtB0i-0005Vn-00 for rohc-web-archive@ietf.org; Tue, 17 Feb 2004 14:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB0j-0005RT-Qr; Tue, 17 Feb 2004 14:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB08-0005Po-9G for rohc@optimus.ietf.org; Tue, 17 Feb 2004 14:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29080 for ; Tue, 17 Feb 2004 14:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtB05-0005VO-00 for rohc@ietf.org; Tue, 17 Feb 2004 14:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAzP-0005So-00 for rohc@ietf.org; Tue, 17 Feb 2004 14:34:40 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AtAyu-0005O6-00 for rohc@ietf.org; Tue, 17 Feb 2004 14:34:08 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HJY6K06971; Tue, 17 Feb 2004 21:34:06 +0200 (EET) X-Scanned: Tue, 17 Feb 2004 21:34:04 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i1HJY4xJ012972; Tue, 17 Feb 2004 21:34:04 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00DYsErm; Tue, 17 Feb 2004 21:34:03 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HJY3O18682; Tue, 17 Feb 2004 21:34:03 +0200 (EET) Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 21:34:03 +0200 Received: from agni.research.nokia.com (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA28123; Tue, 17 Feb 2004 21:34:14 +0200 (EET) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i1HJY0xk000708; Tue, 17 Feb 2004 21:34:00 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i1HJY0ki000707; Tue, 17 Feb 2004 21:34:00 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Abigail Surtees Cc: "'Jan Christoffersson (LU/EAB)'" , "West, Mark" , Robert.Sugar@nokia.com, zhigang.c.liu@nokia.com, "Lars-Erik Jonsson (LU/EAB)" , rohc@ietf.org Subject: Re: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Surtees's message of "Thu, 18 Dec 2003 14:21:52 -0000") References: Date: Tue, 17 Feb 2004 21:34:00 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Feb 2004 19:34:03.0169 (UTC) FILETIME=[FFC2D110:01C3F58C] 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 Surtees, Abigail writes: >Slightly belatedly, a response about continuous mode. The main question is >what is the consensus about what 'continuous mode' actually means? I think >there are at least two interpretations. (I also suggest that when we reach >consensus, it should be put into the implementer's guide.) Even later.. ... >Interpretation 1: >An endpoint can open a UDVM on receipt of part of a SigComp message over TCP >and leave it open until the rest of the message is received. Consequently, >the endpoint has to be able to cope with multiple UDVMs running, but other >than that everything works in the same way as normal. In what way is the >security risk any greater when using this interpretation of continuous mode >than when buffering the message first? I gather that the risk is the DoS attack by multiple concurrent UDVMs? Does not sound very grave; UDVM looks like a (small) piece of memory. >Interpretation 2: ... >The 64k uncompressed message limit is to provide security against >"generating huge messages to muck up the SIP stack" attacks. If the extra >security mechanisms that make continuous mode safe to use can also prevent >this attack, then isn't it safe to drop the message limit? I'd say so. >Then the whole SIP flow can be compressed by one SigComp message and >delivered in small chunks without a message limit size problem. >Which (if either) interpretation have other people assumed, or is there >another interpretation we haven't considered? I initially assumed interpretation 2; then when I started checking for the 64 kB limit (it really makes your life complicated ;), I started using interpretation 1. >On the issue of whether or not use of continuous mode could solve the issue >of multiplexing on a TCP connection, I think that if interpretation 1 is the >consensus, then as Jan said there are still problems and continuous mode is >not the solution. However, if interpretation 2 is the consensus, then as >Mark suggested continuous mode could be used (allowable because of the >security provided by IPsec) and then there is no need for multiplexing. It is also possible to send a large SIP message using multiple SigComp messages. Of course, this would mean that the SigComp application (SIP stack) must accept/reject the SigComp message before entire SIP message has been decompressed. OK, this violates assumptions behind the SigComp security model, but, SIP cannot provide any kind of upper layer security for SigComp unless *extremely* costly and/or underspecified S/MIME tunneling is used. (There has been things like draft-undery-sip-auth-01.txt under works, but they have expired long time ago.) SigComp security model simply does not work with current SIP. So, who cares about yet another invalidated assumption as long as you have a reasonable underlying security (IPSec, TLS)? (Of course, there are other things in SigComp that does not work with SIP, like the compression association and compartments, but I rant about them some other time.) --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 05:01:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04573 for ; Wed, 18 Feb 2004 05:01:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOVa-0007jC-TM for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 05:00:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IA0k6b029686 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 05:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOVW-0007iY-6u for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 05:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04535 for ; Wed, 18 Feb 2004 05:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOVS-0002ro-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 05:00:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOUa-0002o3-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 04:59:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtOTr-0002ke-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 04:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOTt-0007Ym-FG; Wed, 18 Feb 2004 04:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOTh-0007XT-6Z for rohc@optimus.ietf.org; Wed, 18 Feb 2004 04:58:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04435 for ; Wed, 18 Feb 2004 04:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOTe-0002iQ-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:58:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOSo-0002eH-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:57:55 -0500 Received: from [213.214.194.103] (helo=smtp.home.se) by ietf-mx with esmtp (Exim 4.12) id 1AtORw-0002ZC-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:57:00 -0500 Received: from larsman@home.se [194.237.142.7] by home.se with NetMail ModWeb Module; Wed, 18 Feb 2004 09:44:00 +0100 Subject: RE: [rohc] ROHC context reuse & mode From: "Lars-Erik Jonsson" To: rohc@ietf.org CC: zhigang.c.liu@nokia.com Date: Wed, 18 Feb 2004 09:44:01 +0100 X-Mailer: NetMail ModWeb Module X-Sender: larsman@home.se MIME-Version: 1.0 Message-ID: <1077093841.624fcfc0larsman@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Zhigang, I am not sure there would be any technical problems with it, but it is indeed a change in principle from what is stated by 3095, as 3095 clearly says new contexts must start in U-mode. Either way, we should put some clarifying text in the impl. guide, we just have to agree on what (I'll have to think some more about this, or let others convince me on which approach makes most sense). /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 17 februari 2004 19:31 > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com > Cc: rohc@ietf.org > Subject: RE: [rohc] ROHC context reuse & mode >=20 >=20 > Lars-Erik, >=20 > Technically, I don't seen any interoperability problem for the > compressor to stay in current mode (see my email to Kristofer).=20 > Do you? >=20 > BTW, could you please copy me in the To or CC list when commenting > on my emails? That makes it easier for me to know you have comments. > Thanks. >=20 > Zhigang >=20 > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On=20 > Behalf Of ext > > Lars-Erik Jonsson (LU/EAB) > > Sent: 16 February, 2004 03:05 AM > > To: kristofer.sandlund@effnet.com > > Cc: rohc@ietf.org > > Subject: RE: [rohc] ROHC context reuse & mode > >=20 > >=20 > > > Case 2: start a new flow with a CID that hasn't been used. Simple. > > > Start in U-mode as it should be. > > >=20 > > > Case 3: start a new flow but reuse CID. This is the sticky case. > > > Two subcases.=20 > > >=20 > > > 3a) If the new flow belongs to a different profile, the compressor > > > should start in U-mode as discussed.=20 > > >=20 > > > 3b) If same profile, this is actually similar to Case 1 (if=20 > > you think=20 > > > hard about it). The only difference is that the=20 > decompressor didn't > > > send STATIC-NACK. The compressor can stay in the same=20 > mode for the=20 > > > CID (before the new flow), and send all context info in IR=20 > > > (see Case 1 above). > >=20 > > One question is whether this is ok according to 3095? Personally, I > > agree with Carsten that when a new context is initialized, it must > > start in U-mode, and that would also apply to the CID reuse case. > > > > /L-E > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 05:01:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04572 for ; Wed, 18 Feb 2004 05:01:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOVa-0007jB-Qe for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 05:00:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IA0khp029687 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 05:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOVW-0007id-RI for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 05:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04538 for ; Wed, 18 Feb 2004 05:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOVT-0002rt-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 05:00:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOUb-0002oB-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 04:59:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtOTr-0002kf-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 04:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOTt-0007Yu-QC; Wed, 18 Feb 2004 04:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOTh-0007Xc-QN for rohc@optimus.ietf.org; Wed, 18 Feb 2004 04:58:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04438 for ; Wed, 18 Feb 2004 04:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOTe-0002iV-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:58:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOSp-0002eQ-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:57:56 -0500 Received: from [213.214.194.103] (helo=smtp.home.se) by ietf-mx with esmtp (Exim 4.12) id 1AtORw-0002ZD-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:57:00 -0500 Received: from larsman@home.se [194.237.142.7] by home.se with NetMail ModWeb Module; Wed, 18 Feb 2004 09:44:01 +0100 Subject: RE: [rohc] ROHC context reuse & mode From: "Lars-Erik Jonsson" To: rohc@ietf.org CC: zhigang.c.liu@nokia.com Date: Wed, 18 Feb 2004 09:44:01 +0100 X-Mailer: NetMail ModWeb Module X-Sender: larsman@home.se MIME-Version: 1.0 Message-ID: <1077093841.624fcfc0larsman@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Zhigang, I am not sure there would be any technical problems with it, but it is indeed a change in principle from what is stated by 3095, as 3095 clearly says new contexts must start in U-mode. Either way, we should put some clarifying text in the impl. guide, we just have to agree on what (I'll have to think some more about this, or let others convince me on which approach makes most sense). /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 17 februari 2004 19:31 > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com > Cc: rohc@ietf.org > Subject: RE: [rohc] ROHC context reuse & mode >=20 >=20 > Lars-Erik, >=20 > Technically, I don't seen any interoperability problem for the > compressor to stay in current mode (see my email to Kristofer).=20 > Do you? >=20 > BTW, could you please copy me in the To or CC list when commenting > on my emails? That makes it easier for me to know you have comments. > Thanks. >=20 > Zhigang >=20 > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On=20 > Behalf Of ext > > Lars-Erik Jonsson (LU/EAB) > > Sent: 16 February, 2004 03:05 AM > > To: kristofer.sandlund@effnet.com > > Cc: rohc@ietf.org > > Subject: RE: [rohc] ROHC context reuse & mode > >=20 > >=20 > > > Case 2: start a new flow with a CID that hasn't been used. Simple. > > > Start in U-mode as it should be. > > >=20 > > > Case 3: start a new flow but reuse CID. This is the sticky case. > > > Two subcases.=20 > > >=20 > > > 3a) If the new flow belongs to a different profile, the compressor > > > should start in U-mode as discussed.=20 > > >=20 > > > 3b) If same profile, this is actually similar to Case 1 (if=20 > > you think=20 > > > hard about it). The only difference is that the=20 > decompressor didn't > > > send STATIC-NACK. The compressor can stay in the same=20 > mode for the=20 > > > CID (before the new flow), and send all context info in IR=20 > > > (see Case 1 above). > >=20 > > One question is whether this is ok according to 3095? Personally, I > > agree with Carsten that when a new context is initialized, it must > > start in U-mode, and that would also apply to the CID reuse case. > > > > /L-E > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 05:49:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04574 for ; Wed, 18 Feb 2004 05:01:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOVb-0007jH-1l for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 05:00:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IA0kOQ029688 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 05:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOVX-0007ii-GO for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 05:00:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04541 for ; Wed, 18 Feb 2004 05:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOVU-0002ry-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 05:00:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOUc-0002oK-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 04:59:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtOTr-0002kh-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 04:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOTu-0007ZC-Bv; Wed, 18 Feb 2004 04:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtOTi-0007Xk-GE for rohc@optimus.ietf.org; Wed, 18 Feb 2004 04:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04441 for ; Wed, 18 Feb 2004 04:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtOTf-0002ia-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtOSq-0002eY-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:57:57 -0500 Received: from [213.214.194.103] (helo=smtp.home.se) by ietf-mx with esmtp (Exim 4.12) id 1AtORw-0002ZE-00 for rohc@ietf.org; Wed, 18 Feb 2004 04:57:00 -0500 Received: from larsman@home.se [194.237.142.7] by home.se with NetMail ModWeb Module; Wed, 18 Feb 2004 09:44:01 +0100 Subject: RE: [rohc] ROHC context reuse & mode From: "Lars-Erik Jonsson" To: rohc@ietf.org CC: zhigang.c.liu@nokia.com Date: Wed, 18 Feb 2004 09:44:01 +0100 X-Mailer: NetMail ModWeb Module X-Sender: larsman@home.se MIME-Version: 1.0 Message-ID: <1077093841.624fcfc0larsman@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Zhigang, I am not sure there would be any technical problems with it, but it is indeed a change in principle from what is stated by 3095, as 3095 clearly says new contexts must start in U-mode. Either way, we should put some clarifying text in the impl. guide, we just have to agree on what (I'll have to think some more about this, or let others convince me on which approach makes most sense). /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 17 februari 2004 19:31 > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com > Cc: rohc@ietf.org > Subject: RE: [rohc] ROHC context reuse & mode >=20 >=20 > Lars-Erik, >=20 > Technically, I don't seen any interoperability problem for the > compressor to stay in current mode (see my email to Kristofer).=20 > Do you? >=20 > BTW, could you please copy me in the To or CC list when commenting > on my emails? That makes it easier for me to know you have comments. > Thanks. >=20 > Zhigang >=20 > > -----Original Message----- > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On=20 > Behalf Of ext > > Lars-Erik Jonsson (LU/EAB) > > Sent: 16 February, 2004 03:05 AM > > To: kristofer.sandlund@effnet.com > > Cc: rohc@ietf.org > > Subject: RE: [rohc] ROHC context reuse & mode > >=20 > >=20 > > > Case 2: start a new flow with a CID that hasn't been used. Simple. > > > Start in U-mode as it should be. > > >=20 > > > Case 3: start a new flow but reuse CID. This is the sticky case. > > > Two subcases.=20 > > >=20 > > > 3a) If the new flow belongs to a different profile, the compressor > > > should start in U-mode as discussed.=20 > > >=20 > > > 3b) If same profile, this is actually similar to Case 1 (if=20 > > you think=20 > > > hard about it). The only difference is that the=20 > decompressor didn't > > > send STATIC-NACK. The compressor can stay in the same=20 > mode for the=20 > > > CID (before the new flow), and send all context info in IR=20 > > > (see Case 1 above). > >=20 > > One question is whether this is ok according to 3095? Personally, I > > agree with Carsten that when a new context is initialized, it must > > start in U-mode, and that would also apply to the CID reuse case. > > > > /L-E > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 08:27: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 IAA09842 for ; Wed, 18 Feb 2004 08:27:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRj0-0004yM-Iy for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 08:26:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDQoXU019108 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 08:26:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRj0-0004y7-Ei for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 08:26:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09824 for ; Wed, 18 Feb 2004 08:26:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRiz-0005l5-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 08:26:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRi5-0005iQ-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 08:25:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtRhG-0005fU-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 08:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRhF-0004kM-RJ; Wed, 18 Feb 2004 08:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRgM-0004hx-He for rohc@optimus.ietf.org; Wed, 18 Feb 2004 08:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09737 for ; Wed, 18 Feb 2004 08:24:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRgL-0005aK-00 for rohc@ietf.org; Wed, 18 Feb 2004 08:24:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRfK-0005Va-00 for rohc@ietf.org; Wed, 18 Feb 2004 08:23:02 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AtReR-0005Na-00 for rohc@ietf.org; Wed, 18 Feb 2004 08:22:07 -0500 Received: from effnet.com (c-497871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.73]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i1ICLIqf024874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Feb 2004 13:21:23 +0100 Message-ID: <403366E1.7000700@effnet.com> Date: Wed, 18 Feb 2004 14:21:37 +0100 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: Lars-Erik Jonsson CC: rohc@ietf.org, zhigang.c.liu@nokia.com Subject: Re: [rohc] ROHC context reuse & mode References: <1077093841.624fcfc0larsman@home.se> In-Reply-To: <1077093841.624fcfc0larsman@home.se> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Zhigang/L-E, I think that Zhigang's scheme of letting mode be inherited when we have the same profile seems like the best choice to me. I think this approach will be more consistent with the mode transition logic. If we choose the "always U-mode when new flow" approach, and a new flow appears in the middle of a pending mode transition, we would probably have to specify that the decompressor must detect that it is a new flow (for example static-def-diffing as I suggested earlier) and also it should set D_TRANS=done & D_MODE=U-mode when we have a new flow (i.e. mode trans must be restarted). The inheritance scheme will just complete the mode transition without having to understand that it is a new flow. I can agree that this is slightly inconsistent with the spec, but I don't think it "clearly says new contexts must start in U-mode". All it says is "Compression with ROHC MUST start in the Unidirectional mode" (sec. 4.4.1), which _could_ be interpreted as being on a per-channel basis. If so, mode inheritance is completely ok. Rgds, Kristofer Sandlund, Effnet AB Lars-Erik Jonsson wrote: > Zhigang, > > I am not sure there would be any technical problems > with it, but it is indeed a change in principle from > what is stated by 3095, as 3095 clearly says new > contexts must start in U-mode. > > Either way, we should put some clarifying text in the > impl. guide, we just have to agree on what (I'll have > to think some more about this, or let others convince > me on which approach makes most sense). > > /L-E > > > >>-----Original Message----- >>From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] >>Sent: den 17 februari 2004 19:31 >>To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com >>Cc: rohc@ietf.org >>Subject: RE: [rohc] ROHC context reuse & mode >> >> >>Lars-Erik, >> >>Technically, I don't seen any interoperability problem for the >>compressor to stay in current mode (see my email to Kristofer). >>Do you? >> >>BTW, could you please copy me in the To or CC list when commenting >>on my emails? That makes it easier for me to know you have comments. >>Thanks. >> >>Zhigang >> >> >>>-----Original Message----- >>>From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On >> >>Behalf Of ext >> >>>Lars-Erik Jonsson (LU/EAB) >>>Sent: 16 February, 2004 03:05 AM >>>To: kristofer.sandlund@effnet.com >>>Cc: rohc@ietf.org >>>Subject: RE: [rohc] ROHC context reuse & mode >>> >>> >>> >>>>Case 2: start a new flow with a CID that hasn't been used. Simple. >>>>Start in U-mode as it should be. >>>> >>>>Case 3: start a new flow but reuse CID. This is the sticky case. >>>>Two subcases. >>>> >>>>3a) If the new flow belongs to a different profile, the compressor >>>>should start in U-mode as discussed. >>>> >>>>3b) If same profile, this is actually similar to Case 1 (if >>> >>>you think >>> >>>>hard about it). The only difference is that the >> >>decompressor didn't >> >>>>send STATIC-NACK. The compressor can stay in the same >> >>mode for the >> >>>>CID (before the new flow), and send all context info in IR >>>>(see Case 1 above). >>> >>>One question is whether this is ok according to 3095? Personally, I >>>agree with Carsten that when a new context is initialized, it must >>>start in U-mode, and that would also apply to the CID reuse case. >>> >>>/L-E >>> > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 08:39:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10371 for ; Wed, 18 Feb 2004 08:39:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRue-0006bT-9Z for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 08:38:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDcqYa025382 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 08:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRue-0006bJ-5R for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 08:38:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10359 for ; Wed, 18 Feb 2004 08:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRuc-0006aJ-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 08:38:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRtn-0006XR-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 08:38:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtRsr-0006Ta-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 08:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRsr-0006D7-Dk; Wed, 18 Feb 2004 08:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRs0-0006Bx-IG for rohc@optimus.ietf.org; Wed, 18 Feb 2004 08:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10257 for ; Wed, 18 Feb 2004 08:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRrz-0006PF-00 for rohc@ietf.org; Wed, 18 Feb 2004 08:36:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRrF-0006Kl-00 for rohc@ietf.org; Wed, 18 Feb 2004 08:35:22 -0500 Received: from smtp2.home.se ([213.214.194.102]) by ietf-mx with esmtp (Exim 4.12) id 1AtRqc-0006Ev-00 for rohc@ietf.org; Wed, 18 Feb 2004 08:34:42 -0500 Received: from larsman@home.se [194.237.142.7] by home.se with NetMail ModWeb Module; Wed, 18 Feb 2004 14:31:41 +0100 Subject: Re: Re: [rohc] ROHC context reuse & mode From: "Lars-Erik Jonsson" To: kristofer.sandlund@effnet.com CC: rohc@ietf.org, zhigang.c.liu@nokia.com Date: Wed, 18 Feb 2004 14:31:41 +0100 X-Mailer: NetMail ModWeb Module X-Sender: larsman@home.se MIME-Version: 1.0 Message-ID: <1077111101.5e638740larsman@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable OK, I can buy that argumentation. So, what we should clarify then is that: 1) This is what happens when a context is re-used=20 for a new flow, compressed with the same profile. 2) If a context is re-used for compression of a new flow using a different profile, compression is obviously restarted in U-mode, independent of=20 previous mode Would that be it? /L-E Zhigang/L-E, I think that Zhigang's scheme of letting mode be inherited when we have the= same=20 profile seems like the best choice to me. I think this approach will be mor= e=20 consistent with the mode transition logic. If we choose the "always U-mode when new flow" approach, and a new flow app= ears=20 in the middle of a pending mode transition, we would probably have to speci= fy=20 that the decompressor must detect that it is a new flow (for example=20 static-def-diffing as I suggested earlier) and also it should set D_TRANS= =3Ddone &=20 D_MODE=3DU-mode when we have a new flow (i.e. mode trans must be restarted)= . The=20 inheritance scheme will just complete the mode transition without having to= understand that it is a new flow. I can agree that this is slightly inconsistent with the spec, but I don't t= hink it "clearly says new contexts must start in U-mode". All it says is "Compre= ssion with ROHC MUST start in the Unidirectional mode" (sec. 4.4.1), which _could= _ be interpreted as being on a per-channel basis. If so, mode inheritance is completely ok. Rgds, =09Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 12:39:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01449 for ; Wed, 18 Feb 2004 12:39:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVej-0000KB-MQ for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 12:38:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IHcfE1001243 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 12:38:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVej-0000Jy-IJ for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 12:38:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01401 for ; Wed, 18 Feb 2004 12:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVeh-0007Dv-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 12:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVdB-0006zr-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 12:37:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtVcA-0006rN-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 12:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVcA-0008LN-Nf; Wed, 18 Feb 2004 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVbC-0008K0-EB for rohc@optimus.ietf.org; Wed, 18 Feb 2004 12:35:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01186 for ; Wed, 18 Feb 2004 12:34:58 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVbA-0006l3-00 for rohc@ietf.org; Wed, 18 Feb 2004 12:35:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVaG-0006gY-00 for rohc@ietf.org; Wed, 18 Feb 2004 12:34:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AtVZU-0006d7-00 for rohc@ietf.org; Wed, 18 Feb 2004 12:33:16 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IHXDK01984 for ; Wed, 18 Feb 2004 19:33:13 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Feb 2004 19:33:13 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 09:33:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC context reuse & mode Date: Wed, 18 Feb 2004 12:33:09 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B815368D@ajebe001.americas.nokia.com> Thread-Topic: [rohc] ROHC context reuse & mode Thread-Index: AcP2BZXOBycShdQTRNGiP/4M6cgsogAOPGIQ To: , X-OriginalArrivalTime: 18 Feb 2004 17:33:12.0250 (UTC) FILETIME=[484A21A0:01C3F645] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lars-Erik, It looks there are 4 aspects of this issue (or any other issues for that matter), the last one being the most important. 1) What does the RFC 3095 text say? section 4.4.1: "Compression with ROHC MUST start in the=20 Unidirectional mode." The text is a bit ambiguous, as Kristofer raised the question: does=20 it mean per ROHC context, or per ROHC channel? But I also think our *intension* was "per context", considering we could have different modes for different contexts (may or may not make sense in practice, but = the flexibility is good). On the other hand, this looks unnecessary=20 to me (see below). 2) What's the principle/reason behind the text? If I remember correctly, the main reason to have U-mode was because we might have to run ROHC over links where feedback is not possible. Clearly, this is not the case we are discussing here. We know there are feedback channel if we have already been in bi-directional mode. 3) What's benefit of staying in the same mode? Avoid the overhead of switching from U-mode to Bi-mode for every packet flow. U-mode is not desirable due to its lower compression efficiency=20 and higher chance of loss propagation. So, I expect bi-mode will be mostly used in practice. In fact, I've seen contributions in 3GPP=20 related to concerns about U-mode.=20 4) Does the approach of staying in same mode interoperate? All being said, we still have to make sure the approach interoperates with implementations that assume every context starts from U-mode. If it does not, the story will end here. If it does, I don't see why we cannot clarify the approach in the implementation I-D. So far, I haven't seen it's a problem by my own analysis. BR, Zhigang > -----Original Message----- > From: ext Lars-Erik Jonsson [mailto:larsman@home.se] > Sent: 18 February, 2004 02:44 AM > To: rohc@ietf.org > Cc: Liu Zhigang.C (Nokia-NRC/Dallas) > Subject: RE: [rohc] ROHC context reuse & mode >=20 >=20 >=20 > Zhigang, >=20 > I am not sure there would be any technical problems > with it, but it is indeed a change in principle from > what is stated by 3095, as 3095 clearly says new > contexts must start in U-mode. >=20 > Either way, we should put some clarifying text in the > impl. guide, we just have to agree on what (I'll have > to think some more about this, or let others convince > me on which approach makes most sense). >=20 > /L-E >=20 >=20 > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: den 17 februari 2004 19:31 > > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com > > Cc: rohc@ietf.org > > Subject: RE: [rohc] ROHC context reuse & mode > >=20 > >=20 > > Lars-Erik, > >=20 > > Technically, I don't seen any interoperability problem for the > > compressor to stay in current mode (see my email to Kristofer).=20 > > Do you? > >=20 > > BTW, could you please copy me in the To or CC list when commenting > > on my emails? That makes it easier for me to know you have comments. > > Thanks. > >=20 > > Zhigang > >=20 > > > -----Original Message----- > > > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On=20 > > Behalf Of ext > > > Lars-Erik Jonsson (LU/EAB) > > > Sent: 16 February, 2004 03:05 AM > > > To: kristofer.sandlund@effnet.com > > > Cc: rohc@ietf.org > > > Subject: RE: [rohc] ROHC context reuse & mode > > >=20 > > >=20 > > > > Case 2: start a new flow with a CID that hasn't been=20 > used. Simple. > > > > Start in U-mode as it should be. > > > >=20 > > > > Case 3: start a new flow but reuse CID. This is the sticky case. > > > > Two subcases.=20 > > > >=20 > > > > 3a) If the new flow belongs to a different profile, the=20 > compressor > > > > should start in U-mode as discussed.=20 > > > >=20 > > > > 3b) If same profile, this is actually similar to Case 1 (if=20 > > > you think=20 > > > > hard about it). The only difference is that the=20 > > decompressor didn't > > > > send STATIC-NACK. The compressor can stay in the same=20 > > mode for the=20 > > > > CID (before the new flow), and send all context info in IR=20 > > > > (see Case 1 above). > > >=20 > > > One question is whether this is ok according to 3095?=20 > Personally, I > > > agree with Carsten that when a new context is initialized, it must > > > start in U-mode, and that would also apply to the CID reuse case. > > >=20 > > > /L-E > > >=20 >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 18 13:07:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05666 for ; Wed, 18 Feb 2004 13:07:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW6W-0002z9-A2 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 13:07:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1II7OGw011467 for rohc-archive@odin.ietf.org; Wed, 18 Feb 2004 13:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW6V-0002yk-TE for rohc-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 13:07:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05608 for ; Wed, 18 Feb 2004 13:07:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtW6U-0004fL-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 13:07:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtW5Y-0004VN-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 13:06:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtW4H-0004GP-00 for rohc-web-archive@ietf.org; Wed, 18 Feb 2004 13:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW4I-0002ho-GI; Wed, 18 Feb 2004 13:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW3q-0002dQ-8N for rohc@optimus.ietf.org; Wed, 18 Feb 2004 13:04:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05102 for ; Wed, 18 Feb 2004 13:04:34 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtW3o-00048v-00 for rohc@ietf.org; Wed, 18 Feb 2004 13:04:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtW1Q-0003c7-00 for rohc@ietf.org; Wed, 18 Feb 2004 13:02:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AtVz2-0003Ch-00 for rohc@ietf.org; Wed, 18 Feb 2004 12:59:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IHxdH27411 for ; Wed, 18 Feb 2004 19:59:39 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Feb 2004 19:59:37 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 11:59:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: [rohc] ROHC context reuse & mode Date: Wed, 18 Feb 2004 12:59:26 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B815368E@ajebe001.americas.nokia.com> Thread-Topic: Re: [rohc] ROHC context reuse & mode Thread-Index: AcP2JDFwa79E+tdqRVuUTe9FZmtyawAIm9LQ To: , Cc: X-OriginalArrivalTime: 18 Feb 2004 17:59:27.0907 (UTC) FILETIME=[F3744F30:01C3F648] 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 To be accurate, we should say context ID is reused, not the context (e.g. header field values, parameters, etc). In addition, we can also make a clarification related to this: an IR=20 packet will flush out the decompressor context that exists before=20 receipt of the IR packet. (Note: mode is treated differently than the "normal" context which can be in different states.) BR, Zhigang > -----Original Message----- > From: ext Lars-Erik Jonsson [mailto:larsman@home.se] > Sent: 18 February, 2004 07:32 AM > To: kristofer.sandlund@effnet.com > Cc: rohc@ietf.org; Liu Zhigang.C (Nokia-NRC/Dallas) > Subject: Re: Re: [rohc] ROHC context reuse & mode >=20 >=20 >=20 > OK, >=20 > I can buy that argumentation. So, what we should clarify then is that: > 1) This is what happens when a context is re-used=20 > for a new flow, compressed with the same profile. > 2) If a context is re-used for compression of a new > flow using a different profile, compression is > obviously restarted in U-mode, independent of=20 > previous mode >=20 > Would that be it? > /L-E >=20 >=20 >=20 > Zhigang/L-E, >=20 > I think that Zhigang's scheme of letting mode be inherited=20 > when we have the same=20 > profile seems like the best choice to me. I think this=20 > approach will be more=20 > consistent with the mode transition logic. > If we choose the "always U-mode when new flow" approach, and=20 > a new flow appears=20 > in the middle of a pending mode transition, we would probably=20 > have to specify=20 > that the decompressor must detect that it is a new flow (for example=20 > static-def-diffing as I suggested earlier) and also it should=20 > set D_TRANS=3Ddone &=20 > D_MODE=3DU-mode when we have a new flow (i.e. mode trans must=20 > be restarted). The=20 > inheritance scheme will just complete the mode transition=20 > without having to=20 > understand that it is a new flow. >=20 > I can agree that this is slightly inconsistent with the spec,=20 > but I don't think=20 > it "clearly says new contexts must start in U-mode". All it=20 > says is "Compression=20 > with ROHC MUST start in the Unidirectional mode" (sec.=20 > 4.4.1), which _could_ be=20 > interpreted as being on a per-channel basis. If so, mode=20 > inheritance is=20 > completely ok. >=20 > Rgds, > Kristofer Sandlund, Effnet AB >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 19 04:10:33 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 EAA06622 for ; Thu, 19 Feb 2004 04:10:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtkC4-0006TU-58 for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 04:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J9A32m024870 for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 04:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtkC2-0006T3-BN for rohc-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 04:10:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06580 for ; Thu, 19 Feb 2004 04:09:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtkBz-0006Wu-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 04:09:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtkBA-0006TD-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 04:09:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtkAC-0006Pe-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 04:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtkAC-00066z-FI; Thu, 19 Feb 2004 04:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atk9A-0005vB-Od for rohc@optimus.ietf.org; Thu, 19 Feb 2004 04:07:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06451 for ; Thu, 19 Feb 2004 04:07:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atk97-0006L9-00 for rohc@ietf.org; Thu, 19 Feb 2004 04:07:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atk8B-0006IY-00 for rohc@ietf.org; Thu, 19 Feb 2004 04:06:04 -0500 Received: from smtp1.home.se ([213.214.194.101]) by ietf-mx with esmtp (Exim 4.12) id 1Atk7d-0006G3-00 for rohc@ietf.org; Thu, 19 Feb 2004 04:05:29 -0500 Received: from larsman@home.se [194.237.142.7] by home.se with NetMail ModWeb Module; Thu, 19 Feb 2004 10:02:23 +0100 From: "Lars-Erik Jonsson" To: rohc@ietf.org Date: Thu, 19 Feb 2004 10:02:23 +0100 X-Mailer: NetMail ModWeb Module X-Sender: larsman@home.se MIME-Version: 1.0 Message-ID: <1077181343.ad798060larsman@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [rohc] FW: I-D ACTION:draft-cho-rohc-tcp-interflow-behaviour-00.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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ROHC TCP'ers, Check out this draft on Context Replication. /L-E -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: den 13 februari 2004 22:10 Subject: I-D ACTION:draft-cho-rohc-tcp-interflow-behaviour-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =09Title=09=09: Statistical Inter-flow Field Behaviour for Context Replicat= ion in ROHC-TCP =09Author(s)=09: C. Cho =09Filename=09: draft-cho-rohc-tcp-interflow-behaviour-00.txt =09Pages=09=09: 27 =09Date=09=09: 2004-2-12 =09 Context replication increases header compression gains by reducing=20 the redundancy between flows via efficient replicate (IR-CR) packets.=20 The optimum design of IR-CR packet formats requires elaborate =20 understanding of the inter-flow redundancy. As context replication is=20 most well-suited for TCP, this document presents a statistical=20 analysis of TCP/IP inter-flow field behaviour. Based on the analysis,=20 recommendations on ROHC-TCP packet format specifications for context=20 replication are made. It is also shown that inter-flow field=20 behaviour is inherently and significantly asymmetrical, and various=20 ways of handling it are considered. Finally, based on the inter-flow=20 behaviour of TCP Window field, it is noted that current encoding=20 methods do not compress it efficiently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cho-rohc-tcp-interflow-behaviour-= 00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then =09"get draft-cho-rohc-tcp-interflow-behaviour-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 19 06:28:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14608 for ; Thu, 19 Feb 2004 06:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmLc-0001Bm-Qr for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 06:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JBS4fZ004566 for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 06:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmLc-0001BZ-Hz for rohc-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 06:28:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14552 for ; Thu, 19 Feb 2004 06:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmLY-00070V-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 06:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtmKa-0006va-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 06:27:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtmJc-0006s6-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 06:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmJf-0000aF-K6; Thu, 19 Feb 2004 06:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmIn-0000Yr-67 for rohc@optimus.ietf.org; Thu, 19 Feb 2004 06:25:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14504 for ; Thu, 19 Feb 2004 06:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmIj-0006qI-00 for rohc@ietf.org; Thu, 19 Feb 2004 06:25:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtmHr-0006oP-00 for rohc@ietf.org; Thu, 19 Feb 2004 06:24:12 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AtmHc-0006lY-00 for rohc@ietf.org; Thu, 19 Feb 2004 06:23:56 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1JBNuAh007077 for ; Thu, 19 Feb 2004 12:23:57 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 12:23:56 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Feb 2004 12:23:56 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Thu, 19 Feb 2004 12:23:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 19 Feb 2004 11:23:56.0855 (UTC) FILETIME=[DD0EE470:01C3F6DA] Subject: [rohc] FW: [AVT] Updated RFCs on Copyright and IPR in relation to IETF 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, I'm here forwarding a message from the AVT list, reminding all of you to read and be aware of the content of these drafts. It is useful knowledge to all IETF participants, and especially to those who actively contributes to the work, with drafts or by taking part in discussions. /L-E -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus Westerlund (KI/EAB) Sent: den 19 februari 2004 11:32 To: IETF AVT WG Subject: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Hi, I would like to make all WG participants aware of that 3 RFC has been published that updates your rights in submission to the IETF. I would recommend that you look at them. Reasons why you should look at them are: - RFC 3667 updates what an Internet draft needs to contain, thus it is important that any document editor reads this. - RFC 3667 also regulates what rights you grant with any contribution to the IETF. Please note that as contribution is also counted email to the WG, speaking at the WG meeting. Please read the RFC for authoritative text on this. - RFC 3668 describes what rules that apply for IPR disclosures, thus it applies to any contributing to the IETF. - RFC 3669 contains guidelines for how to handle IPR in the WG. This can be useful reading for people discussing, having or disclosing IPR. See document information, abstract and links below. Cheers Magnus BCP 78 RFC 3667 Title: IETF Rights in Contributions Author(s): S. Bradner Status: Best Current Practice Date: February 2004 Mailbox: sob@harvard.edu Pages: 18 Characters: 43297 SeeAlso: BCP 78 I-D Tag: draft-ietf-ipr-submission-rights-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3667.txt The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. BCP 79 RFC 3668 Title: Intellectual Property Rights in IETF Technology Author(s): S. Bradner Status: Best Current Practice Date: February 2004 Mailbox: sob@harvard.edu Pages: 17 Characters: 41365 SeeAlso: BCP 79 I-D Tag: draft-ietf-ipr-technology-rights-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3668.txt The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. RFC 3669 Title: Guidelines for Working Groups on Intellectual Property Issues Author(s): S. Brim Status: Informational Date: February 2004 Mailbox: sbrim@cisco.com Pages: 17 Characters: 40946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipr-wg-guidelines-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3669.txt This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 19 18:16:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02277 for ; Thu, 19 Feb 2004 18:16:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxOe-0007DN-Rr for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 18:15:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JNFu1I027727 for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 18:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxOe-0007D7-K4 for rohc-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 18:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02221 for ; Thu, 19 Feb 2004 18:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtxOb-0001Dy-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 18:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtxNf-000191-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 18:14:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtxMu-000125-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 18:14:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxMs-0006fW-A7; Thu, 19 Feb 2004 18:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxMf-0006ZS-0t for rohc@optimus.ietf.org; Thu, 19 Feb 2004 18:13:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01936 for ; Thu, 19 Feb 2004 18:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtxMc-0000yk-00 for rohc@ietf.org; Thu, 19 Feb 2004 18:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtxLa-0000p8-00 for rohc@ietf.org; Thu, 19 Feb 2004 18:12:47 -0500 Received: from [216.90.186.146] (helo=mail.ipnetfusion.com) by ietf-mx with esmtp (Exim 4.12) id 1AtxK7-0000Hq-00 for rohc@ietf.org; Thu, 19 Feb 2004 18:11:15 -0500 Received: from ipnetfusion.com (pc131 [192.1.2.131]) (authenticated) by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i1JN9EG07144 for ; Thu, 19 Feb 2004 17:09:14 -0600 Message-ID: <40354254.401@ipnetfusion.com> Date: Thu, 19 Feb 2004 17:10:12 -0600 From: Simran Suri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: multipart/alternative; boundary="------------050906080904070901040307" Subject: [rohc] SigComp implementation Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050906080904070901040307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Does anyone know of an implementation for the DEFLATE compression algorithm using the SIP/SDP dictionary? Also its corresponding UDVM ? Thanks, Simran --------------050906080904070901040307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Does anyone know of an implementation for the DEFLATE compression algorithm using the SIP/SDP dictionary? Also its corresponding UDVM ?

Thanks,
Simran
 --------------050906080904070901040307-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 19 19:27: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 TAA06610 for ; Thu, 19 Feb 2004 19:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyV4-00069e-KJ for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 19:26:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K0QcZ0023652 for rohc-archive@odin.ietf.org; Thu, 19 Feb 2004 19:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyV4-00069P-GF for rohc-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 19:26:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06588 for ; Thu, 19 Feb 2004 19:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyV2-0006sC-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 19:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyUC-0006oH-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 19:25:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtyTY-0006k1-00 for rohc-web-archive@ietf.org; Thu, 19 Feb 2004 19:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyTZ-0005y2-0o; Thu, 19 Feb 2004 19:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyTF-0005qs-6L for rohc@optimus.ietf.org; Thu, 19 Feb 2004 19:24:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06435 for ; Thu, 19 Feb 2004 19:24:41 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyTD-0006h8-00 for rohc@ietf.org; Thu, 19 Feb 2004 19:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtySA-0006Xg-00 for rohc@ietf.org; Thu, 19 Feb 2004 19:23:39 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AtyRZ-0006Pj-00 for rohc@ietf.org; Thu, 19 Feb 2004 19:23:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1K0N1H12340 for ; Fri, 20 Feb 2004 02:23:01 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 20 Feb 2004 02:22:58 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 19 Feb 2004 18:22:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Thu, 19 Feb 2004 19:22:56 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B815369A@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcP1jQkqHIE4zJgnT7iq5OAueLWdxwBs1r+w To: , Cc: , , , , X-OriginalArrivalTime: 20 Feb 2004 00:22:59.0410 (UTC) FILETIME=[B1CAC320:01C3F747] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Looking back in the mirror, the reasons why RFC 3320 became as it is=20 today were: - we assumed no security below sigcomp - NAT prevented a flow-based architecture; so came the state model. Now, looking at SigComp over TCP over secure channel (as we are discussing now), I feel we are really dealing with a special=20 sub-case than the general one we assumed above. So special that=20 I'm wondering if it makes sense to define SigComp version 0x02=20 for this case: - it can utilize the security below sigcomp and the reliability=20 provided by TCP. - it can include support for multiplexing SigComp and non-SigComp=20 messages (people seem to agree at least it is good to have). - based on Version 0x01, with minimal changes. Best of all, the new version number solves the negotiation problem for "continuous mode" and multiplexing. Any comments? BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 23 11:24:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04792 for ; Mon, 23 Feb 2004 11:24:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIsc-0003xU-BL for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 11:24:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NGOQJF015213 for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 11:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIsc-0003xI-2T for rohc-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 11:24:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04770 for ; Mon, 23 Feb 2004 11:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIsa-0002AK-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 11:24:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIrh-00026O-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 11:23:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvIrI-00022O-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 11:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIrG-0003oN-2N; Mon, 23 Feb 2004 11:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIqe-0003nm-Oz for rohc@optimus.ietf.org; Mon, 23 Feb 2004 11:22:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04685 for ; Mon, 23 Feb 2004 11:22:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIqd-000210-00 for rohc@ietf.org; Mon, 23 Feb 2004 11:22:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIpg-0001xS-00 for rohc@ietf.org; Mon, 23 Feb 2004 11:21:24 -0500 Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx with esmtp (Exim 4.12) id 1AvIpM-0001ts-00 for rohc@ietf.org; Mon, 23 Feb 2004 11:21:04 -0500 Received: from oleane.com (cust1.clb.oleane.net [213.56.31.97]) (authenticated) by smtp1.clb.oleane.net with ESMTP id i1NGKXd8031850 for ; Mon, 23 Feb 2004 17:20:33 +0100 Date: Mon, 23 Feb 2004 17:20:33 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "=?iso-8859-1?Q?Martin?=" To: "=?iso-8859-1?Q?rohc?=" X-XaM3-API-Version: 3.2 R32 (B53pl7) X-type: 0 X-SenderIP: 194.206.151.59 Content-Transfer-Encoding: quoted-printable Subject: [rohc] =?iso-8859-1?Q?WiMAX_Summit?= 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 WiMAX is considered the next step beyond WiFi because it is optimized for= =0D=0Abroadband operation, fixed and later mobile. The WiMAX Summit, to = be organised =0D=0Ain Paris next May 25-28, will gather the most distingu= ished experts and key =0D=0Aplayers in the field.=0D=0A=95 Are WiMAX and = WiFi complementary?=0D=0A=95 When and how will WiMAX evolve towards mobil= ity? =0D=0A=95 Can WiMAX be considered as a migration path to 4G? =0D=0A=95= How is addressed the interoperability challenge? =0D=0AThese questions, = among others, will be addressed during the event.=0D=0A =0D=0AMore detail= s at:=0D=0Ahttp://www.upperside.fr/wimax04/wimax04intro.htm=0D=0A _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 23 12:12:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06410 for ; Mon, 23 Feb 2004 12:12:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJcB-0007bI-QB for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 12:11:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHBVwA029208 for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 12:11:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJcB-0007b1-Hf for rohc-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:11:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06397 for ; Mon, 23 Feb 2004 12:11:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJcA-0005rg-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 12:11:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJb9-0005mZ-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 12:10:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvJaj-0005ib-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 12:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJak-0007Vt-8K; Mon, 23 Feb 2004 12:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJa8-0007Ro-R5 for rohc@optimus.ietf.org; Mon, 23 Feb 2004 12:09:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06324 for ; Mon, 23 Feb 2004 12:09:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJa7-0005hU-00 for rohc@ietf.org; Mon, 23 Feb 2004 12:09:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJZJ-0005e2-00 for rohc@ietf.org; Mon, 23 Feb 2004 12:08:34 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AvJYe-0005Vg-00 for rohc@ietf.org; Mon, 23 Feb 2004 12:07:52 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMJ4FN>; Mon, 23 Feb 2004 17:07:21 -0000 Message-ID: From: "Price, Richard" To: "'Pekka Pessi'" , "Surtees, Abigail" Cc: "'Jan Christoffersson (LU/EAB)'" , "West, Mark" , Robert.Sugar@nokia.com, zhigang.c.liu@nokia.com, "Lars-Erik Jonsson (LU/EAB)" , rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Mon, 23 Feb 2004 17:07:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , 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 > Surtees, Abigail writes: > >Slightly belatedly, a response about continuous mode. The main question is > >what is the consensus about what 'continuous mode' actually means? I think > >there are at least two interpretations. (I also suggest that when we reach > >consensus, it should be put into the implementer's guide.) > > Even later.. Even later still... > ... > >Interpretation 1: > > >An endpoint can open a UDVM on receipt of part of a SigComp message over TCP > >and leave it open until the rest of the message is received. Consequently, > >the endpoint has to be able to cope with multiple UDVMs running, but other > >than that everything works in the same way as normal. In what way is the > >security risk any greater when using this interpretation of continuous mode > >than when buffering the message first? > > I gather that the risk is the DoS attack by multiple concurrent > UDVMs? Does not sound very grave; UDVM looks like a (small) piece > of memory. I think it should be an implementation choice whether to buffer the SigComp message before decompressing, because the security implications are minimal. This is different from what we mean by "continuous mode". Continuous mode is a special mode of operation for SigComp, which can only be used given prior agreement by the two endpoints. Unlike for vanilla SigComp, in continuous mode there is no 1-1 mapping between SigComp messages and SIP messages. A single SigComp message might contain any number of SIP messages (even fragments of SIP messages). Continuous mode cannot use the decompressed SIP messages for authentication, so it needs additional security to be provided by the lower layer (e.g. TLS). > >The 64k uncompressed message limit is to provide security against > >"generating huge messages to muck up the SIP stack" attacks. If the extra > >security mechanisms that make continuous mode safe to use can also prevent > >this attack, then isn't it safe to drop the message limit? > > I'd say so. Yes, with one small caveat (see below). Continuous mode treats the uncompressed data as a stream, without caring about the boundaries between SIP messages. So it's ok for the decompressed data to contain a single, huge SIP message of more than 64k. The caveat is that it's still important for each decompressed *SigComp* message to contain no more than 64k of data. This is a vital mechanism for protecting the UDVM against broken SigComp messages which cause the UDVM to output data continually - we can't rely on the lower-layer security to protect against broken compressors ;-) However, as continuous mode lets us break a single SIP message up into more than one SigComp message, the 64k limit does not prevent us from compressing really big SIP messages. They just need to be split up into multiple SigComp messages first. > >Then the whole SIP flow can be compressed by one SigComp message and > >delivered in small chunks without a message limit size problem. > > >Which (if either) interpretation have other people assumed, or is there > >another interpretation we haven't considered? > > I initially assumed interpretation 2; then when I started checking > for the 64 kB limit (it really makes your life complicated ;), I > started using interpretation 1. Interpretation 2 is what we meant by "continuous mode" when we were writing the RFC. > >On the issue of whether or not use of continuous mode could solve the issue > >of multiplexing on a TCP connection, I think that if interpretation 1 is the > >consensus, then as Jan said there are still problems and continuous mode is > >not the solution. However, if interpretation 2 is the consensus, then as > >Mark suggested continuous mode could be used (allowable because of the > >security provided by IPsec) and then there is no need for multiplexing. > > It is also possible to send a large SIP message using multiple > SigComp messages. Of course, this would mean that the SigComp > application (SIP stack) must accept/reject the SigComp message > before entire SIP message has been decompressed. Yes, which is why we can't do it with vanilla SigComp. However, it's ok to do this with continuous mode, because there's extra security at the lower layer. > OK, this violates assumptions behind the SigComp security model, > but, SIP cannot provide any kind of upper layer security for > SigComp unless *extremely* costly and/or underspecified S/MIME > tunneling is used. (There has been things like > draft-undery-sip-auth-01.txt under works, but they have expired > long time ago.) SigComp security model simply does not work with > current SIP. The SigComp security model doesn't assume that security is provided by the upper layer. SigComp works equally well if security is provided by the lower layer (in fact, it works even better, because you can use continuous mode and compress SIP messages more than 64k long). > So, who cares about yet another invalidated assumption as long as > you have a reasonable underlying security (IPSec, TLS)? Well, this is what continuous mode is for ;-) As stated in RFC 3320: "continuous mode" invalidates some assumptions of the SigComp security model and can only be used if the transport itself can provide the required protection against denial of service attacks." > (Of course, there are other things in SigComp that does not work > with SIP, like the compression association and compartments, but I > rant about them some other time.) Look forward to hearing about them... Regards, Richard > --Pekka > > _______________________________________________ > 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 Feb 23 12:31:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07790 for ; Mon, 23 Feb 2004 12:31:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJvR-0001NG-Ss for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 12:31:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHVPZK005276 for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 12:31:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJvR-0001N1-O8 for rohc-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:31:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07782 for ; Mon, 23 Feb 2004 12:31:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJvQ-0000OX-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 12:31:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJuV-0000KF-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 12:30:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvJu5-0000GO-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 12:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJu5-00014n-LI; Mon, 23 Feb 2004 12:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJtO-00012J-T9 for rohc@optimus.ietf.org; Mon, 23 Feb 2004 12:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07705 for ; Mon, 23 Feb 2004 12:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJtN-0000Dn-00 for rohc@ietf.org; Mon, 23 Feb 2004 12:29:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJsT-00009Z-00 for rohc@ietf.org; Mon, 23 Feb 2004 12:28:22 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AvJrX-00000l-00 for rohc@ietf.org; Mon, 23 Feb 2004 12:27:23 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGN1M67>; Mon, 23 Feb 2004 17:26:47 -0000 Message-ID: From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , Pekka.Pessi@nokia.com, "Surtees, Abigail" Cc: jan.christoffersson@ericsson.com, "West, Mark" , Robert.Sugar@nokia.com, lars-erik.jonsson@ericsson.com, rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Mon, 23 Feb 2004 17:26:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , 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, > > Looking back in the mirror, the reasons why RFC 3320 became as it is > today were: > - we assumed no security below sigcomp More precisely, we assumed that security below SigComp was not mandatory. SigComp Version 0x01 will certainly run in the presence of lower-layer security, but not optimally. > - NAT prevented a flow-based architecture; so came the state model. > > Now, looking at SigComp over TCP over secure channel (as we are > discussing now), I feel we are really dealing with a special > sub-case than the general one we assumed above. So special that > I'm wondering if it makes sense to define SigComp version 0x02 > for this case: > > - it can utilize the security below sigcomp and the reliability > provided by TCP. > > - it can include support for multiplexing SigComp and non-SigComp > messages (people seem to agree at least it is good to have). > > - based on Version 0x01, with minimal changes. > > Best of all, the new version number solves the negotiation problem > for "continuous mode" and multiplexing. Another advantage, which follows from having continuous mode: - Overcomes the 64k limit for application messages. > Any comments? This is a good suggestion for how to improve SigComp performance if we have lower-layer security. I'd be interested to know if this is just a nice-to-have, or is there anything sufficiently broken about running SigComp Version 0x01 over lower-layer security to make a Version 0x02 a must? Regards, Richard > BR, > Zhigang > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 23 18:51:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03450 for ; Mon, 23 Feb 2004 18:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPqq-0003ZF-Kr for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 18:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NNp4X4013707 for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 18:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPqq-0003Z0-Fz for rohc-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 18:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03432 for ; Mon, 23 Feb 2004 18:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPqn-0005EA-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 18:51:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPpp-00056G-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 18:50:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvPoq-0004xz-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 18:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPoq-0003QV-KM; Mon, 23 Feb 2004 18:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvPoV-0003Py-Vt for rohc@optimus.ietf.org; Mon, 23 Feb 2004 18:48:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03309 for ; Mon, 23 Feb 2004 18:48:34 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPoS-0004vt-00 for rohc@ietf.org; Mon, 23 Feb 2004 18:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPnW-0004rl-00 for rohc@ietf.org; Mon, 23 Feb 2004 18:47:39 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AvPn2-0004no-00 for rohc@ietf.org; Mon, 23 Feb 2004 18:47:09 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NNkvH02657; Tue, 24 Feb 2004 01:46:57 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 01:46:56 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1NNku3C005062; Tue, 24 Feb 2004 01:46:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00XiBYO4; Tue, 24 Feb 2004 01:46:55 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NNknO29105; Tue, 24 Feb 2004 01:46:49 +0200 (EET) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 17:46:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Mon, 23 Feb 2004 18:46:45 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B81536A2@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcP6MoWywmaZieS0SXq7efr6u9cLuQAMPDNQ To: , , Cc: , , , , X-OriginalArrivalTime: 23 Feb 2004 23:46:48.0047 (UTC) FILETIME=[4D360FF0:01C3FA67] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Richard, It looks now you have more time working/talking on SigComp. :-) Please see my comments inline. Zhigang > > Looking back in the mirror, the reasons why RFC 3320 became as it is = > > today were: > > - we assumed no security below sigcomp >=20 > More precisely, we assumed that security below SigComp was not > mandatory. SigComp Version 0x01 will certainly run in the presence > of lower-layer security, but not optimally. Agree. (I was too terse above.) =20 > > Best of all, the new version number solves the negotiation problem > > for "continuous mode" and multiplexing. >=20 > Another advantage, which follows from having continuous mode: >=20 > - Overcomes the 64k limit for application messages. Right. =20 > > Any comments? >=20 > This is a good suggestion for how to improve SigComp performance > if we have lower-layer security. >=20 > I'd be interested to know if this is just a nice-to-have, or is > there anything sufficiently broken about running SigComp Version > 0x01 over lower-layer security to make a Version 0x02 a must? I wouldn't say SigComp Version 0x01 is broken. But a version 0x02 including continuous mode and multiplexing over TCP would be really useful, for the advantages we have discussed (rid of 64KB limit, using less TCP connections and IPsec SAs, etc.). That's particularly=20 the case for 3GPP. Also, I remember the goal of RFC 3320 was to be as generic as possible. Time pressure to deliver SigComp was another factor. However, we didn't=20 exclude the possibility of having a special variance for the case of=20 security-at-lower-layer (I vaguely recall we had some discussions about this during the development of RFC 3320). _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Feb 23 19:31:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04776 for ; Mon, 23 Feb 2004 19:31:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQTA-0005Bl-FH for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 19:30:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O0UeT8019939 for rohc-archive@odin.ietf.org; Mon, 23 Feb 2004 19:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQTA-0005BW-Au for rohc-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 19:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04765 for ; Mon, 23 Feb 2004 19:30:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQT8-0000FX-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 19:30:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQSC-0000B5-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 19:29:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvQRY-00006g-00 for rohc-web-archive@ietf.org; Mon, 23 Feb 2004 19:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQRZ-00057h-I0; Mon, 23 Feb 2004 19:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQRE-00056c-8e for rohc@optimus.ietf.org; Mon, 23 Feb 2004 19:28:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04724 for ; Mon, 23 Feb 2004 19:28:38 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQRC-00005p-00 for rohc@ietf.org; Mon, 23 Feb 2004 19:28:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQQG-00001Q-00 for rohc@ietf.org; Mon, 23 Feb 2004 19:27:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AvQPc-0007kz-00 for rohc@ietf.org; Mon, 23 Feb 2004 19:27:00 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1O0QwH03250; Tue, 24 Feb 2004 02:26:58 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 02:26:55 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1O0QtWL004511; Tue, 24 Feb 2004 02:26:55 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00pZYMM9; Tue, 24 Feb 2004 02:26:53 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1O0QqO09475; Tue, 24 Feb 2004 02:26:52 +0200 (EET) Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 18:26:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Mon, 23 Feb 2004 19:26:49 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B81536A5@ajebe001.americas.nokia.com> Thread-Topic: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Thread-Index: AcP1jQkqHIE4zJgnT7iq5OAueLWdxwE22WEw To: , Cc: , , , , X-OriginalArrivalTime: 24 Feb 2004 00:26:51.0178 (UTC) FILETIME=[E596C0A0:01C3FA6C] Content-Transfer-Encoding: quoted-printable Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pekka, > OK, this violates assumptions behind the SigComp security model, > but, SIP cannot provide any kind of upper layer security for > SigComp unless *extremely* costly and/or underspecified S/MIME > tunneling is used. (There has been things like > draft-undery-sip-auth-01.txt under works, but they have expired > long time ago.)=20 Interesting. This raise a general question in my mind: let's forget=20 about SigComp for a moment, does this mean people basically give up=20 security at SIP layer, but instead rely on security at lower layer (e.g. IPsec and TLS)? > SigComp security model simply does not work with > current SIP.=20 Well, SigComp actually does not require security at application layer. (see text below from "Security Considerations"). No security at=20 application layer can be viewed as a special case. The overall security goal of the SigComp architecture is to not create risks that are in addition to those already present in the application protocols. > So, who cares about yet another invalidated > assumption as long as you have a reasonable underlying security > (IPSec, TLS)? I agree that having IPsec/TLS simplifies a lot of things. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Feb 24 12:28:33 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 MAA00359 for ; Tue, 24 Feb 2004 12:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgLl-0000EY-DD for rohc-archive@odin.ietf.org; Tue, 24 Feb 2004 12:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OHS5ZF000892 for rohc-archive@odin.ietf.org; Tue, 24 Feb 2004 12:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgLl-0000EJ-3I for rohc-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 12:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00316 for ; Tue, 24 Feb 2004 12:28:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgLj-00058a-00 for rohc-web-archive@ietf.org; Tue, 24 Feb 2004 12:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgKk-000530-00 for rohc-web-archive@ietf.org; Tue, 24 Feb 2004 12:27:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvgJm-0004wB-00 for rohc-web-archive@ietf.org; Tue, 24 Feb 2004 12:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgJl-00006K-Bb; Tue, 24 Feb 2004 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgIv-0008Uq-Hr for rohc@optimus.ietf.org; Tue, 24 Feb 2004 12:25:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00265 for ; Tue, 24 Feb 2004 12:25:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgIu-0004qr-00 for rohc@ietf.org; Tue, 24 Feb 2004 12:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgI0-0004jS-00 for rohc@ietf.org; Tue, 24 Feb 2004 12:24:13 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AvgHR-0004YH-00 for rohc@ietf.org; Tue, 24 Feb 2004 12:23:37 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMJ89Z>; Tue, 24 Feb 2004 17:22:57 -0000 Message-ID: From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , Pekka.Pessi@nokia.com, "Surtees, Abigail" Cc: jan.christoffersson@ericsson.com, "West, Mark" , Robert.Sugar@nokia.com, lars-erik.jonsson@ericsson.com, rohc@ietf.org Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection Date: Tue, 24 Feb 2004 17:23:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , 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 Richard, > > It looks now you have more time working/talking on SigComp. :-) Not as much as I'd like ;-) I can probably make some time to help out with any updates for SigComp, if the WG concludes that there's a pressing need to improve the support for lower-layer security. Anyone else got an opinion on this? Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 25 04:28:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05600 for ; Wed, 25 Feb 2004 04:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvL2-00054l-DI for rohc-archive@odin.ietf.org; Wed, 25 Feb 2004 04:28:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9SKhS019500 for rohc-archive@odin.ietf.org; Wed, 25 Feb 2004 04:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvL1-00054R-Ht for rohc-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 04:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05474 for ; Wed, 25 Feb 2004 04:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvKy-0006F9-00 for rohc-web-archive@ietf.org; Wed, 25 Feb 2004 04:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvJA-0005op-00 for rohc-web-archive@ietf.org; Wed, 25 Feb 2004 04:26:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvvHH-0005Nu-00 for rohc-web-archive@ietf.org; Wed, 25 Feb 2004 04:24:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvHJ-00042Q-6X; Wed, 25 Feb 2004 04:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvpLY-0003qy-5x for rohc@optimus.ietf.org; Tue, 24 Feb 2004 22:04:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23762 for ; Tue, 24 Feb 2004 22:04:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvpLV-0000iK-00 for rohc@ietf.org; Tue, 24 Feb 2004 22:04:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvpKa-0000d4-00 for rohc@ietf.org; Tue, 24 Feb 2004 22:03:29 -0500 Received: from [216.90.186.146] (helo=mail.ipnetfusion.com) by ietf-mx with esmtp (Exim 4.12) id 1AvpJi-0000Ha-00 for rohc@ietf.org; Tue, 24 Feb 2004 22:02:35 -0500 Received: from ipnetfusion.com (pc131 [192.1.2.131]) (authenticated) by mail.ipnetfusion.com (8.11.6/8.11.6) with ESMTP id i1P2wcG30890; Tue, 24 Feb 2004 20:58:38 -0600 Message-ID: <403C0F9B.6000109@ipnetfusion.com> Date: Tue, 24 Feb 2004 20:59:39 -0600 From: Simran Suri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Price, Richard" CC: "'zhigang.c.liu@nokia.com'" , Pekka.Pessi@nokia.com, "Surtees, Abigail" , jan.christoffersson@ericsson.com, "West, Mark" , Robert.Sugar@nokia.com, lars-erik.jonsson@ericsson.com, rohc@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070602000601030809090104" Subject: [rohc] SigComp assembler and interpreter ? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070602000601030809090104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, I am working on providing an implementation (compression/decompression) for the SigComp specification, but am not making much headway. I would really welcome it if any of you can provide help/pointers with the following: 1. Does anyone have experience providing an end-to-end SigComp implementation? If so, are there any documents which provide information regarding the same? 2. Has there been any addition to the UDVM assembler/interpreter since March 2002? Specifically, has the implementation expanded to work with all the instructions in the UDVM instruction set? Also does anyone have any programming experience with the UDVM instruction set that can be shared? 3. I tried out the examples posted by Carsten and these worked perfectly. However, can anyone tell me how we got the compressed message in the first place? It doesn't seem that DEFLATE was used to generate the message, since I used the zlib shared library (which uses DEFLATE) on the uncompressed message and got a different message. There is some mnemonic code posted by Richard, but I'm guessing it's for compression not decompression- please correct me if I'm wrong. 4. Has anyone provided an implementation of the compression/decompression algorithms which use predefined dictionaries, for example the SIP/SDP dictionary? Looking forward to hear from someone. Thanks and regards, Simran --------------070602000601030809090104 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

I am working on providing an implementation (compression/decompression) for the SigComp specification, but am not making much headway. I would really welcome it if any of you can provide help/pointers with the following:

1. Does anyone have experience providing an end-to-end SigComp implementation? If so, are there any documents which provide information regarding the same?

2. Has there been any addition to the UDVM assembler/interpreter since March 2002? Specifically, has the implementation expanded to work with all the instructions in the UDVM instruction set? Also does anyone have any programming experience with the UDVM instruction set that can be shared?

3. I tried out the examples posted by Carsten and these worked perfectly. However, can anyone tell me how we got the compressed message in the first place? It doesn't seem that DEFLATE was used to generate the message, since I used the zlib shared library (which uses DEFLATE) on the uncompressed message and got a different message. There is some mnemonic code posted by Richard, but I'm guessing it's for compression not decompression- please correct me if I'm wrong.

4. Has anyone provided an implementation of the compression/decompression algorithms which use predefined dictionaries, for example the SIP/SDP dictionary?

Looking forward to hear from someone.

Thanks and regards,
Simran


 --------------070602000601030809090104-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Feb 25 09:34: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 JAA18055 for ; Wed, 25 Feb 2004 09:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw06r-0005kg-Q6 for rohc-archive@odin.ietf.org; Wed, 25 Feb 2004 09:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEY1w6022106 for rohc-archive@odin.ietf.org; Wed, 25 Feb 2004 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw06r-0005kQ-BH for rohc-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:34:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18024 for ; Wed, 25 Feb 2004 09:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw06p-0005hq-00 for rohc-web-archive@ietf.org; Wed, 25 Feb 2004 09:33:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw05o-0005Zh-00 for rohc-web-archive@ietf.org; Wed, 25 Feb 2004 09:32:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw04t-0005Tz-00 for rohc-web-archive@ietf.org; Wed, 25 Feb 2004 09:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw04u-0005LB-76; Wed, 25 Feb 2004 09:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw04g-0005IE-PT for rohc@optimus.ietf.org; Wed, 25 Feb 2004 09:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17884 for ; Wed, 25 Feb 2004 09:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw04e-0005Rc-00 for rohc@ietf.org; Wed, 25 Feb 2004 09:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw03i-0005LS-00 for rohc@ietf.org; Wed, 25 Feb 2004 09:30:46 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw02p-0005BY-00 for rohc@ietf.org; Wed, 25 Feb 2004 09:29:52 -0500 Received: from jaspreetcl5101 (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 <0HTN008G99HOZM@mta0.huawei.com> for rohc@ietf.org; Wed, 25 Feb 2004 22:27:30 +0800 (CST) Date: Wed, 25 Feb 2004 20:05:44 +0530 From: Jaspreet Singh To: rohc@ietf.org Message-id: <004b01c3fbac$a9543280$3405120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/alternative; boundary="Boundary_(ID_KxMJWd0zxbZhXaBhOBEX0g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [rohc] SIP and SigComp Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_KxMJWd0zxbZhXaBhOBEX0g) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, Is there any recommended compression algorithm for compressing SIP using sigcomp ? Can someone please point me to a web resource which analyses how different compression algorithms perform when used along with sigcomp for compressing SIP. Cheers, Jaspreet --Boundary_(ID_KxMJWd0zxbZhXaBhOBEX0g) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,
 
Is there any recommended compression algorithm for compressing SIP using sigcomp ?
 
Can someone please point me to a web resource which analyses how different compression algorithms perform when used along with sigcomp for compressing SIP.
 
Cheers,
Jaspreet
 
--Boundary_(ID_KxMJWd0zxbZhXaBhOBEX0g)-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 26 08:34: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 IAA11666 for ; Thu, 26 Feb 2004 08:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeH-0003pj-UT for rohc-archive@odin.ietf.org; Thu, 26 Feb 2004 08:33:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QDXvBB014725 for rohc-archive@odin.ietf.org; Thu, 26 Feb 2004 08:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLeH-0003pQ-3f for rohc-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 08:33:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11493 for ; Thu, 26 Feb 2004 08:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLeF-0000nU-00 for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 08:33:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLby-0000In-00 for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 08:31:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwLb5-0000DV-01 for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 08:30:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwLZZ-0004zU-De for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 08:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLZV-0003Pm-I9; Thu, 26 Feb 2004 08:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvxC-0000bb-6p for rohc@optimus.ietf.org; Wed, 25 Feb 2004 05:07:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07935 for ; Wed, 25 Feb 2004 05:07:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avvx8-0003LI-00 for rohc@ietf.org; Wed, 25 Feb 2004 05:07:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvwG-0003Ea-00 for rohc@ietf.org; Wed, 25 Feb 2004 05:06:48 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AvvvX-00039o-00 for rohc@ietf.org; Wed, 25 Feb 2004 05:06:04 -0500 Received: from [IPv6:::1] (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.11/8.12.9) with ESMTP id i1PA5i0H008168; Wed, 25 Feb 2004 11:05:48 +0100 (MET) In-Reply-To: <403C0F9B.6000109@ipnetfusion.com> References: <403C0F9B.6000109@ipnetfusion.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C5B6BE7-677A-11D8-B322-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit Cc: "Price, Richard" , Robert.Sugar@nokia.com, lars-erik.jonsson@ericsson.com, "'zhigang.c.liu@nokia.com'" , Pekka.Pessi@nokia.com, Carsten Bormann , "West, Mark" , jan.christoffersson@ericsson.com, rohc@ietf.org, "Surtees, Abigail" From: Carsten Bormann Subject: Re: [rohc] SigComp assembler and interpreter ? Date: Wed, 25 Feb 2004 11:05:43 +0100 To: Simran Suri X-Mailer: Apple Mail (2.612) 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 Simran, > 2. Has there been any addition to the UDVM assembler/interpreter since > March 2002? Specifically, has the implementation expanded to work with > all the instructions in the UDVM instruction set? Also does anyone > have any programming experience with the UDVM instruction set that can > be shared? Does "the UDVM assembler/interpreter" refer to my half-baked implementation of the -05 draft? I haven't got around to work on this implementation to upgrade it with respect to the changes we made on the way to RFC3320 and the revised assembler syntax we agreed on for the implementers guide. > 3. I tried out the examples posted by Carsten and these worked > perfectly. However, can anyone tell me how we got the compressed > message in the first place? A UDVM implementation is not a complete SigComp implementation. In addition you need: -- an interface to the higher layer protocol (e.g., SIP) -- a state manager -- a portfolio (>= 1) of compression algorithm implementations, and -- UDVM code to send to the decompressor for each of these. Clearly, these are significant pieces of work, some of which also have interesting IPR complications. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Feb 26 12:08:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25028 for ; Thu, 26 Feb 2004 12:08:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOz6-0007B7-St for rohc-archive@odin.ietf.org; Thu, 26 Feb 2004 12:07:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QH7eXk027586 for rohc-archive@odin.ietf.org; Thu, 26 Feb 2004 12:07:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOz6-0007An-1r for rohc-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 12:07:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25005 for ; Thu, 26 Feb 2004 12:07:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOz4-0002Ke-00 for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 12:07:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOyE-0002GL-00 for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 12:06:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwOxU-0002BS-00 for rohc-web-archive@ietf.org; Thu, 26 Feb 2004 12:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOxV-0006qw-3I; Thu, 26 Feb 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOxF-0006os-Cm for rohc@optimus.ietf.org; Thu, 26 Feb 2004 12:05:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24913 for ; Thu, 26 Feb 2004 12:05:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOxD-00029e-00 for rohc@ietf.org; Thu, 26 Feb 2004 12:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOwI-00023r-00 for rohc@ietf.org; Thu, 26 Feb 2004 12:04:46 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx with esmtp (Exim 4.12) id 1AwOvq-0001yp-00 for rohc@ietf.org; Thu, 26 Feb 2004 12:04:18 -0500 Received: from sfo.somewhere.de (pD9E7EC4A.dip.t-dialin.net [217.231.236.74]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i1QH4Gd14225 for ; Thu, 26 Feb 2004 18:04:17 +0100 (MET) Date: Thu, 26 Feb 2004 18:04:12 +0100 From: Stefan Foeckel Reply-To: Stefan Foeckel Organization: Fraunhofer Institut Fokus, Deutschland X-Priority: 3 (Normal) Message-ID: <171769045.20040226180412@fokus.fraunhofer.de> To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] SigComp state_length 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,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I need some clarification about the state_length value in the STATE_CREATE instruction of the UDVM. The spec. says, its a 2-byte value ranging from 0..65535. Regarding this, how do I save the memory of a 65536-byte UDVM as state ? What is supposed to happen on state_length = 0 ? Regards Stefan _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Feb 27 11:15:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11013 for ; Fri, 27 Feb 2004 11:15:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkdZ-00032Z-AQ for rohc-archive@odin.ietf.org; Fri, 27 Feb 2004 11:14:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RGErXn011681 for rohc-archive@odin.ietf.org; Fri, 27 Feb 2004 11:14:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkdZ-00032K-5y for rohc-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 11:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10980 for ; Fri, 27 Feb 2004 11:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkdY-0002Hw-00 for rohc-web-archive@ietf.org; Fri, 27 Feb 2004 11:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkcT-000268-00 for rohc-web-archive@ietf.org; Fri, 27 Feb 2004 11:13:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awkbk-0001xX-00 for rohc-web-archive@ietf.org; Fri, 27 Feb 2004 11:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awkbj-0002qq-9f; Fri, 27 Feb 2004 11:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkbE-0002og-28 for rohc@optimus.ietf.org; Fri, 27 Feb 2004 11:12:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10780 for ; Fri, 27 Feb 2004 11:12:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkbD-0001ts-00 for rohc@ietf.org; Fri, 27 Feb 2004 11:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkaE-0001ms-00 for rohc@ietf.org; Fri, 27 Feb 2004 11:11:27 -0500 Received: from bay12-f115.bay12.hotmail.com ([64.4.35.115] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AwkZd-0001cN-00 for rohc@ietf.org; Fri, 27 Feb 2004 11:10:49 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 Feb 2004 07:46:21 -0800 Received: from 62.254.246.40 by by12fd.bay12.hotmail.msn.com with HTTP; Fri, 27 Feb 2004 15:46:21 GMT X-Originating-IP: [62.254.246.40] X-Originating-Email: [ellyptic@hotmail.com] X-Sender: ellyptic@hotmail.com From: "Richard Price" To: stefan.foeckel@fokus.fraunhofer.de, rohc@ietf.org Subject: RE: [rohc] SigComp state_length Date: Fri, 27 Feb 2004 15:46:21 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Feb 2004 15:46:21.0896 (UTC) FILETIME=[D9237C80:01C3FD48] 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 Stefan, As you've correctly understood from RFC 3320, it's not possible to save the entire contents of a 65536-byte UDVM as a state item. This is fine, however, because the first 32 bytes of UDVM memory are reserved for special values such as the available cycles per bit (see Figure 5: Initializing Useful Values in UDVM memory). These values are updated on a per-message basis, so there's no need to save them as part of the state. Regards, Richard Price >From: Stefan Foeckel >Reply-To: Stefan Foeckel >To: rohc@ietf.org >Subject: [rohc] SigComp state_length >Date: Thu, 26 Feb 2004 18:04:12 +0100 > >Hello, > >I need some clarification about the state_length value in the >STATE_CREATE instruction of the UDVM. The spec. says, its a >2-byte value ranging from 0..65535. Regarding this, how do I >save the memory of a 65536-byte UDVM as state ? What is supposed >to happen on state_length = 0 ? > >Regards >Stefan > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc